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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.105.137 with SMTP id k9mr8992789yhg.14.1423840241186; Fri, 13 Feb 2015 07:10:41 -0800 (PST) X-Received: by 10.140.97.5 with SMTP id l5mr124755qge.4.1423840241170; Fri, 13 Feb 2015 07:10:41 -0800 (PST) Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!j7no309440qaq.1!news-out.google.com!c1ni6qar.1!nntp.google.com!j7no309438qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 13 Feb 2015 07:10:40 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.203.194.21; posting-account=bXcJoAoAAAAWI5APBG37o4XwnD4kTuQQ NNTP-Posting-Host: 74.203.194.21 References: <6c8a59ee-d011-4d9f-999b-54cb0d7cf40a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ravenscar-sfp and interrupt priorities on Cortex-M4 From: Patrick Noffke Injection-Date: Fri, 13 Feb 2015 15:10:41 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:192264 Date: 2015-02-13T07:10:40-08:00 List-Id: On Friday, February 13, 2015 at 4:06:59 AM UTC-6, Simon Wright wrote: > Patrick Noffke writes: >=20 > > I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C > > MCU, using the STM32F4 implementation as a starting point. >=20 > Good stuff! >=20 > > 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. >=20 > 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 loo= k into that. I might need to repeat my porting efforts in the future for a= n 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 t= o 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 li= mit with the rest of the stuff in my application (1 KB just for the UDMA co= ntrol table, 512-1024 bytes for the tasks, application data, etc.). I'm no= t 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! >=20 > Max_Priority : constant Positive :=3D 7; > Max_Interrupt_Priority : constant Positive :=3D 8 + (15 - 5); >=20 > subtype Any_Priority is Integer range 0 .. Max_Interrupt_Priorit= y; > subtype Priority is Any_Priority > range Any_Priority'First .. Max_Priority; > subtype Interrupt_Priority is Any_Priority > range Priority'Last + 1 .. Any_Priority'Last; >=20 > Default_Priority : constant Priority :=3D > (Priority'First + Priority'Last) / 2; >=20 > (Note, this is adapted from ARM 2012, rather than AdaCore's) >=20 > > 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. >=20 > 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-2= 014-arm-elf-linux-bin.tar.gz) and zfp-support-gpl-2014-src.tar.gz, and I ex= tended the code in the zfp tarball to add support for the TM4C(123) MCU. I= s 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