i have done some coding on pic18f2550. but never use RTOS till now. but i want to use and learn about RTOS. I have read about RTOS in college days and i also read in between.
So which RTOS could be better to use??
i am very new to RTOS programming so is there any Tutorials???

 

You may have success if you wander over to http://www.freertos.org/ and see what they say.

I've never has reason to need an OS.

 

If you are starting out, you probably should avoid the 8 bit PICs. From FreeRTOS:

Please note that the segmented memory on the PIC18 makes it a less than ideal candidate for use with an RTOS.

FreeRTOS uses C18 which is going obsolete. XC8 with its OCG optimizer won't compile Salvo and many other RTOS's (including my own) at all. If you look through the various offerings, most start with PIC24 and PIC32. These parts have better architectures for task switching. ARM with Keil RTX looks intriguing.

You can learn a lot from the tutorials that go with most RTOSs. FreeRTOS charges for theirs.

Chapter 2 of the free Salvo Manual has a nice overview. If you read and understood this and a few other chapters, you'd be well on your way. AN777 describes a project using Salvo with some good tutorial stuff. Of note is how clean the code can be when task scheduling and communication is done behind the scenes via the OS.

Poke around the Keil RTX site as well.

MicroC OS II by Jean J. Labrosse has its detractors but its a solid introduction with detailed explanations and source code. uCOS won't run on a PIC18 though.

Keep in mind that the term 'RTOS' is frequently misused. Just because it multitasks, its not necessarily 'real time'. Most of the 8 bit PIC ones I have seen/used/written are some variant of cooperative multitasking.

Personally, all my code has some degree of multitasking, even if its just nested state machines. I find it much easier to manage large code that way. Learning something about the basics should pay off handsomely.

Good luck!

 

Personally, all my code has some degree of multitasking, even if its just nested state machines. I find it much easier to manage large code that way. Learning something about the basics should pay off handsomely.

Good luck!

For most PIC18 projects a 'state machine' with I/O ISR type implementation of cooperative multitasking is much more efficient as there is little support at that level for the correct hardware assist needed for good process swapping and with two levels of interrupts, limited resource locking, no DMA, no virtual machine and not even a primitive MMU a large percentage of the CPU and limited memory will be used to just copy data between processes.

Most beginners at the PIC18 level have really no idea how to properly use preemption in programs. It sounds good as a concept but it's a loaded minefield to debug.
http://www.barrgroup.com/Embedded-Systems/How-To/Preemption-Perils

 

Thanks for the link, nsaspook. Agreed. A preemptive OS would be impractical on PIC18 - and not necessary for most things.

 

...A preemptive OS would be impractical on PIC18 - and not necessary for most things.

Further, I'd like to know of a single 18F application where an OS/RTOS would be advantageous over traditional firmware programming, and why.

Years ago, Microchip was pushing an asm implementation of a non-preemptive "RTOS" using a 1ms task switcher.

The rub was, each process could take no longer than 1 ms to complete its task, and for those that completed in less than 1ms, the cpu would idle until the remaining time expired. The selling point was that the task execution rate was "determinate". I saw it as unnecessary constraints, and a waste of valuable instruction cycles.

 

Further, I'd like to know of a single 18F application where an OS/RTOS would be advantageous over traditional firmware programming, and why.

The OS/RTOS approach is the traditional way schools teach multi-processing based programming so I'm not surprised it keeps coming up. Very little time is devoted to Finite state machines because IMO most CS classes are not aimed at programming bare metal. If you're programming bare metal you don't need the OS abstraction getting in the way until you need complex human interaction and by that time you need at least a PIC32 type CPU to handle the program size and complexity so an preemptive multitasking RTOS might be a help at that stage.

 

Further, I'd like to know of a single 18F application where an OS/RTOS would be advantageous over traditional firmware programming, and why.

If PIC does multiple tasks (as in most applicaions), it does need some sort of scheduler however primitive it might be. Well designed scheduler could be very advantageous when you need to put all your tasks together.

Preentive multitasking looks more like a non-sense for small PIC both because it is not needed and because it creates unnecessary overhead. Cooperative multitasking is much better. Unfortunately, most RTOS are preemptive and thus not very useful. Hence many people don't like them.