Does teensy 3.5 3.6 support freeRTOS

Status
Not open for further replies.

mrmu

Member
Just wonder since arduino boards seem to support it. I guess this os will give more power to it for a lot musical instrument applications.
 
I remember that it had been ported to Teensy 3.2, just use the search function in these forums.

Basically, with the Teensy 3.x processors which are much quicker than the Arduinos and which have special DSP instructions, wasting memory and cpu cycles on preemptive multitasking as freeRTOS does, is not forcibly the best way to do musical instrument applications. The Teensy audio library has highly optimized code for all things sound and music and is coded in an efficient and optimized manner, so that crutches like an RTOS are not needed.
 
As Theremingenieur mentioned, ...

@KurtE: I know that my user name is a bit long and difficult to spell... Thus I think it's the moment to allow my fellow veterans here in these forums to call and cite me alternatively by my first name Thierry if that's easier for you.
 
This is kind of a 2 part question. The first part, about FreeRTOS really revolves around the meaning of the word "support". A salesman would of course say yes, if any port of FreeRTOS can run on Teensy, then of course it's "supported".

But the honest reality of "supported", meaning at least some reasonably large subset of the code you'll find for Teensy actually works with FreeRTOS, or meaning that you'll get good answers from us here on this forum, then no. Hardly any of the existing libraries and non-trivial programs are thread safe, not to mentioned designed to integrate well with multi-threaded FreeRTOS projects. Hardly anyone here really uses FreeRTOS. So while there may be ports that can at least do some trivial things, for all practical purposes FreeRTOS isn't really a viable path, unless you want your project to largely about fiddling with FreeRTOS.

The good news is I have a much better answer to the other half of your question. Well, Theremingenieur already mentioned the audio library. It's comes with its own multi-tier interrupt scheme that allows for your Arduino code, and most other libraries which also need interrupts, to run while the audio is playing. Not a full RTOS, but it does solve the concurrency issue quite well and gives good compatibility with most other libraries, even ones needed fast interrupt response. There's a detailed tutorial for the audio library which tries to explain this with some hands-on examples in parts 1-4 and 1-5 (pages 5-7 of the PDF manual).

I'd highly recommend going through the tutorial material. The PDF is 31 pages. The ideal way is to print the whole thing and sit down for 3-4 hours with the hardware and actually do all the parts. Or you can watch the 45 minute video of me & Alysia doing a full walkthrough. Much like video game walkthroughs, you can quickly see everything happen and get a pretty good idea, but actually playing it all yourself is the way to get the real experience.
 
Last edited:
If the things being done involve idle waits for data to return task switching can be relatively efficient on the Teensy CPU family - but lots of the transfers are already supported by FIFO or DMA or interrupt driven when ready. Task switching could get in the way in some cases so YMMV - many libraries are not designed to be switched. As noted the Audio library works hard to maximize efficiency. Paul is working toward EventResponder implementation for callbacks and async operation and to get the libraries to be switching aware/capable - another WIP is Teensy Threads

Hi Thierry.
 
Thanks for the guide. I have ordered several 3.5 and 3.6 and waiting for their arrival. The first project is to build a musical keyboard which can play sampled wave for each key press. The idea to go rtos is I would like to have quick response (<10ms if possible) for each key press/release. So I think it is good to have a thread keep checkning key events while other threads play pre recorded waves. However, if one key is pressed and suddenly released and got pressed again, I would like to have the wave-playing threads stopped and re-started immediately. So the ideal(simple) way I can imagine is to kill and restart these threads within a rtos.

Or a more general idea is to have emergency stop button which can immediately stop some other threads as soon as it can. The other threads don;t have to save their state so they can resume. This is more general than musical instruments. And if possible, could be used to control satellites even. Is there a way to achieve this?

I have used some multi-thread libraries like scoop in arduino, I didn't find this kind of "hard stop" mechanism. I am reading the multi-thread lib of teensy and will figure it out. thanks again.
 
Last edited:
Yes, it is possible to use the FreeRTOS that has been ported to Arduino Due. You must modify "kinetis.h" file which is located inside the Arduino folders. I'm a Mac User so the file is located here, /Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy3. Inside the file close to the bottom where the extern function prototypes are, you will need to insert __attribute__ ((weak)); after the ones used by CMSIS, such as SysTick, PendSVC, etc.

extern void nmi_isr (void) __attribute__ ((weak));
extern void hard_fault_isr(void) __attribute__ ((weak));
extern void memmanage_fault_isr(void) __attribute__ ((weak));
extern void bus_fault_isr(void) __attribute__ ((weak));
extern void usage_fault_isr(void) __attribute__ ((weak));
extern void svcall_isr(void) __attribute__ ((weak));
extern void debugmonitor_isr(void) __attribute__ ((weak));
extern void pendablesrvreq_isr(void) __attribute__ ((weak));

I have posted what this should look like, I recommend to do this with the interrupt handlers that are exclusive to NXP as well.

extern void uart0_lon_isr(void) __attribute__ ((weak));
extern void uart0_status_isr(void) __attribute__ ((weak));
extern void uart0_error_isr(void) __attribute__ ((weak));
extern void uart1_status_isr(void) __attribute__ ((weak));

This is an example, but I made this work for all of them. Also I will be working on a version that is good for Teensy, because the Due is a Cortex M3 and the Teensy 3.5 and 3.6 are Cortex M4 with FPU. If you don't need the FPU then the mod I have mentioned will work fine.
 
you dont need to modify the core if you just change the handler path and use one thats already not used...
it can even be done by the sketch...
 
Maybe this can be done in future versions then inside the core then. I was simply offering a suggestion on what someone could do if they wanted FreeRTOS to work with Teensy 3.5 or 3.6. At this time, I don't see a lot of options on how to use FreeRTOS with these Teensy's. They are great products with potential. This modification, doesn't disrupt the core at all. All is does it allows to function to be redefined by the port.c, such as:

extern void svcall_isr(void) __attribute__ ((weak));
extern void pendablesrvreq_isr(void) __attribute__ ((weak));

Which is also defined in this file here "EventResponder.cpp"

Since I'm not interested in this file at the time, or understand it's purpose yet, I feel this is a good solution.
 
Status
Not open for further replies.
Back
Top