Re: STM32F4 Discovery, communication and libraries

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 01 Sep 2014 21:39:52 +0300, Niklas Holsti wrote:

> On 14-09-01 19:42 , Dmitry A. Kazakov wrote:
>> On Sun, 31 Aug 2014 21:41:15 +0300, Niklas Holsti wrote:
>> 
>>> On 14-08-31 10:02 , Dmitry A. Kazakov wrote:
>> 
>>>> 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".
>> 
>> That was clear.
> 
> Good, but in that case your comment, quoted above, was rather
> misleading, because it clerly implies that requests are affected by
> No_Local_Protected_Object.

Because you don't want to expose these objects in the interfaces. So,
normally one would use a local object or better an object on the server
side, which Ravescar prevents.

>>> For publish/subscribe, I would do something like this (not tested):
>> [...] 
>> 
>> You don't need anything this complex so long you monitor a single channel.
>> The challenge is to subscribe to several channels and also to avoid
>> unnecessary copying of I/O data.
> 
> So, explain how you do it with the full Ada tasking profile, and I'll
> see if I can implement the same thing under Ravenscar rules. Or show a
> simpler solution for one channel under Ravenscar rules, that would also
> be interesting.

You have I/O channels. You can start I/O on them. You can await for I/O
completion of the specific I/O request or any request. You can await for
I/O request completion in any channel. You can end a specific I/O request
on the channel. Emitters of I/O state changes (publishers) are not blocked
by any subscribers (e.g. no priority inversion, hence, no direct
callbacks). Event/data loss on the subscriber side is detectable. Number of
protected actions per event is constant.

> I/O data copying can be avoided by passing references and using
> reference counting.

Reference counting requires further protected actions for dealing with
counters and this is the number of waiting tasks x the number of operations
x fixed multiplicand, at least, 2. In my design a lock-free-read blackboard
is used, but that has issues with Ravenscar's entry count limitation at the
write-end.

>> Theoretically you could create channels
>> that are combinations of queues of events to monitor register them by the
>> queues. I don't know how much overhead it will be (I was trying to reduce
>> number of protected actions per event), but it looks ugly and overly
>> complicated.
> 
> General rule: a simpler, less powerful language (Ravenscar) leads to
> more complex application programs, when the application functionality is
> kept constant. You pays your money and you takes your choice.

This is certainly true. Ada has enough silly limitations to add Ravenscar
on top of it. From the software and general engineering POV you better
invest in advance into reusable stuff, e.g. into the language, into
libraries, than face complexity later at the application side.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de