RTOS for PIC micros

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
I am really interested in writing or just using a freely available RTOS for PICmicros but not in C (a know almost nothing about C). I work always in assembler.

Other than what is wirten in AN585 from Microchip I couldn't find anything complete making sense.

Could anyone point in the right direction?

Gracias

Agustín Tomás
 

beenthere

Joined Apr 20, 2004
15,819
Hi,

PIC microprocessors really don't support operating systems. They just control things like vending machines and parts of industrial processes.

To make them respond in real time, you write the control code so it accepts the vital inputs as interupts. After handling the interrupt, you go back to the main loop. This is not possible in an operating system such as Windows, and the need to have a computer actually respond to real-world events led someone to write a Real-Time Operating System for full-sized computers.

With microcontrollers, life is much easier - just write your own. It's very easy at the assembler level, too.
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Originally posted by beenthere@Nov 15 2004, 07:49 PM
With microcontrollers, life is much easier - just write your own. It's very easy at the assembler level, too.
Beenthere,

It's easy if you know how to. Where could I learn that? Any easy to read example or text not based in a non-PIC micro?

I think I should do something to progress in that direction. Basically I got a certain familiarity with a 16F877 and I feel I could try more complex things.

C language is unknown to me.

Thanks for replying.
 

beenthere

Joined Apr 20, 2004
15,819
Hi,

I've got a reference for the 6502, but it's pretty old. Try "6502 Assembly Language Programming" by Lance A. Leventhal. Published by Osborne McGraw-Hill, ISBN# 0-070881216-X. It may be out of print. I used the Rockwell RC65C02. It had extensions to the 6502 code set that made it perfect for real-time programming. The old 8051 still has stuff available in the web, and might be a good source for information. Anything dealing with 68000 stuff might be good, too.

In general, most of the memory-oriented processors do better at real-time functions than the resgister-oriented ones. There's a lot of microcontrollers around and there may be lots of programming examples available for them. The technique is always the same in handling interrupts - just the exact code for your device will be different.

In outline, you have a loop running until some terminating condition is met. It may poll external parts of the system, like a keypad or door open switches. Critical events send an interrupt to the processor. Some processors have multiple interrupt lines, some have only one.

In response, the processor saves the current state on the stack, locks out further interrupts, does whatever action is necessary, restores the stack, and reeanbles interrupts. Failing to lock out new interrupts while handling a current one results in an inpossible situation in the stack, which usually has the internal registers pushed on it. If they get lost in the confusion, then your machine will reliably crash.

I have no experience in any of the C languages. Assembler is probably going to be most effective for your PIC.
 

aekalman

Joined Nov 17, 2004
4
Hi.

Salvo is an event-driven, priority-based RTOS that runs on all PICs, and is written in C.

You may find the chapter "RTOS Fundamentals" in our User Manual of use to you.

The main difficulty with writing an RTOS for the PICs (especially the PIC12, PIC16 and PIC17 families) is that the PICs do not have an addressable stack, i.e. no stack pointer. It is decidedly non-trivial to have the functionality you would expect in an RTOS (e.g. tick-based delays, waiting on events with timeouts, etc.) without access to that stack, and while keeping RAM requirements to a minimum.

But, as can be seen from the commercial success of Salvo (which runs on PIC, AVR, ARM7, MSP430, 8051, and other platforms), it can be done.

Salvo was originally written in Assembly for the PIC17C756, BTW. Switching to C was an enormous benefit.

If you want to write your own OS, I'd suggest reading the uC/OS-II book, and also the documentation for CTask, if you can find it on the web.

BTW, Salvo Lite is free and allows you to use up to three tasks and five events with all of the functionality of the paid-for versions of Salvo (e.g. Salvo LE).

Salvo Lite can be downloaded at www.pumpkininc.com

Regards,
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Thanks to you both!

In spite of difficulties in understanding I started to feel more familir with ideas around RTOS.

Andrew, deffinitely, the manual has lot of clear info. Downloaded last night, I did some peeking and looks GOOD.

I know there are advantages in using C but to be honest I feel so confortable with assembler that I never tried seriously to learn it with micros in mind. Sadly that proved an obstacle in RTOS matters, at least to read other people's code.

Now I see why everywhere the 18FXXX are recommended!

Gracias again.
 

aekalman

Joined Nov 17, 2004
4
You're welcome.

There is definitely a learning curve associated with going from Assembly to C.

For example, it's easy to see in Assembly how to do function pointers and call tables. in C, it's not so obvious to the newbie ...

I programmed almost exclusively in Assembly for 10+ years before being forced to move to C because of the benefits of managing very large projects via C's scope rules, and the preprocessor.

Now, I use C almost exclusively, but analyze the Assembler's output and sometimes restructure the C code to generate better machine code. The fact that I'm very comfortable with Assembly now serves me well, as I can be efficient in either C or Assembly.

The big problem with writing an RTOS in assembly is that your investment is nearly useless if you move to a different target family (e.g. PIC to ARM7).

Regards,
 

beenthere

Joined Apr 20, 2004
15,819
Hi,

The good doctor is essentially correct. You inevitably put in enormous effort getting up on assembler stuff, and the nature of progress is that you'll have to move on and kiss all that work goodby.

I used Apple IIe's as carcasses for lab controllers. Easy to put interface cards together, and pretty flexible to utilize. But all the work I put into writing major extensions to an assembler and the functional libraries I wrote became worthless about the time a computer with better storage came along. Also, numbers from an 8 bit machine somehow were less meaningful than from 16 bits. I can do any length floating-point on any machine (as soon as I refer back to my notes, at least).

C still makes me itch, though. K & R were just too anal.
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Hi Andrew & BT,

I've read the Chapter in full. This is by far, the best explanation I ever found for a newbie on that matter. It took time but at least now I understand what they are talking about. Those graphics are simple and because of that, excellent.

I think I should go the C way, sooner or later.

I will complete my next application as a superloop and, next year I will start with C. Just one and half a month ahead, after all :(

The question now is: for a given micro, when you use a RTOS and when you don't?
I am talking of applications already well defined in scope / structure. What makes you to decide using a RTOS or not?

Thanks for your time.
 

beenthere

Joined Apr 20, 2004
15,819
Hi,

Something like a PIC is probably not going to have an elaborare OS to begin with.

Let's use as an example a desktop computer running Windows. The same is going to apply to a Mac, so it's not a slam against Windows, per se.

Down under all the running applications is the ROM BIOS. The Basic Input/Output System. It's job is to service all the standard inputs that are important to the computer. Look at SYSINFO and you can see that the 15 possible interrupt lines are multiply used by the system devices. It's rare to find even one interrupt line not in use. The BIOS will insure that these system interrupts are serviced with priority.

With a set-up like this, an external interrupt is going to have to wait until BIOS is willing to get to it. With a modern processor clocking at several gHz, that probably won't be too long....

But the point of real-time OS's is that the external stuff absolutely, positively has to be dealt with right now. Think of flight control inputs in an F16. Or stopping the flow of an alloying substance into a steel furnace. You have to have immediate response, or the result may not be acceptable - death or rusty stainless steel.

A "real" RTOS has to be able to handle the external interrupts with the highest priority, and only let the BIOS stuff go when things are dealt with. With a PIC, you don't have system devices or a BIOS to get in the way. You can decide when to service external stuff by polling loop, or to write interrupt servicing routines for immediate response. It's your system, so you get to assign the priorities. You get to make the rules.

Have fun - the frustrations og getting it to go are such that it feels great when it finally does what you want. Been there and done that.
 

aekalman

Joined Nov 17, 2004
4
for a given micro, when you use a RTOS and when you don't?
There are lots of BUSINESS reasons for using an RTOS as the foundation of software application. I will address just the more TECHNICAL reasons, for the perspective of a software engineer.

I get asked your question a lot, and I've begun to zero in on the following answer:

Whenever you have things going on asynchronously in a system, an RTOS can be a great benefit, as it manages those things for you in a predictable way.

A simple feature like using a PIC10 to translate an incoming serial stream into another format for output is best implemented in a tight loop.

But as soon as you have multiple things going on at once (e.g. sampling A/D at various rates, serial comms in and out, user interface, general housekeeping, going in and out of sleep mode, etc.) then it becomes increasingly hard to write conventional superloop or state-machine code to handle "all the bases". And it's also brutally difficult to understand such code.

With an RTOS approach, it's much simpler -- whichever task has the highest priority will be the one that's running. So what you end up doing is trading a linear, sequential structure for a rule-based execution in your application. This can be hard to grasp for the novice, but that's why there are good book and manuals and examples out there.

For example, say you want to embed a web server (or simple user interface (UI)) in an existing product. Without an RTOS, you will have to decide where in the superloop you plan to put the web server/UI code. The web server's/UI's responsiveness will be at once locked in by your decision -- as will the overall behavior of the rest of your application. If you want great responsiveness, you'll have to spend lots of time in the web server/UI code, even if no client is connected. If you don't care about responsiveness, then your user experience will suffer. And being in the web server/UI means that you can't be doing other things as often. So it's unlikely that you can easily change the overall responsiveness of the system.

In a very general sense, the RTOS design turns this on its head -- it simply asks "What is important to you?" If the web server's/UI's responsiveness is the most important thing, then you assign the web server/UI task(s) the highest priority, so that they get as much of the processor's power as possible. Other tasks (like sampling) run as often as they need to, but only when the weeb server/UI isn't running -- i.e. only when the web server has nothing to do and therefore the RTOS allows other tasks to run.

Here's a more concrete example. A customer of ours had originally designed a complex communications device using the PIC17C756 is assembly, no RTOS. By the time they filled up the code, it got to the point where the original programmer felt that any further changes were just asking for trouble, as the code had become so complex that it was no longer easily understood. He felt there had to be a better way. He (he's a good programmer, btw) ported our Salvo RTOS to a new, 32-bit embedded processor, and shipped the new product, all in around 4 months. This new product (a successor product) has something like 5 independent high-speed communications channels inside, plus lots of lower-speed stuff like a user interface, sampling, flashing indicators, etc. The point is that by using the RTOS, he was able to separate the code into functional blocks that all worked in harmony, and yielded the required performance, all in a highly asynchronous environment (i.e. stuff could happen in different parts of the system at any time).

Which brings me to my last, admittedly long-winded point. I find that a lot of engineers don't really have a feel for what can be done with the existing CPU power, or how much CPU power is required to get something done. Along the lines of what BT has been alluding to, there are only so many cycles available in a 4MHz PIC (1us/instruction), and software engineers should recognize how to use those cycles best. I tend to have this rule of thumb for desired responsiveness:

1-200 instructions: Do it in a tight loop
200-2,000 instructions: Do it with ISRs
2,000 instructions and beyond: Do it with an RTOS

What this means is that if you have timing requirements that are really tight (1-200us resolution), you'll probably have to code that in a very tight loop (maybe even in assembly), to have totally deterministic, jitter-free performance. An ISR-based approach will often not work, as the save and restore on entry will take too many cycles, and a lack of vectored, priority-based interrupts will usually mean that running two or more ISRs will ruin your timing.

In the 200-2,000 cycles domain, interrupts are great. You'll get good responsiveness, have enough time to service the interrupts, and the jitter probably won't exceed 100-200 us.

Beyond 2,000 cycles, things are pretty slow, from the microprocessor's viewpoint. Therefore stuff that needs to be done at 500Hz and slower (which isn't slow to a human) is easily handled by the RTOS. It's silly to spend time worry about how you're going to add a battery-monitor function (i.e. task) at 27Hz when the RTOS takes care of that in a couple of lines.

Finally, in order for you to successfully be able to use an RTOS in a typical low-cost embedded application, it's imperative that the RTOS not step on interrupts. This way, you can code the "interrupt side" of your application without worrying that the "RTOS side" will mess up your interrupt response times, etc.

Whew!
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Andrew,

Thanks for taking the time and passing so much of your knowledge to me!

I feel encouraged to consider things with a better disposition with a minimal but clear understanding to start with.

I was lucky to have you running across my post in this forum.

GRACIAS again.
 

cyberhehe

Joined Oct 6, 2004
61
IMO, writing RTOS is good if you need reusability of your codes in the future, and maybe shared to every one else for reuse.

The RTOS way takes you into implementing your Software into multiple modules separated into different purposes, like the kernel, HW drivers, Display Drivers, utilities and Applications.
 
Hi

I'm very new to pic programming myself. However with the help of Myke Predko's book 'Programming and Customizing Pic Microcontrollers' (ISBN 0-07-136172-3) I have learnt a great deal and have successfully completed two not uncomplicated projects. The relevence is that he has written and supplies with the book, a cheap and cheerful RTOS written in assembly, with perfectly acceptable task switching times and variable space. It is for the PIC18C452 and I am in the process of writing an application using it at the moment for the PIC18F452 and while not without the occasional glitch or two, it's performing well. I don't pretend to have a bredth of knowledge in this field but it seems to me that this is just what you're after.

Good luck.
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
I've read too many bad comments on the errors and lack of proofreading of that book. What is your opinion?

I am really interested.

Thanks for replying.
 
Top