GNAT stm34f4 zfp question.

GNAT stm34f4 zfp question.

[jan.de.kruyf]

Good morning all,

Can anybody think of a good reason why libgnat.a in rts-zfp has been precompiled with "-msoft-float" ?

Spend the better part of an hour on that. It showed up as a 2nd stack fault.


Thanks for all the help and encouragement.

j.

Re: GNAT stm34f4 zfp question.

[jan.de.kruyf]

On Tuesday, March 3, 2015 at 9:45:30 AM UTC+2, jan.de...@gmail.com wrote:

And I did find another anomaly:

/usr/gnat-arm/lib/gcc/arm-eabi/4.7.4/rts-zfp//adalib/libgnat.a(s-secsta.o): In function `system__secondary_stack__ss_allocate':
s-secsta.adb:(.text+0x8): undefined reference to `__gnat_get_secondary_stack'

I can alleviate the symptoms by employing a local s-secsta.adb from the auxiliary zfp tar file.


The linker complains still abut the '_start_rom' address, I am about to sort that.

Oh by the way, I did employ the ravenscar linker scripts and project xml file
That seems to work to a large extend.

Without that the linker is looking for 'crt0.o'. I know what it is, but I do not know where on earth it is to be found in the ravenscar profile.
There is a crti.o in the zfp profile.

j.
 

Re: GNAT stm34f4 zfp question.

[Patrick Noffke]

On Tuesday, March 3, 2015 at 3:20:16 AM UTC-6, jan.de...@gmail.com wrote:
> On Tuesday, March 3, 2015 at 9:45:30 AM UTC+2, jan.de...@gmail.com wrote:
> 
> And I did find another anomaly:
> 
> /usr/gnat-arm/lib/gcc/arm-eabi/4.7.4/rts-zfp//adalib/libgnat.a(s-secsta.o): In function `system__secondary_stack__ss_allocate':
> s-secsta.adb:(.text+0x8): undefined reference to `__gnat_get_secondary_stack'
> 
> I can alleviate the symptoms by employing a local s-secsta.adb from the auxiliary zfp tar file.
> 
> 
<snip>
> 
> Without that the linker is looking for 'crt0.o'. I know what it is, but I do not know where on earth it is to be found in the ravenscar profile.
> There is a crti.o in the zfp profile.
> 

I had a linking issue with the ravenscar-sfp runtime.  The linker was finding the wrong libgnat.a or libgnarl.a (not the one from the specific RTS I was using).  Once I specified the fully qualified path to those two libraries the linking problems were fixed.

Here is my final linking command in my own Makefile:

	@$(CC) --RTS=$(RTS) $(LD_FLAGS) -Wl,--gc-sections -nostdinc -nodefaultlibs -nostartfiles -T$(LINKER_SCRIPT) -L$(RTS_INSTALL_DIR) $(OBJS) $(RTS_INSTALL_DIR)/libgnat.a $(RTS_INSTALL_DIR)/libgnarl.a -lgcc -o $@

where

LD_FLAGS := -fmessage-length=0 -gnatA -mcpu=cortex-m4 -mlittle-endian -mfpu=fpv4-sp-d16 -march=armv7e-m -mfloat-abi=hard -mthumb

(This was for a Cortex-M4 MCU.)

Pat

Re: GNAT stm34f4 zfp question.

[jan.de.kruyf]

On Tuesday, March 3, 2015 at 7:15:29 PM UTC+2, Patrick Noffke wrote:

> 
> I had a linking issue with the ravenscar-sfp runtime.  The linker was finding the wrong libgnat.a or libgnarl.a (not the one from the specific RTS I was using).  Once I specified the fully qualified path to those two libraries the linking problems were fixed.
> 
> Here is my final linking command in my own Makefile:
> 
> 	@$(CC) --RTS=$(RTS) $(LD_FLAGS) -Wl,--gc-sections -nostdinc -nodefaultlibs -nostartfiles -T$(LINKER_SCRIPT) -L$(RTS_INSTALL_DIR) $(OBJS) $(RTS_INSTALL_DIR)/libgnat.a $(RTS_INSTALL_DIR)/libgnarl.a -lgcc -o $@
> 
> where
> 
> LD_FLAGS := -fmessage-length=0 -gnatA -mcpu=cortex-m4 -mlittle-endian -mfpu=fpv4-sp-d16 -march=armv7e-m -mfloat-abi=hard -mthumb
> 
> (This was for a Cortex-M4 MCU.)
> 

Thank you Patrick,
Highly appreciated. I have entertained myself for the last half hour reading the ugx manual that came with the package. There is some useful info there also.
But I doubt it will resolve all my wishes.

In any case I do coding for relaxation now. With some music its really cool. This adacore business drives me up the wall.

Cheers,
may the peace be with you.

j.

Re: GNAT stm34f4 zfp question.

[jan.de.kruyf]

On Tuesday, March 3, 2015 at 7:15:29 PM UTC+2, Patrick Noffke wrote:

> Here is my final linking command in my own Makefile:
> 
> 	@$(CC) --RTS=$(RTS) $(LD_FLAGS) -Wl,--gc-sections -nostdinc -nodefaultlibs -nostartfiles -T$(LINKER_SCRIPT) -L$(RTS_INSTALL_DIR) $(OBJS) $(RTS_INSTALL_DIR)/libgnat.a $(RTS_INSTALL_DIR)/libgnarl.a -lgcc -o $@
> 
> where
> 
> LD_FLAGS := -fmessage-length=0 -gnatA -mcpu=cortex-m4 -mlittle-endian -mfpu=fpv4-sp-d16 -march=armv7e-m -mfloat-abi=hard -mthumb
> 
> (This was for a Cortex-M4 MCU.)
> 

Just a quick update: 
I managed to make a reasonable looking runtime libgnat.a by diligently reading the gnathie_ug.pdf and the  gnat_ugx.pdf  manuals.

Especially the first one gives some rationale as to why the zfp tar file looks the way it looks.

So I added some ravenscar runtime files into the mix and build with gps.

The biggest issue is to sort out the board support files, since I now wanted to do away with threads and some other cruft in there, sine we have ravenscar if I need that.


Tomorrow we try to use it . . .

cheers,

j.

Re: GNAT stm34f4 zfp question.

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> I managed to make a reasonable looking runtime libgnat.a by diligently
> reading the gnathie_ug.pdf and the gnat_ugx.pdf manuals.

Thanks a lot for this hint! lots of work indicated. Mostly tidying, I
think; it's good to see the rationale for the switches in system.ads.

> The biggest issue is to sort out the board support files, since I now
> wanted to do away with threads and some other cruft in there, sine we
> have ravenscar if I need that.

My approach was to use the BSP and FreeRTOS code supplied by STM and map
the compiler-generated RTS calls onto that. This is not the approach
adopted by AdaCore; on the whole they implement tasking in the System.BB
family, which they access via System.OS_Interface; however there seemed
to be a lot of code in the full RTS packages such as System.Tasking
which had been left out of the ravenscar-sfp version.

I'm beginning to think that there's not much to be gained by using STM's
HAL, compared to accessing the hardware directly, except possibly for
complex board features such as the STM32F429I's on-board LCD. And even
then I'm concerned about multiplexed GPIO interrupts; as I understand
it, there is only one EXTI0 interrupt, corresponding to pin 0 on any
GPIO, so if you need more than one pin 0 interrupt you'll need to manage
all of them in one super-handler, or arrange to chain handlers (which I
don't think AdaCore's RTS supports??)

Re: GNAT stm34f4 zfp question.

[jan.de.kruyf]

On Wednesday, March 4, 2015 at 8:28:15 PM UTC+2, Simon Wright wrote:


ja, and I put unchecked conversions under ada for some reason, but the ravenscar files i used took them straight. So there was another trip through wonderland, before I got wise.

Otherwise, when I need an operating system I will certainly look at your work. But at the moment I like to try if I can follow the tiny-os recipe:
Thow little jobs on the workstack and poll in between execution. (You can also make interrupts throw jobs onto the workstack if needed) Its a brilliant concept for small stuff. But read the book first!

So I have not looked at the interrupt structure yet. First test what we got. And see that I have all the language components I like.

I dont think I saw a libm in the collection, I wonder if I must follow up on that. But perhaps we can get away with some pre-cooked code from some other library.

the STM hal is well tested and reasonably complete with DSP routines and all. So I am not discounting that, but this project is a bit hairy, so I need control. With STM cube I can only write a binding then a program then test. And they are a bit verbose here and there. I dont like to do a lot of work and then find out I have to start again. So this is an excellent way of learning the chip _and_ Ada properly.

cheers,

j.

Re: GNAT stm34f4 zfp question.

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> And even then I'm concerned about multiplexed GPIO interrupts; as I
> understand it, there is only one EXTI0 interrupt, corresponding to pin
> 0 on any GPIO, so if you need more than one pin 0 interrupt you'll
> need to manage all of them in one super-handler, or arrange to chain
> handlers (which I don't think AdaCore's RTS supports??)

Somewhat clearer about this now!

There are 16 GPIO-related interrupt lines, corresponding to the 16 bits
in a GPIO register.

Each line is associated with one GPIO (the default is GPIOA).

Each line can have interrupts enabled (and/or events???)

Lines 0..4 have their own interrupts, EXTI0_IRQ to EXTI4_IRQ.

Lines 5..9 are multiplexed to one interrupt, EXTI9_5_IRQ.

Lines 10..15 are multiplexed to one interrupt, EXTI15_10_IRQ.

So pin PC11 (GPIOC, bit 11), which is one of the unassigned pins on the
STM32F429I Disco, can be interrupt-enabled (in which case no other
GPIO's pin 11 can be interrupt-enabled) and will generate
EXTI15_10_IRQ. If interrupts are required on lines 10, 12, 13, 14, or 15
(which can each be associated with different GPIOs) then the handler for
EXTI15_10_IRQ will have to determine which is which.

At the moment I'm toying with mechanical translation of the STMCube
stm32f429xx.h (using -fdump-ada-spec and a sed script), and have the
code below, which is fairly ugly, rather like the C equivalent. I could
copy AdaCore's design (not the code, of course!) which handles multi-bit
fields much better, but I'm looking for a mechanical translation at this
stage.

with Ada.Interrupts.Names;
with Interfaces;
with System;
with stm32f429xx_h; use stm32f429xx_h;
package body Button is

   --  We're going to use a pin on the left-hand side of the board:
   --  P1/44 is PC11.

   protected B
   with
     Interrupt_Priority => System.Interrupt_Priority'First is
      entry Wait_For_Trigger;
   private
      Triggered : Boolean := False;
      procedure Handler;
      pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI15_10_IRQ);
   end B;

   procedure Wait_For_Button_Release is
   begin
      B.Wait_For_Trigger;
   end Wait_For_Button_Release;

   protected body B is
      entry Wait_For_Trigger when Triggered is
      begin
         Triggered := False;
      end Wait_For_Trigger;

      procedure Handler is
         use type Interfaces.Unsigned_32;
      begin
         if (EXTI.PR and EXTI_PR_PR11) /= 0 then
            Triggered := True;
            EXTI.PR := EXTI_PR_PR11;  -- clear the interrupt by *writing* 1
         else
            raise Program_Error with "unexpected interrupt";
         end if;
      end Handler;
   end B;

   procedure Initialize is
      use type Interfaces.Unsigned_32;
   begin
      --  First, we need to enable GPIOC's clock.
      RCC.AHB1ENR := RCC.AHB1ENR or RCC_AHB1ENR_GPIOCEN;

      --  Don't need to configure bit 11 as an input, because that's
      --  the default.

      --  Don't need to configure OTYPER, because the pin is an input.

      --  Don't need to configure OSPEEDR, because the pin is an input.

      --  Configure PUPDR for pull-up (AdaCore have no-pull?)
      declare
         Pull_Register : Interfaces.Unsigned_32;
      begin
         Pull_Register := GPIOC.PUPDR;
         Pull_Register := Pull_Register and not GPIO_PUPDR_PUPDR11;
         Pull_Register := Pull_Register or GPIO_PUPDR_PUPDR11_0;
         GPIOC.PUPDR := Pull_Register;
      end;

      --  Enable SYSCFG's clock.
      RCC.APB2ENR := RCC.APB2ENR or RCC_APB2ENR_SYSCFGEN;

      --  Then, configure SYSCFG_EXTICR3[12:15] (pin 11) for GPIOC.
      declare
         Exti_Register : Interfaces.Unsigned_32;
      begin
         Exti_Register := SYSCFG.EXTICR (2);  -- C indexing!
         Exti_Register := Exti_Register and not SYSCFG_EXTICR3_EXTI11;
         Exti_Register := Exti_Register or SYSCFG_EXTICR3_EXTI11_PC;
         SYSCFG.EXTICR (2) := Exti_Register;
      end;

      --  Then, configure EXTI on pin 11 for rising-edge (button-release)
      EXTI.RTSR := EXTI.RTSR or EXTI_RTSR_TR11;
      --  and enable interrupts on pin 11.
      EXTI.IMR := EXTI.IMR or EXTI_IMR_MR11;
   end Initialize;

begin
   Initialize;
end Button;