I've noted a certain style of programming that makes me uncomfortable, and I'm trying to articulate why....
Some people write real time programs that rely on properties of the scheduler and the respective priorities of the threads to ensure the proper sequencing of events.
ie. We have a bit-mapped / non-preemptive scheduler where higher priority runnable threads will always run before lower priority threads.
I prefer to use messaging or synchronization primitives to guarantee that no matter which scheduler, no matter what priorities, the events will occur in the correct sequence.
If you can't think of any other reason to be uncomfortable about this, consider that they're counting on a side effect of the OS for correct program behavior. This is the sort of thing that may well work just peachy for years, but will be fragile and will put extra constraints on the design process.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
In OSEK system (in one-task-per-priority mode) it is quite common. In this case it will even be portable!
If this will always be the case, than basing on that do not have to be a bad idea. If properly documented, that is. I would say- this is an acceptable shortcut.
Yes, but... This is more complicated approach. And in OSEK system sometimes not necessary. And sometimes you are punished heavily by OSEK implementation, if you want to use more than one 'extended' (one, that can wait for events) task - you are discouraged by OS itself. By punishment I mean- if there is only one task per priority and only the highest priority task is run and no task waits, then one can have one, common stack for all tasks. But if one wants to have tasks, that can wait for events, this is clearly not possible. The implementation then
*copies* the waiting task's stack to some storage, and copies it back to stack on task wake-up. This is *slow*.
To sum it up- synchronizing with events is cleaner, but sometimes unacceptable due to system constraints (memory, time) or project's design pattern (style). One has to adapt to requirements *and* rest of a team (or persuade others).
Hmm. Interesting. I have worked out what's bugging me though.
The "synchronize by priorities" pattern fundamentally breaks as soon as you port to a multicore system. Because then the lower priority and the higher priority thread can run concurrently.
How does OSEK plan on handling the wave of multicore CPU's coming out now?
Honestly? No idea :). OSEK (+MISRA) is used for passenger/driver security related systems in automotive (probably also for engine control). Because of MISRA one can not even use dynamic memory allocation or recursion (unless heavily guarded); +5V is is still the power supply of choice and no cache is a standard. It is meant to be cheap and simple. I doubt multicore falls in that category yet :). Besides OSEK is somewhat like POSIX - specification rather than system. With multiple implementation some of which contain system extensions not covered by OSEK (and this will be probably the way, how multicore will be put into use - by some system extensions).
\begin{speculation} I see two routes here:
1) OSEK extension - the specification will be extended to embrace muticore,
2) Two cores will be used as two separate CPUs, with communication via some 'interface' (shared memory?), so you will have two OSEKs running in parallel. \end{speculation}
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.