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: aek@pumpkininc.com

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