Teensy 4 RTOS

brtaylor

Well-known member
Paul, in this Teensy 4 post you suggested that, while not necessary, Teensy API's would move towards working with an RTOS. Any thoughts on which RTOS you're considering for Teensy 4? I understand that the selection of an RTOS would ultimately be up to the user, but my take on Teensy 4 is that many of its use cases could benefit from one and I'm making the assumption that there will be a preferred RTOS to use.

I'm asking because I'm currently writing some software for the Teensy 3.6, which could likely benefit from either: 1) TeensyThreads and EventResponder or 2) a full blown RTOS. My plan is to move much of this functionality to Teensy 4 when it becomes available and would like to make that transition as painless as possible.
 
Hi Brian.
You might find this thread interesting. https://forum.pjrc.com/threads/46733-Support-for-FreeRTOS?highlight=RTOS for your work. Bill G. has a ported copy - looked it up once but forgot the details. Think that was about when I discovered TeensyThreads.

Thanks! It looks interesting, I would just hate to go that route and end up having to port everything to a different RTOS or TeensyThreads / EventResponder. Especially since it seems like the port to v9 hasn't been completed yet.

After fixing some issues with my build environment, I've been playing a little today with the TeensyThreads / EventResponder framework to try learning it better.
 
I'm also interested in this, as I was just about to start shopping RTOS options myself. Long-term support is what brought me to the Teensy platform.
 
YASQ (yet another stupid question)

What are you good people doing that would require more than a scheduler/state machine?
 
YASQ (yet another stupid question)

What are you good people doing that would require more than a scheduler/state machine?

YASA (….answer)
T3.x is such a small processor that I only need a well understood interrupt sequence, maybe a cooperative scheduler, with/without timed execution
 
YASA (….answer)
T3.x is such a small processor that I only need a well understood interrupt sequence, maybe a cooperative scheduler, with/without timed execution

Likewise...my use case is a research quality flight control system for fixed wing and multi-rotor drones. I have some tasks that need to be executed regularly on an interrupt (data acquisition synced to an MPU-9250 data ready signal and control laws), some that need to be run at a fixed interval of time (actuator commands sent a fixed time after data acquisition), some that are lower priority (polling for new GNSS data, data buffering and logging), and some that are lower rate (telemetry and path planning). I may be able to meet these requirements with EventResponder and TeensyThreads; although, I'm not sure I'll get the same guarantees with the scheduler with that approach that I would in FreeRTOS or another RTOS (I don't think I want to write my own scheduler).

With Teensy 4, I'll likely be moving more of the processes on my BeagleBone Black co-processor to the Teensy. Which simply means more threads running at different rates and different priorities sharing data. So the scheduling may become more important with respect to guarantees on running the high priority tasks on time.

I'm most concerned about using the solution / approach that will let me continue expanding the utility of my flight control software without needing to do a major refactor in the future; either because I've added more items for the software to do or because I'm upgrading from Teensy 3.6 to Teensy 4.x.

Brian
 
Custom full-authority ECU for use in the motorsport sector. Modular avionics-level sensor package, datalogging, engine protection, etc.
 
Quick update: I tried Bill Greiman's port of FreeRTOS and, without support or an update, it's basically unusable for Teensy 3.5 / 3.6:
https://github.com/greiman/FreeRTOS-Arduino

Setting ticks faster than 1ms seems to not work, even following the FreeRTOS advice on which macros to use. I think this may be because of limitations in the underlying timer being used. A bigger issue is that floating point math is not supported and produces a hard fault, I suspect having to do with issues in working with the FPU state between threads.
 
Hi Mike,

I saw Bill discussing an update to FreeRTOS v9, but it hasn't happened yet on his GitHub and the version posted (FreeRTOS v8) doesn't work. I haven't tried this yet, but that might be next up for me:
https://github.com/vanbergeijk/teensy-3.6-FreeRTOS-template

Seems like still a limitation for > 1kHz tick frequency.

I'm still trying to figure out whether TeensyThreads and EventResponder might fit my needs. Additionally, I've been looking at some potential in house type solutions based on articles like:
https://www.embedded.com/design/prototyping-and-development/4025691/Build-a-Super-Simple-Tasker
 
I'm a little wary of ChibiOS because of its licensing structure. I develop open source, but would like my work to be able to be used in closed source projects.
 
You could always check out the FreeRTOS site it self to see if there are any questions on 1khz. Also, you could post a issue on Bill's GitHub page. He's usually pretty could at responding. I had to do that with another library of his.
 
I have FreeRtos running on Teensy4.1, but I used the NXP MCUXpresso IDE. Built the stock lpuart demo with no changes and it just worked!
 
I have FreeRtos running on Teensy4.1, but I used the NXP MCUXpresso IDE. Built the stock lpuart demo with no changes and it just worked!
Hi @john_c_kennedy how did you do this? I found the lpuart examples you mention, but how do you flash it to teensy 4.1? I've trying to make teensy work with MCUXpresso
 
You have to create a hex file with MCUXpresso then just use the Teensy loader to flash it to Teensy4.1. MCUXpresso creates a header in the hex file that is compatible with the Teensy loader as long as the MCUXpresso project has the Xip_device driver, and the xip_board and xip_board_dcd components included in the project. To create a hex file select the project, right click, select Properties, click the drop down menu for C/C++ Build, select Settings, click on the Build Steps tab, edit the post build steps, un-comment the second line using objcopy to create a binary file and change it to this: arm-none-eabi-objcopy -v -O ihex "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex". Then each time you build the project it will create a hex file that you can flash to the Teensy using the Teensy loader. You can also go to the Debug folder, select the .axf file, right click and select Binary Utilities and select create hex file. The difference with MCUXpresso is that it links everything to run in flash, whereas Teensyduino links so most of the code will run in ram. I've tried to do this in MCUXpresso but haven't got it to work yet, as MCUXpresso has different startup code and linker files. When I import an example project into MCUXpresso I select the EVKMIMXRT1060 board (you have to download the SDK from NXP for this board). This board uses the same IMXRT1062 part as Teensy 4.x but with a different package, however the pinout is identical to Teensy4.1 (as far as I've been able to determine). Not all MCUXpresso examples will work because some things are different, for example the user LED on the EVK board is on a different pin than the LED on Teensy4.x, but most of these things can be fixed with the MCUXpresso Config tools. However as I mentioned above the FreeRtos lpuart demo just worked with no changes at all. Let me know if you need more help. John
 
Thank you very much John. I manage to make the hex file and flash it to my teensy 4.1. I am still struggling with an issue though. After flashing the hex file, teensy doesn't show up as serial port anymore while flashing from arduino IDE makes it come back ( after using the reset button ). Maybe I am missing some pin configuration?
Also does the memory configuration has to be changed? i.e ram/flash sizes
 
Alvaro, as I recall the FreeRtos lpuart demo for MCUXpresso uses LPUART1 for the serial port, which is connected to pins 24,25 on the Teensy 4.1. So it doesn't use the USB serial port. You need a serial adapter cable like this one:https://www.amazon.com/JBtek-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88. There are a lot of these adapters out there so you might be able to find one cheaper on ebay or elsewhere. Just make sure you get one that will work on 3.3v. Connect the TX, RX and GND pins of the adapter to the Teensy, don't connect the power pin to Teensy. Then use a terminal emulator like RealTerm or something similar to connect to it. There are other MCUXpresso demos that use the USB serial port but not with FreeRtos, look at the hello_world_virtual_com demo. Using MCUXpresso with Teensy 4.1 can be a challenge, especially since Teensy 4.1 doesn't have a debugger, if something goes wrong it's difficult to diagnose. I added a heartbeat task to the FreeRtos lpuart demo which blinks the Teensy 4.1 LED just for a visible check that FreeRtos is running. I've found that adding more tasks requires you to increase the heap size in both FreeRtos and MCUXpresso linker. You have to be careful with FreeRtos on the IMXRT1060 (Teensy 4.x) since many of the stdio functions are not thread safe, and it's easy to crash FreeRtos, there's a lot of info about this on the internet. Good luck, John.
 
You need a serial adapter cable like this one:https://www.amazon.com/JBtek-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88. There are a lot of these adapters out there so you might be able to find one cheaper on ebay or elsewhere. Just make sure you get one that will work on 3.3v. Connect the TX, RX and GND pins of the adapter to the Teensy, don't connect the power pin to Teensy.

I want to reaffirm that. I killed a 4.0 by mistakingly touching a Teensy Pin with the red one. After that, i did cut the red one.
 
This is a lot of great info. the 'hello_world_virtual_com' example did the trick, but I might end up using the serial adapter cable (already have one) since it seems there is no good support for debugging on USB apparently. But anyway, I have most of the pieces to work with this. Thanks!
 
Back
Top