Ravenscar-sfp and interrupt priorities on Cortex-M4

Ravenscar-sfp and interrupt priorities on Cortex-M4

[Patrick Noffke]

Hello,

I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C MCU, using the STM32F4 implementation as a starting point.

I noticed a problem where the interrupt priorities were not correct.  I was setting an interrupt handler's priority to 251, and the runtime converted it to a PRI value, and when it got converted back to an Interrupt_Priority it came back as 252.

I determined this is because the TM4C MCU only uses the 3 most-significant bits for the PRI value, where as the runtime implementation assumes 4 bits.  The ARM Cortex-M4 user's guide does not specify the number of bits, only that the most significant bits shall be used and the unused bits are zeros when read and writes have no effect (http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/CIHIGCIF.html).

The file system-xi-cortexm4-sfp.ads defines Interrupt_Priority range from 241 to 255, and this should be 249 to 255 for the TM4C MCU.  Because the available range is processor-dependent, this file should probably be renamed to something like system-xi-stm32f4.ads and system-xi-tm4c.ads, etc., and the appropriate file selected in build-rts.sh.

I copied file s-bbbosu-stm32f4.adb to s-bbbosu-tm4c.adb and had to then change the To_PRI and To_Priority functions to multiply and divide by 32, respectively.

I am happy to share my implementation when I have confidence it is working.  Please let me know the best way to share it.  I'm fine for it to become a part of the GNAT release.

Please let me know if you agree with my above findings and suggestions.

Best regards,
Patrick

Re: Ravenscar-sfp and interrupt priorities on Cortex-M4

[Simon Wright]

Patrick Noffke <patrick.noffke@gmail.com> writes:

> I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C
> MCU, using the STM32F4 implementation as a starting point.

Good stuff!

> The file system-xi-cortexm4-sfp.ads defines Interrupt_Priority range
> from 241 to 255, and this should be 249 to 255 for the TM4C MCU.
> Because the available range is processor-dependent, this file should
> probably be renamed to something like system-xi-stm32f4.ads and
> system-xi-tm4c.ads, etc., and the appropriate file selected in
> build-rts.sh.

I'm working with FreeRTOS (for STM32F4), which supports priorities from
0 to 7 out of the box. STM's Hardware Abstraction Layer disapproves of
applications using hardware interrupt priorities 4 .. 1 (4 for
SysTick_Handler), so I've mapped hardware interrupt priorities 15 .. 5
to Ada interrupt priorities 8 .. 18. I'm working on support for
different boards!

   Max_Priority           : constant Positive := 7;
   Max_Interrupt_Priority : constant Positive := 8 + (15 - 5);

   subtype Any_Priority       is Integer range 0 .. Max_Interrupt_Priority;
   subtype Priority           is Any_Priority
     range Any_Priority'First .. Max_Priority;
   subtype Interrupt_Priority is Any_Priority
     range Priority'Last + 1 .. Any_Priority'Last;

   Default_Priority : constant Priority :=
     (Priority'First + Priority'Last) / 2;

(Note, this is adapted from ARM 2012, rather than AdaCore's)

> I copied file s-bbbosu-stm32f4.adb to s-bbbosu-tm4c.adb and had to
> then change the To_PRI and To_Priority functions to multiply and
> divide by 32, respectively.

Which base distribution are you working with? Doesn't look like the GPL
one, which doesn't have any of the files you mention.

Re: Ravenscar-sfp and interrupt priorities on Cortex-M4

[Patrick Noffke]

On Friday, February 13, 2015 at 4:06:59 AM UTC-6, Simon Wright wrote:
> Patrick Noffke writes:
> 
> > I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C
> > MCU, using the STM32F4 implementation as a starting point.
> 
> Good stuff!
> 
> > The file system-xi-cortexm4-sfp.ads defines Interrupt_Priority range
> > from 241 to 255, and this should be 249 to 255 for the TM4C MCU.
> > Because the available range is processor-dependent, this file should
> > probably be renamed to something like system-xi-stm32f4.ads and
> > system-xi-tm4c.ads, etc., and the appropriate file selected in
> > build-rts.sh.
> 
> I'm working with FreeRTOS (for STM32F4), which supports priorities from
> 0 to 7 out of the box.

I only just learned about the FreeRTOS-based runtime yesterday.  I will look into that.  I might need to repeat my porting efforts in the future for an Atmel SAM4S (or similar) MCU, and I think they offer a FreeRTOS port.

I am using the TM4C123 MCU which only has 32 KB of SRAM.  As it is, I had to reduce the interrupt handler stack size (from 1024 to either 256 or 512 -- TBD) in order to fit in the BSS section, and I'm still approaching the limit with the rest of the stuff in my application (1 KB just for the UDMA control table, 512-1024 bytes for the tasks, application data, etc.).  I'm not sure if FreeRTOS would add much overhead.  Do you have any input on that?

> STM's Hardware Abstraction Layer disapproves of
> applications using hardware interrupt priorities 4 .. 1 (4 for
> SysTick_Handler), so I've mapped hardware interrupt priorities 15 .. 5
> to Ada interrupt priorities 8 .. 18. I'm working on support for
> different boards!
> 
>    Max_Priority           : constant Positive := 7;
>    Max_Interrupt_Priority : constant Positive := 8 + (15 - 5);
> 
>    subtype Any_Priority       is Integer range 0 .. Max_Interrupt_Priority;
>    subtype Priority           is Any_Priority
>      range Any_Priority'First .. Max_Priority;
>    subtype Interrupt_Priority is Any_Priority
>      range Priority'Last + 1 .. Any_Priority'Last;
> 
>    Default_Priority : constant Priority :=
>      (Priority'First + Priority'Last) / 2;
> 
> (Note, this is adapted from ARM 2012, rather than AdaCore's)
> 
> > I copied file s-bbbosu-stm32f4.adb to s-bbbosu-tm4c.adb and had to
> > then change the To_PRI and To_Priority functions to multiply and
> > divide by 32, respectively.
> 
> Which base distribution are you working with? Doesn't look like the GPL
> one, which doesn't have any of the files you mention.

I am working with the "bare metal" Linux-hosted ARM32-elf distribution from libre.adacore.com.  I grabbed the binary toolchain and runtime (gnat-gpl-2014-arm-elf-linux-bin.tar.gz) and zfp-support-gpl-2014-src.tar.gz, and I extended the code in the zfp tarball to add support for the TM4C(123) MCU.  Is development of this implementation going to continue in the future, or do you think Free-RTOS-based runtimes will be the norm for Cortex-M4?

Best regards,
Patrick

Re: Ravenscar-sfp and interrupt priorities on Cortex-M4

[Simon Wright]

Patrick Noffke <patrick.noffke@gmail.com> writes:

> On Friday, February 13, 2015 at 4:06:59 AM UTC-6, Simon Wright wrote:

>> I'm working with FreeRTOS (for STM32F4), which supports priorities from
>> 0 to 7 out of the box.
>
> I only just learned about the FreeRTOS-based runtime yesterday.  I
> will look into that.  I might need to repeat my porting efforts in the
> future for an Atmel SAM4S (or similar) MCU, and I think they offer a
> FreeRTOS port.
>
> I am using the TM4C123 MCU which only has 32 KB of SRAM.  As it is, I
> had to reduce the interrupt handler stack size (from 1024 to either
> 256 or 512 -- TBD) in order to fit in the BSS section, and I'm still
> approaching the limit with the rest of the stuff in my application (1
> KB just for the UDMA control table, 512-1024 bytes for the tasks,
> application data, etc.).  I'm not sure if FreeRTOS would add much
> overhead.  Do you have any input on that?

I found that (for a fairly paltry task) 768 bytes was too small for the
stack, 1024 was OK. I don't know how much of that was used by FreeRTOS
calls.

This blinky application (3 tasks, 2 POs) used 18k of RAM, including 15k
of heap (the task stacks are allocated on the heap).

>> Which base distribution are you working with? Doesn't look like the GPL
>> one, which doesn't have any of the files you mention.
>
> I am working with the "bare metal" Linux-hosted ARM32-elf distribution
> from libre.adacore.com.  I grabbed the binary toolchain and runtime
> (gnat-gpl-2014-arm-elf-linux-bin.tar.gz) and
> zfp-support-gpl-2014-src.tar.gz, and I extended the code in the zfp
> tarball to add support for the TM4C(123) MCU.  Is development of this
> implementation going to continue in the future, or do you think
> Free-RTOS-based runtimes will be the norm for Cortex-M4?

I'd forgotten about zfp-support-gpl-2014-src.tar.gz.

AdaCore are basing the libre release on the bare-board runtimes they
supply for the high integrity market. I doubt very much whether they'd
want to use FreeRTOS in that context; I can see it being a selling point
that almost the whole system is in Ada.

I chose FreeRTOS for two reasons: first, to have a basis for building
proprietary systems, if people want to, and second, to avoid most of the
porting exercise. I find myself most comfortable in the space between
applications and the bare metal!