Page 1 of 1


PostPosted: Tue Oct 30, 2007 8:08 am
by aastokes

I'm new to the world of programming and RTOS's. I've bought a C8051F SiLabs MCU and I'm interested in using Salvos to produce a range of waveforms at the outputs and to act according to feedback inputs.

Is this the right product for my application?

I'm trying to develop the software for control of an XY stage using stepper motors and with minimal feedback except start and stop switches on each actuator to feedback the start and stop positions.




PostPosted: Tue Oct 30, 2007 8:12 am
by aek
Well, it can certainly make for a much more structured approach to programming, among others.

Which 8051 compiler do you use / intend to use?




PostPosted: Tue Oct 30, 2007 8:16 am
by aastokes
I have both the SiLabs IDE and Keil uVision 2. Do you think that they type of automation that I'm interested in will be possible/easy using the Salvo approach?


PostPosted: Tue Oct 30, 2007 8:33 am
by aek
uVision2 + Salvo is a perfect combo.

You want to leverage the strength of the RTOS against what you want to do (in terms of the whole application).

An event-driven approach (Salvo is purely event-driven) means that you will have an application that is always "primed to react" to system events, without wasting time and screwing up program flow by things like polling.

You bought the SiLabs parts because of their peripheral mix, I suspect. So in an app, it's imperative that you be able to leverage those peripherals to the max. Salvo allows you to "hand over" the functions of the application that are just below the fastest and most time-critical ones to the RTOS, and the RTOS will handle them in a manner that does not impact what you're doing at that fastest and most time-critical level (basically, running your peripherals like PWM).

My rule of thumb is, "If the performance is critical to the tune of:"

1-99 cycles, code it in-line, no interrupts.
100-999 cycles, code it via an ISR.
1000 cycles and beyond, let the RTOS handle it.

E.g. it makes perfect sense to have the RTOS handle your incoming and outgoing 9600 baud serial comms, with e.g. a Rx ISR handler signaling to a task when complete incoming packets have arrived, so that the receive task only wakes up and acts on said packets when necessary.

OTOH, if you have a critical mechatronics operation that requires that you bit-bang an I/O pin for a highly accurate number of cycles, you'll probably do that as inline code, with interrupts disabled, so that there's no jitter. But you can't overdo that, because while interrupts are disabled, you might lose incoming chars. So this sort of thing has to be FAST.

IOW, the low-level stuff operates as inline code and ISRs, whereas the higher-level stuff operates as tasks and the other things that an RTOS brings (like resource locking, priorities, simple management (like start/stop a task), etc.

For someone like you (I assume you don't have too much experience) perhaps the coolest thing about RTOS programming is that it enables you to build an application is a highly modular / loosely coupled way. Need some new functionality? Just create another task, and know that it won't break all the other code that you've already written.