Re: STM32F4 Discovery, communication and libraries

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

On 14-08-31 10:02 , Dmitry A. Kazakov wrote:
> On Fri, 29 Aug 2014 19:31:00 +0300, Niklas Holsti wrote:
> 
>> For example (from memory, not tested):
> 
> [...]
> 
>> Did that answer your question?
> 
> Sort of.

Good.

> No_Local_Protected_Objects means all requests are pre-allocated at the
> library level and distributed by another protected object? With busy
> waiting for a free request?

No, the _request_ in my example code is not a protected object; it is an
ordinary record type. It _refers_ to a protected object which is a kind
of "I/O wait object".

The PO "wait object" is of course statically allocated (by Ravenscar
rules). Any task that will issue I/O requests must allocate such a PO
for itself. (If the task uses several different I/O servers, which have
different "wait object" types, the task has to allocate one PO for each
such I/O server it will use.)

(Oh well, of course one could also statically allocate a shared pool of
such POs and use some kind of protocol by which tasks can reserve a PO
from the pool when they need one, but why make things difficult?)

The example code I gave assumed that each client issues at most one
request at a time, to one server, and then waits for the request to be
completed. This requires one request object (which can be locally
allocated, or can even have value-semantics and be constructed in the
I/O call as in my example code), and one PO, which can be reused for any
number of requests.

By adding request identifiers and other data-structure complexities one
can implement multiple concurrent requests, waiting for any one of
multiple requests to complete ("select"), etc.

> When I evaluated Ravenscar for our middleware (long ago), the concern was
> publisher/subscriber services. I/O queue viewed as one of them. I didn't
> consider a solution like yours because the requirement was that more than
> one task could await for same I/O event. You reserve the event for single
> task and other publisher/subscriber services (e.g. the data logger, network
> data server, health monitor etc) may not use it because of
> Max_Protected_Entries = 1. The event cannot propagate because of
> No_Requeue_Statements. Tasks could flood the queue with their
> requests/events but they cannot do that for more than one queue.

You list a lot of things there... I don't really see how they are
related to each other, or if they are separate problems.

If for some reason you want to wake up two tasks when one I/O finishes,
the sample principle can be used: record two references, to two
protected objects - one per task - in the I/O request, and signal both
of them when the I/O completes.

For publish/subscribe, I would do something like this (not tested):


   protected type Mailbox_T
   --
   -- Each subscriber has an object of this type.
   --
   is

      procedure Signal (Event : in Event_Data_T);
      -- Called by the Publisher (through Publication_Channel, see
      -- below) to broadcast the Event to each subscriber.

      procedure Get_Last (
         Signalled : out Boolean;
         Event     : out Event_Data_T);
      -- Called by the Subscriber to poll (ask) if a new
      -- Event has been Signalled (i.e. non-blocking).

      entry Await (Event : out Event_Data_T);
      -- Called by the Subscriber when it wants to wait for
      -- the next broadcast Event.
   ...

   end Mailbox_T;


   type Mailbox_Ref is access all Mailbox_T;
   -- What the Publisher knows about a Subscriber.


   protected Publication_Channel is

      procedure Subscribe (
         Mailbox : in     Mailbox_Ref;
         Success :    out Boolean);
      -- Called by a new Subcriber.
      -- Enters the Mailbox (reference) in the subscriber list, or
      -- fails if the list is full (Success returned as False).

      procedure Publish (Event : in Event_Data_T);
      -- Called by the Publisher to broadcast a new Event
      -- to all subscribers in the list, by calling the Signal
      -- operation of the Mailbox for each subscriber.

   private

      Subscribers : array (1 .. 100) of Mailbox_Ref;

      Num_Subscribers : Natural := 0;
      -- The active subscriptions are indexed 1 .. Num_Subscribers.

   end Publication_Channel;


Depending on the timing and on whether it is important not to lose any
events, Mailbox_T may need an internal Event queue, or there may be a
global queue of past events to which the queue in Mailbox_T holds
references, and other such data structure refinements, all orthogonal to
Ravenscar constraints.

> It might do what you wanted, but it does not look scalable for the OP's
> purpose.

So far, I don't see anything in the OP's requirements that could not be
implemented with Ravenscar tasking.

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