FreeRTOS Suggestions / Pitfalls for Teensy-LC?

[jeffsf]

I'm working on a controller that needs to have predictable, real-time response, as well as having a watchdog timer than can handle potential "lock ups" of the controller. If this wasn't the case, there are plenty of small, inexpensive devices that can run a Linux kernel and do what I need. The lagging price / performance of Arduino-class devices led me to order a Teensy-LC to try out and am looking forward to receiving it early next week.

I've read through several threads here on FreeRTOS and, staying out of the why an RTOS discussion, there seem to be mixed messages about the functionality of FreeRTOS on the Teensy series.

Development hosts here include macOS, FreeBSD, or Debian. I'm likely to use CLion as the IDE.

One resource that I did find that seemed viable is https://wiki.uiowa.edu/display/teensymacos/Getting+Started, likely using the platformio path

Is this a recommended approach? Are there other approaches or resources that would be worth exploring as well?

https://github.com/greiman/FreeRTOS-Arduino looks to be v8.2.3, several years old (as well as GPL-encumbered). Are there any more recent ports available?

I see that https://www.freertos.org/RTOS_ports.html indicates support for "Kinetis ARM Cortex-M4", but not the M0+ -- Have I ordered the wrong board for this?
I don't need the speed or memory of the Teensy 3.2; an ATmega328 would have been sufficient.

 

[rjp]

I'm working on a controller that needs to have predictable, real-time response, as well as having a watchdog timer than can handle potential "lock ups" of the controller. If this wasn't the case, there are plenty of small, inexpensive devices that can run a Linux kernel and do what I need. The lagging price / performance of Arduino-class devices led me to order a Teensy-LC to try out and am looking forward to receiving it early next week.

I've read through several threads here on FreeRTOS and, staying out of the why an RTOS discussion, there seem to be mixed messages about the functionality of FreeRTOS on the Teensy series.

Development hosts here include macOS, FreeBSD, or Debian. I'm likely to use CLion as the IDE.

One resource that I did find that seemed viable is https://wiki.uiowa.edu/display/teensymacos/Getting+Started, likely using the platformio path

Is this a recommended approach? Are there other approaches or resources that would be worth exploring as well?

https://github.com/greiman/FreeRTOS-Arduino looks to be v8.2.3, several years old (as well as GPL-encumbered). Are there any more recent ports available?

I see that https://www.freertos.org/RTOS_ports.html indicates support for "Kinetis ARM Cortex-M4", but not the M0+ -- Have I ordered the wrong board for this?
I don't need the speed or memory of the Teensy 3.2; an ATmega328 would have been sufficient.

you can do scheduled timer events and watchdog from teensy arduino, RTOS is only required if you want a more complex "multi threaded" setup.

https://www.pjrc.com/teensy/td_timing_IntervalTimer.html

https://github.com/adafruit/Adafruit_SleepyDog

 

[jeffsf]

Thanks, I appreciate the references. There certainly is a lot one can do with an Arduino-style programming model, but, as you point out, it is not well suited for multi-threaded programming, especially when there are deadlines for execution along with thread prioritization. Hence the desire for an RTOS implementation.

 

[brtaylor]

I had some discussion regarding RTOS on this thread:
https://forum.pjrc.com/threads/53662-Teensy-4-RTOS

I compile for Teensy 3.6 using a makefile on linux platforms. Greiman's port of FreeRTOS and Chibi both work as library with a standard Arduino install as well. I have all of the Teensy platforms, but have only played with RTOS code on Teensy 3.6 (needed the FPU for my software).

How fast do you need tick to run? Overall I found that this port worked fine if you could live with 1ms tick:
https://github.com/vanbergeijk/teensy-3.6-FreeRTOS-template

Faster ticks look possible, but likely to break the standard Arduino 'delay' function without switching the tick to another clock.

Overall, I'm actually considering adding priority scheduling to TeensyThreads and using it in combination with EventResponder to get the scheduling functionality that I'm after.

 

[jeffsf]

On one of the two applications I was considering using the Teensy boards with, 1 ms would be sufficient. Disappointing that it's not faster on a device with a 48 or 72 MHz clock.

You've already seen warnings that nearly all libs aren't reentrant or thread safe, so perhaps that ought to temper "would be awesome"...

is rather concerning.

The combination of the two (no RTOS, significant concerns around thread-safe libraries) has pushed me to cancel my order until I can look into the options more fully.

With devices with an order of magnitude higher performance and an order or two greater resources available at the same price point, microcontroller boards in the US$10-30 range that can't properly handle non-trivial, real-time processing aren't much more than toys to me.

 

[brtaylor]

It's definitely possible to get faster than 1ms tick resolution, the issue is that FreeRTOS expects to use systick and Arduino uses systick for delay. Changing systick so FreeRTOS has a tick faster than 1ms breaks the Arduino delay functionality and possibly any libraries that rely on it. So the solution has to be either: 1) changing FreeRTOS to use another timer, such as IntervalTimer (which TeensyThreads uses) or TimerOne, 2) changing delay to use another timer.

 

[PaulStoffregen]

.... that can't properly handle non-trivial, real-time processing aren't much more than toys to me.

Teensy probably is not the right product for you. Buy something else where FreeRTOS is the primarily supported system.

It's very clear your entire problem solving thought process revolves around a specific software paradigm. If you can't imagine real-time response any other way, you're almost certainly not going to be happy with much of the software ecosystem the has built up with Teensy.

 

[jeffsf]

Having worked with real-time systems back into the days of core memory, conceiving of how to deal with single-threaded execution and implementing it is well within my experience. I'm very familiar with many ways in which that can be accomplished. However, in this day and age, the cost of development and test of a custom scheduler, especially when the libraries aren't thread-safe, exceed the benefits of what certainly seems to be a very high quality product at a reasonable price for small-run purposes. Past the quality of the Teensy hardware, that most of the core software associated with the Teensy line isn't encumbered by GPL/LGPL-like restrictions is also very welcome.

With an eye to the future for the Teensy, especially with Amazon's purchase and subsequent release of FreeRTOS under MIT licensing, perhaps the Teensy team might want to consider working toward a thread-safe, reentrant implementation of the core libraries. Even if FreeRTOS (or similar) was not "officially" supported, that would allow a straightforward, third-party port to be implemented.