Re: STM32F4 Discovery, communication and libraries

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-08-29 03:07 , Roy Emmerich wrote:
> To go a little deeper into my design:
> 
> Each sub-module will run in its own task with its own timer.

Hmm. I would probably not design it that way, but of course I don't know
all your requirements or plans.

To me, the modular aspect and the tasking/timing aspect should be
orthogonal and (nearly) independent aspects of the design.

I would describe a (functional) module as some coherent, inter-related
set of state variables, and operations which use and update the state
variables. The module does not necessarily have tasks of its own.

A task, on the other hand, defines a time-line of activations of
operations in (usually) several modules, which require similar or
synchronised timing, sequencing, or periodic execution.

In my experience, in a real-time system, most functional modules have
operations with different timing constraints and execution periods, and
which therefore should be executed by different tasks with different
priorities (in a pre-emptive system) or different execution periods (in
a statically scheduled, non-pre-emptive system).

In my designs, tasks contained in sub-modules tend to be sporadically
activated -- for example, the server task in the recent
I/O-request-queue discussion -- rather than cyclic.

> If, for example, I am monitoring a solar photovoltaic inverter via
> MODBUS RTU, it is possible to retrieve a lot of different information.
> Some information, like voltage and current, I may want to retrieve
> every second whereas other information like battery temperature
> I may only want to retrieve every 5 minutes.

That agrees with my experience.

> The module will know the sampling frequency for each variable to be
> monitored and will trigger itself when it is time to do so.

If these sampling frequencies are totally unrelated to other frequencies
and sampling phases in other sub-modules, defining a dedicated task (or
even two tasks, with different periods) within the sub-module can be the
sensible thing to do.

However, if many sub-modules have similar timing requirements, I would
use a couple of global tasks -- say, a cyclic task with 1-second period,
and another with a 1 minute period -- and have them call dedicated
procedures in this sub-module, and in other sub-modules with similar
sample-timing requirements. The benefit is avoiding the local timing
calculations; the drawback is that one must consider interference
between the tasks.

Perhaps the simplest design is to have one global task with a 1-second
period, which calls the 1-second operations from all sub-modules in
every period, and the 1-minute operations in every 60th period. But this
assumes that all the 1-minute operations can be finished in less than
one second of execution time.

Reducing the number of tasks in this way reduces the need for
stack-space RAM and tends to make the system's behaviour more regular,
predictable and understandable. But if your processor has plenty of
speed and memory, these effects may not be important to you.

If you want to make it very easy to add/remove sub-modules from the
system, defining local tasks in each sub-module may be the better
choice, because then you can easily avoid explicit calls from the main
application to the sub-module.

> Using protected objects and hard/firm/soft/non-critical tasks
> it sounds like this could indeed be a viable approach.

Sure. Many systems have been built that way in Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .