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: 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