PRTOS - A simple but full-feature preemptive RTOS

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Announcing the release PRTOS, an open-source preemptive real time operating system kernel for bare-metal applications.

 

PRTOS is released by Cleveland Engineering Design - the developer of the CoRTOS cooperative real time OS, also available on AVRFREAKS.

 

PRTOS presently supports the AVR and MSP430 architectures.

 

PRTOS is available on Sourceforge at https://sourceforge.net/projects...

 

The advantages of PRTOS are:

 

  •   It has the smallest footprint of any true preemptive system: 1.9kB for basic scheduling and task control, 5.1kB with all the features below (AVR '328 / gcc -Os);
  •   Only 950 lines of code implement all of the RTOS features (SLOC-L);
  •   The system is configurable, you include only the features you need;
  •   There is minimal to zero interrupt burden;
  •   The system is well documented with a short but comprehensive manual, well-commented source code, and a test suite demonstrating the features;
  •   The system is proven - it has been in use since 1982 with applications in in-vitro medical equipment, process control instrumentation and industrial machinery;
  •   It is released under a GPL V3 license and commercial licensing is available.

 

PRTOS provides the following features:

 

Scheduling

  •   Preemptive
  •   Prioritized
  •   Round-robin equal priority tasks

 

Task Control

  •   Initialize/Ready
  •   Suspend/Resume
  •   Lock/Unlock
  •   Change priority
  •   Relinquish a round-robin turn

 

Communication

  •   Messages, priority messages
  •   Signals

 

Delay & Time

  •   Task delays
  •   Time-outs
  •   Periodic signals
  •   Run timers

 

Resources  (semaphores/mutexes)

  •   Multiple resource ownership
  •   Priority inversion mitigation
  •   Priority or FIFO queuing

 

ISR -> task functions

  •   Send signal
  •   Send message, send priority message
  •   Resume task

 

Edit: 10/17/18 - Correct code size, move downloads to sourceforge

Nicholas O. Lindan

Cleveland Engineering Design, LLC

Last Edited: Wed. Oct 17, 2018 - 11:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the TBC size per task? IOW how many tasks can you get into a sensible chunk of the AVRs RAM?

 

I remember exploring one in the past on the mega168, which I think has 1K SRAM, it could sensibly acommodate something like 5 tasks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, first of all using a full-dress preemptive RTOS in an ATMega328 is more a learning exercise than a practical affair.

 

TCB size varies with options.  The minimum is 21 bytes, you can get that down to 12 by moving some fixed values to FLASH/program space but then you can't reuse the TCBs for mutually exclusive tasks.  Put in all the options and I think the TCBs grow to 43 bytes.

 

Stack size is a bigger encroachment into the limited RAM available on an ATMega328, figure ~100 bytes per stack.  I've always thought to kludge something up to have a stack dedicated just to nested interrupts.

 

Of course the more tasks you have the more RAM you need for all the things that the real-world tasks do.

 

The ATMEGA1284 with 128K/16K/40dip|44tqfp would be a very good choice for large embedded systems that would use a preemptive RTOS.  There is a the $30 ATMEGA1284P-XPLD development board available.  And there is the ATMega2560 with 256K of code space; although it has only 8K SRAM on chip it does have an interface to an external 64K of SRAM.

Nicholas O. Lindan

Cleveland Engineering Design, LLC

Last Edited: Fri. Oct 5, 2018 - 10:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

V 1.01 of PRTOS is available on Sourceforge https://sourceforge.net/projects....

 

The release adds support for the 1284P-XPLD board with LED drivers for the board.  The release also makes changes to the MSP430 support.

 

Nicholas O. Lindan

Cleveland Engineering Design, LLC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

V102 is available on Sourceforge https://sourceforge.net/projects...

 

This version adds counting & binary semaphores

Nicholas O. Lindan

Cleveland Engineering Design, LLC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting, but I have my doubts about it being simple.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:

> Interesting, but I have my doubts about it being simple.

 

Simplicity is in the eye of the beholder, so there is not much debating it.

 

Being the author of the system, I think "Well, it's perfectly obvious what's going on.  Simplicity itself.  I don't understand why everybody else doesn't see it."  While a wee little rational corner of by mind says to me "It's clear as mud to some folks - and not much you can do about it."

 

In basic RTOS functions PRTOS is in league with FreeRTOS and uC/OS.

 

The main differences are: PRTOS uses static structures and the others use dynamic memory allocation;  uC/OS and FreeRTOS do have lots and lots of drivers and communications stacks, PRTOS doesn't; FreeRTOS and uC/OS have provision for UART debugging, PRTOS uses the IDE and ICE/JTAG/SPI/USB.

 

As all things are relative:

 

Documentation -
PRTOS: 40 page manual.
uC/OS: 600 page manual.
FreeRTOS: 360 page manual.

 

Code size, compiled -
PRTOS: AVR 1.9kB base, 5.8kB loaded; 80x86/87 2kB loaded (ASM86)
uC/OS: 80x86 13kB loaded(?)
FreeRTOS: AVR 8kB-16kB reported w/ an unknown feature set

 

Download package, compressed -
PRTOS: 53kB (+177kB manual - bloated with WP->PDF conversion)
uC/OS: ??
FreeRTOS: 46MB (w/ multiprocessor support, lots of demos)

 

                                                                                   *      *      *

 

If you are just starting out with learning about preemptive RTOSes then I think PRTOS might be a good place to cut your teeth.  Though cutting teeth is usually a painful process.

 

If you are looking for something really simple in an RTOS, I can suggest CoRTOS - it's a cooperative system and so it's very straightforward.  https://sourceforge.net/projects...

 

Nicholas O. Lindan

Cleveland Engineering Design, LLC

Last Edited: Tue. Oct 30, 2018 - 07:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a question.  Hopefully it makes sense.

 

There is an interrupt that causes a certain task to run.  If the interrupt occurs 3 times before the task runs, will the task run 3 times?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nolindan wrote:
Documentation -

PRTOS: 40 page manual.

uC/OS: 600 page manual.

FreeRTOS: 360 page manual.

You may have misunderstood your potential audience if you think that providing LESS information is an advantage?!?

Code size, compiled -
PRTOS: AVR 1.9kB base, 5.8kB loaded; 80x86/87 2kB loaded (ASM86)
uC/OS: 80x86 13kB loaded(?)
FreeRTOS: AVR 8kB-16kB reported w/ an unknown feature set

Again this doesn't really help much.  Come up with a "typical" application - maybe one with a thread reading ADC, a thread having a dialog on I2C, a thread reporting stuff to a UART, a thread reporting data to an LCD. Now implement them each with the O/S you are comparing and then quote the complete size of the implementation. No one really cares how big/small the OS core is - if you are using an OS on an AVR you are using at least 16KB and more like 32KB/64KB/up so 2 or 5 or 10K for the OS core doesn't matter. It's the other resource usage that really matters. For AVR the thing that's likely to give out first is actually the SRAM so it's usage of that is key.

Download package, compressed -
PRTOS: 53kB (+177kB manual - bloated with WP->PDF conversion)
uC/OS: ??
FreeRTOS: 46MB (w/ multiprocessor support, lots of demos)

Again you seem to be saying "small is good". I think an OS that came with 50 examples would be far more useful than one that comes with just 1. Already mentioned manual size above - the more the merrier IMAO! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

 

> You may have misunderstood your potential audience if you think that providing LESS information is an advantage?!?

 

It's not how much is provided.  It's the amount of documentation that is needed.  And for that I think I have understood my audience.  I have been explaining this system to client staff for many, many years and they have to understand it.  Sometimes less is more.

 

> Again you seem to be saying "small is good".

 

Yes, exactly.  I design products for a living and small is indeed good.  One should always reduce a design to its essentials: The same function for 1/10 the cost;  Fewer parts, fewer parts to break.  There is the old adage "An Engineer does for $1 what any fool can do for $10."  A good programmer can do in 100 bytes what any fool can do in 1000.  Small is good; Bloat is bad.

 

> I think an OS that came with 50 examples would be far more useful than one that comes with just 1.

 

 

It comes with 9.  How many do you need?  But, look, it's not a one size fits all - FreeRTOS and uC/OS seem to meet many peoples' needs.  PRTOS is just one more option - a simpler one.

 

> Already mentioned manual size above - the more the merrier IMAO!

 

Until you have to read it.

 

PRTOS is here as a learning example.  You start small and simple.

 

 

Nicholas O. Lindan

Cleveland Engineering Design, LLC

Last Edited: Tue. Oct 30, 2018 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:

> There is an interrupt that causes a certain task to run.  If the interrupt occurs 3 times before the task runs, will the task run 3 times?

 

Not quite how it works.

 

It's not the interrupt occurring that triggers a task to run.

 

Say a UART interrupt takes in characters, stores them in a buffer, and with the final character, an ETX or LF, it sends a signal to a task to parse, act & respond.  The task is waiting for the signal from the ISR and when the ISR sends the signal the task wakes up and does it's thing, clearing the message from the buffer when it's done.  The task is only affected if it is waiting for a signal and the interrupt sends a signal.  Otherwise the two don't interact.

 

If three messages come in then the ISR sends three signals as each message is received.  If the task is busy doing something else then it is not affected.  When the task does finally get around to waiting for a signal it will immediately 'take' one of the signals waiting there, process the message, and then come back for the next signal/message... and so one.  The sent signals accumulate in the signal counter (and hopefully the ISR doesn't write over/over-run the buffer) and are removed as the messages are processed.  If the task throws a hissy fit and decides not to take any more signals then it is too bad for the ISR as it has no control over the task; messages just pile up until there is no room for more and then the ISR has to throw up its hands and give up.

 

So in a sense yes, three interrupts where a task has to be informed, three signals sent, three events processed by the task.  But the interrupt doesn't have the power to cause the task to run - it's a cooperative exchange between the ISR and the task.

 

 

 

 

Nicholas O. Lindan

Cleveland Engineering Design, LLC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nicholas,  first thanks for openly sharing your work.  If one wants to learn about rtos or even a larger multi-file projects, use of pointers, etc, then I think it's a great example.  I'll spend some time looking it over and if I can get the time, even play with a few examples.  May even attempt to port it to a different tool set.   Is this an open source project where others can contribute, if so what is the best way to reach you if one has questions?

Here on AvrFreaks, PM or email? 

I would like to see you add "chapters" to your pdf, much like the AVR datasheets, although one can do a text search on a topic to fast forward thru the pdf.

Thanks

Jim

 

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Tue. Oct 30, 2018 - 06:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Nicholas,  first thanks for openly sharing your work.  <Open source ....>

 

You are very welcome.

 

It's not open source in GitHub/forks sense.  You are free to make any changes as you see fit, not that anyone would need/want my permission.

 

If you have changes to suggest this forum is probably the best place.

 

ki0bk wrote:

I would like to see you add "chapters" to your pdf

 

So would I.  The method I use, WordPerfect's pdf output, doesn't do chapters; it also produces the most awful bloated pdf files.

 

 

 

 

 

 

Nicholas O. Lindan

Cleveland Engineering Design, LLC

Last Edited: Tue. Oct 30, 2018 - 07:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Version 1.03 is available on Sourceforge https://sourceforge.net/projects...

 

This expands on the semaphores section in the manual, adds more semaphore demo/test programs and fixes a bug with initializing resource owning tasks.

 

Take enough morning showers and you end up with a new software release.

Nicholas O. Lindan

Cleveland Engineering Design, LLC