Re: STM32F4 Discovery, communication and libraries

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

On 14-08-29 16:06 , Dennis Lee Bieber wrote:
> On Thu, 28 Aug 2014 13:34:58 -0700 (PDT),
> embeddedrelatedmike@scriptoriumdesigns.com declaimed the following:
> 
>> On Thursday, August 28, 2014 1:09:05 PM UTC-7, Dmitry A. Kazakov wrote:
>>> Not really. OS is more than tasking, it is also a queueing mechanism, which
>>> allows waiting for I/O completion in one task without blocking all other
>>> tasks.
>>> ......
>>> You could not implement an equivalent of I/O queueing under the Ravenscar 
>>> constraints.
>>
>> Are you saying that a full Ada implementation on bare metal could
>> not implement an equivalent of I/O queueing?
>>
>> Or are you saying that Ravenscar tasking on bare metal could not implement
>> such queueing?
> 
> 	Have you looked at the list of restrictions that profile requires?
> 
> 	Max_Task_Entries = 0 (which goes along with)
> 	No_Select_Statements
> 
> 	Max_Protected_Entries = 1 (effectively no queuing up for access to
> protected objects by multiple tasks)
> 	Simple_Barriers (plain T/F Boolean variable controlling entries)
> 
> 	No_Relative_Delays (no "delay n" only "delay until m")
> 
> 	Oh, and No_Abort_Statements (and a number of other restrictions)

All Ravenscar restrictions are on the _tasking_ system, with the
exception of No_Implicit_Heap_Allocation and forbidding the use of
Ada.Calendar (but _explicit_ heap allocation remains possible).

The rest of Ada remains in its full form.

However, some Ravenscar run-time systems _also_ have other restrictions,
for example limitations on the use of unconstrained array types in
expressions.

> 	It works if the entire system including the "user application" level is
> built "as one".

That same restriction holds for all standard Ada programs (with the
possible exception of distributed programs -- I have no experience
there). At bind time, all the compilation modules forming the program
are identified and included in the program, and no other modules/code
can be added later, unless the program dynamically links to plug-in
libraries, which is not standard Ada.

> It is NOT a very dynamic arrangement wherein you may plug
> in a new sensor and have it magically install itself to some list of
> sensors to be reported.

It is certainly possible to write a Ravenscar program in which adding a
new sensor can be done by adding a single line, "with My_New_Sensor", to
the main subprogram. At elaboration time, My_New_Sensor can install its
tasks and protected objects in the application's data structures. No
problem.

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