Pumpkin, Inc.

Pumpkin User Forums

Salvo Questions

If you have a general question or comment regarding Salvo, post it here.

Salvo Questions

Postby Unregistered User » Wed Aug 31, 2005 3:22 am


My experience with real-time systems is restricted to VxWorks. We will soon be working on a low-power microcontroller project, so I am trying to survey the industry for various types of information including types of microcontrollers, various microcontroller RTOS's, different compiler tools, etc. We have previous experience working with 8051's and using Keil compiler tools. I noticed Keil offers their own RTOS. One aspect of Salvo that I would like to get a better understanding of is the issue of it being priority based cooperative vs. pre-emptive. I assume this means that if we are running in one task and another task of higher priority is ready to run, the higher priority task will not run until the lower priority task relinquishes the CPU. Can you briefly talk about the advantages / disadvantages between Salvo and other RTOS's like Keil's?

Unregistered User
Posts: 36
Joined: Thu Aug 09, 2001 11:00 pm

Re: Salvo Questions

Postby aek » Wed Aug 31, 2005 3:23 am

Sure, I'd be happy to address that.

First, for the disadvantages.

In a cooperative RTOS, you are correct in saying that other tasks cannot run before the current task "relinquishes control" by doing an explicit context switch. This has the side-effect that very long operations (e.g. a multi-step complex operation involving floating point numbers) in a task may need to be broken up so that overall system responsiveness does not suffer too much.

Also, in Salvo's case, there is are two additional constraints imposed on the programmer: First, since Salvo does not have task stacks and therefore does not store local (auto) variables in each task, the use of local variables is restricted to those circumstances where persistence across a context switch is not required (e.g. a counter in a local loop that does not contain a context switch).

The second constraint is that context switches may only occur at the task level in Salvo. The primary effect of this is to make encapsulation in the conventional sense impossible. I.e. you cannot block a task from within a deeply called function via an OS call if, say, a resource is not available.

These are the primary differences that I feel can arguably be identified as a disadvantage when Salvo is compared to a preemptive RTOS with a similar feature set.

Now, to the advantages. First, to address the points above.

Some programmers actually prefer to have context switching entirely under their control, and either do not like or want preemptive systems, or disable preemption in certain circumstances. Since most preemptive RTOSes allow you to disable preemption, such RTOSes could arguably give you the best of both worlds. But it's much more complicated than that when we analyze overall system performance -- more on that later.

As for Salvo's restriction on auto variables, static variables can always be used in tasks. The "cost" in ROM and RAM associated with using a static variables is usually lower than that in using an auto variable that would be saved to a task stack. The RAM requirements will be the same, and as for ROM, sometimes there is additional code (SP-relative addressing) required to access a variable in a task's stack frame compared to simply accessing a global. This is highly architecture-dependent.

The inability to context switch at other than the task level would seem to be a deal-killer at first inspection. There are two common solutions to this. Either "flatten" the task code so that all OS calls that lead to context switches (in Salvo, all "OS_Xyz()" calls) are in thee task body itself, or manage this sort of encapsulation via separate tasks (as opposed to via functions). From a practical viewpoint, our customers seem to rarely have a problem with this.

Now, to delve further into the advantages.

One of the real issues facing many novice and intermediate programmers is the sheer complexity of a preemptive system, and trying to debug it, etc. Many users are turned off by the idea of even using an RTOS on a small embedded system because of prior bad experiences with (preemptive) RTOSes on larger systems. Salvo is at its core very simple, and highly optimized for high performance. We have not yet offered any "RTOS-aware DLLs" for task state inspection, etc. primarily because they turn out to be unnecessary. The complexity of debugging a Salvo application is only slightly removed from debugging a simple main loop application, and much much less than that of debugging a preemptive system.

A preemptive system requires ISR hooks (because any interrupt can cause a context switch), which will add overhead and increase ISR latency. This is an important consideration when you are trying to extract the maximum performance out of your chosen target processor. Salvo has no need for ISR hooks. It extremely fast event signaling (which would normally be called at the ISR level) -- which allows for very fast ISRs, and can be configured to only disable those interrupt sources that must be disabled in critical sections (as opposed to disabling interrupts globally, which is Salvo's default but can be changed with Salvo Pro).

There are additional internal optimizations as well (e.g. Salvo's timer is far more efficient than any timer scheme we know of that involves an array-based priority resolution scheme) which make Salvo ideally suited for enabling the programmer to get the maximum performance out of the target's "available horsepower". This is partly due to the run-time simplicity of a cooperative RTOS, and partly due to careful internal optimizations.

Lastly, I ought to touch on the original "raison d'etre" of Salvo -- that is, to provide priority-based, event-driven multitasking in a tiny RAM footprint. There isn't much point running an RTOS on an 8- or 16-bit microcontroller if it eats up all your RAM and you have nothing left to work with. The coding restrictions above (restricted use of auto variables in tasks, and context switches only at the task level) have an immediate benefit in a huge (1-to-several-orders-of-magnitude) reduction in the amount of RAM required by the RTOS. I like to say that Salvo offers "80-90% of the RTOS benefits and features in 1/10th the RAM footprint" of competing schemes.

Of course as you would expect with any professional RTOS, Salvo is completely portable without user source-code changes across the various compilers and target processors we support.

Salvo is royalty-free and is licensed per-seat, much like most compilers and tools.

So, to summarize Salvo's strengths: Simple, Fast, Small (Tiny?), Configurable, Comprehensive and (perhaps most importantly) extremely Reliable.

P.S. Salvo integrates very nicely with the Keil C51 and CARM toolsets. They're a good match with one another.


[This message has been edited by aek (edited August 31, 2005).]

Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Salvo Questions

Postby aek » Wed Aug 31, 2005 3:41 am

Oh, I forgot one (albeit subjective) thing ... with over 5 years of Salvo being used in the field, what we see is that Salvo is more than capable of adequate responsiveness etc. across a wide variety of applications. We simply don't get tech support queries that are performance-related. Most involve configuration and "how do I do this" sorts of things.

I interpret this to mean that Salvo's context-switching scheme and overall performance are adequate for a wide range of applications, and in those cases where additional performance is required, we recommend that users code their "high-rate" stuff into ISRs and configure Salvo for optimal ISR performance.

Note that every small processor has a limit to what it can do based on architecrure, clock speeds, etc. The maximum performance will almost always be achieved without an RTOS "in the way". The key is to use an RTOS that (via configurability and/or inherent design) allows a combination of RTOS-, ISR- and hard-coding to extract maximum performance.

To this end, my empirical coding guidelines for high performance and responsiveness are:

1-99 cycles: Code in a tight loop, no interrupts. Always jitter-free.

100-999 cycles: Use interrupts. Some jitter.

1,000 cycles and up: Use the RTOS. More jitter, but easily tolerated.

I touched on this issue in-depth in a recent presentation:



[This message has been edited by aek (edited August 31, 2005).]

Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Salvo Questions

Postby tbims23822 » Tue Jul 07, 2009 6:27 am

www.drop-shopping.com is a premium website for cheap air jordans shoes and other more really nike air jordan shoes.We have varity of cheap air jordan shoes available for wholesale.Cheap China wholesale shoes including cheap Nike shoes and cheap jordan shoes,nike sneakers,nike sneakers discount,air jordan sneakers,air force sneakers.We supply nike sneakers,jordan sneakers,air jordan sneakers,air force sneakers wholesale.You can buy very cheap jordans shoes including cheap women shoes,cheap nike shoes,cheap running shoes from us.

Return to General

Who is online

Users browsing this forum: No registered users and 1 guest