>
>
> Tim Wescott wrote:
>
>>>
>>> In SST, you can't preempt the current highest priority task just
>>> because you decided to do that. You also can't make time based
>>> scheduling. In this sense the SST is a classic background-foreground
>>> dual tasker with the cooperative multitasking on the top of it.
>>> Although I agree, it may be handy on some occasions.
>>>
>> One of us is confused. I know both of us are smart, and I know that I
>> read that article carefully. So I want to know if it's me, 'cause
>> I'll learn something thereby.
>
>
> Here is what I mean:
>
> In the SST, if the task A is preempted by B, and if B is preempted by C,
> there is no way to switch from C directly back to A. You have to unwind
> the stack. If you have A->B->C, then it has to be C->B->A.
>
> To me, it sounds like a serious limitation. First of all, I see the
> preemptive multitasking as the concept which greatly simplifies the
> development. In SST, if you have more then two tasks, you have to
> carefully watch for deadlocks.
>
If each task has a strictly different priority then this is no problem
at all, and the behavior is no different than a task loop (except for
the not-loop part, which I'll address in a bit).
> The SST paradigm of functions instead of loops is not very convenient
> either. Here is the typical application: an instrument which processes
> the raw data (hard realtime task), performs the math (soft realtime, but
> it takes a lot of CPU time), outputs the data to the graphic display
> (soft realtime, may take a very different amount of CPU time depending
> on the situation), processing of the user input (must be responsive),
> communication interface - very asynchronous task, system tasks: timers -
> hard realtime, flash memory - soft realtime. Implementing this in the
> SST paradigm would be a mess.
>
I agree that it isn't the most convenient, but sometimes one is
constrained in one's choice of processors. The authors were pushing it
in the context of their statechart tool, which inherently generates just
the sort of great big event-driven case statement which this task
switcher calls for, so for them they've already disposed of that point.
> Of course, the SST is using the CPU and memory very efficiently, however
> I would trade the code efficiency for the ease of the development.
>
I would take it on a case-by case basis. In a small system, or one
where I was using the aforementioned CASE tool, or if I had a client
willing to trade off development cost for unit cost, I'd consider it.
For a big system, or one that's relatively power, size and cost
indifferent, I wouldn't touch it with a 10 foot pole.
> Bottom line I don't really know if SST can be any useful to me and what
> would be the advantage of using it compared to a simple background -
> foreground system with the state machine based cooperative multitasking.
>
> Vladimir Vassilevsky
>
> DSP and Mixed Signal Design Consultant
>
> http://www.abvolt.com
>
Reply by Robert Adsett●November 14, 20062006-11-14
Vladimir Vassilevsky wrote:
> Tim Wescott wrote:
>
> >>
> >> In SST, you can't preempt the current highest priority task just
> >> because you decided to do that. You also can't make time based
> >> scheduling. In this sense the SST is a classic background-foreground
> >> dual tasker with the cooperative multitasking on the top of it.
> >> Although I agree, it may be handy on some occasions.
> >>
> > One of us is confused. I know both of us are smart, and I know that I
> > read that article carefully. So I want to know if it's me, 'cause I'll
> > learn something thereby.
>
> Here is what I mean:
>
> In the SST, if the task A is preempted by B, and if B is preempted by C,
> there is no way to switch from C directly back to A. You have to unwind
> the stack. If you have A->B->C, then it has to be C->B->A.
Sounds like a variation of what I call Run To Completion tasking. It
also fits well with RMA which is fairly common. And the unwinding is
no more complex (less so actually) than task switching.
> To me, it sounds like a serious limitation. First of all, I see the
> preemptive multitasking as the concept which greatly simplifies the
> development. In SST, if you have more then two tasks, you have to
> carefully watch for deadlocks.
Well, in this form of pre-emptive tasking tasks cannot block so
deadlocks simply don't occur. This can sound terribly restrictive but
there are a lot of situations it fits nicely with. For instance take a
control systems consisting of three loops a slow outer loop watching
for human control inputs run every 50mS, a middle loop run every 10mS
that some form of feedback loop that feeds a setpoint to a fast 1mS
loop. These are scheduled off a timer or timer derived interrupt with
the faster loops higher in priority (RMA) So when the outer loop is
running every time the inner loops need to run they will pre-empt it
run to completion and return to previous tasking. No fuss, no muss.
If you really need to block then it won't work. But if most of the
control is structured as a reponse to events or as control loops as
above then it may work. Some blocks may be transformable into events
instead.
It is pre-emptive (not cooperative). Unlike other pre-emptive and
cooperative systems though it is non-blocking.
Robert
Reply by Vladimir Vassilevsky●November 14, 20062006-11-14
Tim Wescott wrote:
>>
>> In SST, you can't preempt the current highest priority task just
>> because you decided to do that. You also can't make time based
>> scheduling. In this sense the SST is a classic background-foreground
>> dual tasker with the cooperative multitasking on the top of it.
>> Although I agree, it may be handy on some occasions.
>>
> One of us is confused. I know both of us are smart, and I know that I
> read that article carefully. So I want to know if it's me, 'cause I'll
> learn something thereby.
Here is what I mean:
In the SST, if the task A is preempted by B, and if B is preempted by C,
there is no way to switch from C directly back to A. You have to unwind
the stack. If you have A->B->C, then it has to be C->B->A.
To me, it sounds like a serious limitation. First of all, I see the
preemptive multitasking as the concept which greatly simplifies the
development. In SST, if you have more then two tasks, you have to
carefully watch for deadlocks.
The SST paradigm of functions instead of loops is not very convenient
either. Here is the typical application: an instrument which processes
the raw data (hard realtime task), performs the math (soft realtime, but
it takes a lot of CPU time), outputs the data to the graphic display
(soft realtime, may take a very different amount of CPU time depending
on the situation), processing of the user input (must be responsive),
communication interface - very asynchronous task, system tasks: timers -
hard realtime, flash memory - soft realtime. Implementing this in the
SST paradigm would be a mess.
Of course, the SST is using the CPU and memory very efficiently, however
I would trade the code efficiency for the ease of the development.
Bottom line I don't really know if SST can be any useful to me and what
would be the advantage of using it compared to a simple background -
foreground system with the state machine based cooperative multitasking.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by Tim Wescott●November 13, 20062006-11-13
Vladimir Vassilevsky wrote:
>
>
> Tim Wescott wrote:
>
>>> What is described there is not a true preemptive multitasker, but
>>> just another way to implement a cooperative multitasking. Therefore
>>> it appears to be fairly trivial and not very interesting.
>>>
>> If you mean "true preemptive multitasker" in the sense of "works just
>> like VxWorks", then no, it isn't.
>
>
> Exactly.
>
> What I usually need is several different threads. Each of the threads is
> running at least one time per X milliseconds, and is preempted after
> running for a maximum of Y milliseconds, if it did not return the
> control by itself.
>
> But it _does_ interrupt a lower
>
>> priority task just about anywhere it feels like to service a higher
>> priority task, and it doesn't go back until that higher priority task
>> is ready -- that seems like "true preemptive multitasking" to me.
>
>
> In SST, you can't preempt the current highest priority task just because
> you decided to do that. You also can't make time based scheduling. In
> this sense the SST is a classic background-foreground dual tasker with
> the cooperative multitasking on the top of it. Although I agree, it may
> be handy on some occasions.
>
One of us is confused. I know both of us are smart, and I know that I
read that article carefully. So I want to know if it's me, 'cause I'll
learn something thereby.
I assume that by "preempt the highest priority task just because you
decided to" means that if a higher priority task comes due, it'll run.
Assuming that I'm reading the article correctly, SST will do that and if
not a moderately clever fellow could fix it. What you _can't_ do is
temporarily raise a low-priority task's priority to resolve a priority
inversion issue, but in all the time I've been writing software for real
time systems this hasn't come up in any real designs.
As far as meeting time-based scheduling (priority-inversion avoidance
maneuvering aside), it will be the same as a more traditional task-loop
RTOS, barring the overhead of entering a function _then_ finding your
place in the state machine. So for even loadings, and assuming equal
overhead, SST and a more conventional RTOS should have exactly
equivalent performances.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by Vladimir Vassilevsky●November 13, 20062006-11-13
Tim Wescott wrote:
>> What is described there is not a true preemptive multitasker, but just
>> another way to implement a cooperative multitasking. Therefore it
>> appears to be fairly trivial and not very interesting.
>>
> If you mean "true preemptive multitasker" in the sense of "works just
> like VxWorks", then no, it isn't.
Exactly.
What I usually need is several different threads. Each of the threads is
running at least one time per X milliseconds, and is preempted after
running for a maximum of Y milliseconds, if it did not return the
control by itself.
But it _does_ interrupt a lower
> priority task just about anywhere it feels like to service a higher
> priority task, and it doesn't go back until that higher priority task is
> ready -- that seems like "true preemptive multitasking" to me.
In SST, you can't preempt the current highest priority task just because
you decided to do that. You also can't make time based scheduling. In
this sense the SST is a classic background-foreground dual tasker with
the cooperative multitasking on the top of it. Although I agree, it may
be handy on some occasions.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by Tim Wescott●November 12, 20062006-11-12
Vladimir Vassilevsky wrote:
>
>
> Hans-Bernhard Br�ker wrote:
>
>> Tim Wescott wrote:
>>
>>> Look in Embedded Systems Programming magazine a couple of issues
>>> back. There's a preemptive multitasker that does just that, as long
>>> as your tool chain lets you jump straight to a C function from an
>>> interrupt.
>>
>> And since when are interrupts codable in hardware-independent C?
>>
>> Jumping straight to a C function may be possible, but how does it jump
>> into the middle of a C function it interrupted, when the schedule
>> comes back to it?
>>
> What is described there is not a true preemptive multitasker, but just
> another way to implement a cooperative multitasking. Therefore it
> appears to be fairly trivial and not very interesting. Although it takes
> some time to dig through the words to realize what they are really doing.
>
If you mean "true preemptive multitasker" in the sense of "works just
like VxWorks", then no, it isn't. But it _does_ interrupt a lower
priority task just about anywhere it feels like to service a higher
priority task, and it doesn't go back until that higher priority task is
ready -- that seems like "true preemptive multitasking" to me.
So perhaps you could define your terms? We are both talking about the
one in the July '06 issue:
http://www.embedded.com//showArticle.jhtml?articleID=190302110, right?
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by Tim Wescott●November 12, 20062006-11-12
Hans-Bernhard Br�ker wrote:
> Tim Wescott wrote:
>
>> Look in Embedded Systems Programming magazine a couple of issues back.
>> There's a preemptive multitasker that does just that, as long as your
>> tool chain lets you jump straight to a C function from an interrupt.
>
>
> And since when are interrupts codable in hardware-independent C?
Good point -- I should have qualified that. For tool chains that have
the common interrupt embellishments, the concept appears to work for
less hardware dependent code than any other thing I'd see.
>
> Jumping straight to a C function may be possible, but how does it jump
> into the middle of a C function it interrupted, when the schedule comes
> back to it?
>
Reply by Vladimir Vassilevsky●November 12, 20062006-11-12
Hans-Bernhard Br=F6ker wrote:
> Tim Wescott wrote:
>=20
>> Look in Embedded Systems Programming magazine a couple of issues back.=
=20
>> There's a preemptive multitasker that does just that, as long as your =
>> tool chain lets you jump straight to a C function from an interrupt.
>=20
>=20
> And since when are interrupts codable in hardware-independent C?
>=20
> Jumping straight to a C function may be possible, but how does it jump =
> into the middle of a C function it interrupted, when the schedule comes=
=20
> back to it?
>=20
What is described there is not a true preemptive multitasker, but just=20
another way to implement a cooperative multitasking. Therefore it=20
appears to be fairly trivial and not very interesting. Although it takes =
some time to dig through the words to realize what they are really doing.=
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by ●November 12, 20062006-11-12
Tim Wescott wrote:
> Look in Embedded Systems Programming magazine a couple of issues back.
> There's a preemptive multitasker that does just that, as long as your
> tool chain lets you jump straight to a C function from an interrupt.
And since when are interrupts codable in hardware-independent C?
Jumping straight to a C function may be possible, but how does it jump
into the middle of a C function it interrupted, when the schedule comes
back to it?
Reply by Artur Lipowski●November 12, 20062006-11-12
Tim Wescott wrote:
> Hans-Bernhard Br�ker wrote:
>> jetmarc@hotmail.com wrote:
>>
>>> I'm looking for a 32-bit kernel with preemptive multitasking (realtime
>>> is not required). It should be simple & lightweight, and be written in
>>> hardware independant C (with full sourcecode).
...
> Tasks must run to completion (i.e. there are no task loops), which turns
> some 'ordinary' RTOS programming paradigms on their heads, but it looks
> like a solid way to code a very lightweight multi-tasker.