[Race Coordinator]

My recommendation would be to put a "WITH_R4" define in the sketch. That way we can turn it on/off. This new define would replace the current reset code (watchdog and asm code) with what he has above. If that's done, and somebody verifies it, I'd include it in the next RC release for anybody to use.

Does R4 have built in BT? If it does, that would be nice to support at some point so BT users don't need the addon board. Someday when I retire I'd like support the wifi on the board as well. I assume it has wireless, in which case it would be really cool to have another wireless option. I suspect wireless support wouldn't be hard, but it will require both sketch changes to configure and send the data over wifi, and changes to RC to support it...

 

[Race Coordinator]

Oooooh. The R4 has a HID interface which means if supported, no more virtual serial port. We could auto-detect the board and no more driver installs would be required.

And the wifi version has built in BT which makes that a lot easier for end users (no more daughter board and having to flash/deal with it). Interesting, I'd likely not need to support wifi with the built in BT. Except maybe to support old PCs with a network card but no BT.

I wonder how many win10 (and newer) PCs have BT and how many do not?

 

[Slingshotx]

Could use the boards.txt defined I e.

ARDUINO_UNOR4_WIFI ||
ARDUINO_UNOR4_MINIMA

And esp32 is I think ESP32 for all variations.

R4 has a daughter esp32 for WiFi and BT.

The esp32 is a much smaller form factor and would fit under even plastic track.

 

[BigBadBuzz]

I've replaced the jmp 0 instruction with @Slingshotx 's suggestion and replaced #include avr/wdt.h with #include <WDT.h> as suggested in the Arduino IDE's UNO R4 example code. The modified sketch does verify but gives this warning:

WARNING: library WDT claims to run on renesas architecture(s) and may be incompatible with your current board which runs on renesas_uno architecture(s).​

Odd, since I used the WDT header file they suggested. Anyway, I've been able to upload this modified sketch to the UNO R4 WiFi. Doing so did wipe out the display of the heart on the spiff little 12x8 LED matrix. Looking around on the web last night, I did see that there is a library available to futz around with the little matrix display, so just for fun here ya go.

I'll try to hook up the R4 later today and see if it can successfully talk to RC.

Regards,
BBB

 

[Slingshotx]

If you commented out //#define WITH_WATCH_DOG, and used NVIC_SystemReset() you shouldn't need WDT.h at all. I think it's only needed for the watchdog code.

If it works and Dave doesn't have time I'll do a version of the sketch that should work on all 3 platforms R3, R4 and my favourite ESP32.
I may even try do a BT version that will connect to RC without additional boards.

 

[BigBadBuzz]

I was trying to see if I could get new watchdog timer code working - obviously not. I’ll try just commenting out the watchdog next.

 

[Race Coordinator]

I definitely won't get to it anytime soon. Work is busy, I may have to start my track build all over again due to some serious mistakes that may be easier to do over than to fix, and honestly my motivation is incredibly low right now. Oh and I don't have the board on hand so I'd have to buy one.

 

[BigBadBuzz]

Sorry about your track; I’ve been reworking mine for far longer than I would care to admit.

As @Slingshotx mentioned earlier, once it is determined what is needed to make an Uno R4 work with RC, instructions on modifying the sketch could be “unofficial“ until / if you decide to add the support…

Regards,
BBB

 

[BigBadBuzz]

Well, I stripped out the new watchdog code I took a (very weak) shot at, commented out #define WITH_WATCH_DOG, and added NVIC_SystemReset(). The code compiles and uploads. but when I then fire up RC and go to Expert Track Setup, the connection light in the "Manage Arduino" screen never goes green. Any other suggestions on things to try?

BBB

 

[BigBadBuzz]

I added some debug code at various points - sending various 2-char text codes to the R4WiFi’s LED matrix. Never saw anything change. So as best as I can tell, RC is indeed not communicating with the Arduino. I don’t know how to use a serial debug setup with the Arduino.
BBB

 

[Race Coordinator]

If you bring up the serial debugger in the arduino IDE and set it to 11500 baud. If you set the baud rate correctly you should see a constant stream if what looks like gibberish showing in the terminal. Then if you type "RESET;" (no double quotes but include the semicolan and use all caps) into the command line and pressing enter you should see a "V" pop up into that stream.

Try this first with an unmodified sketch running on an R3 board, then switch to the R4...

Note: I can't remember the exact baud rate, its a standard high rate one. The digits I showed above are close to the digits in the correct baud rate...

 

[BigBadBuzz]

RC:

Thanks! Yes, I was trying that after a rather frustrating afternoon. I just went back to the UNO R3 with unmodified sketch 1.0.0.13 uploaded into it (with #define WITH_SERIAL_DEBUG uncommented). The RESET; command (as well as some extended protocol commands) all seem to behave correctly / give appropriate responses. In the Serial Monitor I selected "No Line Ending" and a baud rate of 115200. So the "baseline" is working. Providing the text commands via the serial debug interface is pretty cool (and old school - which I am a fan of).

I probably won't get back to the R4 until tomorrow morning. The version of 1.0.0.13 sketch that I had modified for UNO R4 definitely was NOT responding to any serial commands. Maybe I messed something up in that sketch...

Regards,
BBB

 

[BigBadBuzz]

I have been working WITH_SERIAL_DEBUG on the UNO R4 WiFi. I can't say there has been much progress, but I have learned a few things.

I went back to the 1.0.0.13 sketch that ships with RC 1.15.2.0, commented out #define WITH_WATCH_DOG, replaced the 'jmp 0' code in the softwareReboot() routine with with NVIC_SystemReset(). The code verifies and uploads to the UNO R4 WiFi. I then un-commented WIITH_SERIAL_DEBUG, verified and uploaded. However, when I enter 'RESET;' (no single parens are actually entered) at the Arduino serial monitor, there is no discernible change in serial output - just the ongoing deluge of :

Avg Poll time: 0.01ms
Avg Poll time: 0.01ms
TB<;Avg Poll time: 0.01ms

the seemingly random characters shown at the beginning of the third line do not seem to have a pattern as to which line they appear in, and the characters are not the same each time. What I can say is that the "gibberish" always seems to show as 7 characters in the Serial Monitor - always with T as the first character and ; as the last character.

I then added some of my debug code to try to figure out what is going on. The first added debug stuff was in the same section of code that prints out the "Avg Poll time". The added code prints out the value of 'Serial.available()' and the boolean variable 'bRead' -- see below. After resetting the UNO, the serial monitor shows continuing sets of two lines:

Avg Poll time: 0.01ms
# of serial characters avail. to read: 0 | Value of boolean bRead: 0

As soon as I enter 'RESET;' at the serial monitor, the two lines change to:

Avg Poll time: 0.01ms
# of serial characters avail. to read: 6 | Value of boolean bRead: 0

Serial.available changing from 0 to 6 seems correct for an entry of 'RESET;', however nothing seems to be happening as far as the Arduino processing the available serial characters. The Serial.available value remains = 6. I added debug code to the beginning of routine

void serialEvent()
{
while (!bRead && Serial.available())
{
byte inChar = Serial.read();
SERIAL_PRINTLN("** Entered serialEvent routine **"); //Debug

but I never see output from that debug code being sent to serial monitor.

I'm not a software guy - just a hardware guy that can hack around a bit. Anyone have suggestions as to what I do next?

Regards,
BBB

 

[BigBadBuzz]

Note that I found this while searching the web for something (anything) helpful:

Arduino Language Reference - serialEvent

This page says:

Please note that serialEvent() does not work on any modern Arduino boards. The only recognized boards to have support as of 2023/12/06 are the UNO R3, Nano, Mega 2560 Rev3 and Due.​

Instead, you can use the available() method. Examples in this page demonstrates how to read serial data only when it is available, similarly to how Serial.event() is implemented.​

Hmm - so if that is correct, that would explain why the serial input characters are not being read/processed into incoming messages.

 

[Ade]

Apologies 🙏 for the hijack , but what are the advantages of the new revision regards use for slot tracks 🤔.

 

[jordan898989.jordan8]

Good question, they 4's seem more hassle than they're worth unless you really need BT/wifi, I can see most slot car users who have 3Bs or lower sticking with them as they just work, the limited current on pins is also a big deal for those of us with start lights.

 

[BigBadBuzz]

Just an exercise to see what might have to be changed in order to have the R4's compatible with RC. As far as RC goes, I don't know if the faster 32-bit processor (with more memory, additional features, etc.) really buys you anything. But you might not be able to figure that out if you can't get it working...

Regards,
BBB

 

[BigBadBuzz]

Following on from Post #34, according to this Arduino Forum thread -

serialEvent() on R4

The serialEvent() function is defined for the AVR processors but not for UNO R4. So, that confirms why I never saw any characters being pulled from the Serial read buffer into inBuffer[]. I think a new routine would have to be added to the end of the main loop as, from my understanding, serialEvent() was a special "off to the side" thingie that got called after each iteration of the main loop.

Regards,
BBB

 

[Race Coordinator]

Yeah looks like you'll have to change how the sketch is reading the serial data. Probably not too hard. There are probably sample programs that do it, you likely could use that code as a guide and change how the current sketch does things.

Note: If you want me to keep your changes, you're going to have to put everything in a WITH_R4 define for now. That way I can guarantee the old tried and true sketch works.

 

[BigBadBuzz]

I will freely admit I am no software person - I just futz around to explore and sometimes add a few extended protocol additions. @Slingshotx, In one of your posts in this thread, you were considering a "one ring to bind them" sketch that would support UNO R3, R4 and esp32 - are you still considering that? If so, I would be glad to provide some testing since I have the R4 WiFi.

Regards,
Paul