[Efi332] cMOS

[Andrei Chichak]

At 07:38 AM 4/15/2005, you wrote:
>Hello list,
>
>I'm told some folks are using cMOS for MPC555 based applications.

Umm, do you mean uC/OS? CMOS is a complimentary metal oxide semiconductor, 
uC/OS is an RTOS (real time operating system).

>Can anyone
>articulate some of the major benefits of using an OS (assume this is
>real-time OS) as opposed to a simple control loop and some interrupts?

(SET RandomRamblings 1)

Can you walk? Can you chew gum? Can you sing "Psycho Killer"? How about 
juggle? Now do them all at the same time. How about if you had four people 
and a cart, a hot dog vendor pushing the cart and on the cart you had a 
teenage girl, David Byrne, and one of the Brothers Karamazov? Same result? 
 From a black box point of view, yes.

Okay, using four people is actually a case of multi-processing. If you 
could push the cart for a second, stop, chew gum, stop, sing a couple of 
words, stop, and juggle for a second, then start all over again, that would 
be easier, but if the juggling pins are in mid air, that would be a 
problem, but with enough coordination and speed we could learn. Now your 
agent says that for your next gig you have to tap-dance at the same time.

I have found that, in a non-rigorously defined development project, using 
an RTOS saves your butt so often that it is a very small price to pay for 
the flexibility it affords.

(what the hell am I talking about?)

Here's the scoop, if you had a project where all of the design has been 
figured out down to the last state machine transition and going from an 8K 
memory footprint to 16K would mean changing processors or including a 
memory chip which would make your project too big, too expensive, or too 
slow, then you craft a program that does the absolute minimum.

But if someone then says, "hey let's put in a data logging feature", or 
"hey I want a serial port LCD screen", then you have to figure out where to 
shoehorn in the extra functionality so it doesn't affect your finely tuned 
timing. You quit and go on to the next job.

Running an RTOS might take more space, time, and money  than a simple event 
loop and it is almost impossible to convince someone to use an RTOS if they 
have never used one, until they do a project that NEEDED one. By then a lot 
of people have ended up writing their own and they are typically less 
flexible, poorly documented, and are less space, time, and money efficient.

The structure of a process within an RTOS is a simple infinite loop that 
does some work and goes to sleep until the next scan is required. The RTOS 
takes care of what to do when the system is not busy doing something else, 
like passing messages back and forth or running another process that does 
data logging or a serial communications remote control interpreter. 
Meanwhile, the simple infinite loop just keeps on looping and sleeping, 
completely oblivious to the other task gyrations.

The interrupts are still used and are at the core of the task switching 
system. The RTOS does some very clever gymnastics that make it look like 
only one process is running. Then when the task timer interrupt fires, the 
running process is put on hold, the process with the highest priority that 
is ready to run has its stack pointer and registers restored and a return 
from interrupt is executed. The second process continues like it never 
stopped. UNIX does this, windows does this, your Linksys router does this, 
your iPod does this.

Since the RTOS takes care of the sleeping and waking of processes, you 
don't have to write that part. Since you can have more than one 
simultaneous process, they can be simpler than if they were combined in a 
"simple" control loop.

It is like having the TPU to take care of the timing stuff while the CPU 
takes care of the high level control stuff. You could do the timing stuff 
in the CPU and just send out pulses on parallel port bits.

In the case of an engine management system, I would have one process to 
take care of the ignition system, one to take care of the injection system, 
a monitor process to grab the values off of the ADCs periodically and make 
them available to the rest of the system, one to act as an error logger, 
one as a serial comm interpreter, one to act as a human interface 
controller, and the main process to watch the other processes and reset the 
system if any of them quits working properly. To wrestle all of these 
activities into a single monolithic program is doable, people do it every 
day, but I have had to debug someone else's monolith and I wouldn't wish it 
on anyone.

The system that I developed for work runs on a 16MHz 68332, has 11 
processes, 33 channels of ADC, just about uses up all of the TPU channels, 
and typically runs at about 22% of the CPU's capacity. The high priority 
processes are very time constant, you could set a clock by them, and the 
low priority processes have very little time wobble. Our other processors 
do not use an RTOS, their function is small and very specific, they are 
required to run without external memory, and their timing is required to be 
"as fast as possible". We count calculation loop cycles on these machines.

RTOS's should not be applied to all projects and processors, and the same 
is true for monolithic control loops. The more you know about how a system 
works, the less you need an RTOS. If you expect the system to evolve, the 
more an RTOS makes sense.

The best thing about uC/OS is the price. For hobby stuff, it's free. For 
commercial purposes, it's cheap. The full source code is published in a 
book. It is robust and is not feature poor. The author is actively working 
on extensions, but is not altering the interfaces. The user community is 
porting it to a raft of processors (from the micro to the mega) and 
compilers (from the free to the $$$$$$$$$). Did I mention it is cheap.

How that?

Andrei

>Thanks,
>
>Dave


------------------------------
Andrei Chichak

4024-120 Street                         (780)434-6266
Edmonton, Alberta                       agchichak at compusmart.ab.ca
Canada
T6J 1X8

Lat: 53? 28' 40" N
Lon: 113? 32' 27" W