STM32F4 GNAT Run Time System - roadmap

STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Looking for some input on priorities for work.

* Standard library packages.
* Other MCUs.
* Finalization.
* ?

Standard library packages
-------------------------

An obvious omission is the rest of the Ada.Containers.Bounded* packages:
  Doubly_Linked_Lists
  Ordered_Maps
  Hashed_Sets
  Ordered_Sets
  Multiway_Trees
  Synchronized_Queues
  Priority_Queues

Any other nice-to-haves? (I haven't looked at Annex G, might be
problematic!)

Other MCUs
----------

STM have just released a significant number of affordable Nucleo
development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
Flash, 32-KB SRAM, which would just-about take my current testbed
program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
next day delivery from Farnell[0].

The problem with this is that different MCUs require different compiler
options, and building GCC for ARM with multilibs is only supported in
the ARM fork at [1]; so far there are only GCC 4.9-based releases. GCC
4.9 is a perfectly competent compiler, of course.

Finalization
------------

It would be very nice to be able to use the generalized container
iterators of Ada 2012 (generalized array iterators are already OK).

They require finalization: I've implemented finalization and generalized
iteration over Bounded_Vectors in the 'finalization' branch at [2].

Unfortunately, adding finalization to a restricted runtime triggers bugs
in GCC.

I've raised two GCC PRs; "gnatbind generates invalid code when
finalization is enabled in restricted runtime"[3], and "Front-end error
if exception propagation disabled"[4].

=====================================================================
[0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
[1] https://launchpad.net/gcc-arm-embedded
[2]
https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

Re: STM32F4 GNAT Run Time System - roadmap

[Tero Koskinen]

Hi,

9.6.2015, 15:02, Simon Wright wrote:
> Looking for some input on priorities for work.
>
> * ?

These days I try to avoid building (cross-)gnat as much as possible,
since usually it is pretty painful (read: time consuming). Also, that is
one reason why I prefer to toy with AVRs instead of Cortex-Mx ARMs.

So, STM32F4 GNAT runtime in a ready-to-run package would be nice.

Ideally, you should need only one command for installation and another
for compiling the app:
$ sudo apt-get install stm32f4-gnat
$ stm32f4-gnatmake -XBOARD=nucleof401re myproject

> * Other MCUs.

STM32F4 series (F407, F405, F4x1RE) has been ok, also Atmel's
SAM D20/D21 Cortex-M0+ MCUs seem reasonable. Some day, it would be
interesting to run Ada on NXP's multicore LPC43xx (M4 and M0+) MCUs.

On the other hand, I don't really like Freescale's Kinetis series.
I don't find the datasheets as easy to read as Atmel's or ST's
datasheets. In addition, there are not that many (decent) evaluation
boards available for Kinetis MCUs.

Yours,
  Tero

Re: STM32F4 GNAT Run Time System - roadmap

[MIchael Erdmann]

On 6/9/2015 9:44 PM, Tero Koskinen wrote:
> Hi,
> 
> 9.6.2015, 15:02, Simon Wright wrote:
>> Looking for some input on priorities for work.
>>
>> * ?
> 
> These days I try to avoid building (cross-)gnat as much as possible,
> since usually it is pretty painful (read: time consuming). Also, that is
> one reason why I prefer to toy with AVRs instead of Cortex-Mx ARMs.
> 
> So, STM32F4 GNAT runtime in a ready-to-run package would be nice.

I agree; i have an STM32F4 disco board; but frankly speaking i am using
C since i don't want to spend the time to compile the stuff.

Some libs i can port my self if i need them

Regards
   Michael

> 
> Ideally, you should need only one command for installation and another
> for compiling the app:
> $ sudo apt-get install stm32f4-gnat
> $ stm32f4-gnatmake -XBOARD=nucleof401re myproject
> 
>> * Other MCUs.
> 
> STM32F4 series (F407, F405, F4x1RE) has been ok, also Atmel's
> SAM D20/D21 Cortex-M0+ MCUs seem reasonable. Some day, it would be
> interesting to run Ada on NXP's multicore LPC43xx (M4 and M0+) MCUs.
> 
> On the other hand, I don't really like Freescale's Kinetis series.
> I don't find the datasheets as easy to read as Atmel's or ST's
> datasheets. In addition, there are not that many (decent) evaluation
> boards available for Kinetis MCUs.
> 
> Yours,
>  Tero

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

MIchael Erdmann <michael.erdmann@snafu.de> writes:

> I agree; i have an STM32F4 disco board; but frankly speaking i am
> using C since i don't want to spend the time to compile the stuff.

Do you use STM32Cube or bare-metal C + the datasheets? (or somewhere
between?)

Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf]

On Tuesday, June 9, 2015 at 2:02:25 PM UTC+2, Simon Wright wrote:
> Looking for some input on priorities for work.
> 
> * Standard library packages.
> * Other MCUs.
> * Finalization.
> * ?
> 
> Standard library packages
> -------------------------
> 
> An obvious omission is the rest of the Ada.Containers.Bounded* packages:
>   Doubly_Linked_Lists
>   Ordered_Maps
>   Hashed_Sets
>   Ordered_Sets
>   Multiway_Trees
>   Synchronized_Queues
>   Priority_Queues
> 
> Any other nice-to-haves? (I haven't looked at Annex G, might be
> problematic!)
> 
> Other MCUs
> ----------
> 
> STM have just released a significant number of affordable Nucleo
> development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
> Flash, 32-KB SRAM, which would just-about take my current testbed
> program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
> next day delivery from Farnell[0].
> 
> The problem with this is that different MCUs require different compiler
> options, and building GCC for ARM with multilibs is only supported in
> the ARM fork at [1]; so far there are only GCC 4.9-based releases. GCC
> 4.9 is a perfectly competent compiler, of course.
> 
> Finalization
> ------------
> 
> It would be very nice to be able to use the generalized container
> iterators of Ada 2012 (generalized array iterators are already OK).
> 
> They require finalization: I've implemented finalization and generalized
> iteration over Bounded_Vectors in the 'finalization' branch at [2].
> 
> Unfortunately, adding finalization to a restricted runtime triggers bugs
> in GCC.
> 
> I've raised two GCC PRs; "gnatbind generates invalid code when
> finalization is enabled in restricted runtime"[3], and "Front-end error
> if exception propagation disabled"[4].
> 
> =====================================================================
> [0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
> [1] https://launchpad.net/gcc-arm-embedded
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

Simon,
Thanks for all your hard work :)
on the matter of bug 66205:
-------
        if not Suppress_Standard_Library_On_Target then
            WBI ("   Is_Elaborated : Boolean := False;");
         end if;
-------
This ties with the behaviour I get on 4.7.4 
When Standard_Library is not suppressed it wants to load some Handler and initialize a handful of variables. So for mixed language mode with minimal runtime and a foreign linker I have to suppress the standard library, so 'adainit' purely does the elaboration of the stuff I wrote (be it program or runtime) 
As I said: with it, adainit does a few things more.

At the moment I am in the middle of a hairy issue in s-memory (getting an address overlay to work, so I ask for a few pages from the kernel and use it as a system byte array) But as soon as I have a working compile again, without errors, some time tomorrow, I will post the relevant code pieces with and without 'Suppress_Standard_Library_On_Target'. I think your binder gives out too much code from what I see.

the other bug ties in with my observations about exceptions on 4.7.4. Perhaps in a slightly different way. But I am not following your test case too well, its evening. 

As far as the road ahead:
The things you mentioned are certainly all 'nice to haves' but at the same time I personally have not missed them yet. Since it is easy enough to roll your own if and when the need arises. In a big project I would say that the priorities are quite different. There you look for lots of reusable software. But then I might be mistaken.

I would certainly vote for more cpu's that are usable 'off the shelf' with either a ravenscar profile or a zfp. But.
This has to go together with some kind of a publicity effort, otherwise it is just a nice hobby but it serves no real purpose. 

Maybe we need to ask David about his opinion.

Besides I like to mention that the big issue with micro controllers is a good, solid, workable hardware definition. You have chosen to go the 'cube' library route, which is viable of course. and it has the added advantage of having the hidden fix-ups packaged already. (And there are some, I discovered to my horror).
Personally I like to work on the bare metal though. However, I miss sorely some good hardware definition files. For the 407 I made them up as I went, but it is only a first try. The method needs to be discussed and perhaps improved upon. We have all this beautiful type machinery in Ada, so why not use it. 
Again, we need forum discussion and afterwards publicity! Otherwise it is all rather useless.

 I suppose I have talked enough again for tonight ,

cheers,

j.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> on the matter of bug 66205:
> -------
>         if not Suppress_Standard_Library_On_Target then
>             WBI ("   Is_Elaborated : Boolean := False;");
>          end if;
> -------
> This ties with the behaviour I get on 4.7.4 
> When Standard_Library is not suppressed it wants to load some Handler
> and initialize a handful of variables. So for mixed language mode with
> minimal runtime and a foreign linker I have to suppress the standard
> library, so 'adainit' purely does the elaboration of the stuff I wrote
> (be it program or runtime) As I said: with it, adainit does a few
> things more.

These bugs were about including finalization in the RTS.

I guess there's some work to be done on exiting a kernel module; whether
that's something that relates to Ada.Finalization is a different matter!

And I'm not clear what Suppress_Standard_Library_On_Target means .. oh,
it's about standard exception data. I had to include it in my RTS
because some packages needed it, but it's only needed if the user code
calls the features involved (e.g. streams, containers).

I think the writeup in [1] is slightly misleading:

 Suppress_Standard_Library : Boolean;

 --  If this flag is True, then the standard library is not included by
 --  default in the executable (see unit System.Standard_Library in file
 --  s-stalib.ads for details of what this includes). This is for example
 --  set True for the Zero Footprint case, where these files should not
 --  be included by default.
 --
 --  This flag has some other related effects:
 --
 --    The generation of global variables in the bind file is suppressed,
 --    with the exception of the priority of the environment task, which
 --    is needed by the Ravenscar run-time.
 --
 --    The generation of exception tables is suppressed for front end
 --    ZCX exception handling (since we assume no exception handling).
 --
 --    The calls to __gnat_initialize and __gnat_finalize are omitted
 --
 --    All finalization and initialization (controlled types) is omitted
 --
 --    The routine __gnat_handler_installed is not imported

At least the part about "All finalization and initialization (controlled
types) is omitted" iw wrong; it just doesn't work!

[1] http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_gnat_configurable_run_time_facility.html

Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf]

On Wednesday, June 10, 2015 at 7:47:21 PM UTC+2, Simon Wright wrote:

> 
> These bugs were about including finalization in the RTS.

Yes, but there is a vague area there-abouts. It seems to affect a couple of things.

> 
> I guess there's some work to be done on exiting a kernel module; whether
> that's something that relates to Ada.Finalization is a different matter!
> 
Yes you need to diligently clean up after yourself, otherwise you get a kernel memory leak. But I rather did that by getting a personally managed pool of a fixed size that I can give up when I leave (that reminds me I must still program that) Its not always as easy of course.



> And I'm not clear what Suppress_Standard_Library_On_Target means 

All I found so far is what I posted before, but it might have other effects.
I suppose grepping the compiler source might bring some light.

> I had to include it in my RTS
> because some packages needed it,

I am not completely sure what you are up to, but it is a feat to have part with an rts and part without. I do everything without and use an include directory. But I believe I saw that one can compile with or without RTS (or with diffent RTS's I should rather say) for different packages.

But the binding the scheme seems to be regulated by the 'Suppress_Standard_Library' variable in System. So how that is going to work out in a by-morph I hate to think.


> 
> At least the part about "All finalization and initialization (controlled
> types) is omitted" iw wrong; it just doesn't work!

So are you trying to use that? or are you trying to drop that?
and: with or without stdlib?

Cheers,

j.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> On Wednesday, June 10, 2015 at 7:47:21 PM UTC+2, Simon Wright wrote:

>> At least the part about "All finalization and initialization (controlled
>> types) is omitted" iw wrong; it just doesn't work!
>
> So are you trying to use that? or are you trying to drop that?
> and: with or without stdlib?

I don't understand the question. And I don't understand what you mean by
stdlib.

I wrote up my approach at
http://forward-in-code.blogspot.co.uk/2015/06/building-runtime-system-for-arm-eabi.html

Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf]

On Tuesday, June 9, 2015 at 2:02:25 PM UTC+2, Simon Wright wrote:
> Looking for some input on priorities for work.
> 
> * Standard library packages.
> * Other MCUs.
> * Finalization.
> * ?
> 
> Standard library packages
> -------------------------
> 
> An obvious omission is the rest of the Ada.Containers.Bounded* packages:
>   Doubly_Linked_Lists
>   Ordered_Maps
>   Hashed_Sets
>   Ordered_Sets
>   Multiway_Trees
>   Synchronized_Queues
>   Priority_Queues
> 
> Any other nice-to-haves? (I haven't looked at Annex G, might be
> problematic!)
> 
> Other MCUs
> ----------
> 
> STM have just released a significant number of affordable Nucleo
> development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
> Flash, 32-KB SRAM, which would just-about take my current testbed
> program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
> next day delivery from Farnell[0].
> 
> The problem with this is that different MCUs require different compiler
> options, and building GCC for ARM with multilibs is only supported in
> the ARM fork at [1]; so far there are only GCC 4.9-based releases. GCC
> 4.9 is a perfectly competent compiler, of course.
> 
> Finalization
> ------------
> 
> It would be very nice to be able to use the generalized container
> iterators of Ada 2012 (generalized array iterators are already OK).
> 
> They require finalization: I've implemented finalization and generalized
> iteration over Bounded_Vectors in the 'finalization' branch at [2].
> 
> Unfortunately, adding finalization to a restricted runtime triggers bugs
> in GCC.
> 
> I've raised two GCC PRs; "gnatbind generates invalid code when
> finalization is enabled in restricted runtime"[3], and "Front-end error
> if exception propagation disabled"[4].
> 
> =====================================================================
> [0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
> [1] https://launchpad.net/gcc-arm-embedded
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

Good Morning Simon,
Here is a b-xxx.adb with 'Suppress_Standard_Library_On'
-----------------------

pragma Ada_95;
pragma Source_File_Name (ada_main, Spec_File_Name => "b~demo.ads");
pragma Source_File_Name (ada_main, Body_File_Name => "b~demo.adb");

package body ada_main is
   pragma Warnings (Off);

   E03 : Short_Integer; pragma Import (Ada, E03, "last_chance_handler_E");
   E05 : Short_Integer; pragma Import (Ada, E05, "linux_kernel_E");
   E19 : Short_Integer; pragma Import (Ada, E19, "niniel_E");
   E26 : Short_Integer; pragma Import (Ada, E26, "niniel__ioctl_E");
   E30 : Short_Integer; pragma Import (Ada, E30, "secondary_stack_E");


   procedure adainit is
   begin
      null;

      E05 := E05 + 1;
      E03 := E03 + 1;
      if E19 = 0 then
         Niniel'Elab_Body;
      end if;
      E19 := E19 + 1;
      if E26 = 0 then
         Niniel.Ioctl'Elab_Body;
      end if;
      E26 := E26 + 1;
      E30 := E30 + 1;
   end adainit;

end ada_main;

-------------------------------------

All the quoted strings are my own stuff. Since I cannot use any standard library in kernel programming.
 j.

Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf]

On Tuesday, June 9, 2015 at 2:02:25 PM UTC+2, Simon Wright wrote:
> Looking for some input on priorities for work.
> 
> * Standard library packages.
> * Other MCUs.
> * Finalization.
> * ?
> 
> Standard library packages
> -------------------------
> 
> An obvious omission is the rest of the Ada.Containers.Bounded* packages:
>   Doubly_Linked_Lists
>   Ordered_Maps
>   Hashed_Sets
>   Ordered_Sets
>   Multiway_Trees
>   Synchronized_Queues
>   Priority_Queues
> 
> Any other nice-to-haves? (I haven't looked at Annex G, might be
> problematic!)
> 
> Other MCUs
> ----------
> 
> STM have just released a significant number of affordable Nucleo
> development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
> Flash, 32-KB SRAM, which would just-about take my current testbed
> program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
> next day delivery from Farnell[0].
> 
> The problem with this is that different MCUs require different compiler
> options, and building GCC for ARM with multilibs is only supported in
> the ARM fork at [1]; so far there are only GCC 4.9-based releases. GCC
> 4.9 is a perfectly competent compiler, of course.
> 
> Finalization
> ------------
> 
> It would be very nice to be able to use the generalized container
> iterators of Ada 2012 (generalized array iterators are already OK).
> 
> They require finalization: I've implemented finalization and generalized
> iteration over Bounded_Vectors in the 'finalization' branch at [2].
> 
> Unfortunately, adding finalization to a restricted runtime triggers bugs
> in GCC.
> 
> I've raised two GCC PRs; "gnatbind generates invalid code when
> finalization is enabled in restricted runtime"[3], and "Front-end error
> if exception propagation disabled"[4].
> 
> =====================================================================
> [0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
> [1] https://launchpad.net/gcc-arm-embedded
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

And here is a b-demo.adb for use with a standard library

--------------------

pragma Ada_95;
pragma Source_File_Name (ada_main, Spec_File_Name => "b~demo.ads");
pragma Source_File_Name (ada_main, Body_File_Name => "b~demo.adb");

package body ada_main is
   pragma Warnings (Off);

   E04 : Short_Integer; pragma Import (Ada, E04, "last_chance_handler_E");
   E06 : Short_Integer; pragma Import (Ada, E06, "linux_kernel_E");
   E20 : Short_Integer; pragma Import (Ada, E20, "niniel_E");
   E27 : Short_Integer; pragma Import (Ada, E27, "niniel__ioctl_E");
   E31 : Short_Integer; pragma Import (Ada, E31, "secondary_stack_E");

   Local_Priority_Specific_Dispatching : constant String := "";
   Local_Interrupt_States : constant String := "";

   Is_Elaborated : Boolean := False;

   type No_Param_Proc is access procedure;

   procedure adainit is
      Main_Priority : Integer;
      pragma Import (C, Main_Priority, "__gl_main_priority");
      Time_Slice_Value : Integer;
      pragma Import (C, Time_Slice_Value, "__gl_time_slice_val");
      WC_Encoding : Character;
      pragma Import (C, WC_Encoding, "__gl_wc_encoding");
      Locking_Policy : Character;
      pragma Import (C, Locking_Policy, "__gl_locking_policy");
      Queuing_Policy : Character;
      pragma Import (C, Queuing_Policy, "__gl_queuing_policy");
      Task_Dispatching_Policy : Character;
      pragma Import (C, Task_Dispatching_Policy, "__gl_task_dispatching_policy");
      Priority_Specific_Dispatching : System.Address;
      pragma Import (C, Priority_Specific_Dispatching, "__gl_priority_specific_dispatching");
      Num_Specific_Dispatching : Integer;
      pragma Import (C, Num_Specific_Dispatching, "__gl_num_specific_dispatching");
      Main_CPU : Integer;
      pragma Import (C, Main_CPU, "__gl_main_cpu");
      Interrupt_States : System.Address;
      pragma Import (C, Interrupt_States, "__gl_interrupt_states");
      Num_Interrupt_States : Integer;
      pragma Import (C, Num_Interrupt_States, "__gl_num_interrupt_states");
      Unreserve_All_Interrupts : Integer;
      pragma Import (C, Unreserve_All_Interrupts, "__gl_unreserve_all_interrupts");
      Exception_Tracebacks : Integer;
      pragma Import (C, Exception_Tracebacks, "__gl_exception_tracebacks");
      Detect_Blocking : Integer;
      pragma Import (C, Detect_Blocking, "__gl_detect_blocking");
      Default_Stack_Size : Integer;
      pragma Import (C, Default_Stack_Size, "__gl_default_stack_size");
      Leap_Seconds_Support : Integer;
      pragma Import (C, Leap_Seconds_Support, "__gl_leap_seconds_support");

      procedure Install_Handler;
      pragma Import (C, Install_Handler, "__gnat_install_handler");

      Handler_Installed : Integer;
      pragma Import (C, Handler_Installed, "__gnat_handler_installed");

      Finalize_Library_Objects : No_Param_Proc;
      pragma Import (C, Finalize_Library_Objects, "__gnat_finalize_library_objects");
   begin
      if Is_Elaborated then
         return;
      end if;
      Is_Elaborated := True;
      Main_Priority := -1;
      Time_Slice_Value := -1;
      WC_Encoding := 'b';
      Locking_Policy := ' ';
      Queuing_Policy := ' ';
      Task_Dispatching_Policy := ' ';
      Priority_Specific_Dispatching :=
        Local_Priority_Specific_Dispatching'Address;
      Num_Specific_Dispatching := 0;
      Main_CPU := -1;
      Interrupt_States := Local_Interrupt_States'Address;
      Num_Interrupt_States := 0;
      Unreserve_All_Interrupts := 0;
      Exception_Tracebacks := 1;
      Detect_Blocking := 0;
      Default_Stack_Size := -1;
      Leap_Seconds_Support := 0;

      if Handler_Installed = 0 then
         Install_Handler;
      end if;

      E06 := E06 + 1;
      E04 := E04 + 1;
      if E20 = 0 then
         Niniel'Elab_Body;
      end if;
      E20 := E20 + 1;
      if E27 = 0 then
         Niniel.Ioctl'Elab_Body;
      end if;
      E27 := E27 + 1;
      E31 := E31 + 1;
   end adainit;

end ada_main;

-------------------------------------

now al of a sudden there is a mass of symbols imported from somewhere.
I am sure some diligent use of grep and/or nm will find them back in some library.

These files are generated by binding with gnat (gcc 4.7.4) by the way, on a 64 bit linux system.

j.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> now al of a sudden there is a mass of symbols imported from somewhere.
> I am sure some diligent use of grep and/or nm will find them back in
> some library.

But what you really need is to suppress the standard library!

Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf]

On Wednesday, June 10, 2015 at 7:55:18 PM UTC+2, Simon Wright wrote:


Simon,

> But what you really need is to suppress the standard library!

but that is then in the linking phase. Let me just look what I do here. . . 

You are right the standard link command includes " -lgnat -static-libgcc" on native, and I leave that out in my custom link command.

If it helps you, this is what I do:

for compiling:
gnatmake -f -u -c -b -a -Pkernel.gpr

for binding:
gnatmake -b -Pkernel.gpr

then a dummy linking phase to get the b~demo.ada set compiled. But the real linking fails here because it cannot find libgcc and libgnat. Its not in the search path (because -nostdlib). It is handy though if you have it verbal, to get a list of object files to link in the stage below.
Command:
gnatmake -l -nostdlib -Pkernel.gpr
And note that -nostdlib does not switch off the -lgnat etc. That is another falleximble.

then I partially link with:
'ld -r -m elf_x86_64 . . . . . . . . -o demo.x

And the demo.x is then used in the module-building link. (part is in C)
But that is outside my direct control it is done in the module-building machinery of the kernel environment.

In the project file:
binder switches ("-E", "-n")
linker switches ("-r", "-v")

I am sure there is a whole lot of cruft in my way of doing things, partly that is historical of course, you mess about until something works and you forget  afterward.

So one sunny saturday afternoon I might be seduced to make a minimal building process, but for the time being this works. I semi automated it with a shell script.

I can post the project file, but there is no earth shattering science in there. Just a handful of compiler switches that I copied from a C kernel module compile. (where applicable)
And the RTS I set to the working directory in which there is no lib so also no lib gets linked, but the runtime is taken from the include directory in the main directory, just standard project file fare.

Hope this enlightens the subject a bit.

cheers,
j.

Re: STM32F4 GNAT Run Time System - roadmap

[Brian Drummond]

On Tue, 09 Jun 2015 13:02:22 +0100, Simon Wright wrote:

> Looking for some input on priorities for work.

> Other MCUs ----------
> 
> STM have just released a significant number of affordable Nucleo
> development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
> Flash, 32-KB SRAM, which would just-about take my current testbed
> program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
> next day delivery from Farnell[0].

I confess I haven't been following this as closely as I'd like, but there 
are many possibilities for "other MCUs".

Anything that can be done to make adding an MCU easier is worthwhile. In 
the MSP430 case I had a parser for the C header files so that all MSP430s 
were available (to the extent the parser worked) but that won't work 
across multiple manufacturers.

So establishing a framework into which someone can plug in the details of 
a new MCU, or which guides or helps him in doing so, would be important.

Specific MCUs it would be good to target: 
TI have several families, some with low cost Launchpad boards, including 
the Stellaris. They have announced  anew "MSP432" line aiming squarely at 
their own ultra-low-power MSP430 market but with a Cortex core.

And notably they have the Hercules series, again with cheap Launchpads, 
aimed at high reliability for industrial and automotive markets - with 
dual CPUs operating in lockstep to detect errors. 

http://www.ti.com/ww/en/launchpad/launchpads-hercules.html
http://uk.farnell.com/texas-instruments/launchxl-rm42/dev-board-rm42-
hercules-launchpad/dp/2341348

What better platform for running Ada?

-- Brian

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Anything that can be done to make adding an MCU easier is
> worthwhile. In the MSP430 case I had a parser for the C header files
> so that all MSP430s were available (to the extent the parser worked)
> but that won't work across multiple manufacturers.
>
> So establishing a framework into which someone can plug in the details
> of a new MCU, or which guides or helps him in doing so, would be
> important.
>
> Specific MCUs it would be good to target:
> TI have several families, some with low cost Launchpad boards,
> including the Stellaris. They have announced anew "MSP432" line aiming
> squarely at their own ultra-low-power MSP430 market but with a Cortex
> core.
>
> And notably they have the Hercules series, again with cheap
> Launchpads, aimed at high reliability for industrial and automotive
> markets - with dual CPUs operating in lockstep to detect errors.
>
> http://www.ti.com/ww/en/launchpad/launchpads-hercules.html
> http://uk.farnell.com/texas-instruments/launchxl-rm42/dev-board-rm42-
> hercules-launchpad/dp/2341348
>
> What better platform for running Ada?

Well, I see your point; but my approach was to try for an Ada RTS,
rather than a BSP. I think you're asking for a BSP written in Ada (or at
any rate easily usable from Ada.

The reason for choosing FreeRTOS as a basis was that it decouples the
Ada RTS from the BSP; so provided _someone_ has ported FreeRTOS to the
board (and, at least judging by STM, its C BSP) we are at a good
position to get Ada up and running.

I don't know what would be involved in "a framework into which someone
can plug in the details of a new MCU". Sounds like a major exercise.

Re: STM32F4 GNAT Run Time System - roadmap

[Brian Drummond]

On Wed, 10 Jun 2015 22:19:29 +0100, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> Anything that can be done to make adding an MCU easier is worthwhile.
...
> Well, I see your point; but my approach was to try for an Ada RTS,
> rather than a BSP. I think you're asking for a BSP written in Ada (or at
> any rate easily usable from Ada.

I see both as necessary in an MCU : unless you expect the RTS (or FreeRTOS 
underneath) to provide drivers for every peripheral out there - not just 
basic I2C, CANBUS etc but ADCs and everything under the sun that can be 
integrated onto the same silicon. (Of course the RTS must have exclusive 
access to a subset of these : one timer, one UART for example)

So yes, I was hinting at a BSP. For the RTS itself, your approach does 
have the merit that someone else has probably already done the work, 
albeit in C!

> I don't know what would be involved in "a framework into which someone
> can plug in the details of a new MCU". Sounds like a major exercise.

That's the problem...

-- Brian

Re: STM32F4 GNAT Run Time System - roadmap

[Jedi Tek'Unum]

On Wednesday, June 10, 2015 at 4:19:30 PM UTC-5, Simon Wright wrote:
> Well, I see your point; but my approach was to try for an Ada RTS,
> rather than a BSP. I think you're asking for a BSP written in Ada (or at
> any rate easily usable from Ada.
> 
> The reason for choosing FreeRTOS as a basis was that it decouples the
> Ada RTS from the BSP; so provided _someone_ has ported FreeRTOS to the
> board (and, at least judging by STM, its C BSP) we are at a good
> position to get Ada up and running.
> 
> I don't know what would be involved in "a framework into which someone
> can plug in the details of a new MCU". Sounds like a major exercise.

My 2 cents as a hobbyist uncommitted to Ada...

Supporting a wide variety of chips/boards directly via Ada is not going to happen. It appears that keeping up with a single vendor/series is unproven.

I have no interest in vendor BSPs because I work with multiple vendors.

FreeRTOS seems like the lowest level portable base. Yet it is very limited. I'd rather be writing applications than redeveloping "systems software".

While I have no experience using RTEMS, I understand that it supports Ada. From a distance it seems to be commercially oriented (although free open source) and evolves slowly.

I've been dipping my toes in NuttX which seems to have an active community and is BSD licensed. At the moment this would be my top choice.

My observation is that low-end ARM capabilities are growing rapidly and prices falling. We aren't far from a sub-$20 board that runs FreeBSD/Linux. (I'm doing that on a $19 Pogoplug V4 system - board/case/power - although it is considered obsolete!) I pause to wonder if NuttX or RTEMS is worth the bother.

I'm not suggesting that "Unix" is the best OS we could ever create BUT it is the train that almost everyone is on. (Dare I say the same kind of momentum that keeps C/C++ at the top.)

Re: STM32F4 GNAT Run Time System - roadmap

[Dmitry A. Kazakov]

On Sat, 13 Jun 2015 06:21:42 -0700 (PDT), Jedi Tek'Unum wrote:

> My observation is that low-end ARM capabilities are growing rapidly and
> prices falling. We aren't far from a sub-$20 board that runs
> FreeBSD/Linux. (I'm doing that on a $19 Pogoplug V4 system -
> board/case/power - although it is considered obsolete!) I pause to wonder
> if NuttX or RTEMS is worth the bother.
> 
> I'm not suggesting that "Unix" is the best OS we could ever create BUT it
> is the train that almost everyone is on. (Dare I say the same kind of
> momentum that keeps C/C++ at the top.)

I fully agree. Only large firms shipping huge series may afford developing
for some obscure BSP and rudimentary RTOS. In our case we do embedded on
Debian for BB. If you have to deliver 100+ installation to pay 50 more
euros per board is still far more cheaper than maintaining a developing
branch for one more target.

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

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

"Jedi Tek'Unum" <jeditekunum@gmail.com> writes:

> FreeRTOS seems like the lowest level portable base. Yet it is very
> limited. I'd rather be writing applications than redeveloping "systems
> software".

Do you mean very limited in the sense of "doesn't support any hardware"
(GPIO etc) or "is missing RTOS features"?

If the latter, what?

Re: STM32F4 GNAT Run Time System - roadmap

[Jedi Tek'Unum]

On Saturday, June 13, 2015 at 9:55:32 AM UTC-5, Simon Wright wrote:
> "Jedi Tek'Unum" writes:
> 
> > FreeRTOS seems like the lowest level portable base. Yet it is very
> > limited. I'd rather be writing applications than redeveloping "systems
> > software".
> 
> Do you mean very limited in the sense of "doesn't support any hardware"
> (GPIO etc) or "is missing RTOS features"?
> 
> If the latter, what?

The former.

Example: https://store.particle.io/?product=particle-photon $19 (US) with Wi-Fi! Just started shipping.

I suspect NuttX will be fully supporting it in a matter of months.

I don't want to spend my time developing/porting Wi-Fi drivers for example.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Anything that can be done to make adding an MCU easier is
> worthwhile. In the MSP430 case I had a parser for the C header files
> so that all MSP430s were available (to the extent the parser worked)
> but that won't work across multiple manufacturers.
>
> So establishing a framework into which someone can plug in the details
> of a new MCU, or which guides or helps him in doing so, would be
> important.

ARM's CMSIS[1] contains (in the CMSIS-SVD tab) the definition

   "The System View Description (SVD) files provide peripheral
   information and other device parameters in formalized XML based
   format.

   "The SVD file typically matches the information provided by silicon
   vendors in device reference manuals."

AdaCore, as recently noted here, have made some tools available on
Github[2]; one of these is svd2ada.

There are a lot of SVDs archived at [3]. They appear to have come from
the ARM site[1] (but there are more vendors at [3] than at [1]).

svd2ada will process these files (well, I tried the Arduino Due,
ATSAM3X8E, and AdaCore used STM32F4*); I've not done any evaluation yet
aside from noting that they generate the GNAT-specific
Volatile_Full_Access aspect, which is noted in the 'under development'
version of the GCC docs (so, will likely be in GCC 6). Maybe plain
Volatile will do (but users would have to remember to access the whole
register explicitly, rather than leaving it up to the compiler to Do The
Right Thing); that would be an easy-enough patch.

[1]
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
[2] https://github.com/AdaCore
[3] https://github.com/posborne/cmsis-svd

Re: STM32F4 GNAT Run Time System - roadmap

[Brian Drummond]

On Sun, 06 Dec 2015 18:34:41 +0000, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> Anything that can be done to make adding an MCU easier is worthwhile.
>> In the MSP430 case I had a parser for the C header files so that all
>> MSP430s were available (to the extent the parser worked) but that won't
>> work across multiple manufacturers.
>>
>> So establishing a framework into which someone can plug in the details
>> of a new MCU, or which guides or helps him in doing so, would be
>> important.
> 
> ARM's CMSIS[1] contains (in the CMSIS-SVD tab) the definition
> 
>    "The System View Description (SVD) files provide peripheral
>    information and other device parameters in formalized XML based
>    format.
> 
>    "The SVD file typically matches the information provided by silicon
>    vendors in device reference manuals."
> 
> AdaCore, as recently noted here, have made some tools available on
> Github[2]; one of these is svd2ada.

This looks excellent! 

Though I can't see SVDs for any of the Texas Instruments devices there 
yet.

Thanks,
-- Brian

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

>> ARM's CMSIS[1] contains (in the CMSIS-SVD tab) the definition
>> 
>>    "The System View Description (SVD) files provide peripheral
>>    information and other device parameters in formalized XML based
>>    format.
>> 
>>    "The SVD file typically matches the information provided by silicon
>>    vendors in device reference manuals."
>> 
>> AdaCore, as recently noted here, have made some tools available on
>> Github[2]; one of these is svd2ada.
>
> This looks excellent! 
>
> Though I can't see SVDs for any of the Texas Instruments devices there 
> yet.

The embsysregview project at Sourceforge has a jar file for download
(the last on the embsysregview / 0.2.5 page) which contains
msp430g2553.xml (not in the same format as an SVD, though).

I got to this via the Keil pages.

I've been working on patches to the svd2ada project to support Atmel's
ATSAM3X8E (as in the Arduino Due). Almost there!
https://github.com/simonjwright/svd2ada, branch sjw

Re: STM32F4 GNAT Run Time System - roadmap

[Brian Drummond]

On Thu, 28 Jan 2016 20:52:37 +0000, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:

>>> AdaCore, as recently noted here, have made some tools available on
>>> Github[2]; one of these is svd2ada.
>>
>> This looks excellent!
>>
>> Though I can't see SVDs for any of the Texas Instruments devices there
>> yet.
> 
> The embsysregview project at Sourceforge has a jar file for download
> (the last on the embsysregview / 0.2.5 page) which contains
> msp430g2553.xml (not in the same format as an SVD, though).

I was not aware of that, thanks! Though I don't know how I could apply it 
to the rest of the MSP430 family (500-odd distinct MCUs)

I was actually referring to TI's ARM-Cortex devices - they have at least 
four different families of ARM processors:
	Tiva (formerly Stellaris) at the low end
	Sitara (high end GHz devices, as in the Beaglebone boards)
	MSP432 (ultra low power, for the MSP430 market)
	Hercules (RM42/57000 sub- families for industrial and automotive)

The last of these families is especially interesting - dual CPUs in 
lockstep (but 2 cycles apart) with a trap mechanism if the 2 CPUs do 
anything different from each other. Aimed at high integrity applications, 
they would be a logical target for Ada.

-- Brian

Re: STM32F4 GNAT Run Time System - roadmap

[Jere]

I'm a little late to the party here, but I definitely would like to see support for more chips over the BSP.  Mind you I am biased, but I can usually wade through the data sheet and make a BSP from that.  Not that I wouldn't like a premade BSP, but given the option, I would prefer more chips to choose from.  I am currently looking at an M0+ chip, which as far as I can tell, has no GNAT cross compiler's available (nor runtimes).  It does have a GCC port for 4.9.3 I think, but not GNAT.  Speaking from the perspective of developing on a Windows machine.

At some point I guess I will have to dig in and figure out how to build GNAT for the m0+ using windows, then I'll have to figure out the runtime, but I am light years from understanding that stuff at the moment.

On Sunday, December 6, 2015 at 1:34:43 PM UTC-5, Simon Wright wrote:
> ARM's CMSIS[1] contains (in the CMSIS-SVD tab) the definition
> 
>    "The System View Description (SVD) files provide peripheral
>    information and other device parameters in formalized XML based
>    format.
> 
>    "The SVD file typically matches the information provided by silicon
>    vendors in device reference manuals."
> 
> AdaCore, as recently noted here, have made some tools available on
> Github[2]; one of these is svd2ada.
> 
> There are a lot of SVDs archived at [3]. They appear to have come from
> the ARM site[1] (but there are more vendors at [3] than at [1]).
> 
> svd2ada will process these files (well, I tried the Arduino Due,
> ATSAM3X8E, and AdaCore used STM32F4*); I've not done any evaluation yet
> aside from noting that they generate the GNAT-specific
> Volatile_Full_Access aspect, which is noted in the 'under development'
> version of the GCC docs (so, will likely be in GCC 6). Maybe plain
> Volatile will do (but users would have to remember to access the whole
> register explicitly, rather than leaving it up to the compiler to Do The
> Right Thing); that would be an easy-enough patch.
> 
> [1]
> http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
> [2] https://github.com/AdaCore
> [3] https://github.com/posborne/cmsis-svd
I am fairly new to the ARM arena, so this may be a stupid question but what exactly does svd2Ada generate based off of the SVD files?  From the description and what I saw in the git repo it sounds like it makes something like a BSP?

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Jere <jere.groups@gmail.com> writes:

> I am fairly new to the ARM arena, so this may be a stupid question but
> what exactly does svd2Ada generate based off of the SVD files?  From
> the description and what I saw in the git repo it sounds like it makes
> something like a BSP?

The SVD corresponds to the chip reference manual, and gives
register/field descriptions for the manufacturer-specific devices (so
not for e.g.NVIC). So the atsam3x8e SVD outputs

atsam3x8e-adc.ads
atsam3x8e-can.ads
atsam3x8e-chipid.ads
atsam3x8e-dacc.ads
atsam3x8e-dmac.ads
atsam3x8e-ebi.ads
atsam3x8e-efc.ads
atsam3x8e-emac.ads
atsam3x8e-hsmci.ads
atsam3x8e-interrupts.ads
atsam3x8e-matrix.ads
atsam3x8e-pio.ads
atsam3x8e-pmc.ads
atsam3x8e-pwm.ads
atsam3x8e-spi.ads
atsam3x8e-ssc.ads
atsam3x8e-sysc.ads
atsam3x8e-tc.ads
atsam3x8e-trng.ads
atsam3x8e-twi.ads
atsam3x8e-uart.ads
atsam3x8e-uotghs.ads
atsam3x8e-usart.ads
atsam3x8e.ads

where atsam3x8e.ads defines types for bitfields and, for example,

   PIOA_Base: constant := 16#400E0E00#;

for device register base addresses; and the others define specific
register definitions for devices.

Not all the generated files compile without error;

   compilation of atsam3x8e-adc.ads failed
   compilation of atsam3x8e-chipid.ads failed
   compilation of atsam3x8e-uotghs.ads failed

and, for the first,

atsam3x8e-adc.ads:525:07: reserved word "in" cannot be used as identifier
atsam3x8e-adc.ads:526:07: reserved word "out" cannot be used as identifier
atsam3x8e-adc.ads:531:15: expecting expression or component association
atsam3x8e-adc.ads:532:07: declaration expected

(the first two are the actual problem). So, work to be done.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Jere <jere.groups@gmail.com> writes:

> I am currently looking at an M0+ chip, which as far as I can tell, has
> no GNAT cross compiler's available (nor runtimes).  It does have a GCC
> port for 4.9.3 I think, but not GNAT.  Speaking from the perspective
> of developing on a Windows machine.
>
> At some point I guess I will have to dig in and figure out how to
> build GNAT for the m0+ using windows, then I'll have to figure out the
> runtime, but I am light years from understanding that stuff at the
> moment.

I think it'd be simple enough to make an M0+ compiler (once one's found
the proper incantation); the problem I had was getting one compiler to
generate M3 or M4F code as required. I think the ARM branch at
https://launchpad.net/gcc-arm-embedded can do it, but the changes
haven't been rolled in to the GCC trunk; and there are apparently
problems building Ada with that source tree; and they are up to 4.9.3
only.

Of course the work I've done has been on Mac OS X; perhaps look at
TDM-GCC, starting at http://getadanow.com/#get_windows

If your chip has FreeRTOS you might be able to work from my
http://sourceforge.net/projects/cortex-gnat-rts/ - there are 12 or so
board-specific sources, though I think that at least two of the files
could be moved to common.

Re: STM32F4 GNAT Run Time System - roadmap

[Jere]

On Monday, December 7, 2015 at 11:49:11 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > I am currently looking at an M0+ chip, which as far as I can tell, has
> > no GNAT cross compiler's available (nor runtimes).  It does have a GCC
> > port for 4.9.3 I think, but not GNAT.  Speaking from the perspective
> > of developing on a Windows machine.
> >
> > At some point I guess I will have to dig in and figure out how to
> > build GNAT for the m0+ using windows, then I'll have to figure out the
> > runtime, but I am light years from understanding that stuff at the
> > moment.
> 
> I think it'd be simple enough to make an M0+ compiler (once one's found
> the proper incantation); the problem I had was getting one compiler to
> generate M3 or M4F code as required. I think the ARM branch at
> https://launchpad.net/gcc-arm-embedded can do it, but the changes
> haven't been rolled in to the GCC trunk; and there are apparently
> problems building Ada with that source tree; and they are up to 4.9.3
> only.
That the one I have been looking at in my off time.  The vendor for my chip actually provides a version of that build for their IDE.  I've been going through various webpages with references to building a GNAT cross compiler.  I'll get that down eventually I hope.

> Of course the work I've done has been on Mac OS X; perhaps look at
> TDM-GCC, starting at http://getadanow.com/#get_windows
I'm definitely able to get Ada for Windows (Both GNAT GPL and FSF) for windows development.  I guess I meant that so far all the references to building a cross compiler have been from the Linux context.  Translating to a windows environment is sometimes challenging.  Again though, I'll get there.  Just have to take my time and figure things out.  The other issue is all the tutorials seem to target M3 and M4, so I need to translate those to M0+ as well.

> If your chip has FreeRTOS you might be able to work from my
> http://sourceforge.net/projects/cortex-gnat-rts/ - there are 12 or so
> board-specific sources, though I think that at least two of the files
> could be moved to common.
This is something I should ask about:  I am running pure bare metal.  We won't have SD cards or hard drives.  Everything we do will need to run straight on the micro's Flash itself.  We may or may not have EEPROMs, but even if we do, we are talking 512K bits (64k bytes) of standard EEPROM (so too slow for general use ... 1-5ms write times).  I am pretty sure there is a FreeRTOS port for my chip (I'll need to verify, but I am pretty sure).  Is there a configuration where I am able to use the FreeRTOS runtime you made in that context?  Does the runtime have all it needs to operate on a baremetal board or do I need to have FreeRTOS installed and running similar to windows or Linux with an SD card to hold the application executable?  In my ideal world, I would simply write an Ada program, compile it, and write it straight to the micro's Flash.  I am unsure if the runtime you proposed works in that manner or not.  The ravenscar profile based runtime provided by AdaCore appears to (I have not had to install an OS to use that cross compiler).

That said, I am mostly familiar with straight up bare metal, so a zero foot print runtime (if I understand what that entails) would be fine as well and maybe preferable due to our timing constraints. I don't really need tasking.  In the past I've not had it...well that is not entirely true depending on how you define it.  I remember yall joking about Duff's device in another thread, but I've used an implementation of that for some cooperative threading in C (see Adam Dunkels protothreads).  Not the prettiest thing, but in lei of no actual tasking primitives, it made some of the programming easier.  Either way, that was a one off thing.  I usually just program without anything resembling tasking.

If any of this sounds brash or curt or dismissive, I apologize.  I in no way mean it to sound so.  I am writing quickly as I have to run to a meeting.  I am really excited about this stuff.  

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Jere <jere.groups@gmail.com> writes:

> This is something I should ask about: I am running pure bare metal.
> We won't have SD cards or hard drives.  Everything we do will need to
> run straight on the micro's Flash itself.  We may or may not have
> EEPROMs, but even if we do, we are talking 512K bits (64k bytes) of
> standard EEPROM (so too slow for general use ... 1-5ms write times).
> I am pretty sure there is a FreeRTOS port for my chip (I'll need to
> verify, but I am pretty sure).  Is there a configuration where I am
> able to use the FreeRTOS runtime you made in that context?  Does the
> runtime have all it needs to operate on a baremetal board or do I need
> to have FreeRTOS installed and running similar to windows or Linux
> with an SD card to hold the application executable?  In my ideal
> world, I would simply write an Ada program, compile it, and write it
> straight to the micro's Flash.  I am unsure if the runtime you
> proposed works in that manner or not.  The ravenscar profile based
> runtime provided by AdaCore appears to (I have not had to install an
> OS to use that cross compiler).
>
> That said, I am mostly familiar with straight up bare metal, so a zero
> foot print runtime (if I understand what that entails) would be fine
> as well and maybe preferable due to our timing constraints. I don't
> really need tasking.

My RTS definitely works in the bare-metal environment. However, I'd have
thought your board is on the small side? a fairly small demo used

   $ arm-eabi-size stairwell_arduino_demo
      text	   data	    bss	    dec	    hex	filename
    130716	   1992	  17152	 149860	  24964	stairwell_arduino_demo

If you're happy with zero footprint, check out
http://www.inspirel.com/articles/Ada_On_Cortex.html

Re: STM32F4 GNAT Run Time System - roadmap

[Jere]

On Monday, December 7, 2015 at 5:02:38 PM UTC-5, Simon Wright wrote:
> My RTS definitely works in the bare-metal environment. However, I'd have
> thought your board is on the small side? a fairly small demo used
> 
>    $ arm-eabi-size stairwell_arduino_demo
>       text	   data	    bss	    dec	    hex	filename
>     130716	   1992	  17152	 149860	  24964	stairwell_arduino_demo
> 
> If you're happy with zero footprint, check out
> http://www.inspirel.com/articles/Ada_On_Cortex.html

Yeah, I am running a 256k flash chip, so it looks a bit too tight.  I normally
 work in the 32k to 64k arena (but on chips that there is no chance on Ada due
 to lack of even GCC for their architecture).  Moving to this new chip (SAML21
 series from Atmel) gave me the option to possibly look at an Ada solution:
  There is a working GCC port for it and I have 4x the code space that I am
 used to.

Would a zero foot print run time be out of the question as well? Most of my
 projects tend to be 12k lines of code or less on average.  I realize I will
 have to shrink from that to allow room for all the runtime checks added by
 Ada, but I am hoping with a zero foot print run time, that I won't be getting
 a lot of other space being taken up.

Re: STM32F4 GNAT Run Time System - roadmap

[Tero Koskinen]

8.12.2015, 16:03, Jere wrote:
> Yeah, I am running a 256k flash chip, so it looks a bit too tight.  I
> normally work in the 32k to 64k arena (but on chips that there is no
> chance on Ada due to lack of even GCC for their architecture).
> Moving to this new chip (SAML21 series from Atmel) gave me the option
> to possibly look at an Ada solution: There is a working GCC port for
> it and I have 4x the code space that I am used to.

I have GNAT cross-compiler for Atmel SAM D10/D20/D21 (ARM Cortex-M0+) on
my todo list.

I have quite many SAM Dxx boards[1,2,3,4,5] and peripheral drivers
(SERCOM, EIC, RTC, WDT) for them (written in C). I just need to find
time to create actual Ada cross-compiler, simple RTS, and generator for
register mappings. (And then port the drivers from C to Ada.)

Adding support also for L21 should be easy, assuming that I
find interesting development board for that or have time to
create one by myself.

Yours,
  Tero


[1] https://www.flickr.com/photos/terokoskinen/22903880554
[2] https://www.flickr.com/photos/terokoskinen/22734740787
[3] https://www.flickr.com/photos/terokoskinen/21014063201
[4] https://www.flickr.com/photos/terokoskinen/19329683873
[5] https://www.flickr.com/photos/terokoskinen/17190102006

Re: STM32F4 GNAT Run Time System - roadmap

[Jere]

On Tuesday, December 8, 2015 at 10:08:01 AM UTC-5, Tero Koskinen wrote:
> I have GNAT cross-compiler for Atmel SAM D10/D20/D21 (ARM Cortex-M0+) on
> my todo list.
> 
> I have quite many SAM Dxx boards[1,2,3,4,5] and peripheral drivers
> (SERCOM, EIC, RTC, WDT) for them (written in C). I just need to find
> time to create actual Ada cross-compiler, simple RTS, and generator for
> register mappings. (And then port the drivers from C to Ada.)
> 
> Adding support also for L21 should be easy, assuming that I
> find interesting development board for that or have time to
> create one by myself.

Awesome.  You'll definitely get there long before me, but that sounds great.  There is a development board for the L21 series, but it runs a bit more than $50.  It has a button, LED, and USB interface that allows for UART, SPI, and I2C.  Aside from that it just has headers to give access to all the pins.

http://www.digikey.com/product-detail/en/ATSAML21-XPRO/ATSAML21-XPRO-ND/5056089

Re: STM32F4 GNAT Run Time System - roadmap

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lya8pnh1dq.fsf@pushface.org...
> ...I've not done any evaluation yet
> aside from noting that they generate the GNAT-specific
> Volatile_Full_Access aspect, which is noted in the 'under development'
> version of the GCC docs (so, will likely be in GCC 6). Maybe plain
> Volatile will do (but users would have to remember to access the whole
> register explicitly, rather than leaving it up to the compiler to Do The
> Right Thing); that would be an easy-enough patch.

The ARG has decided on a different direction to fix the problem addressed by 
Volatile_Full_Access; essentially, accesses to non-volatile components of 
atomic objects have to be accessed with a read-modify-write cycle. (See 
AI12-0128-1.) Various parts of Annex C will be rewritten to make that make 
sense.

I think someone here originally proposed that (or at least something like 
it); it took us quite a while to come around to that view, mainly because of 
compatibility concerns. But there is also the concern of doing something 
unexpected.

Anyway, I don't expect that there is much use of that GNAT-specific aspect 
once the changes are approved (probably will happen next year at our next 
meeting).

                                                     Randy.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Clubley]

On 2015-12-08, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lya8pnh1dq.fsf@pushface.org...
>> ...I've not done any evaluation yet
>> aside from noting that they generate the GNAT-specific
>> Volatile_Full_Access aspect, which is noted in the 'under development'
>> version of the GCC docs (so, will likely be in GCC 6). Maybe plain
>> Volatile will do (but users would have to remember to access the whole
>> register explicitly, rather than leaving it up to the compiler to Do The
>> Right Thing); that would be an easy-enough patch.
>
> The ARG has decided on a different direction to fix the problem addressed by 
> Volatile_Full_Access; essentially, accesses to non-volatile components of 
> atomic objects have to be accessed with a read-modify-write cycle. (See 
> AI12-0128-1.) Various parts of Annex C will be rewritten to make that make 
> sense.
>

Hmm, one of the two I submitted last year. :-) Nice to see it moving forward.

What's the general feeling within the ARG about the related AI12-0127-1
partial aggregate notation proposal, especially as it applies to updating
bitfields within device registers ? How likely is that to happen ?

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: STM32F4 GNAT Run Time System - roadmap

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:n49suh$en8$1@dont-email.me...
> On 2015-12-08, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lya8pnh1dq.fsf@pushface.org...
>>> ...I've not done any evaluation yet
>>> aside from noting that they generate the GNAT-specific
>>> Volatile_Full_Access aspect, which is noted in the 'under development'
>>> version of the GCC docs (so, will likely be in GCC 6). Maybe plain
>>> Volatile will do (but users would have to remember to access the whole
>>> register explicitly, rather than leaving it up to the compiler to Do The
>>> Right Thing); that would be an easy-enough patch.
>>
>> The ARG has decided on a different direction to fix the problem addressed 
>> by
>> Volatile_Full_Access; essentially, accesses to non-volatile components of
>> atomic objects have to be accessed with a read-modify-write cycle. (See
>> AI12-0128-1.) Various parts of Annex C will be rewritten to make that 
>> make
>> sense.
>>
>
> Hmm, one of the two I submitted last year. :-) Nice to see it moving 
> forward.
>
> What's the general feeling within the ARG about the related AI12-0127-1
> partial aggregate notation proposal, especially as it applies to updating
> bitfields within device registers ? How likely is that to happen ?

The holdup is that the proposal only covers record aggregates. The similar 
SPARK feature includes all kinds of aggregates, and of course we'd like to 
be able to replace the SPARK feature entirely. The problem being that there 
isn't an obvious extension for array aggregates (it's much messier once 
multi-dimensional arrays are considered), so it's back in the lab at the 
moment. I think there is a good chance that it will be adopted down the 
road, but it's definitely not a slam-dunk.

                                         Randy.

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Clubley]

On 2015-12-09, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:n49suh$en8$1@dont-email.me...
>>
>> What's the general feeling within the ARG about the related AI12-0127-1
>> partial aggregate notation proposal, especially as it applies to updating
>> bitfields within device registers ? How likely is that to happen ?
>
> The holdup is that the proposal only covers record aggregates. The similar 
> SPARK feature includes all kinds of aggregates, and of course we'd like to 
> be able to replace the SPARK feature entirely. The problem being that there 
> isn't an obvious extension for array aggregates (it's much messier once 
> multi-dimensional arrays are considered), so it's back in the lab at the 
> moment. I think there is a good chance that it will be adopted down the 
> road, but it's definitely not a slam-dunk.
>

Thanks Randy.

It would be a shame if it was rejected because of SPARK. Even when
restricted to records it still brings benefits to Ada code, especially
when doing things like device register bitfield manipulation.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

AI12-0128 (was: STM32F4 GNAT Run Time System - roadmap)

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lya8pnh1dq.fsf@pushface.org...
>> ...I've not done any evaluation yet aside from noting that they
>> generate the GNAT-specific Volatile_Full_Access aspect, which is
>> noted in the 'under development' version of the GCC docs (so, will
>> likely be in GCC 6). Maybe plain Volatile will do (but users would
>> have to remember to access the whole register explicitly, rather than
>> leaving it up to the compiler to Do The Right Thing); that would be
>> an easy-enough patch.
>
> The ARG has decided on a different direction to fix the problem
> addressed by Volatile_Full_Access; essentially, accesses to
> non-volatile components of atomic objects have to be accessed with a
> read-modify-write cycle. (See AI12-0128-1.) Various parts of Annex C
> will be rewritten to make that make sense.

I see that !example, 4 lines from the end, says
   if Status_Register.Read then -- Illegal.
- should be .Ready

Reading this (several times), I think the effect is that if I mark a
composite object as Exact_Size_Only, and want to change a component, I
must explicitly read-object-to-temp; modify-temp; write-temp-to-object ?

At the moment I've said e.g.

   type Device_Registers is record
      S0 : Interfaces.Unsigned_16;
      S1 : Interfaces.Unsigned_16;
      L0 : Interfaces.Unsigned_32;
      L1 : Interfaces.Unsigned_32;
   end record
   with Volatile;

and let the components inherit the Volatile.

With the new aspect, I think I'd need to say e.g.

   type Device_Registers is record
      S0 : Interfaces.Unsigned_16 with Exact_Size_Only;
      S1 : Interfaces.Unsigned_16 with Exact_Size_Only;
      L0 : Interfaces.Unsigned_32 with Exact_Size_Only;
      L1 : Interfaces.Unsigned_32 with Exact_Size_Only;
   end record
   with Volatile;

?

Re: AI12-0128 (was: STM32F4 GNAT Run Time System - roadmap)

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyfuz92fqk.fsf_-_@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lya8pnh1dq.fsf@pushface.org...
>>> ...I've not done any evaluation yet aside from noting that they
>>> generate the GNAT-specific Volatile_Full_Access aspect, which is
>>> noted in the 'under development' version of the GCC docs (so, will
>>> likely be in GCC 6). Maybe plain Volatile will do (but users would
>>> have to remember to access the whole register explicitly, rather than
>>> leaving it up to the compiler to Do The Right Thing); that would be
>>> an easy-enough patch.
>>
>> The ARG has decided on a different direction to fix the problem
>> addressed by Volatile_Full_Access; essentially, accesses to
>> non-volatile components of atomic objects have to be accessed with a
>> read-modify-write cycle. (See AI12-0128-1.) Various parts of Annex C
>> will be rewritten to make that make sense.
>
> I see that !example, 4 lines from the end, says
>   if Status_Register.Read then -- Illegal.
> - should be .Ready

You're reading an obsolete version of the AI. We're still working on the new 
version. But thanks for pointing out the example, 'cause it wasn't updated 
at all in the new version.

There's no extra aspect at all in the newest recommendation, rather 
compilers are supposed to do the right thing. (That requires making 
exceptions to C.6(20) and C.6(22) in the case of nonatomic components of an 
atomic object, plus some added Legality Rules).

                       Randy. 

Re: STM32F4 GNAT Run Time System - roadmap

[Patrick Noffke]

On Tuesday, June 9, 2015 at 7:02:25 AM UTC-5, Simon Wright wrote:
> Looking for some input on priorities for work.
> 
> * Other MCUs.

If you are interested, I could share my support packages for the following MCUs:

Atmel SAM4S
TI Tiva (TM4C123)

The latter uses TI's driverlib whose license appears at first glance to be GPL-"friendly".  For Atmel, I wrote everything from scratch, and I'm willing to assign copyright to the FSF.

Contact me off-group if you want to pursue it.

Regards,
Patrick

Re: STM32F4 GNAT Run Time System - roadmap

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> It would be very nice to be able to use the generalized container
> iterators of Ada 2012 (generalized array iterators are already OK).
>
> They require finalization: I've implemented finalization and generalized
> iteration over Bounded_Vectors in the 'finalization' branch at [2].
>
> Unfortunately, adding finalization to a restricted runtime triggers bugs
> in GCC.
>
> I've raised two GCC PRs; "gnatbind generates invalid code when
> finalization is enabled in restricted runtime"[3], and "Front-end error
> if exception propagation disabled"[4].
>
> =====================================================================
> [0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
> [1] https://launchpad.net/gcc-arm-embedded
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

The patch for [4] was reasonably-well received, but AdaCore want to take
it rather further than I did. Only just posted the patch for [3].

So I don't think I'll be able to support generalized container iterators
for a while yet :-)