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

[Simon Wright <simon@pushface.org>]

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!