Re: Shared Memory for Application/Communication decoupling

"Christian Walter" <wolti@xxxxxx> wrote in message
news:newscache$pym6aj$sii$1@xxxxxxxxxxxxxx

Yes - the OS we had was custom and used a non standard fieldbus protocol
in the past. The old protocol did not set any requirements on the timing
of the device. If the device was busy it only answered to special
commands which where handled in an interrupt.

Building a message in an interrupt is fine; any further processing should be
scheduled. I'm sure that's what you mean.

Normal communication took place in the main loop where all calculations
where performed.

Some time ago it was decided that we need to support additional fieldbus
protocols and the project was limited in time and therefore most of the
existing code base had to be used. The new protocol had timing
requirements and we also needed to support reading values at any time.
Therefore I worked on the operating system (C + 68k assembler) and added a
preemptive multitasker together with some simple IPC primitives. This
parts are finished and therefore at least theoretically available for a
new design.

We are now in the need to support more devices in the feature and also
have time and resources to rework and create bigger software components.
In addition we want to move away from building our own OS ;).

FWIW, I often find that "building one's own OS" is an overstated task. A
simple roundrobin is easy to maintain, and actually enhances synchronism.
True preemptive multitasking has its place, but the asynchrony it brings
carries a lot of overhead and baggage. Again, I suspect you know this.

Maybe I could have told more about our already existing system but I think
it is sometimes necessary to rethink old ideas. And I did not want to bias
any of the opinions.

To put it another way, ensure that the comms task can only run when the
data is stable and self-consistent. If this means building comms data
packets on one pass through the loop, and buffering and transmission at a
more leisurely pace either by interrupts or by polling, so be it.
Similarly, for reception: when the application task runs, any
comms-written data should be stable: it'll be able to react to
(signalled) changes of data consistently, in one place. And you get your
temporal decoupling [1] for free, or more specifically as a key part of
the design.

It is not possible that the communication task runs only when the
currently calculated data has become stable (which is calculated during
automatic measurements) because the calculation takes to long (will also
take a lot of time on a fast CPU). Therefore we introduced some buffering
to communicate the values from the previous calculation. Of course I was a
requirement that both tasks only work on consistent data.

Do you mean that there's fast data and slow data? Can you not synchronise
the snapshots available to the comms task to the slower task? Or is that
what you mean by "previous calculation"?

Updating is therefore always done in atomic blocks and at well known
times.

This is good ;).

I'd say again: use a messaging system, not global data. Use methods (and
hence the opportunity to signal a query or a change) to access internal
data. At the very least, ensure that your comms task knows nothing at all
about the application task's data structure and use, and vice versa. I
repeat: there be dragons.

Right now they are linked as separate modules and do not know anything
from each other. The only share a common header file with SHM keys.

Hmmm. That's still global data. <Shudder.>

But as most people suggested a Message-Passing solutions I think I will go
away from the SHM approach and use a message passing system with three
tasks where one tasks acts as a coordinator. This matches my requirements,
is clear from the design and using a new OS I can use the message passing
primitives from there.

Wahay! You'll reap the benefits, I promise you. Decoupling is a Good Thing.
Not only does it immediately simplify things, it makes you think in another
way, which usually results in a simpler, cleaner system. And very often more
efficient too, since all the workarounds and kludges fall out. Wahay! ;)

Steve
http://www.fivetrees.com


.

Relevant Pages

  • Re: Shared Memory for Application/Communication decoupling
    ... If the device was busy it only answered to special commands which where handled in an interrupt. ... The big problems are that you have problems with consistency and in my opinion it should be done like I scratched below (at least if requirements allow and what I learned from working with protocol stacks). ... And you get your temporal decoupling for free, or more specifically as a key part of the design. ... It is not possible that the communication task runs only when the currently calculated data has become stable because the calculation takes to long. ...
    (comp.arch.embedded)
  • Re: What is the Result from Invoking this Halt Function?
    ... > whether or not the return protocol changes the calculation. ... machines in all programming languages, ... There is no 'query the UTM' operation. ...
    (sci.logic)
  • Re: What is the Result from Invoking this Halt Function?
    ... > whether or not the return protocol changes the calculation. ... machines in all programming languages, ... There is no 'query the UTM' operation. ...
    (comp.theory)