rtos on bloatware vs int on 8 bit

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

Hi,

I've been reading about rtos with GNU/Linux. These documents discuss rtos on the 32 and 64 bit level (not the humble but mighty 8 bit uC).

The mainstream definition of rtos on these platforms is the ability to implicitly define CPU response times and not wait for the CPU to respond after a file swap or something....

But...what's the big deal? Most if not all of these documents are penned by individuals who might have a hard time knowing 8-bit design constraints.

I'm having problems drawing a distinct line between rtos and proper use of interrupts.... and that means the 8 bit wins over bloated hardware with rtos, right? :shock:

Help me out here...thanks.

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

This is how I see it.

"Software people" are not really busy with the hardware, if its labled with 12GigaHz cpu they assume its good enough for playing 3d pong... and it would need atleast 512mb ram because they want to do alpha blending with a motion picture.

Hardware people tend to focus on what is possible with the knowledge they have over their hardware and then implement a much more lightweigh software package for it.

An 8 bit rtos is not directly unsuitable for performing highly complex tasks. Nor is a 64 bit machine bad in doing low level tasks... Just balance the scales a bit till you found the most economical solution.. If you can get a 10000,- euro development package that allows you to write and debug software in 3 months, or a 100 euro dev package that needs you to debug for atleast a year ...... Most of those more expensive packages also include over weighted/powered baseboards.

Thats now i see it :roll:

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

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

Hi Doc! :)

Um, what exactly are you asking here?

Defining exactly what an RTOS means is difficult, as witnessed by a Google search for the definition. IIRC, an RTOS means that you have an Operating System where the response time to an input is deterministic. The amount of time it takes to respond, depends upon the processor, and the design of the RTOS. Usually the response time is defined as quick enough to be able to respond in "real-time". However the definition of "real-time" can be debated. One can define it as "able to handle the frequency of inputs of the system", whatever system you're building.

Now that I've said all that, it will probably spark an interesting debate...... :)

So perhaps it would be better to narrow down what you're interested in doing or asking.

HTH
Eric

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

I think the definition of 'real-time' is what escapes me. After all, interrupts still provide a low level of real-time responsiveness, but interrupts do not rely on an OS. So are authors tossing the rtos design around like there is no other way to accomplish the same tasks? Or are they simply unaware of what can be accomplished without the rtos?

And to complicate it more, I'm wondering why, if something is so important to interrupt the CPU during a file swap (like stopping a machine to save someones fingers...) then why was the system designed in the digital world anyway? Shouldn't it have been put in a subsystem with discreet components and not a CPU?

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

The definition of a "real-time" system is simple : It's a system that does what it needs to do, in time.
Whatever that timeframe is, depends on your needs, be it a nuclear power plant controller or a goldfish watering system.
And it has no coupling to OS whatsoever, many (if not most) smaller realtime systems do not have an OS at all. An OS WILL make the system slower, but that slight slowdown may not be critical, and may be balanced by the other features that an OS will offer.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Well let's limit the conversation, for the moment, to AVR embedded systems instead of RTOSes and Linux and file swapping and stuff that you probably won't find on an AVR. This is just so we don't bring in the whole kitchen sink....

Yes, interrupts provide the lowest-level of real-time responsiveness, and they do not rely on an OS. There is a class of embedded programs, that do not have an RTOS, or any type of Real Time Executive, called main() + isr. This means that the program has a main() function (we're talking C language here) with an infinite loop, plus Interrupt Service Routines (ISR). The infinite loop takes care of calling any necessary functions for the system. And the ISRs process any events that need to interrupt the main code. This is the most basic level.

Then you realize that all of those functions being called in the infinite loop in main(), really are tasks that the system needs to do. And sometimes you want those tasks, not to be executed on every sequence of the main() infinite loop, but perhaps at a particular frequency (whether every 25 milliseconds, or every 2 seconds). And then you have to figure out how to get those taks to co-operate and work together. Sometime you would like a task to interrupt another task. Or you may want to have a task send data or commands to another task. All of those things (and probably more) can be provided by a Real-Time Operating System. An RTOS gives you task scheduling, multi-tasking, system timers, etc. An RTOS will hook into some of the processor interrupts to achieve this. And then there are different designs of RTOSes, co-operative, or pre-emptive. There are whole Computer Science courses devoted to the study and design of Operating Systems.

So, like with all other engineering, there are tradeoffs. You perhaps lose some response time, but you gain the ability to better organize the whole system and with that organization, you can scale up farily easily.

HTH
Eric

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

Maybe a new term is in order? RTNOS, or Real Time No Operating System? This new term will help those of us who do not use an OS to feel recognized as equally important. RTOS always seemed to carry a mystique about it.

thanks for the comments!

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

The rtos is the tool to manage cpu tasks, memory, io devices. Like Eric says, lets restrict the picture to embedded systems... no disks, no swapping. But even small systems have multiple things to do 'simultaneously'. Teller machine, gas pump, even a lowly vending machine.... In fact that might be a good example of something that is simple enough to do with a main loop of subroutine calls and a couple of interrupt handlers. (When I was at ECC simulation, we 'beat our swords into plowshares' and made a bunch of vending machines for Snapple... I learned a LOT about vending machines there for a year or two), but this system is also complicated enough to actually seem SIMPLER by carving it up into tasks. Now you write each task like it was a separate program, and you use the os to keep the tasks running. Now what to put in a task... rule of thumb? Anything that is 'asynchrounous' with the main loop.... keypad, bill machine, coin machine, compressor on off and temperature, scroll the display, and actually vend product with all those motors and relays and whatever else. So there's 5 or 6 things. I guess the tricky part is when the tasks are sort of intertwined and need to talk to each other... then we get to learn about several tools for interprocess communication (semaphores, message queues, mailboxes) Tomorrows class will be on priority inversion and monotonic rate scheduling.....

Imagecraft compiler user

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

bobgardner wrote:
Tomorrows class will be on priority inversion and monotonic rate scheduling.....

Class texts:
http://en.wikipedia.org/wiki/Pri...
http://en.wikipedia.org/wiki/Rat...

Pop quiz after lecture. ;)

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

Are you grading on a curve? If so, I'll take the pass/fail option!

IIRC, there has been a lot of discussion on this forum about reseting vectors for interrupts. Am I correct in thinking that really these discussions were attempting to address these issues of priority (and mimic some features of an OS)?

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

I always try to make the program as simple as possible. If use the serial port for debugging, I usually start out in polled mode. If I need to grab a stream of chars coming in the serial, I'll turn on rx interrupts. Similar logic to timing.... start out counting a 1ms interrupt to get simnple timings, etc. About this level of complexity, we start seeing the questions here on freaks where the guys debugging their programs are wondering "What happens if the char comes in while I'm servicing the timer int?" Or the other way around? Gee, do we need to re-enable interrupts in the interrupt handler to keep from missing the other (higher priority) interrupts? There is a whole chapter in Jean Labrosse's ucos-II book about how the task scheduler in ucos can select which task should be run based on priorities of ready to run tasks. I think learning/using the rtos features is a lot of work, but it pays off when you master it. Similar to learning a new complicated computer language (which I also need to do) or learning how to do CPLDs and FPGAs. Say Doc, I've got this pain here that's been bothering me for a while.....

Imagecraft compiler user

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

Quote:
RTNOS, or Real Time No Operating System?

In OS taxonomy, the Polling Loop is a particular form of Run To Completion
scheduler, which itself is a particular form of Cooperative Multitasking.
With a polling loop like

for (;;) { do_this(); do_that(); }

the do_XXX()-s are tasks, scheduled Round Robin. Beyond that, it's just a
question of features.

Feel better? (:-))

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

Hi
there is two ways for real time programming :

- the asynchronous real time programming uses RTOS (but I think that this is not a solution for 8 bits microcontrollers),

- the synchronous programming uses a program lauched periodically ( by an IT, for example every 10 ms). Fisrt you take in to account all the inputs, 2nd, you make sequentially all your treatments, 3rd, you write your ouputs.
Interruptions read asynchronous inputs, for example, the uart IT take the incomming octet and store it into a buffer.Interruption programs must be as short as possible.
Traditionnal langages for synchronous programming are Esterel, Lustre, Signal, but for non critical systems, I program directly in C ( Thank EW for Winavr).

Daniel

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

>Traditionnal langages for synchronous programming are Esterel, Lustre, Signal,
======================================================
Computers are wonderful. I've been messing with them since hi school ('68 ish). Nice to know you can read books about a subject for 35 years and have someone mention 3 languages you have never even heard the name of.

Imagecraft compiler user

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

bobgardner wrote:
I always try to make the program as simple as possible.

I think 'swords into plowshares' is really a great perspective. I'll remember this one.

bobgardner wrote:
Say Doc, I've got this pain here that's been bothering me for a while.....

Sorry, I am licensed in Kansas but not Florida. Besides, you might need surgery for that pain of yours, and remote robotic surgery takes more than 8 bits at a time to do it right. Dunno, maybe we could get the job done with qrprox http://tinyurl.com/7wdbh and AVR.

mckenney wrote:
In OS taxonomy, the Polling Loop is a particular form of Run To Completion
scheduler, which itself is a particular form of Cooperative Multitasking.
With a polling loop like

for (;;) { do_this(); do_that(); }

the do_XXX()-s are tasks, scheduled Round Robin. Beyond that, it's just a
question of features.

OK, so with an OS, is there any kind of looping going on with the CPU like there is in the AVR with

while()
{//wait for interrupts and use isr};

?

bobgardner wrote:
Nice to know you can read books about a subject for 35 years and have someone mention 3 languages you have never even heard the name of.

now that does make me feel better!

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

Quote:
so with an OS, is there any kind of looping going on

Yes. At its core, an OS (conceptually) looks like:

for (;;) {if (something_to_run) run_something();}

That said, there's about a zillion (I'm pretty sure that's accurate) ways to do this,
and you may not recognize this code when you see it.

I'm not trying to be pedantic here -- I think it's useful to describe a continuum
rather than OS/no-OS since:
a) It's evident that OSes aren't magic (merely illusion); it's just a Program Counter
going from here to there.
b) You can start to think of an OS as primarily an organizational mechanism, and its
features a means of abstraction.
c) You can apply to your "little OS" some of the same analytical tools and notions
(latency/throughput/concurrency, e.g.) that the "big guys" use.

In answer to your earlier question, I don't think "RTOS" has a place in the OS
taxonomy, since "Real Time" is really orthogonal. Originally it was
intended to mean "OS with features conducive to writing applications with
guaranteed Real-Time response ((*)Analysis not included)", but now it's just
Marketing-Speak for "OS for a small system".

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

A-ha! So an OS is more like a resident interpreter (or a 'language') capable of managing threads? And hacking the kernel (say, GNU/Linux) it really means tailoring the OS to the specific requirements of the software and capabilities of the hardware?

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

Well, close.

An interpreter is something else entirely:
http://en.wikipedia.org/wiki/Int...

... and it's definitely not a language in the sense of a programming language:
http://en.wikipedia.org/wiki/Pro...

... you could probably interchange the term threads and tasks here in this context. Though that might be splitting hairs:
http://en.wikipedia.org/wiki/Thr...

So I would say that the OS is a "construct" that is capable of managing tasks. (It depends on the scale of the OS whether it is simple tasks in an RTOS, or whether you have full blown processes and threads in say the Linux kernel.) And the term "managing", covers a lot as well.

Eric

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

Hey,

For a good understanding of what a RTOS is and why it's useful, check the Salvo user manual at http://www.pumpkininc.com/conten... and skip to chapter 2.

Regards,

-Colin

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

In terms of O/S you can have real time or non real time. Real time declares that for a given stimulus, the o/s will respond in a given time. The value of 'real time' varies - as long as it is adequate for your application it is ok! Put another way, if your app requires specific response in 1ms and the O/S says it can do it on 100us then you are ok. So non real-time says that the O/S will get around to what is required in its own sweet time. For example Windows - if Windows is tied up doing file access, the rest of your app can slow down or stop. For the most time things happen swiftly - but there are no guarantees.

Then we get down into the various methods of task swapping - co-operative and pre-emptive. Co-operative means each task does what it has to then the next task runs etc. If one task sits in a loop, the rest of the tasks stop. Windows does this with its message queue - when you click a button etc, this causes an event to be placed in a queue and your app has a main loop that reads the queue and has a big switch statement to call the code to process that event.Once the event code has processed what it has to, it goes back to the top again. Visual Basic hides all these gory details.
The other method is pre-emption. This is pretty much what happens when an interrupt fires - the cpu saves the return address and goes to the ISR pointed to by the vector address. Basically, anything that was happening has been stopped and something else run. In a O/S there is normally a timer tick interrupt that runs a piece of code called the 'scheduler'. The scheduler decides which task should run next. Rather than just return from the timer tick interrupt, the code saves the current context (stack & regs) of the task that was running into ram and loads the new task's context. Pretty much like putting one task into a box for later and pulling a new task out of it's box. The design of the scheduler affects the real time aspect and priority structure of how the tasks are run.

In terms of a small cpu like the AVR - pre-emptive chews up a lot of ram as each task needs its own area of stack and somewhere to store the cpu context (cpu regs). It also has a slice of execution overhead - you need to pay for its work! So you probably would not choose this if you were using a '2313! Most likely a Mega due to the extra ram. Historically, on most small cpus co-operative has been the choice as effectively you only have one task - the main loop. To code using co-operative means each 'task' must do its job the exit as fast as possible without sitting in a wait loop. You can use 'finite state machines' to implement these tasks. There's been plenty written about these techniques - especially for Basic Stamps (you have no choice - there is only one task!) and PIC's as it's difficult if not impossible to do pre-emptive on the older models. Things like fuel injection computers use the co-operative method. Small but time critical stuff is done in the interrupts fired by timers and inputs, but the main loop of getting the inputs,processing the data and updating the ouputs are done as one big loop. Timers can set flags that are tested by the code to decide whether certain parts execute in the current loop.

So there you have it. Computer Science 101 in 10 mins!

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

Yes... little Johnny in row 3..... what's that? Does the scheduler run every timer tick? Yes I think so. What? How often does the timer tick in windows on a 1GHz processor? Why I don't know. Do any of you in the class know?

Imagecraft compiler user

Last Edited: Sat. May 7, 2005 - 07:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
OK, so with an OS, is there any kind of looping going on with the CPU like there is in the AVR with

while()
{//wait for interrupts and use isr};

?

in the case of a pre-emptive RTOS (easier to explain) you have a timer ISR
(tick) that periodically (say every millisecond) calls a scheduler.

The scheduler suspends the current task... and selects the next task that is ready to run....

Say I have some push switches and I need to check them every 10mS (not realistic).......the period of that task(A) will be 10 ticks. i
Then I have a 4 digit LED display....which I need to update every 5mS (not realstic) so the the period of this task(B) will be 5 ticks.

Now assign priority level 2 (highest) to task A and priority level 1 to task A.
We need an idle task with priority level 0.....i.e. something to do when we have nothing else.

The scheduler will choose and the tasks as follows:

A
B
idle
idle
idle
B
idle
idle
idle
idle
A
B

and because task A and task B are like two separate programs.....even if task A gets stuck in a loop....task B should still run. and because I can assign priority....I know that my highest prioity task will always be executed periodically on the dot.

oh look the processor runs idle most of the time.....maybe I can have another task to control a motor, and another to run an LCD and another.......there's no stopping me.

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

You can think of an OS as a set of routines that do something
that programs usually need. So, you gather this set of very
useful and frequently used routines and call it an OS (let's say
a routine to setup UART communication, or to get an ADC
sample).
But an OS is more than this; you can have these routines
"packed" together as a library. Additionally, the OS provides
"services" to you. Things that usually make your live easier
when programming, like hardware abstractions and
programming models. It can also provide you hardware
independance.
"Threads" are just a programming model. You can do the
same things using other models, such as event-based. Both
these models were already described here.
When you stick the label "realtime" in an OS, it usually means
at least that:

A) Interrupt latency is bounded. It is garanteed that an interrupt
has a certain "small" maximum and ~constant (for
predictability) processing time.
B) There is preemption. At any time, the process (or thread,
which for these purposes you can think as being the same
thing) running in the processor is the one with the highest
priority, and this thread is executed for how long it needs.

A) is important because in some systems you have a rigid
small time to respond to an event (let's say, a fire detector that
raises its alarm).
In a non-realtime OS, B) doesn't usually happen. This is
because, as someone already said, the "scheduling" (the
process of decision of what process or thread should be run
next) is performed at fixed intervals in time (in Linux running on
IA32 it used to be 10ms). So a higher priority thread would
have to wait until the next "10ms" to get running.

This is just the tip of the iceberg. It is very very dificult to talk
about this topic without introducing a bunch of concepts and
nomenclature. If you'e really interested in this, I sugest you get
a book on OS's. Maybe on from Mr. Andrew S. Tanembaum, a
well known "authority" in the subject.

Embedded Dreams
One day, knowledge will replace money.

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

My simple take on this subject is that RTOS is a chunk of code you paste into every micro you use in order to make designing software for embedded systems easier. It is a trade off involving code space and speed for ease and consistence in the software design process. However, making the design of embedded systems software easier can be done in other ways. Coding frameworks can provide equivalent aid to the embedded systems developer. By sticking to any of several software design idioms, you can achieve the benefits of an RTOS without all of the sacrifices. An idiom I am familiar with is Quantum Programming which is promoted by Miro Samek. http://www.quantum-leaps.com/

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

Quote:
I think the definition of 'real-time' is what escapes me. After all, interrupts still provide a low level of real-time responsiveness, but interrupts do not rely on an OS.

Forget interrupts for a while. If the quality of some system functionality depends on ending a computational task at a certain time that might be inconsistemt with concurrent requiremets on short response time on external events. Just imagine how hard it is for yourself to meet a dead line if you get interrupted all the time. CPU's has the same problem.

In this context real time is about delivering a certain amount of computational power, meeting start times and meeting deadlines. There are also different cost functions associated the the time constraints. If a cost function rises sharply constraints are hard (as in hard real time). If the rise is more graceful the constraints are soft (as in soft real time). If the cost is high the system functionality is critical. If the cost is low the system functionality is uncritical.

Cheers

Olof