From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!enother.net!enother.net!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Ravenscar-sfp and interrupt priorities on Cortex-M4 Date: Fri, 13 Feb 2015 18:40:36 +0000 Organization: A noiseless patient Spider Message-ID: References: <6c8a59ee-d011-4d9f-999b-54cb0d7cf40a@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="4eba6dd55c03f4a8d448cad2a88d67ef"; logging-data="27378"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195ox04+JcBZwYuS/WQVhoh2aEOerWw9r4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin) Cancel-Lock: sha1:0Dd5Lc+cGR13mRk/6qnKzTYUgGI= sha1:oOeYBW+J+6ndteYWGVOgO3Lxds4= Xref: number.nntp.giganews.com comp.lang.ada:192268 Date: 2015-02-13T18:40:36+00:00 List-Id: Patrick Noffke 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!