How to configure GNAT GPL on x86-64 Linux for ARM ELF development

How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Adam Jensen]

Prologue:

I would like to tinker with Ada and Spark embedded real-time software 
development. I have these two books:

https://www.amazon.com/Concurrent-Real-Time-Programming-Alan-Burns/dp/
0521866979/
https://www.amazon.com/Analysable-Real-Time-Systems-Programmed-Ada/dp/
1530265509/

And these two books are on the way:

https://www.amazon.com/Building-Parallel-Embedded-Real-Time-Applications/
dp/0521197163/
https://www.amazon.com/Building-High-Integrity-Applications-SPARK/dp/
1107656842/

To start, I have a Nucleo-144 board with an STM32F429ZIT6 MCU. 

https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-
F429ZI/497-16280-ND/5806777

I have installed Adacore's Gnat GPL and SPARK Discovery on Ubuntu 18.04 
LTS in: 

$HOME/.local/gnat

And I've installed gnat-gpl-2017-arm-elf-linux-bin.tar.gz in:

$HOME/.local/gnat-arm

I am following this tutorial:

http://www.inspirel.com/articles/Ada_On_Cortex.html
-------------------------------------------------------------------------

The first example in that tutorial is:

#program.ads
package Program is

   procedure Run;
   pragma Export (C, Run, "run");

end Program;

# program.adb
package body Program is

   procedure Run is
   begin
      loop
         null;
      end loop;
   end Run;

end Program;

# flash.ld
OUTPUT_FORMAT("elf32-littlearm")
OUTPUT_ARCH(arm)

SECTIONS
{
    .vectors 0x08000000 :
    {
        LONG(0x20010000)
        LONG(run + 1)
        FILL(0)
    }

    .text 0x08000200 :
    {
        *(.text)
    }
}
-------------------------------------------------------------------------

Given:

PATH="$HOME/.local/gnat-arm/bin:$PATH"; export PATH

The tutorial suggests that maybe this (below) might produce a binary 
suitable to be loaded onto the MCU:

arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb
arm-eabi-ld -T flash.ld -o program.elf program.o 
arm-eabi-objcopy -O binary program.elf program.bin

This is what actually happens:

$ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb
fatal error, run-time library not installed correctly
cannot locate file system.ads
compilation abandoned

I guess that the LD_LIBRARY_PATH and GPR_PROJECT_PATH environment 
variables should be set but I don't yet understand enough to make 
reasonable guesses. 

Any advice on how to proceed would be very much appreciated! 

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Simon Wright]

Adam Jensen <hanzer@riseup.net> writes:

> $ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb
> fatal error, run-time library not installed correctly
> cannot locate file system.ads
> compilation abandoned

> Any advice on how to proceed would be very much appreciated! 

I think that the reason why the tutorial works and your attempt doesn't
is that the tutorial was developed on a Raspberry Pi, which is already
an ARM-based machine, so the native compiler actually has a runtime
(i.e. system.ads etc etc) visible to it.

Yours doesn't, and gcc-for-ada must see an RTS.

I managed to get a compilation using this over-the-top incantation:

   $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4

but a simpler (more memorable!) procedure might be to construct your own:

1. Create directories adainclude/, adalib/

2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your
   adainclude/ ($prefix is the root of your compiler installation, I
   think ~/.local/gnat-arm)

The zfp- (zero footprint) runtime is the closest to what you need, and
the fact that the -stm32f4 part isn't quite right shouldn't matter; I
suspect that system.ads is the same for all the zfp runtimes.

Now,

   $ arm-eabi-gcc --RTS=. -c program.adb

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Adam Jensen]

On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote:

> Adam Jensen <hanzer@riseup.net> writes:
> 
>> $ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb fatal error,
>> run-time library not installed correctly cannot locate file system.ads
>> compilation abandoned
> 
>> Any advice on how to proceed would be very much appreciated!
> 
> I think that the reason why the tutorial works and your attempt doesn't
> is that the tutorial was developed on a Raspberry Pi, which is already
> an ARM-based machine, so the native compiler actually has a runtime
> (i.e. system.ads etc etc) visible to it.
> 
> Yours doesn't, and gcc-for-ada must see an RTS.
> 
> I managed to get a compilation using this over-the-top incantation:
> 
>    $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4
> 

Many thanks, this works! I do not yet know why it works - what it is 
doing - but the hint is a valuable. It occurred to me that I should be 
looking for Adacore documentation. I have yet to find a "getting started" 
tutorial for embedded development aimed at scientists, engineers and 
other technically mature people (ideally, such a tutorial would be 
comprehensive, to the point, and regularly tested), but I did find:

GPRbuild and GPR Companion Tools User’s Guide
<https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html>

and

GNAT User’s Guide Supplement for Cross Platforms
<http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx.html>

By mining these two documents it might be possible to extract a basic 
explanation for these very first steps of the embedded development 
process.

It is curious that the Ada technology's utilization of the system 
engineering approach has not [yet] been extended into the pedagogical 
component. After all, software development is a very human-centric 
process.

But I digress. Thanks again for the guidance! After extracting the basics 
of project management from the core documentation, I hope to find a build 
process that enables the use of a Ravenscar profile. And after that I 
hope to configure the development environment to include Spark process 
components in the real-time embedded system. Does this seem reasonable? 
 

> but a simpler (more memorable!) procedure might be to construct your
> own:
> 
> 1. Create directories adainclude/, adalib/
> 
> 2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your
>    adainclude/ ($prefix is the root of your compiler installation, I
>    think ~/.local/gnat-arm)
> 
> The zfp- (zero footprint) runtime is the closest to what you need, and
> the fact that the -stm32f4 part isn't quite right shouldn't matter; I
> suspect that system.ads is the same for all the zfp runtimes.
> 
> Now,
> 
>    $ arm-eabi-gcc --RTS=. -c program.adb

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Brian Drummond]

On Thu, 24 May 2018 07:35:46 +0000, Adam Jensen wrote:

> On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote:
> 
>> Adam Jensen <hanzer@riseup.net> writes:
>> 
>>> Any advice on how to proceed would be very much appreciated!
>> 
>> I managed to get a compilation using this over-the-top incantation:
>> 
>>    $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4
>> 
>> 
> Many thanks, this works! I do not yet know why it works - what it is
> doing - but the hint is a valuable. It occurred to me that I should be
> looking for Adacore documentation. I have yet to find a "getting
> started"

The error you saw "Cannot find system.ads" and Simon's answer arise 
because, targeting small embedded CPUs, you are looking below the full 
Ada environment (supplied by the runtime system (RTS) on the host 
machine, to targets which may require unique runtimes supplying the 
facilities you need and nothing more (thanks to potential space 
limitations).

As such I would suggest a ZFP RTS as a good short-term study,for several 
reasons:

it can be a pretty small codebase, but revealing in terms of how things 
are done and how to adapt them.

there are a plethora of targets out there, un- or semi-supported by Ada, 
from the AVR and MSP430 to ARM cores from ST, NXP, TI and others. 
Starting with the STM4 as you are is good, but you may want to port to 
other platforms for cost, power, security or other reasons ... the TI 
Hercules which runs dual ARM cores in lockstep for safety, has obvious 
attractions as an Ada target, for example. 

Nice price too ... https://store.ti.com/LAUNCHXL-TMS57004.aspx 

And porting to these builds on understanding the RTS, starting with the 
simplest - ZFP - as in Simon's suggestion - or AVR-Ada or my MSP430-Ada 
adaptation. I finally got round to machining the case and bezel, so I am 
wearing a wristwatch running Ada, telling the time 1970's style, in under 
1 kilobyte including RTS.

(the current version still has 200 bytes of C startup code which the 
linker insists on inserting by default; one TODO is to persuade the 
linker to let me replace that with pure Ada and strip out the unnecessary 
stuff)


You suggest going in 2 more interesting directions: 

building up to a Ravenscar profile : I believe Simon's work so far builds 
on FreeRTOS, but a "native" Ravenscar RTOS would be nice too...

SPARK qualification would be excellent ... again, especially for the 
Hercules. And again, a SPARK proven ZFP RTS would be a good base to build 
on, and a relatively simple place to start.


-- Brian

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Adam Jensen]

I am trying the "Digital Output" example described here:
<http://www.inspirel.com/articles/Ada_On_Cortex_Digital_Output.html>

Compilation seems to be successful with these commands: 
gprbuild -c -u -f utils.adb --target=arm-eabi --RTS=zfp-stm32f4
gprbuild -c -u -f pins.adb --target=arm-eabi --RTS=zfp-stm32f4
gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4

But linking fails like this:
arm-eabi-ld -T ../flash.ld -o program.elf program.o pins.o utils.o
pins.o: In function `pins__enable_output':
pins.adb:(.text+0x20): undefined reference to `__gnat_last_chance_handler'
pins.o: In function `pins__write':
pins.adb:(.text+0x7a): undefined reference to `__gnat_last_chance_handler'

The symbols in "pins" are:
arm-eabi-nm pins.o
         U __gnat_last_chance_handler
         U GPIOA_BSRR
         U GPIOA_MODER
00000000 D pins_E
00000000 T pins__enable_output
00000060 T pins__write
         U RCC_AHB1ENR

Eager to move forward, I cobbled together a GPR project file targeting 
the full Ravenscar profile.

#ravenScar.gpr
 project Ravenscar is
    for Source_Dirs use ("src");
    for Ignore_Source_Sub_Dirs use (".svn");
    for Object_Dir use "obj";
    for Exec_Dir use ".";
    for Main use ("program.adb");
    for Runtime ("Ada") use "ravenscar-full-stm32f4";
    for Target use "arm-eabi";

    package Builder is
        for Executable_Suffix use "";
        for Global_Configuration_Pragmas use "src/gnat.adc";
    end Builder;

    package Compiler is
        for Default_Switches ("ada") use ("-O0", "-gnatwa", "-gnatQ", "-
gnatw.X");
    end Compiler;

    package Binder is
        for Required_Switches ("Ada") use Binder'Required_Switches 
("Ada") &
            ("gnatbind_prefix=arm-eabi-") &
            ("--RTS=/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/
ravenscar-full-stm32f4/") &
            ("-nostdlib");
        for Driver ("Ada") use
            "/home/hanzer/.local/gnat-arm/libexec/gprbuild/gprbind";
    end Binder;

    package Linker is
        for Driver use Compiler'Driver ("Ada");
        for Map_File_Option use "-Wl,-Map,";
        for Response_File_Format use "GCC_GNU";
        for Max_Command_Line_Length use "8192";
        for Required_Switches use Linker'Required_Switches &
            ("-L/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/ravenscar-
full-stm32f4/adalib",
            "-nostartfiles", "-lgnat", "-lc", "-lgnat", "-lgcc",
            "-L/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/ravenscar-
full-stm32f4/ld",
            "-T", "flash.ld");
    end Linker;
end Ravenscar;
-------------------------------------------------------------------------

I didn't really expect it to work - I am well into the realm of wild-ass 
guesses at this point. This is what happens:

gprbuild -P ./ravenscar.gpr
Compile
   [Ada]          program.adb
   [Ada]          pins.adb
   [Ada]          utils.adb
   [Ada]          registers.ads
Bind
   [gprbind]      program.bexch
   [Ada]          program.ali
program.adb:1: Program cannot be used as a main program
gprbind: invocation of gnatbind failed
gprbuild: unable to bind program.adb


On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote:

> I think that the reason why the tutorial works and your attempt doesn't
> is that the tutorial was developed on a Raspberry Pi, which is already
> an ARM-based machine, so the native compiler actually has a runtime
> (i.e. system.ads etc etc) visible to it.

This is so very relevant yet the tutorial seems rather vague [to me] on 
this point. It should be explicit, in bold, in a highlighted box on the 
front page, IMO. Thanks again for pointing that out. Even on a second 
reading, it isn't clear [to me] that using a Raspberry Pi as a software 
development platform is the environment of the tutorial. 

<http://www.inspirel.com/articles/
Ada_On_Cortex_Documentation_And_Tools.html>

> but a simpler (more memorable!) procedure might be to construct your
> own:
> 
> 1. Create directories adainclude/, adalib/
> 
> 2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your
>    adainclude/ ($prefix is the root of your compiler installation, I
>    think ~/.local/gnat-arm)
> 
> The zfp- (zero footprint) runtime is the closest to what you need, and
> the fact that the -stm32f4 part isn't quite right shouldn't matter; I
> suspect that system.ads is the same for all the zfp runtimes.
> 
> Now,
> 
>    $ arm-eabi-gcc --RTS=. -c program.adb

I will try this next. It's a bit like learning to swim by jumping into 
the deep end of the pool (or being thrown in). This article might help:

"Porting the Ada runtime to a new ARM board"
<https://blog.adacore.com/porting-the-ada-runtime-to-a-new-arm-board>

I also ordered a copy of this book (below) since I don't actually know 
the Ada programming language (I have plenty of experience with VHDL).

<https://www.amazon.com/Programming-Ada-2012-John-Barnes/dp/110742481X/>

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Adam Jensen]

On Thu, 24 May 2018 12:12:26 +0000, Brian Drummond wrote:

> The error you saw "Cannot find system.ads" and Simon's answer arise
> because, targeting small embedded CPUs, you are looking below the full
> Ada environment (supplied by the runtime system (RTS) on the host
> machine, to targets which may require unique runtimes supplying the
> facilities you need and nothing more (thanks to potential space
> limitations).
> 
> As such I would suggest a ZFP RTS as a good short-term study,for several
> reasons:
> 
> it can be a pretty small codebase, but revealing in terms of how things
> are done and how to adapt them.
> 
> there are a plethora of targets out there, un- or semi-supported by Ada,
> from the AVR and MSP430 to ARM cores from ST, NXP, TI and others.
> Starting with the STM4 as you are is good, but you may want to port to
> other platforms for cost, power, security or other reasons ... the TI
> Hercules which runs dual ARM cores in lockstep for safety, has obvious
> attractions as an Ada target, for example.
> 
> Nice price too ... https://store.ti.com/LAUNCHXL-TMS57004.aspx
> 

Adacore's Gnat GPL seems to include a full Ravenscar RTS for Xilinx's 
zynq7000 ARM/FPGA SoC:

<https://www.xilinx.com/products/boards-and-kits/device-family/nav-
zynq-7000.html>

One of those development kits might be my next target platform, but 
successfully configuring tools from two different vendors for hardware/
software co-design - simulation, emulation, and cross-compilation - on a 
third-party OS (Ubuntu or RHEL) seems like a long way off. Right now, 
configuring a Ravenscar/Spark development environment that can produce a 
binary for the Nucleo-144 board that will flash an LED is the 
[surprisingly challenging] goal :)  

> And porting to these builds on understanding the RTS, starting with the
> simplest - ZFP - as in Simon's suggestion - or AVR-Ada or my MSP430-Ada
> adaptation. I finally got round to machining the case and bezel, so I am
> wearing a wristwatch running Ada, telling the time 1970's style, in
> under 1 kilobyte including RTS.
> 
> (the current version still has 200 bytes of C startup code which the
> linker insists on inserting by default; one TODO is to persuade the
> linker to let me replace that with pure Ada and strip out the
> unnecessary stuff)
> 

That seems [to me] like a curiously superfluous application of the 
technology but rock on, dude.
 
> 
> You suggest going in 2 more interesting directions:
> 
> building up to a Ravenscar profile : I believe Simon's work so far
> builds on FreeRTOS, but a "native" Ravenscar RTOS would be nice too...
> 
> SPARK qualification would be excellent ... again, especially for the
> Hercules. And again, a SPARK proven ZFP RTS would be a good base to
> build on, and a relatively simple place to start.

Is it common for developers to create their own run-time system for 
embedded platforms? My inclination would be to look for hardware based on 
1) RTS availability/quality and 2) toolkit complexity/completeness 
(completeness implies useful documentation). Given that, which seems like 
an obvious thing to do, I am surprised that Adacore does not have more 
apparent associations with hardware vendors where dev-kits and SBC 
products are promoted. I bought the Nucleo-144 board because I thought 
there was a BSP, RTS, and a tool-chain configuration tutorial. That 
turned out to be a bit of a mistake and generally a poor choice. If 
Adacore, or some other enterprising entrepreneur, offered well-developed 
BSP, RTS, tool-chain configuration and programming tutorials for several 
MCU dev-kits and SBC (single board computer) products, that would make 
the choice easy and actually enable people to get started with the 
technology in a reasonable way. It seems so bizarre to me that this isn't 
a front-page item for Adacore. I guess there are hidden obstacles in 
their business model and the way the incentives are arranged in their 
social organization. I suppose it could have something to do with 
European culture. In France, does pedagogy have the demeanor of a wood-
chipper (e.g., is it based in punishment, toil, and obscurity)? <smirk>

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Simon Wright]

Adam Jensen <hanzer@riseup.net> writes:

> I am trying the "Digital Output" example described here:
> <http://www.inspirel.com/articles/Ada_On_Cortex_Digital_Output.html>
>
> Compilation seems to be successful with these commands: 
> gprbuild -c -u -f utils.adb --target=arm-eabi --RTS=zfp-stm32f4
> gprbuild -c -u -f pins.adb --target=arm-eabi --RTS=zfp-stm32f4
> gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4
>
> But linking fails like this:
> arm-eabi-ld -T ../flash.ld -o program.elf program.o pins.o utils.o
> pins.o: In function `pins__enable_output':
> pins.adb:(.text+0x20): undefined reference to `__gnat_last_chance_handler'
> pins.o: In function `pins__write':
> pins.adb:(.text+0x7a): undefined reference to `__gnat_last_chance_handler'

From the tutorial, towards the end,

   You should notice the -gnatp option when compiling the pins.adb
   file. This option instructs the compiler not to generate calls to
   range check functions that verify whether the values that are
   assigned to variables or converted between types fall within expected
   ranges and if not, an appropriate standard exception is raised. We
   have decided not to rely on the Ada run-time library and without this
   option the final program would not link properly (try it, you can
   also check the assembly output for the pins.adb file and see that
   indeed there are some calls to other, language-supporting
   subprograms).

and then

   Instead, we can verify the code and conclude that all values are safe
   and therefore resign from run-time range checks altogether, which in
   the embedded context is a more robust approach anyway. Later on we
   will see how to automate such analysis, which with bigger programs
   could be much less straightforward when done manually. For the time
   being, we will rely on manual verification and the -gnatp option in
   such cases.

I think Maciej is referring to proof techniques, which is laudable, but
I find it necessary to let the exceptions happen if I make a mistake;
I've tended to have a 'heartbeat' LED flash, so that if the last chance
handler (which disables interrupts and loops) happens I can at least see
that something's wrong.

AdaCore's Certyflie[1] implementation for the Crazyflie brings some
SPARK proof to the drone's firmware, but (a) it only applies to the
application layer, not the drivers, (b) it crashes the 2017 CE SPARK
package, (c) without expert assistance, I can't get my head round the
contortions necessary to do SPARK (particularly the real-time aspects).

[1] https://github.com/AdaCore/Certyflie

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Brian Drummond]

On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote:

> On Thu, 24 May 2018 12:12:26 +0000, Brian Drummond wrote:
> 
>> The error you saw "Cannot find system.ads" and Simon's answer arise
>> 
>> SPARK qualification would be excellent ... again, especially for the
>> Hercules. And again, a SPARK proven ZFP RTS would be a good base to
>> build on, and a relatively simple place to start.
> 
> Is it common for developers to create their own run-time system for
> embedded platforms? My inclination would be to look for hardware based
> on 1) RTS availability/quality and 2) toolkit complexity/completeness
> (completeness implies useful documentation). 

Not common, no. But RTS availability (esp. SPARK RTS) has to start 
somewhere, and for the MSP430 I didn't really develop one, just adapt 
from AVR-Ada.

With remarkably little feedback on that project, I admit I've put 
remarkably little effort into pushing it further. But I want it for my 
own purposes, the watch is just a pretty by-product.


> Given that, which seems
> like an obvious thing to do, I am surprised that Adacore does not have
> more apparent associations with hardware vendors where dev-kits and SBC
> products are promoted. I bought the Nucleo-144 board because I thought
> there was a BSP, RTS, and a tool-chain configuration tutorial. That
> turned out to be a bit of a mistake and generally a poor choice. 

Not Adacore ... there isn't much hobbyist money for them, given their 
business model. They do publicise occasional hobby-level projects like 
Lego Mindstorms and Certyflie, but I don't see them making money off it.

Meanwhile we have to support each other, perhaps your work on Nucleo can 
feed back into Simon's RTS and expand its supported platforms.

-- Brian

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Adam Jensen]

On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote:

> On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote:
> 
>> Is it common for developers to create their own run-time system for
>> embedded platforms? My inclination would be to look for hardware based
>> on 1) RTS availability/quality and 2) toolkit complexity/completeness
>> (completeness implies useful documentation).
> 
> Not common, no. But RTS availability (esp. SPARK RTS) has to start
> somewhere, and for the MSP430 I didn't really develop one, just adapt
> from AVR-Ada.
> 
> With remarkably little feedback on that project, I admit I've put
> remarkably little effort into pushing it further. But I want it for my
> own purposes, the watch is just a pretty by-product.

Super cool. Are your project's documents posted/hosted anywhere for 
others to view and use? 

>> Given that, which seems like an obvious thing to do, I am surprised
>> that Adacore does not have more apparent associations with hardware
>> vendors where dev-kits and SBC products are promoted. I bought the
>> Nucleo-144 board because I thought there was a BSP, RTS, and a
>> tool-chain configuration tutorial. That turned out to be a bit of a
>> mistake and generally a poor choice.
> 
> Not Adacore ... there isn't much hobbyist money for them, given their
> business model. They do publicise occasional hobby-level projects like
> Lego Mindstorms and Certyflie, but I don't see them making money off it.

They have the "Make with Ada" competition: 
<https://www.makewithada.org/>

And the Adacore University:
<http://university.adacore.com/>

If there is not a large vibrant community of people who understand and 
use the technology it will fade and collapse. It seems like maybe they 
recognize this but it doesn't seem like they know what to do. (Only an 
idiot would have advertisers involved in technical communication). C'est 
la vie.
 
> Meanwhile we have to support each other, perhaps your work on Nucleo can
> feed back into Simon's RTS and expand its supported platforms.

The Nucleo-144 board was selected as a gentle starter kit to develop some 
confidence and familiarity with the tool-chain and the work-flow. It was 
a total failure in this role. However, I have been keeping notes and at 
some point I might create a tutorial for Ada/Spark development on Ubuntu 
x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I will 
probably move to a platform with more resources. Eventually, I need a 
processor coupled with an FPGA - the FPGA is where most of the hard real-
time activity (traction with physics) should take place, IMO.

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Brian Drummond]

On Sat, 26 May 2018 05:06:40 +0000, Adam Jensen wrote:

> On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote:
> 
>> On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote:
>> 
>>> Is it common for developers to create their own run-time system for
>>> embedded platforms? My inclination would be to look for hardware based
>>> on 1) RTS availability/quality and 2) toolkit complexity/completeness
>>> (completeness implies useful documentation).
>> 
>> Not common, no. But RTS availability (esp. SPARK RTS) has to start
>> somewhere, and for the MSP430 I didn't really develop one, just adapt
>> from AVR-Ada.
>> 
>> With remarkably little feedback on that project, I admit I've put
>> remarkably little effort into pushing it further. But I want it for my
>> own purposes, the watch is just a pretty by-product.
> 
> Super cool. Are your project's documents posted/hosted anywhere for
> others to view and use?

https://sourceforge.net/projects/msp430ada/

It's somewhat stuck in the past, using Peter Bigot's rather nice MSP430 
backend, because gcc's own MSP430 backend built into newer versions have 
a considerably poorer code generator (last time I looked a couple of 
years ago).

Revisiting it is on my to-do list, hopefully it has improved.

> They have the "Make with Ada" competition:
> <https://www.makewithada.org/>
> 
> And the Adacore University:
> <http://university.adacore.com/>

Both good forms of publicity, though I wonder to what extent they manage 
to bring in new people as opposed to reaching to the converted.

(and I know you've been involved with at least one Ada project for a few 
years :-)

> The Nucleo-144 board was selected as a gentle starter kit to develop
> some confidence and familiarity with the tool-chain and the work-flow.
> It was a total failure in this role. However, I have been keeping notes
> and at some point I might create a tutorial for Ada/Spark development on
> Ubuntu x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I
> will probably move to a platform with more resources. Eventually, I need
> a processor coupled with an FPGA - the FPGA is where most of the hard
> real- time activity (traction with physics) should take place, IMO.

You'll know all about the bottlenecks between a nice fast FPGA engine and 
any embedded CPU then.

-- Brian

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Jacob Sparre Andersen]

Brian Drummond wrote:

> Both good forms of publicity, though I wonder to what extent they
> manage to bring in new people as opposed to reaching to the converted.

It is my impression that the Make with Ada competition actually has
reached people, who didn't use Ada before.  (Not that people who already
know Ada aren't interested too.)

Greetings,

Jacob
-- 
»Saving keystrokes is the job of the text editor, not the
 programming language.«                    -- Preben Randhol

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[JLotty]

On Friday, May 25, 2018 at 11:06:41 PM UTC-6, Adam Jensen wrote:
> On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote:
> 
> > On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote:
> > 
> >> Is it common for developers to create their own run-time system for
> >> embedded platforms? My inclination would be to look for hardware based
> >> on 1) RTS availability/quality and 2) toolkit complexity/completeness
> >> (completeness implies useful documentation).
> > 
> > Not common, no. But RTS availability (esp. SPARK RTS) has to start
> > somewhere, and for the MSP430 I didn't really develop one, just adapt
> > from AVR-Ada.
> > 
> > With remarkably little feedback on that project, I admit I've put
> > remarkably little effort into pushing it further. But I want it for my
> > own purposes, the watch is just a pretty by-product.
> 
> Super cool. Are your project's documents posted/hosted anywhere for 
> others to view and use? 
> 
> >> Given that, which seems like an obvious thing to do, I am surprised
> >> that Adacore does not have more apparent associations with hardware
> >> vendors where dev-kits and SBC products are promoted. I bought the
> >> Nucleo-144 board because I thought there was a BSP, RTS, and a
> >> tool-chain configuration tutorial. That turned out to be a bit of a
> >> mistake and generally a poor choice.
> > 
> > Not Adacore ... there isn't much hobbyist money for them, given their
> > business model. They do publicise occasional hobby-level projects like
> > Lego Mindstorms and Certyflie, but I don't see them making money off it.
> 
> They have the "Make with Ada" competition: 
> <https://www.makewithada.org/>
> 
> And the Adacore University:
> <http://university.adacore.com/>
> 
> If there is not a large vibrant community of people who understand and 
> use the technology it will fade and collapse. It seems like maybe they 
> recognize this but it doesn't seem like they know what to do. (Only an 
> idiot would have advertisers involved in technical communication). C'est 
> la vie.
>  
> > Meanwhile we have to support each other, perhaps your work on Nucleo can
> > feed back into Simon's RTS and expand its supported platforms.
> 
> The Nucleo-144 board was selected as a gentle starter kit to develop some 
> confidence and familiarity with the tool-chain and the work-flow. It was 
> a total failure in this role. However, I have been keeping notes and at 
> some point I might create a tutorial for Ada/Spark development on Ubuntu 
> x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I will 
> probably move to a platform with more resources. Eventually, I need a 
> processor coupled with an FPGA - the FPGA is where most of the hard real-
> time activity (traction with physics) should take place, IMO.

You might also look into these codebases:
https://github.com/lambourg/Ada_Bare_Metal_Demos
https://travis-ci.org/AdaCore/Ada_Drivers_Library

Both are supported by AdaCore and provide runtime systems for STM32F4 boards, as well as Raspberry Pi.  The STM33F4 is a fairly inexpensive board.  I would recommend beginning development on it to build confidence and learn the embedded Ada details, then begin porting to the Nucleo-144 board specifications as described in 

"Porting the Ada runtime to a new ARM board" 
<https://blog.adacore.com/porting-the-ada-runtime-to-a-new-arm-board> 

Both of these repositories worked out of the box for me on GNAT 2017.

James

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Simon Wright]

JLotty <jlotspeich34@gmail.com> writes:

> https://github.com/lambourg/Ada_Bare_Metal_Demos
> https://travis-ci.org/AdaCore/Ada_Drivers_Library

The Bare_Metal_Demos doesn't seem to have anything for STM3F4
The Ada_Drivers_Library is actually at github.com

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[JLotty]

On Wednesday, May 30, 2018 at 3:58:34 PM UTC-6, Simon Wright wrote:
> JLotty <jlotspeich34@gmail.com> writes:
> 
> > https://github.com/lambourg/Ada_Bare_Metal_Demos
> > https://travis-ci.org/AdaCore/Ada_Drivers_Library
> 
> The Bare_Metal_Demos doesn't seem to have anything for STM3F4
> The Ada_Drivers_Library is actually at github.com

The Bare_Metal_Demos contain:
stm32f429_demos.gpr
stm32f469_demos.gpr
stm32f746_demos.gpr
stm32f769_demos.gpr

Choose the project to match your version of STM32F4 board.  All of these follow the same base configuration/functionality.

Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development

[Simon Wright]

JLotty <jlotspeich34@gmail.com> writes:

> On Wednesday, May 30, 2018 at 3:58:34 PM UTC-6, Simon Wright wrote:
>> JLotty <jlotspeich34@gmail.com> writes:
>> 
>> > https://github.com/lambourg/Ada_Bare_Metal_Demos
>> > https://travis-ci.org/AdaCore/Ada_Drivers_Library
>> 
>> The Bare_Metal_Demos doesn't seem to have anything for STM3F4
>> The Ada_Drivers_Library is actually at github.com
>
> The Bare_Metal_Demos contain:
> stm32f429_demos.gpr
> stm32f469_demos.gpr
> stm32f746_demos.gpr
> stm32f769_demos.gpr
>
> Choose the project to match your version of STM32F4 board.  All of
> these follow the same base configuration/functionality.

Yes, but AFAICR OP had what AdaCore's RTS's call an STM32F4,
i.e. STM32F407. The board was called STM32F4DISCOVERY, current order
code STM32F407G-DISC1