Searching \ for '[EE]:Embedded system ,RTOS' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=embedded+system
Search entire site for: 'Embedded system ,RTOS'.

Exact match. Not showing close matches.
PICList Thread
'[EE]:Embedded system ,RTOS'
2001\08\09@065304 by pic list

picon face
Hi,

Good afternoon. i have several issues that i am in
doubt.

1. what is embedded system? what is the difference
between a normal electronic system with a uC, with an
embedded system?

2. i am used to programming pic16F84 and 68hc11. the
procedure is like this. key in the assembly in an
editor, them assemble them to hex file, then download
them to the uC. that's it. the uC can be brought
everywhere and still function the same.

My question is, why people are telling me that i need
a RTOS ( Real Time Operating System ) to develop an
embedded system? They are telling me that drivers need
to be written, so on and so forth. Why?
What role does the RTOS play?

i don't get it, cause i am still looking things at the
binary level.

3. Another issue is the driver issue. When someone
told me that driver need to be written for certain
embedded component, i start to go blank. how should i
start?
Another senior engineer told me that i have actually
been writing drivers without knowing it. really?

Can anyone please enlighten me?

thanks a lot

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\08\09@082204 by Peter Tiang

flavicon
face
> Hi,
>
> Good afternoon. i have several issues that i am in
> doubt.
>
> 1. what is embedded system? what is the difference
> between a normal electronic system with a uC, with an
> embedded system?

   Here's a definition of embedded system:

   http://www.mitre.org/research/y2k/faq/embedded.html#1

{Quote hidden}

   What you have been programming all along
   is what's call the "foreground/background"
   or "superloop" system.

   That is, an application in an infinite loop
   calling different modules/functions to perform
   a desired operation in the "background"

   Occasionally it is "interrupt"ed to perform
   some critical task in the "foreground".
   These are your interrupt subroutines.

   This system works fine for most application.

   Biggest drawback is that modules/functions
   in the "superloop" does not get it's
   share of CPU time at a constant rate, or
   to put in RTOS-speak, it is in a
   non-deterministic manner.
   The rate that your function gets executed
   depends on the time taken by other
   modules/function calls in the loop.

   This becomes a problem when your "background"
   system or "superloop" gets increasingly
   complicated with more and more modules.
   When system that previously works fine,
   but no longer works when new code is
   added to the "superloop".

   How then can you ensure that a function
   IS executed, say every 10 millisecond.
   Task/function response time will be
   "non-deterministic" in your current
   system, because you have to go thru
   the all modules in the "superloop"
   before it gets to your function.

   Best example is a system where you
   enter a key, but sometimes, nothing
   happens until a certain time later.
   Sometime fast, sometime slow.

   This is one side-effect of
   non-deterministic system.

   You probably can use a timer interrupt
   to perform this task.

   But what if you have more and more functions
   that need to be executed every, say 5ms, 50ms,
   1s, 1 hour, 1 day etc.

   This is where a RTOS comes in.
   With an RTOS, every task/module/function
   is given a share of CPU time at a
   predetermined rate and prioritized
   according to a predetermined task
   priority.

   This ensures that the highest priority
   task gets executed as quick as possible
   by the CPU and thus improves and
   optimises overall system responsiveness.

   This means that a task that is just
   waiting for an event (such as keypress)
   can give up CPU time to other more
   important task, instead of hogging
   CPU time in a polling loop.

> i don't get it, cause i am still looking things at the
> binary level.

   You will, once you start working on
   bigger and more complex systems, when
   even assembly coding will no longer
   do.

   You'll most probably need to move on
   to higher-level language such as C.

> 3. Another issue is the driver issue. When someone
> told me that driver need to be written for certain
> embedded component, i start to go blank. how should i
> start?
> Another senior engineer told me that i have actually
> been writing drivers without knowing it. really?

   A driver is just a piece of code that
   you write to make certain piece of
   harware function.

   Say you have an external EEPROM, the
   code you write to interface with that
   EEPROM is the driver.

>
> Can anyone please enlighten me?
>
> thanks a lot
>

   Hope the explanation helps.

   If you want to learn about RTOS, a good
   book is "MicroC/OS-II, The Real-Time Kernel"
   by Jean Labrosse. http://www.micrium.com

   Highly recommended and I'm in no way
   connected to Jean Labrosse or Micrium ;-)

Regards,
Peter Tiang

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\08\09@084333 by Spehro Pefhany

picon face
At 11:39 PM 8/8/01 -0700, you wrote:

>1. what is embedded system? what is the difference
>between a normal electronic system with a uC, with an
>embedded system?

There are arguements about this on USENET regularly,
as in comp.arch.embedded. The difference is clear, not
so clear, then clear again. A PC can be an embedded
system in some circumstances.

>2. i am used to programming pic16F84 and 68hc11. the
>procedure is like this. key in the assembly in an
>editor, them assemble them to hex file, then download
>them to the uC. that's it. the uC can be brought
>everywhere and still function the same.

Rightt....

>My question is, why people are telling me that i need
>a RTOS ( Real Time Operating System ) to develop an
>embedded system? They are telling me that drivers need
>to be written, so on and so forth. Why?
>What role does the RTOS play?

Provides system services (the OS part) specifically
related to real time work (the RT part). You do the
same thing in a crude way when you set up a periodic
interrupt on your PIC, then slice the work between
different tasks depending on a state byte. You can
even get RTOS systems for the PIC, see the "salvo"
product (I have not tried it, but would be interested
in any feedback). Look at the available
services to see if you could use this. At the lowest
level, the RTOS will use some hardware resources of
the chip (a timer, say) and everything will be keyed
off of that (it will use a bit of RAM to keep track
of things. There's nothing magic about them, you
could write your own, given the time and inclination.

>i don't get it, cause i am still looking things at the
>binary level.

It is all 1's and 0's (with the occasional indeterminate
bit) if you get close enough.

>3. Another issue is the driver issue. When someone
>told me that driver need to be written for certain
>embedded component, i start to go blank. how should i
>start?

These terms assume a level of abstraction that doesn't
always exist in small micro programming. If you take
the section of code that goes between your application
and something external, make it a seperate program and
document the interface to it, that's a driver.

>Another senior engineer told me that i have actually
>been writing drivers without knowing it. really?

Probably you've been doing the hard part, but unless
the program interface to it is documented and perhaps
encapsulated in some way, I wouldn't call it a driver.
You'd normally do this anyway, even in assembly, so
as to be able to re-use your code.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\08\09@090152 by uter van ooijen & floortje hanneman

picon face
>1. what is embedded system? what is the difference
>between a normal electronic system with a uC, with an
> embedded system?

The distinction that I make is embedded <-> open

- uC is embedded when the device performs a specific function, that could -
maybe in theory - also be performed by hard-wired digital or even analog
electronics, or by some mechanical, hydrolical etc. equivalent. In most
cases the user interaface is limited or even absent. The interaction with
the hardware is often important and takes a lot of the programming effort.
The hardware is often carefully cost-tuned for the specific purpose. Typical
examples: microwave oven, TV, car electronics, avoinics, watch, mouse.

- a uC is open (general purpose) when it is possible and often done to run a
customer-determined program on the uC. The user interface is often
important, and (consequently) the interaction with the user is often a large
part of the programming effort. The hardware is often design as a compromise
between widely varying ways of use. Typical examples: PC, mainframe, laptop.

There are of course examples that blurr the distinction:
- a Lego mindstorm brik that runs LegOS
- a mobile telephone that runs a game that has been downloaded from the
internet
- a playstation that runs Linux
- a PC without monitor and with a keyboard-simulator working as IP router

Wouter van Ooijen
van Ooijen Technische Informatica: http://www.xs4all.nl/~wf/index.html

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\08\09@100942 by Olin Lathrop

face picon face
> My question is, why people are telling me that i need
> a RTOS ( Real Time Operating System ) to develop an
> embedded system?

Trying to sell you one, perhaps?

> They are telling me that drivers need
> to be written, so on and so forth. Why?
> What role does the RTOS play?

On very small resource limited systems like PICs, an RTOS is just plain
silly.  Yes, I know there are vendors out there who actually sell RTOSs for
PICs, and some of them are on this list, but that doesn't change my opinion.
Most things an RTOS does for you aren't necessary on a PIC, and the ones
that are useful for a particular project are easy to implement yourself.
I've done over two dozen PIC project and never once wished I had an RTOS.

However if the embedded system is using a more "complicated" processor, like
an embedded Pentium or PowerPC, then an RTOS can be useful and will do
things for you that you actually need done.  These systems also have more
resources like RAM, stack, etc, so that you can afford to have an RTOS use
up some of them.

> 3. Another issue is the driver issue. When someone
> told me that driver need to be written for certain
> embedded component, i start to go blank. how should i
> start?
> Another senior engineer told me that i have actually
> been writing drivers without knowing it. really?

Probably not.  You have probably been writing routines that present a
somewhat generalized procedural interface to specific hardware.  These may
look a lot like driver code, but I don't consider them to be drivers.  I
think of a driver as the device-specific code that implements a common
device-independent interface for I/O or whatever.  The application can then
use a common set of routines to access different devices, like hard disk
files, CD files, serial ports, etc.

It is very unlikely that you took your PIC code to this level of
abstraction.  For example, I commonly encapsulate PIC serial I/O in a UART
module which presents the UART_PUT and UART_GET subroutines to the rest of
the system.  This is short of a true driver because the generalized I/O
abtraction layer is missing.  These are still very much UART routines, and
there are no common device-independent PUT and GET routines.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\08\09@115550 by Robert E. Griffith

flavicon
face
>> My question is, why people are telling me that i need
>> a RTOS ( Real Time Operating System ) to develop an ...

There are two general ways to structure an embedded program (I would call
any uC based system an embedded system) - 1) poll loop 2) task switching.

The poll loop way is what you are familiar with. You have a main loop in
your program that checks and controls the various things that your system
does.  If one of these checks/action takes a lot of time, the other
checks/actions have to wait their turn in the loop before they get a chance
to do anything.  If you have a check/action that has to be done without
delay, you can put it in an ISR (interrupt service routine) so that it
interrupts what ever the poll loop is doing.  The ISR puts the poll loop on
hold while it runs then returns control to the poll loop.  The poll loop is
one thread of execution and the ISR is another.  All PIC programming is done
this way because the PICs do not support the other way (task switching) else
for technical reasons.  For many systems, the poll loop way is the best way.
At some point, however, as the complexity raises (more checks/actions and
strict time constraints on what order things have to be done in), it become
difficult or impossible to make the poll loop satisfy all the requirements.

The task switching way does not have a main poll loop.  Instead of having
one loop that checks/does A,B,and C, it lets you have one loop to check/do
A, one loop to check/do B, and one loop to check/do C.   Each check/action
can be written in a separate function (referred to as the 'task' or
'thread') that typically has its own infinite loop.  You can think of each
task as its own, somewhat independent program (thread of execution) running
on the uC.  Only one thread of execution is actively running on the uC at a
time.  Whenever an interrupt occurs, the currently running thread of
execution is put on hold while the interrupt runs. This is just like what
happens when an interrupt occurs in the poll loop example above.  The
difference is that when the ISR is done, it does not necessarily return
control of the uC back to the same thread! The original thread is just kept
on hold while a different thread gets to run.  Eventually, based on rules
that are called 'scheduling', the original thread will be the one that
'wakes up' from some interrupt and it will continue on its way.  To make
sure that an opportunity to switch tasks happens frequently, you could have
a timer creating an interrupt say.. 30 times a second.

A surprisingly small (but complicated) amount of code is needed to proved
this 'task (thread) switching' behavior as long as the uC provides a way for
each thread to have its own stack space in memory and a way to save its
context (put the thread on hold). (The PIC does not)

If you wrote this task switching yourself for one project then for a second
project, instead of rewriting the entire task switching code again from
scratch, you might pull it out from your first project and reuse it.  You
would find that you could put it in a library that provided functions for
any program you write in the future that enables it to task switch without
worrying about the code in your library that makes it happen.

That library you would call an operating system (OS).  If the rules that you
made up for scheduling when threads get to run provide a predictable
worst-case time between when events happen and when threads get to run (and
a few more details), you would call it a real-time operating system (RTOS)
and you could sell it to other programmers for use in their projects.

Next you would find that some programmers wanted to use your RTOS code on
other uC's.  So you port your code to other processors.  To keep the code
manageable, you separate the parts that are the same for any processor from
the parts that need to be changed for each new processor you port to.  The
parts that change you would call the driver. You would have one copy of the
base code that does not need to change (like the definitions of the
functions prototypes in your library or 'API') and you would have one driver
(the part of the code that changed) for each uC you supported.

Next you would find that you could also provide functions in your library
(RTOS) to make it easy for programmers to use, say.. an SPI interface.
Because the specifics on how to implement the SPI interface varies from uC
to uC, you would separate it into the parts that are common to any SPI use
and the part that had to change to match the details of how a uC talks SPI
(bit bashing on some uC, MSSP on others).  You would call the non-changing
part the 'SPI API' in your RTOS and the changing parts the SPI driver for
this uC and the SPI driver for that uC.

You would then repeat this same API / driver pattern that you used for the
'Task Switching' API and 'SPI API' over and over again for memory
management, communications protocols, etc...

Drivers don't have to be used only for code that changes from one uC to
another.  You can use the driver pattern any time you can factor out the
code that changes for any parameter; uC, hardware, UI style. For example you
could have a driver for each type of video hardware that plugs into your
embedded system's bus.

So that's what an RTOS and drivers are.

--BobG



{Original Message removed}

2001\08\09@142126 by Andrew E. Kalman

flavicon
face
Re:

>My question is, why people are telling me that i need
>a RTOS ( Real Time Operating System ) to develop an
>embedded system? They are telling me that drivers need
>to be written, so on and so forth. Why?
>What role does the RTOS play?


Some of the responses you got (I found Peter Tiang's and Robert
Griffith's to be exceptionally well-put) w/regard to RTOSes do an
excellent job of describing the how and why of RTOSes in general.
And the uC/OS-II book is a very good read.

Olin Lathrop is, as usual, very anti-RTOS-on-a-PIC, but he is, after
all, Olin ... :-) I personally have just about stopped writing
non-RTOS PIC apps, because with the RTOS approach I get things done
so much faster. But I do have a vested interest ion Salvo ...

Our RTOS, which is available for all PICmicro devices, is also
available in a freeware version called Salvo Lite. You may want to
download it and take it for a spin. The Salvo User manual has a
chapter dedicated to RTOS fundamentals -- not as in-depth as Jean
Labrosse's book, but a good starting point, and free for the
downloading.

Also, Microchip recently released App Note AN777 which details the
use of Salvo on a PIC16F877.

Regards,
--

 ______________________________________
Andrew E. Kalman, Ph.D.


Salvo(TM), The RTOS that runs in tiny places(TM)
Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: KILLspamaekKILLspamspampumpkininc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\08\09@171817 by Glen Torr

picon face
Andrew E. Kalman wrote:-

>The Salvo User manual has a
> chapter dedicated to RTOS fundamentals -- not as in-depth as Jean
> Labrosse's book, but a good starting point, and free for the
> downloading.
>
> Also, Microchip recently released App Note AN777 which details the
> use of Salvo on a PIC16F877.

I downloaded the Salvo User manual the other day and found the RTOS
fundamentals and examples an excellent starting point. The rest of the
manual appears as well written.I also downloaded Salvo light (but have not
played with it yet).

I can see how a RTOS could have made several of my previous projects better
than "superloop" technology.

I have the feeling that moving to the RTOS approach where applicable will be
like the move I am currently making from assembler to C, in my context I
feel the result will be that my productivity will grow significantly. Just
my opinion.

Glen Torr
Technical Officer
School of Electrical Engineering
Australian Defence Force Academy

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\08\15@084141 by uter van ooijen & floortje hanneman

picon face
> Our RTOS, which is available for all PICmicro devices, is also
> available in a freeware version called Salvo Lite. You may want to
> download it and take it for a spin. The Salvo User manual has a
> chapter dedicated to RTOS fundamentals -- not as in-depth as Jean
> Labrosse's book, but a good starting point, and free for the
> downloading.

The main problem with any RTOS running on 12 and 14 bit PICs (including
Salvo) is that a task switch can only occur in the main body of a task, not
in a called function. Think about the implications for a HD44780-LCD or I2C
library that has to wait between operations: it must either use a busy wait
(stalling the other tasks) or be in-lined in the main task (with grave
consequences for the code size). I think I must agree with Olin: no
accessible purpose stack? In that case an RTOS makes no sense. Note that a
library of usefull routines might still make sense (an Salvo seems to fall
in that category), but it is misleading to call it an RTOS. Note also that
the size of the microcontroller (RAM, ROM, interrupt or not) has nothing to
do with it. It is just the fact that you can not stack-switch.

Wouter van Ooijen

van Ooijen Technische Informatica: http://www.xs4all.nl/~wf/
Jal compiler for PIC microcontrollers:  http://www.xs4all.nl/~wf/wouter/jal

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@112514 by Don Hyde

flavicon
face
> the size of the microcontroller (RAM, ROM, interrupt or not)
> has nothing to
> do with it. It is just the fact that you can not stack-switch.

I disagree, though not long ago, I would have expressed exactly the same
skepticism -- no stack-switch, no RTOS.

I downloaded the freeware version and played with it.  Now, I had such
difficulties getting the freeware version to run correctly that I gave up
trying to actually run it.  I can only hope that a paid-for version would be
easier to get working.  I did take a good close look at the examples and the
generated code.  I was surprised at how efficient and useful it was.

I've written ad-hoc "superloop" realtime code, and used different RTOS's.
I've even built my own RTOS on more than one occasion so that I could escape
the superloop spaghetti.  Since I started coding for PIC's, I have been
writing code whose designs I hate because I didn't believe that a usable
RTOS could exist without stack switching.  Right now I'm in the middle of a
nightmare of modifying and then debugging some horribly spaghettified code
that has grown cold for me.

While the lack of a stack imposes very great limitations on the system
design, the little RTOS certainly is workable, and achieves what I think is
the main goal of an RTOS, which is simplification of the design.  It
eliminates the "superloop" with all its horrible design and maintenance
nightmares, and helps to make different parts of the design be independent
of one another.

I think that the no-stack-switch limitations have much less impact on a
design than the limited code and data space we are so familiar with in all
PIC-based designs.

> {Original Message removed}

2001\08\15@120647 by Andrew E. Kalman

flavicon
face
Wouter wrote:

>The main problem with any RTOS running on 12 and 14 bit PICs (including
>Salvo) is that a task switch can only occur in the main body of a task, not
>in a called function. Think about the implications for a HD44780-LCD or I2C
>library that has to wait between operations: it must either use a busy wait
>(stalling the other tasks) or be in-lined in the main task (with grave
>consequences for the code size). I think I must agree with Olin: no
>accessible purpose stack? In that case an RTOS makes no sense. Note that a
>library of usefull routines might still make sense (an Salvo seems to fall
>in that category), but it is misleading to call it an RTOS. Note also that
>the size of the microcontroller (RAM, ROM, interrupt or not) has nothing to
>do with it. It is just the fact that you can not stack-switch.

I think you're missing the bigger picture here. A short busy-wait
isn't going to have much effect on a PIC application, whether it's
Salvo-based or not. In either case, interrupts can still proceed, and
the rest of the application is "held up" while the busy-wait occurs.
This would be the case in any superloop application, in any
cooperative RTOS, and also in a preemptive RTOS with preemption
(temporarily) disabled -- makes no difference.

The _advantage_ of the RTOS like Salvo is that if you're willing to
code it (and in fact there's a 44780 LCD controller initialization
example in the manual), you can have the system do other things while
in an RTOS-driven delay. In the example I mention, the rest of the
system goes on running while the LCD display task is initializing the
LCD. For example, you might start the LCD task first, and then, while
it's delayed for 50ms talking to the 44780's command register, other
tasks can fire up, too, doing things like initializing UARTs and
buffers, etc.

The larger issue isn't busy-waits, it's encapsulation. Meaning that
if you have, say, access to a UART and you have two tasks pumping
data to the UART, you can't call putchar() and expect TaskB() to wait
(i.e. be blocked) while TaskA() has control of the UART.  With a
stackless RTOS like Salvo, you have to check for resource
availability in each task by waiting a semaphore before accessing the
resource via the function, and the function must make the resource
available by signaling the semaphore when it's done.  The code size
is admittedly a bit larger, but the net effect is the same --
controlling access to resources via semaphores.

Also, many Salvo applications are indistinguishable from what a
preemptive application would look like if it could run on the PIC
(but of course it can't). These are the cases where all tasks either
wait events or are delayed (no "simple" context switches). At the C
level, they look the same.

We're just wrapping up a quad 1200 baud full-duplex UART application
for the 16F877 using Salvo (see AN-8 on the website). This is a very
interesting application, as it shows that a timing-critical
application can be done fairly easily in Salvo, and also that the
system can run lots of other tasks in addition to the UART tasks
because of the priority scheme involved. When UART activity is low,
other tasks run more. When UART activity is high, they are blocked
due to their low priority. This is of course all done automatically,
simply by assigning priorities to tasks.

Regards,
--

 ______________________________________
Andrew E. Kalman, Ph.D.


Salvo(TM), The RTOS that runs in tiny places(TM)
Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: TakeThisOuTaekEraseMEspamspam_OUTpumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@145939 by uter van ooijen & floortje hanneman

picon face
> I think you're missing the bigger picture here. A short busy-wait
> isn't going to have much effect on a PIC application, whether it's
> Salvo-based or not.

Indeed, but it is the longer waits that I was worried about. Short waits
(short relative to the time comstraints on the other task) can be busy
waits, without any problems.

> This would be the case in any superloop application, in any
> cooperative RTOS, and also in a preemptive RTOS with preemption
> (temporarily) disabled -- makes no difference.

True, that is the reason that the time that preemption is disabled must be
limited - it is in fact one of the important quality factors of an RTOS,
because it determines the responsivity (interrupt latency).

> The _advantage_ of the RTOS like Salvo is that if you're willing to
> code it (and in fact there's a 44780 LCD controller initialization
> example in the manual), you can have the system do other things while
> in an RTOS-driven delay.

Yes, but you must code for it - delays during which the other tasks must run
must be in the main body of the task. So you cxan not take a library that
what not written with this limitation in mind and use it.

> The larger issue isn't busy-waits, it's encapsulation.

I agree, the fact that you are forced to put the waits in the main loop is
not so much a problem in itself, but it forces you to make internals of a
library visible to the library user.

> but the net effect is the same controlling access to resources via
semaphores.

True, but the resctricition imposed by the RTOS weights heavily on the
application structure: everything that can wait (including semaphores and
other synchronisation primitives) must be in the main body, it can not be
buried (abstracted away) in a library function.

> Also, many Salvo applications are indistinguishable from what a
> preemptive application would look like if it could run on the PIC
> (but of course it can't). These are the cases where all tasks either
> wait events or are delayed (no "simple" context switches). At the C
> level, they look the same.

Here I disagree: a Salvo (or other non-preemtive RTOS) application has the
big ristriction: no long (or potentially long) waits in (non-inline)
functions!

Wouter van Ooijen

van Ooijen Technische Informatica: http://www.xs4all.nl/~wf/
Jal compiler for PIC microcontrollers:  http://www.xs4all.nl/~wf/wouter/jal

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@161409 by Andrew E. Kalman

flavicon
face
Wouter wrote:

>True, but the resctricition imposed by the RTOS weights heavily on the
>application structure: everything that can wait (including semaphores and
>other synchronisation primitives) must be in the main body, it can not be
>buried (abstracted away) in a library function.

and

>Here I disagree: a Salvo (or other non-preemtive RTOS) application has the
>big ristriction: no long (or potentially long) waits in (non-inline)
>functions!


Well, that's the price we PIClisters pay for not having a software
stack. Not much we can do about that, unfortunately.

also, re:

>True, that is the reason that the time that preemption is disabled must be
>limited - it is in fact one of the important quality factors of an RTOS,
>because it determines the responsivity (interrupt latency).

Entirely true.  But cooperative RTOSes have better interrupt response
and recovery. So there are areas where cooperative may be better than
preemptive for the particular application.

Wouter is entirely correct that library functions with long delays
are incompatible with a non-preemptive RTOS that needs high
responsivity. Given that a preemptive RTOS is out of the question on
PIC12/PIC16/PIC17 series PICmicros, this issue becomes a question of
"Are you willing to code long delays at the task level to get around
this restriction? And what do you gain from it?"

Any application that has long delays is likely to be written to do
processing at the interrupt level during the delays, otherwise much
time is being wasted and responsivity suffers. A cooperative RTOS,
with long  delays "moved" to the task level, allows you to move much
of the interrupt-based processing out of ISRs and into tasks, and
shrink the ISR to an absolute minimum size and maximum speed.

With libraries containing long delays, the PIC programmer has to
figure out how to write your interrupt code to take advantage of time
spent in the delays. You have effectively only one "high priority
task" (the ISR), and everything else is low priority. With the Salvo
approach, the RTOS effectively allocates processor cycles to the
things you want down (tasks) on a priority basis.

As a practical matter, I don't dwell too much on Salvo's advantages
with just simple delays. The real benefit is when things are
event-driven, and tasks wait on semaphores to be signaled, etc.
Unfortunately, due to the PIC's architecture, all the waiting must be
done at the task level. But I find that's a small price to pay for
the benefits that come with the RTOS approach.

--

 ______________________________________
Andrew E. Kalman, Ph.D.


Salvo(TM), The RTOS that runs in tiny places(TM)
Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: RemoveMEaekspamTakeThisOuTpumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@163952 by uter van ooijen & floortje hanneman

picon face
> As a practical matter, I don't dwell too much on Salvo's advantages
> with just simple delays. The real benefit is when things are
> event-driven, and tasks wait on semaphores to be signaled, etc.
> Unfortunately, due to the PIC's architecture, all the waiting must be
> done at the task level. But I find that's a small price to pay for
> the benefits that come with the RTOS approach.

I think that is the bottom line of our disagreement: I think mainly from the
point of view of a library writer that wants to provide a library that a
programmer can use without modification, while your view is of an
application writer who's application has a large portion of (application
specific) things like synchronisation, for which a crippled RTOS (crippled
by the PIC architecture, not by your fault!) can still offer a lot of
assistance. But it still does not allow me to write a general-purpose
library with embedded delays ;(

Wouter van Ooijen

van Ooijen Technische Informatica: http://www.xs4all.nl/~wf/
Jal compiler for PIC microcontrollers:  http://www.xs4all.nl/~wf/wouter/jal

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@170326 by Jim

flavicon
face
Back in their days, the TI 960 minicomputer (TTL
technology) used to have a crude OS (though they
*didn't* call it that) in the form of "PSM"  (Program
Support Monitor) and "PAM" (Program Automation
Monitior) - essentially a set of callable 'routines' linked
together (entries via a table) that handled peripherals and
some other tasks.

Routines to handle a CRT/Terminal, card reader, paper
tape reader, etc, as well 'calls' to do floating point operations
were the core of PSM or PAM.

Jim


{Original Message removed}

2001\08\15@210817 by Olin Lathrop

face picon face
> I think you're missing the bigger picture here. A short busy-wait
> isn't going to have much effect on a PIC application, whether it's
> Salvo-based or not. In either case, interrupts can still proceed, and
> the rest of the application is "held up" while the busy-wait occurs.
> This would be the case in any superloop application, in any
> cooperative RTOS, and also in a preemptive RTOS with preemption
> (temporarily) disabled -- makes no difference.

This is not related to the point you are trying to make in this paragraph,
but you keep characterising the non-RTOS option as a very stupidly written
"superloop".  There are more intelligent designs than what you describe that
are easy to do and certainly don't require buying an RTOS.

Most forground "threads" can be handled very nicely by an an event loop,
since most of the time things are event driven.  I usually have my
foreground code enter an endless loop for main system operation.  It checks
all the events that could require service, and jumps to an event routine if
one does.  One of the difference from what you describe is that event
routines jump back to the start of the event loop when done.  This provides
some event priority, which is often useful.  Most event routines are short.
If handling one "event" requires waiting for something else to happen, then
you just think of this as two events.  A common example of this is reading
the A/D.  One event starts the conversion, and another event fires when the
conversion is complete.  This is really very easy to do with a little
thinking about the design.  You can see an example of such an A/D handler in
HAL_AD.ASPIC at http://www.embedinc.com/pic/hal.htm.  The event loop is in
the HAL_MAIN.ASPIC module.

One exception to the above scheme that comes up regularly is handling a
command input stream from the UART or something while continuing all the
other foreground processing.  This looks the same to the event loop, because
the event is that an input character is available to be processed.  However,
since a command processor is often highly state driven, the event model
would be too cumbersome because there would be a large number of possible
events, depending on where you are in the command processing sequence.  To
get around this, I create a macro that fakes a call to "get" the next input
byte.  It really saves the program address immediately following the macro
call and returns to the event loop.  The event handler for dealing with a
new input byte gets this address and jumps to immediately following the
macro, thereby "returning" with the next byte.  You could say this is
essentially a cooperative thread of an RTOS, but this is so simple to do
yourself it hardly justifies purchasing one.  In case anyone doesn't believe
this, I have provided the source code below.  It is exactly 42 lines long if
you eliminate the 111 comment and blank lines.  Big deal.


;   ***************************************************************
;   * Copyright (c) 2001, Embed Inc (http://www.embedinc.com)     *
;   *                                                             *
;   * Permission to copy this file is granted as long as this     *
;   * copyright notice is included in its entirety at the         *
;   * beginning of the file, whether the file is copied in whole  *
;   * or in part and regardless of whether other information is   *
;   * added to the copy.                                          *
;   *                                                             *
;   * The contents of this file may be used in any way,           *
;   * commercial or otherwise.  This file is provided "as is",    *
;   * and Embed Inc makes no claims of suitability for a          *
;   * particular purpose nor assumes any liability resulting from *
;   * its use.                                                    *
;   ***************************************************************
;
;
;***********************************************************************
;
;   Configuration constants.
;
nsave    equ     5           ;num regs saved accross GETBYTE, starts with
REG1
lbank    equ     1           ;register bank for the local state of this module
;
;   Derived constants.
;
lbankadr equ     bankadr(lbank) ;address within local state register bank
;
;***********************************************************************
;
;   Local state.
;
 if lbank != gbank
.bank#v(lbank) udata
   endif

injump   res     2           ;where to jump on next input byte

saveregs res     nsave       ;save area for registers accross GETBYTE invocations

.cmd    code
;
;***********************************************************************
;
;   Macro GETBYTE
;
;   The code in this module gets run whenever a new input byte is available.
;   This macro makes it appear as if the code in this module is a separate
;   thread that goes and gets the next input byte.  It saves a restart address,
;   then returns to the main event loop.  When CMD_BYTE gets envoked the next
;   time, it resumes execution at the restart address.
;
;   This macro therefore appears like a subroutine call that returns with
;   the next input byte in REG0.  The register bank assumptions must be
;   correct when this macro is used.
;
;   From the caller's point of view, REG0 is returned with the new input
;   byte, REG1 - REG<nsave> are preserved, and the remaining registers are
;   trashed.
;
getbyte  macro
        local   restart
;
;   Set the address at which to restart next time.  This is the address
;   immediately after this macro.
;
        dbankif lbankadr
        movlw   low restart ;save where to restart next time
        movwf   injump+0
        movlw   high restart
        goto    getbyte2    ;to non-replicated code to do the rest
;
;   Set the assembler state to indicate the register bank settings.
;   The settings are a function of the code in CMD_BYTE that jumps to the
;   restart address.
;
restart                      ;end up here next time CMD_BYTE is envoked
        dbankis lbankadr    ;direct register set for access to local state
        ibank?              ;indirect bank setting is unknown
        endm
;
;**********
;
;   This section of code is only run implicitly from the GETBYTE macro.
;   There is only one copy of this code at a fixed location, whereas
;   the GETBYTE code is replicated for every use of the macro.  This code
;   is jumped to from GETBYTE to perform as much of the GETBYTE operation
;   as possible that is not unique to each individual invocation of GETBYTE.
;   This reduces redundant code which would otherwise be produced for each
;   GETBYTE invocation.
;
getbyte2
;
;   The low byte of the restart address has already been saved in INJUMP+0,
;   and the high byte is in W.  Now save the high byte into INJUMP+1.
;   The direct register bank is set for access to the local state.
;
        dbankis lbankadr
        movwf   injump+1
;
;   Save some of the registers locally.  These will be restored when
;   CMD_BYTE is run next before it jumps to the restart address.
;
        dbankif lbankadr
        copyn   saveregs, reg1, nsave ;save the preserved registers

        gjump   loop_main   ;back to the main event loop
;
;***********************************************************************
;
;   Subroutine CMD_INIT
;
;   Initialize the state managed by this module.
;
        glbsub  cmd_init, noregs

        dbankif lbankadr
        movlw   low cmd_start ;init to where to start processing next in byte
        movwf   injump+0
        movlw   high cmd_start
        movwf   injump+1

        leaverest
;
;***********************************************************************
;
;   Routine CMD_BYTE
;
;   This routine is jumped to from the main event loop when there is an
;   input byte available from UART_GET.
;
        glbent  cmd_byte

        gcall   uart_get    ;get the input byte into REG0
;
;   Restore the registers that are preserved accross invocations of the
;   GETBYTE macro.
;
        dbankif lbankadr
        copyn   reg1, saveregs, nsave ;restore the preserved registers
;
;   Jump to the restart address.  The restart address was saved by GETBYTE
;   before it jumped back to the main event loop.
;
        dbankif lbankadr
        movf    injump+1, w ;get restart address high byte
        movwf   pclath      ;set jump address high byte
        movf    injump+0, w ;get restart address low byte
        movwf   pcl         ;jump to the restart address
;
;   The restart address is jumped to with the direct register bank set for
;   access to the local state.  The indirect register bank setting is unknown.
;


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\15@215554 by Andrew E. Kalman

flavicon
face
Olin wrote:

[snip]
>  In case anyone doesn't believe
>this, I have provided the source code below.  It is exactly 42 lines long if
>you eliminate the 111 comment and blank lines.  Big deal.
[snip]

That's all very interesting -- I used to write code like that. But to
do it in Salvo takes just one line:

       for (;;) OSSched();

Time is money ...

--

 ______________________________________
Andrew E. Kalman, Ph.D.


Salvo(TM), The RTOS that runs in tiny places(TM)
Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: EraseMEaekspampumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\16@090711 by Olin Lathrop

face picon face
> That's all very interesting -- I used to write code like that. But to
> do it in Salvo takes just one line:
>
>         for (;;) OSSched();
>
> Time is money ...

I hope you're not seriously suggesting one should run out and buy an RTOS to
save writing a few tens of lines of code!  Evaluating RTOSs, ordering one,
installing it, and reading its documentation would take many times longer
than just writing the code.  Like you said, time is money.  And then you
have something that you know exactly how it works, and can modify for future
projects to suit.  All make versus buy decisions don't automatically come up
"buy" because you want people to buy your product.

I'm not against RTOSs in general, but they just don't make sense on really
small processors like the 16xxx PICs.  I've also noticed that most embedded
control problems don't need most of the features of most RTOSs.  There are
very few problems that can't be solved very nicely with a simple cooperative
task model where tasks can optionally sleep until some number of clock ticks
have elapsed.

I know you say you now program everything using your RTOS.  That only proves
an RTOS can be used if you really want to.  If you didn't have an RTOS and
didn't have the bias of trying to profit from one, you would find most
problems can be solved very well without one.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinEraseMEspamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\08\16@101042 by PeterTiang

flavicon
face
Hi Guys,

   Let's not get too agitated on this issue.

   It's nice to know that there is a solution
   such as Olin's solution and commercial
   solution like Salvo.

   I'm sure Salvo provider is entitled to
   profit from engineers who is too lazy to
   write their own task manager ;-)

   Another simple solution would be to write
   the modules in the "superloop" as state
   machines.

   State machines acts more or less like a
   cooperative OS by slicing codes into
   fragments that gets a tiny slice of CPU
   time in a particular state. It gives
   up CPU time before proceeding to the
   next state, this way, letting other state
   machines (modules) gets a share of CPU
   time in the "superloop".

   Of course, it's still non-deterministic,
   but by careful slicing of code in the
   state machine, system responsiveness
   can be very much improved compared to
   conventional function call.

   Critical events can still be handled
   in foreground by interrupt subroutines.

   A good side effect is that it helps you
   identify which state that your app is
   stucked in during debug.

   I've used state machines in complicated
   control application such as Compact Disc
   servo control and it works pretty well
   without an RTOS.

Rgds,
Peter Tiang

{Original Message removed}

2001\08\16@102518 by Andrew E. Kalman

flavicon
face
Olin wrote:

>I hope you're not seriously suggesting one should run out and buy an RTOS to
>save writing a few tens of lines of code!  Evaluating RTOSs, ordering one,
>installing it, and reading its documentation would take many times longer
>than just writing the code.  Like you said, time is money.  And then you
>have something that you know exactly how it works, and can modify for future
>projects to suit.  All make versus buy decisions don't automatically come up
>"buy" because you want people to buy your product.

Getting up and running with any new product takes time, granted. But
the same can be said of moving from Assembly to C, or even newer
versions of MPLAB, and you're not seriously suggesting that people
shouldn't use certain PIC C compilers just because they're not free,
are you?

At the MASTER's class this year I was very upfront with attendees and
what Salvo can do for them.  After all, many are just now moving from
Assembly to C. For many, the idea of structured programming in C with
an RTOS is very appealing.

>I know you say you now program everything using your RTOS.  That only proves
>an RTOS can be used if you really want to.  If you didn't have an RTOS and
>didn't have the bias of trying to profit from one, you would find most
>problems can be solved very well without one.

Ah, but the corollary is that if you do have an RTOS, you will find
that most problems can be solved very well with it. And you don't
have to modify it for future projects. And Salvo Lite is free! And I
won't bore the list with all the benefits you get from an RTOS
approach in terms of portability, understandability, and
life-of-product management, etc.

Theoretically, any PIC application can be written without our RTOS.
It could be solved by writing in machine code, too, for an outlay of
exactly $0, with no value placed on one's time. But I don't think
anyone does that on the PICList. At least I hope not :-)

We'll have to agree to disagree, as neither of us is budging on this
one. We both recognize that the "other" method works, but  we each
think that our method is faster, cheaper and better. We're both
looking for customers. It's up to them to decide which path to take.

Cheers! I enjoy your acerbic wit.

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   RemoveMEaekspam_OUTspamKILLspampumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\08\16@104641 by Dale Botkin

flavicon
face
On Thu, 16 Aug 2001, Olin Lathrop wrote:

> > That's all very interesting -- I used to write code like that. But to
> > do it in Salvo takes just one line:
> >
> >         for (;;) OSSched();
> >
> > Time is money ...
>
> I hope you're not seriously suggesting one should run out and buy an RTOS to
> save writing a few tens of lines of code!  Evaluating RTOSs, ordering one,
> installing it, and reading its documentation would take many times longer
> than just writing the code.  Like you said, time is money.  And then you
> have something that you know exactly how it works, and can modify for future
> projects to suit.  All make versus buy decisions don't automatically come up
> "buy" because you want people to buy your product.

I have to agree here.  No comment one way or the other on Salvo or RTOS in
general, but working as I do in corporate America I see far too many
decisions come up "Buy" simply because there is a vendor to blame -- er,
consult - if something goes wrong.  It's a shame to see talented people
doing grunt work because developing something in-house is looked down
upon.  Again, this is NOT a comment on Salvo, since I know nothing at all
about the product.

> I know you say you now program everything using your RTOS.  That only proves
> an RTOS can be used if you really want to.  If you didn't have an RTOS and
> didn't have the bias of trying to profit from one, you would find most
> problems can be solved very well without one.

Hey, when you have a REALLY NICE hammer, more things begin to resemble
nails!  8-)  Heck, I write everyting in C now.  Not exactly the same
thing, but getting close.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\08\17@050126 by Michael Pont

flavicon
face
Olin Lathrop wrote:

> There are
> very few problems that can't be solved very nicely with a simple
cooperative
> task model where tasks can optionally sleep until some number of clock
ticks
> have elapsed.

I'm with Olin on this one.  I've been a dedicated 'co-operative scheduler'
user for several years and have, in fact, just published a large book on the
topic (it's based on the 8051, I'm afraid: the details are on my WWW site if
anyone is interested).

The main reason I like this approach is that - in my view - it results in
very reliable systems.  This is because it is very simple and very easy to
understand.  This is the main reason that software-based aircraft are using
these techniques, and the automotive industry is rapidly following the same
route.   I know nothing about Salvo, but the majority of RTOSs are simply
too complicated for use in systems which must be reliable.

In my experience, people new to embedded systems start using a RTOS because
an OS is what they are used to on desktop machines.  Some systems can
benefit from such an approach but most don't.

Michael.

+==================================+

Michael J. Pont
http://www.le.ac.uk/engineering/mjp9

+==================================+

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\17@112621 by Andrew E. Kalman
flavicon
face
Michael Pont wrote:

>I'm with Olin on this one.  I've been a dedicated 'co-operative scheduler'
>user for several years and have, in fact, just published a large book on the
>topic (it's based on the 8051, I'm afraid: the details are on my WWW site if
>anyone is interested).

I'm happy so see that cooperative schedulers are (still) so popular
... many people have a hard time believing anything short of fully
preemptive is of any use.

and
>This is the main reason that software-based aircraft are using
>these techniques, and the automotive industry is rapidly following the same
>route.

Around 10 years ago I remember reading about a microprocessor
designed in the UK that was specifically targeted at aircraft use. I
believe it was called the Viper. It was supposedly a "provably
correct" design, the logic being that it therefore had no (hardware)
bugs and ought to prevail in that design environment. Trouble is,
their "proof" was apparently in error ... and I haven't heard of it
since.

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   RemoveMEaekTakeThisOuTspamspampumpkininc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\17@124642 by Dale Botkin

flavicon
face
On Fri, 17 Aug 2001, Andrew E. Kalman wrote:

> Around 10 years ago I remember reading about a microprocessor
> designed in the UK that was specifically targeted at aircraft use. I
> believe it was called the Viper. It was supposedly a "provably
> correct" design, the logic being that it therefore had no (hardware)
> bugs and ought to prevail in that design environment. Trouble is,
> their "proof" was apparently in error ... and I haven't heard of it
> since.

All my designs are "provably correct", at least to me...  if it wasn't
correct, I wouldn't have done it that way, no?  8-)

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\18@195027 by Edson Brusque

face
flavicon
face
Hellow Andrew,

> Salvo(TM), The RTOS that runs in tiny places(TM)

   your product seens to be very interesting. There's interest in porting
it to CCS compiler?

   Best regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2138  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...