On 11-12-13 12:49 , Alessandro Basili wrote:
> On 12/13/2011 12:06 AM, Anony Mous wrote:
>> On 12/12/2011 3:01 PM, Alessandro Basili wrote:
>>> I just started to (re)design the software for an embedded application on
>>> a very old DSP (ADSP21020 32bit floating point) and I was trying to look
>>> for some good books on embedded software development since I wanted to
>>> start it right from the beginning rather than chase it later on.
> [...]
>
>>
>> Not specifically on the ADSP21020, but the best embedded software book
>> that I've read is Practical UML Statecharts in C/C++ by Miro Samek.
>> http://www.state-machine.com/psicc2/index.php
>>
>
> That sounds good, I actually wanted to handle the whole code through
> hierarchical state machines. My biggest concern is the Time Analysis, or
> a strategy to keep the execution time under control. The application
> should not be very demanding in terms of computation but I still have to
> serve serial port commands and I wanted to avoid the usage of the
> interrupts.
It seems to me that these plans and concerns don't quite match up.
State machines help to master logical and functional complexity. By
reifying (part of) the state as state variables, it becomes easier to
make the state evolve a step at a time, and to make major ad-hoc
modifications to the state, for example to reset some part of the
software to its initial state. But state machines do not help with
timing in real-time systems.
In my opinion, the proper tool for timing problems in complex systems is
preemptive and prioritized execution, which includes interrupts and
perhaps several threads. Before you exclude them from your design space,
you should be sure that they are not needed. To do so, you must find and
consider the response-time requirements for your SW. For example, if
some I/O interface requires a SW response in 100 microseconds, you can
avoid interrupts only by making sure that your SW polls the interface at
that rate, which may force you to insert polling code within many
unrelated functions and activities. As those functions evolve during SW
development, you will have to maintain the polling code and ensure that
the duration between polls is always small enough. This can be quite a
burden, and must be done accurately if the SW is to be reliable.
Hardware features, such as FIFOs, that relax response-time requirements
help with this problem, but it seems (from other posts in this thread)
that your system lacks such features, at least in some places.
If the SW is built around some kind of event model, with a central
event-handling loop as in some state-machine implementations, the
polling can be centralized to the loop, as long as no event needs more
than 100 microseconds to be processed. But to ensure that each event is
processed rapidly enough, you may have to break up logical events into a
kind of "micro-events", which adds states to the state machines.
Alternatively, you can insert polling code within the processing of a
single event, again adding complexity and fragility.
Another way to try to systematize a non-preemptive design is to use a
cyclic major-frame/minor-frame schedule. But this has the same problems
of polling frequency, as illustrated by the daisy wheel printer software
that Walter Banks described in one of his posts in this thread (2011-12-18).
On 11-12-16 07:49 , Alessandro Basili wrote:
> I do believe that for these kind of applications the complexity
> of multi-tasking or multi-threading is not necessary and a
> simple hierarchical state machine may get the job done,
It may, but I consider that approach -- a single-thread, even with a
state machine -- quite risky for the development process. If the
real-time requirements turn out to be harder than can be supported in
the straight-forward state machine, you will either have to complicate
the state machine, as above, or add threads or interrupt handlers.
When the timing requirements are stringent, multi-threading under a
suitable kernel usually *removes* complexity from the application code.
> but since I have to serve the serial port in a timeliness fashion
> I'm not quite sure I would control the timing of the FSM.
You are right to worry about this, especially if one of your aims is to
speed up the serial communication.
> I personally believe that interrupts should be setting flags
> and that's it,
That seems an artificial and problematic limitation. You would be using
a high-priority, low-latency mechanism (the interrupt handler) just to
send a slow message (the flag) to tell a low-priority, high-latency
actor (the main thread) to do something, eventually, that in most cases
should be done urgently.
The division of labour between the interrupt handlers and the other
threads should be driven by the response-time requirements. The standard
approach is that the interrupt handler does whatever must be done at
that level, and then the handler signals (triggers) a thread, at an
appropriate priority level, to do the rest of the response to the
interrupt. This thread may be a dedicated one, ensuring that it is not
busy when the interrupt occurs.
> in this way the synchronization is totally handled at the FSM level
When the FSM gets around to it...
> and I shouldn't chase funny combinations of interrupts occurring in
> various moments (how would I test that???).
Interrupts always occur in funny combinations, however you handle them.
But you can usually write the handler to prevent nested interrupts, if
that feels safer.
> I think synchronization is really complex whenever you are down to the
> multi-thread business and/or have multiple interrupt servicing.
Multiple threads and multiple interrupts, with a proper kernel, can also
simplify the system by isolating different functions from each other,
especially for timing issues.
> Given the old technology and luckily very few support for an OS (I
> haven't found any),
For the 21020 there used to be at least a kernel called Virtuoso, from
Eonic Systems in Belgium. The company seems to exist still
(www.eonic.com) but I found no mention of Virtuoso on their web.
For this, and other questions on tools for the 21020, you can perhaps
get some help from the European Space Agency. Philippe Armbruster
(philippe.armbruster@esa.int) of the Data Systems division at ESA used
to be in charge of the space-qualified European 21020 implementation, as
I recall.
> I was aiming to have a very simple, procedural design which
> I believe would be much easier to test and to make it meet the specs.
Easier to test -- yes. Easier to meet specs -- doubtful for the
real-time specs.
On 11-12-18 06:24 , Alessandro Basili wrote:
> ... as I realized that I may be loosing
> interrupts I started to wonder about a different mechanism, trying to
> get under control the WCET of each function in order to meet timing,
> even though how can I rely on my WCET analysis?
Use an available static WCET-analysis tool for the 21020, and validate
its parameters with some execution-time measurements on your system.
Moreover, consider if your peripherals can block the 21020 by stealing
memory-access cycles with DMA. This can sometimes have a considerable
effect on execution time, and it can be hard to measure, since the DMA
is episodic.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .