Re: Ada in command / control systems

[russ lyttle <lyttlec@removegmail.com>]

On 2/26/19 6:09 PM, Simon Wright wrote:
> lyttlec <lyttlec@removegmail.com> writes:
> 
>> The "use linker script" part is where I am having difficulty with gnat
>> targeting a PC. Haven't tried the STM32F4 yet.
>> All I've found so far, including tutorial on AdaCore, apply only to
>> Windows and produce errors in Linux. For example the  advice to  use
>> "-Xlinker -Wl --stack = ..." is Windows only.
> 
> gnatbind (try --help to get the full set of options) has these, which
> might help. Bad idea to use these in a small MCU.
> 

>    -dnn[k|m] Default primary stack size = nn [kilo|mega] bytes
>    -Dnn[k|m] Default secondary stack size = nn [kilo|mega] bytes
> 
>>   We may have to give up and switch back to using Makefile, which
>> probably isn't such a bad idea anyway.
> 
> Don't see how this will help, you need to work out how to get the
> compiler, binder and linker to cooperate.
> 
Done that with Makefiles  on other projects. Now looking for a way to do 
it with gpr files. I don't want to give up until I'm sure that I must.

> I'm having a bit of trouble working out what you're trying to do. You
> seem to be targeting a wide range of platforms, from Linux to embedded
> MCUs. The need to control sizes etc is much less in a Unix-like
> environment, and I doubt very much you'd want to use EEPROM (do you mean
> that, by the way? MCUs seem to use Flash) or even bother to think about
> how the linker arranges things so that the program starts up properly.
> 
Should have said Flash.
Watch
https://www.youtube.com/watch?v=3jstaBeXgAs
Not my project, but you get the idea. Lots of (small) computers 
networked. Penney's count so the lowest cost mcu must be used. At least 
one device has an OS, some need a scheduler, most are bare bones. All 
are going to be pushed to the limit.  The life of the software will be 
long, even though some of the mcu might change. For example the mcu 
reporting tire air pressure might change between production runs or 
model year.
> The same applies to more capable boards on the lines of the Raspberry Pi
> - just another Unix-like platform.
We will have one or more R-Pi class devices that need a provably secure 
and correct OS. While Raspbian is much better than Windows 10, how would 
you show that it is correct?
> 
> But when it comes to MCUs like the STM32F4 with a megabyte of Flash and
> 128K of RAM (actually, there's another 64K of close-coupled RAM, I see)
> more care is needed. A lot of this will have been looked after by
> whoever provides your runtime.
The STM32F4 is one of the easy ones. Think of it as representing a class 
of target, rather than a specific target. STMicro today might be 
replaced with Freescale next year. "Whoever provides your runtime" is me.
>