How ordinary embedded differs from RTOS code?

There seems to be a problem with your keyboard that misses out characters, mainly vowels...

An RTOS is a program running on the microcontroller/processor upon which your own application code runs - in exactly the same way that Windows or Linux runs your code on your PC. There are many available - VxWorks, QNX, FreeRTOS, uCos, etc - but they do provide a layer of abstraction between your code and the hardware.

You do not need to have one at all if you are happy to write your program to run directly on the processor and handle its initialisation yourself - not a massively difficult task on your PIC in my opinion. If you want to then check out

for a port that will work on bigger PICs and a lot of good information about what an RTOS is actually doing.

Ur writing a news posting, nt a txt msg. Use full words, please.

Many "ordinary" embedded systems use RTOSs; I assume you mean what's the difference with using an RTOS vs. not.

You're writing code that must carry out a number of independent tasks. With an RTOS you can assign each of these to an RTOS task; without you usually write a task loop that does everything in one context.

With an RTOS as described above the code for each task can be fairly independent of the rest of the code base. The code for each task can read like a 'regular' computer program, with OS calls at every spot where you need to stop for more data or want to yield execution. If you're using a preemptive multitasker, you can write the low priority tasks without having to worry about hogging the processor.

The usual way to implement a task loop is to have an executive loop, usually in 'main', that calls all of the 'task' functions. It may do so after checking flags, etc., or the task functions may check the flags themselves. In any case, each iteration of the task loop means calling each function at it's head. This means that if you must implement a number of different states in a task function you have to define a state variable and have a giant switch statement that goes to the right code, updates the state, then exits gracefully. It also means that any low-priority code must be exquisitely aware of the needs of the high-priority code, and must be broken down into little bits to guarantee that the high-priority code gets enough of the processor.

The basic trade off is this: With an RTOS you have to find a free version or pay for a commercial one, then you have to get the blasted thing working, then you have to learn all it's quirks, then you have to _keep_ it working. With a task loop you can start working immediately, but all your code impacts all your other code, and each piece of code is bigger.

In general an RTOS is better if you have one processor doing a whole bunch of different things, particularly if the priorities are significantly different. OTOH, a task loop is better if you have a slim, simple problem.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

SIMPLE. The difference is similar to the difference between bread and cheese. Sometime you have one, somtimes the other and somethimes BOTH.

I always say an embedded system is a computer system that does not look like a computer to the end user. e.g. your PC keyboard includes a processor, but you don't consider that a computer do you?

RTOS is the accronym for Real Time Operating System. A characteristic of Real Time systems is they are deadline driven. IOW, a result returned late is as bad (or worse) than a wrong result. For example a Computer controller in a factory work cell area is clearly a computer. it has hard realtime constraints, but the users know it and treat it as a computer.

many embedded systems also have realtime constraints. Your laser printer needs to process the image, control motors, read sensors all under realtime constraints. It is an example of being both embedded and realtime. (whether it uses a RTOS is known to the designers). I used this as an example becuase I have worked on such systems (well a typesetter product actually, but same basic architecture).

HTH. Ed

This is a BSP or device drivers, not an RTOS

A value not worth spelling out full words?

--
Dan Henry

Guys, come on, English is not his native language. Cut him some slack... (and Madan, take the groups comments to heart next time)

For the English, yes. For the lazy inconsiderate abbreviations, no.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

..so, what's the "B" stand for, C.B.?

--Gene