Tiny RTOS for Teensy3.0/1

Status
Not open for further replies.
S

SteveS

Member
Hi All-

Been enjoying both a teensy2.0 and 3.1. The 2.0 was for the original intent of making a smart switch. The 3.1 bought on curiousity...

I've a very small microkernel that has been around for awhile and have succeeded in porting it to the ARM-M4 - teensy3.0/1. First off this involved the normal route of installing the development environments for both the AVR and ARM environment for the teensies. Used the AVR environment in stock fashion, but ripped out enough from the Arduino environment to get a simple makefile environment on Win7. First a working main() - then LED flashing - finally serial hosted USB communication. I outlined this evolution in a .txt file that could be of interest to some here who want to do standalone teensy3.0/1 development...

This of course provided the springboard to porting an existing micro kernel. It's designed to be little more than a dynamic state machine that incorporates being able to get state stimulus from interrupts as well. Its supports a limited number of fixed priority tasks + a background task. Simple deterministic scheduling - simply the highest priority ready task is always running. It was also designed for the even a limited cranium programmer/author to be able to read and figure it out from a mere handful pages of source code. Mostly portable with a detailed glue interface. Some documentation - again just a few pages needed. It is about as simple as you can get...

I did not touch the Arduino code components borrowed. Simply fleshed out the glue code + portable code of the rtos. Wrote a bit of an application that also chronicles quite of a bit of the evolution of the port. The glue code was documented quite a bit - probably easily transferable to bring up another ARM-M environment. Quite tiny if minimully configured - this one has got some generousity allocated to buffers and the like - still weighs in at < 2K each flash and ram. It runs in almost entirely in privileged thread mode (scheduler does not require handler mode) and pretty non-invasive of the interrupt environment. I think it could *easily* be run under the Arduino envirnment, but I have not really used, or know much about the Arduino runtime. Maybe someone else could run better with that one...

I don't have it online at all in any fashion. If interested - I can email a .zip that is everything along with some know how (I think not much) to get it going. Have fun with the teensies. Still amazed at the capabilities for the value -- THANKS!

Steve Speier
 
I'm interested in looking at this. Does it:
  • Have option for preemption in the task scheduler?
  • Have option to disable preemption and use cooperative scheduling, to simplify use of non-reentrant library code?
  • Have a stack per task/thread?
  • Enable use of the Teensy library routines' I/O?
Perhaps a user guide answers these questions.
FreeRTOS is ported and runs on Teensy, with ability to call Teensyduino libraries (with the reentrancy caveat).
 
I would be interested as well. But instead of email, just upload and attach the zip to your post above, the forum allows that.
 
Bullet 1) The tasking model is based on a signal()/wait() scheduling mechanism. This primitive is the basis for the higher tasking constructs: binary semaphores and messages as well...
Bullet 2) Yes - tasks can control task scheduling with forbid()/permit() surrounded code. More stringently with disable()/enable() which hold off interrupts. These services also nest...
Bullet 3) Each task has it's own process stack. I toyed with the idea of a single stack (handler mode) as it was an easier, more conventional model to port to. But memory is a premium and discovered a way to take care of scheduling/context switching without much overhead, and more importantly within the portable framework of code. The model in place is close to being as efficient as the single stack model, but each local stack does not have to also host the system/exception system (the handler stack) - so can get by with smaller per task stacks.
Bullet 4) I'm heavily borrowing the USB libraries. They seem to be OK when using within the multitasking environment, but can't be sure - and I have not looked into the code behind the service functions I used. What I *did* do is create a little output system that everyone posts message into, but only the background task actually displays (QOUT.c & h). This solves not only coherency, but insures that displaying messages never holds off the activity of any higher priority task...

Lastly I do have a word document outlining the OS. I don't have much of an online presence. I think there is another post on this thread on what I can do to make this available -- will be looking at that...
 
Thanks. Sounds interesting.
Not totally clear to me about preemption - must a task wait() or yield() or some such?
library routines underneath things like printf() with the ... operator, and some others, aren't RTOS friendly. So I'd think we use a MUTEX so the task can just wait until a concurrent one finishes.
 
Teensy3.1 POS - and more should be uploaded...

Ok-

Thrown together a bit. There should be a readme.txt in the root directory of this that serves as a starting point and will lead you through a trail of supporting readme.txts as well. This was on a win7 system and best to expand this .zip in the root of a drive. That way you'll better be able to use the makefiles as they are...

This contains - really - the summary of work done on both a 2.0 and 3.1 teensy over the last month or so...

Note sure it's complete, but hopefully steers you well enough to navigate a bit on your own...

Steve S
 

Attachments

  • TeensyPOS.zip
    1.7 MB · Views: 173
Hi Steve, sounds like you come from the Carl Sassenrath school of RTOS design! I'd love to have a look :)
 
Last edited:
Status
Not open for further replies.
Back
Top