FreeRTOS discrepancies in Uno R4 port

I was recently comparing FreeRTOS in various Arduino boards. Each microcontroller family has a different FreeRTOS port and unfortunately they aren't compatible. The Renesas port (Uno R4) is the least compatible without making some changes. I'll list the important issues here, compared to the AVR port used in the Uno R3 (and others):

  • A call to vTaskStartScheduler() must be added at the end of the setup function to start the FreeRTOS scheduler running. The AVR port does this "behind the scenes".
  • The AVR port, actually all the other ports, calls the loop function from within the Idle Task. The sole Uno R4 example program creates a task that repeatedly calls loop, however loop can be called from within the Idle Task, for compatibility. Just define the function void vApplicationIdleHook(void) { loop(); }
  • The Uno R4 port is also unique in setting the configuration option configUSE_TIME_SLICING to 0 rather than 1. This means the running task will not be forced to yield at the end of the time slice. IMHO this is the best option for experienced users, but it can cause poorly written programs to hang.
  • It might cause a problem in that the tick period is 1ms rather than roughly 15ms. Programs should be using configTICK_RATE_HZ or portTICK_PERIOD_MS rather than making assumptions about the period.

See a comparison of the ports on my blog, https://tomalmy.com/freertos-implementations-on-newer-arduino-boards/

Could you add links to the specific "FreeRTOS" ports that you're comparing?
AFAIK, only the ESP32 version is an official product (part of the standard ESP runtime environment.)

Sure!

I've also modified the AVR port to run on the ATmega4809 The Continuing Adventure of FreeRTOS - Tom Almy's Blog

Thanks. Yeah, four different ports maintained by four different entities. :frowning:
If you have a favorite set of behaviors, you can try submitting github issues asking them to change. Best case they'll all adjust toward common behavior. Worst case, there will be "documentation" of a sort for the difference, it a more-highly-visible spot.

(Do you think that any of the differences have reasons that are inapplicable to the other platforms?)

No reason other than four different developers. And the differences are fairly trivial. However there presumably is some effort to make the boards compatible, and all the ports are at least endorsed by Arduino being that they are available in the Arduino IDE. The example programs aren't consistent with different boards which makes comparison difficult.

Of course the ESP32 port has an excuse to be different -- it has been enhanced to support the two processor cores.

Wish I had come on your post earlier. The MANY variants of (Arduino) devices only tends to confuse those trying to learn about these little powerhouses. Also, many of them come with insufficient memory for any real applications. I guess because the libraries are often enormous.

I have been programming PLCs and early (BlueEarth Technology [now defunct] 805x) microcontrollers since 1986 or so. The shear-number of competitors in this arena now is staggering.

I have always thought it best to learn something about the assembly language for a given processor first so as to have a good foundation. Now, this is very difficult, in part due to lack of available documentation. Apparently, an NDA is need for many of the core vendors. Too bad.

I think that in the case of the many Arduinos, they don’t want you to “go under the hood”. I had written several books on programming the AVR based Arduinos “to the metal” but stopped mid-book writing one for the SAMD21 seeing the trajectory for Arduino models veering away from low level programming. Of course their target customer has been people who want to use them as black boxes, just using provided libraries. Electronics hobbyists can still do fine with the AVRs as long as they are made, and there are, of course, alternatives to Arduino.

What leads you to believe that Arduino has an agenda against people going "under the hood"?

Just because we want to provide the option of creating projects via a higher level, and dedicate our finite resources towards that goal, doesn't mean that we are opposed to people writing low level code. Even if we don't prioritize our resources towards facilitating it, Arduino doesn't take any actions to prevent doing so. In fact, Arduino IDE has explicit support for using assembly source files in your sketch projects.

The option for low level programming already existed before Arduino began.

You are right that there is no Arduino agenda against going under the hood. But there is no agenda promoting it either! The targeted customer has always been someone who can use the technology in projects with little knowledge of electronics. (Exception being ARDUINOPRO)

Spam and associated replies deleted.