Re: STM32F4 Discovery, communication and libraries

[Mike Silva <mjsilva697@gmail.com>]

On Friday, August 29, 2014 12:34:06 AM UTC-7, Dmitry A. Kazakov wrote:
> On Thu, 28 Aug 2014 13:34:58 -0700 (PDT),
> 
> Mike Silva wrote:
> 
> > Are you saying that a full Ada implementation on bare metal could not
> > implement an equivalent of I/O queueing?
> 
> You could, but that would be equivalent to writing a small OS.

This is certainly the case - a complete Ada runtime is more complex than e.g. a complete C runtime, but it doesn't have to be built on an OS, and for smaller systems a bare-metal implementation is often going to be more attractive.  Interestingly, the original Lego Mindstorms Ada port was built on an RTOS, but later they switched over to bare metal.
> 
> > Or are you saying that Ravenscar tasking on bare metal could not implement
> > such queueing?
> 
> Ravenscar tasking profile has serious constraints preventing this. The
> nature of the constraints is to statically ensure schedulability. Asking
> that much you must pay the price...

That brings up two points relevant to this thread.  One is to find out from AdaCore how much more capability, if any, their current ARM Cortex M runtime actually has beyond the Ravenscar constraints.  I'd like to find that out.

Second is a brief comment I received from AdaCore, that they are looking at another tasking subset that removes some of the Ravenscar limitations while still allowing a small and fast bare-metal tasking implementation.  In my own words, I think they are looking for another sweet spot re functionaliy vs runtime complexity, one that will be useful to designers not requiring the guarantees that Ravenscar allows.  It makes a lot of sense to think that there could be other beneficial tasking/runtime profiles besides just Ravenscar and full Ada.