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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: GNAT stm34f4 zfp question. Date: Wed, 04 Mar 2015 18:28:13 +0000 Organization: A noiseless patient Spider Message-ID: References: <07330c00-0317-4bb2-8ffb-67bff98dc9eb@googlegroups.com> <05f8f7cc-a934-4a2b-aa58-4f40fc540e66@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="342d0b904178f3fa79dba1c9d29f7c6c"; logging-data="1046"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++AcvrSqj/RYBc5i7l7bHDHHWvWEDr540=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin) Cancel-Lock: sha1:3bwNGicjXfGw3HlUf7lAqcaD9IU= sha1:Qsp2AV9vBshtE5qi5EqCHJgmtZ8= Xref: news.eternal-september.org comp.lang.ada:25106 Date: 2015-03-04T18:28:13+00:00 List-Id: 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??)