* How to configure GNAT GPL on x86-64 Linux for ARM ELF development @ 2018-05-23 6:37 Adam Jensen 2018-05-23 8:07 ` Simon Wright 0 siblings, 1 reply; 15+ messages in thread From: Adam Jensen @ 2018-05-23 6:37 UTC (permalink / raw) Prologue: I would like to tinker with Ada and Spark embedded real-time software development. I have these two books: https://www.amazon.com/Concurrent-Real-Time-Programming-Alan-Burns/dp/ 0521866979/ https://www.amazon.com/Analysable-Real-Time-Systems-Programmed-Ada/dp/ 1530265509/ And these two books are on the way: https://www.amazon.com/Building-Parallel-Embedded-Real-Time-Applications/ dp/0521197163/ https://www.amazon.com/Building-High-Integrity-Applications-SPARK/dp/ 1107656842/ To start, I have a Nucleo-144 board with an STM32F429ZIT6 MCU. https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO- F429ZI/497-16280-ND/5806777 I have installed Adacore's Gnat GPL and SPARK Discovery on Ubuntu 18.04 LTS in: $HOME/.local/gnat And I've installed gnat-gpl-2017-arm-elf-linux-bin.tar.gz in: $HOME/.local/gnat-arm I am following this tutorial: http://www.inspirel.com/articles/Ada_On_Cortex.html ------------------------------------------------------------------------- The first example in that tutorial is: #program.ads package Program is procedure Run; pragma Export (C, Run, "run"); end Program; # program.adb package body Program is procedure Run is begin loop null; end loop; end Run; end Program; # flash.ld OUTPUT_FORMAT("elf32-littlearm") OUTPUT_ARCH(arm) SECTIONS { .vectors 0x08000000 : { LONG(0x20010000) LONG(run + 1) FILL(0) } .text 0x08000200 : { *(.text) } } ------------------------------------------------------------------------- Given: PATH="$HOME/.local/gnat-arm/bin:$PATH"; export PATH The tutorial suggests that maybe this (below) might produce a binary suitable to be loaded onto the MCU: arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb arm-eabi-ld -T flash.ld -o program.elf program.o arm-eabi-objcopy -O binary program.elf program.bin This is what actually happens: $ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb fatal error, run-time library not installed correctly cannot locate file system.ads compilation abandoned I guess that the LD_LIBRARY_PATH and GPR_PROJECT_PATH environment variables should be set but I don't yet understand enough to make reasonable guesses. Any advice on how to proceed would be very much appreciated! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-23 6:37 How to configure GNAT GPL on x86-64 Linux for ARM ELF development Adam Jensen @ 2018-05-23 8:07 ` Simon Wright 2018-05-24 7:35 ` Adam Jensen 2018-05-25 3:29 ` Adam Jensen 0 siblings, 2 replies; 15+ messages in thread From: Simon Wright @ 2018-05-23 8:07 UTC (permalink / raw) Adam Jensen <hanzer@riseup.net> writes: > $ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb > fatal error, run-time library not installed correctly > cannot locate file system.ads > compilation abandoned > Any advice on how to proceed would be very much appreciated! I think that the reason why the tutorial works and your attempt doesn't is that the tutorial was developed on a Raspberry Pi, which is already an ARM-based machine, so the native compiler actually has a runtime (i.e. system.ads etc etc) visible to it. Yours doesn't, and gcc-for-ada must see an RTS. I managed to get a compilation using this over-the-top incantation: $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4 but a simpler (more memorable!) procedure might be to construct your own: 1. Create directories adainclude/, adalib/ 2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your adainclude/ ($prefix is the root of your compiler installation, I think ~/.local/gnat-arm) The zfp- (zero footprint) runtime is the closest to what you need, and the fact that the -stm32f4 part isn't quite right shouldn't matter; I suspect that system.ads is the same for all the zfp runtimes. Now, $ arm-eabi-gcc --RTS=. -c program.adb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-23 8:07 ` Simon Wright @ 2018-05-24 7:35 ` Adam Jensen 2018-05-24 12:12 ` Brian Drummond 2018-05-25 3:29 ` Adam Jensen 1 sibling, 1 reply; 15+ messages in thread From: Adam Jensen @ 2018-05-24 7:35 UTC (permalink / raw) On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote: > Adam Jensen <hanzer@riseup.net> writes: > >> $ arm-eabi-gcc -c -mcpu=cortex-m4 -mthumb program.adb fatal error, >> run-time library not installed correctly cannot locate file system.ads >> compilation abandoned > >> Any advice on how to proceed would be very much appreciated! > > I think that the reason why the tutorial works and your attempt doesn't > is that the tutorial was developed on a Raspberry Pi, which is already > an ARM-based machine, so the native compiler actually has a runtime > (i.e. system.ads etc etc) visible to it. > > Yours doesn't, and gcc-for-ada must see an RTS. > > I managed to get a compilation using this over-the-top incantation: > > $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4 > Many thanks, this works! I do not yet know why it works - what it is doing - but the hint is a valuable. It occurred to me that I should be looking for Adacore documentation. I have yet to find a "getting started" tutorial for embedded development aimed at scientists, engineers and other technically mature people (ideally, such a tutorial would be comprehensive, to the point, and regularly tested), but I did find: GPRbuild and GPR Companion Tools User’s Guide <https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html> and GNAT User’s Guide Supplement for Cross Platforms <http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx.html> By mining these two documents it might be possible to extract a basic explanation for these very first steps of the embedded development process. It is curious that the Ada technology's utilization of the system engineering approach has not [yet] been extended into the pedagogical component. After all, software development is a very human-centric process. But I digress. Thanks again for the guidance! After extracting the basics of project management from the core documentation, I hope to find a build process that enables the use of a Ravenscar profile. And after that I hope to configure the development environment to include Spark process components in the real-time embedded system. Does this seem reasonable? > but a simpler (more memorable!) procedure might be to construct your > own: > > 1. Create directories adainclude/, adalib/ > > 2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your > adainclude/ ($prefix is the root of your compiler installation, I > think ~/.local/gnat-arm) > > The zfp- (zero footprint) runtime is the closest to what you need, and > the fact that the -stm32f4 part isn't quite right shouldn't matter; I > suspect that system.ads is the same for all the zfp runtimes. > > Now, > > $ arm-eabi-gcc --RTS=. -c program.adb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-24 7:35 ` Adam Jensen @ 2018-05-24 12:12 ` Brian Drummond 2018-05-25 4:45 ` Adam Jensen 0 siblings, 1 reply; 15+ messages in thread From: Brian Drummond @ 2018-05-24 12:12 UTC (permalink / raw) On Thu, 24 May 2018 07:35:46 +0000, Adam Jensen wrote: > On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote: > >> Adam Jensen <hanzer@riseup.net> writes: >> >>> Any advice on how to proceed would be very much appreciated! >> >> I managed to get a compilation using this over-the-top incantation: >> >> $ gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4 >> >> > Many thanks, this works! I do not yet know why it works - what it is > doing - but the hint is a valuable. It occurred to me that I should be > looking for Adacore documentation. I have yet to find a "getting > started" The error you saw "Cannot find system.ads" and Simon's answer arise because, targeting small embedded CPUs, you are looking below the full Ada environment (supplied by the runtime system (RTS) on the host machine, to targets which may require unique runtimes supplying the facilities you need and nothing more (thanks to potential space limitations). As such I would suggest a ZFP RTS as a good short-term study,for several reasons: it can be a pretty small codebase, but revealing in terms of how things are done and how to adapt them. there are a plethora of targets out there, un- or semi-supported by Ada, from the AVR and MSP430 to ARM cores from ST, NXP, TI and others. Starting with the STM4 as you are is good, but you may want to port to other platforms for cost, power, security or other reasons ... the TI Hercules which runs dual ARM cores in lockstep for safety, has obvious attractions as an Ada target, for example. Nice price too ... https://store.ti.com/LAUNCHXL-TMS57004.aspx And porting to these builds on understanding the RTS, starting with the simplest - ZFP - as in Simon's suggestion - or AVR-Ada or my MSP430-Ada adaptation. I finally got round to machining the case and bezel, so I am wearing a wristwatch running Ada, telling the time 1970's style, in under 1 kilobyte including RTS. (the current version still has 200 bytes of C startup code which the linker insists on inserting by default; one TODO is to persuade the linker to let me replace that with pure Ada and strip out the unnecessary stuff) You suggest going in 2 more interesting directions: building up to a Ravenscar profile : I believe Simon's work so far builds on FreeRTOS, but a "native" Ravenscar RTOS would be nice too... SPARK qualification would be excellent ... again, especially for the Hercules. And again, a SPARK proven ZFP RTS would be a good base to build on, and a relatively simple place to start. -- Brian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-24 12:12 ` Brian Drummond @ 2018-05-25 4:45 ` Adam Jensen 2018-05-25 10:50 ` Brian Drummond 0 siblings, 1 reply; 15+ messages in thread From: Adam Jensen @ 2018-05-25 4:45 UTC (permalink / raw) On Thu, 24 May 2018 12:12:26 +0000, Brian Drummond wrote: > The error you saw "Cannot find system.ads" and Simon's answer arise > because, targeting small embedded CPUs, you are looking below the full > Ada environment (supplied by the runtime system (RTS) on the host > machine, to targets which may require unique runtimes supplying the > facilities you need and nothing more (thanks to potential space > limitations). > > As such I would suggest a ZFP RTS as a good short-term study,for several > reasons: > > it can be a pretty small codebase, but revealing in terms of how things > are done and how to adapt them. > > there are a plethora of targets out there, un- or semi-supported by Ada, > from the AVR and MSP430 to ARM cores from ST, NXP, TI and others. > Starting with the STM4 as you are is good, but you may want to port to > other platforms for cost, power, security or other reasons ... the TI > Hercules which runs dual ARM cores in lockstep for safety, has obvious > attractions as an Ada target, for example. > > Nice price too ... https://store.ti.com/LAUNCHXL-TMS57004.aspx > Adacore's Gnat GPL seems to include a full Ravenscar RTS for Xilinx's zynq7000 ARM/FPGA SoC: <https://www.xilinx.com/products/boards-and-kits/device-family/nav- zynq-7000.html> One of those development kits might be my next target platform, but successfully configuring tools from two different vendors for hardware/ software co-design - simulation, emulation, and cross-compilation - on a third-party OS (Ubuntu or RHEL) seems like a long way off. Right now, configuring a Ravenscar/Spark development environment that can produce a binary for the Nucleo-144 board that will flash an LED is the [surprisingly challenging] goal :) > And porting to these builds on understanding the RTS, starting with the > simplest - ZFP - as in Simon's suggestion - or AVR-Ada or my MSP430-Ada > adaptation. I finally got round to machining the case and bezel, so I am > wearing a wristwatch running Ada, telling the time 1970's style, in > under 1 kilobyte including RTS. > > (the current version still has 200 bytes of C startup code which the > linker insists on inserting by default; one TODO is to persuade the > linker to let me replace that with pure Ada and strip out the > unnecessary stuff) > That seems [to me] like a curiously superfluous application of the technology but rock on, dude. > > You suggest going in 2 more interesting directions: > > building up to a Ravenscar profile : I believe Simon's work so far > builds on FreeRTOS, but a "native" Ravenscar RTOS would be nice too... > > SPARK qualification would be excellent ... again, especially for the > Hercules. And again, a SPARK proven ZFP RTS would be a good base to > build on, and a relatively simple place to start. Is it common for developers to create their own run-time system for embedded platforms? My inclination would be to look for hardware based on 1) RTS availability/quality and 2) toolkit complexity/completeness (completeness implies useful documentation). Given that, which seems like an obvious thing to do, I am surprised that Adacore does not have more apparent associations with hardware vendors where dev-kits and SBC products are promoted. I bought the Nucleo-144 board because I thought there was a BSP, RTS, and a tool-chain configuration tutorial. That turned out to be a bit of a mistake and generally a poor choice. If Adacore, or some other enterprising entrepreneur, offered well-developed BSP, RTS, tool-chain configuration and programming tutorials for several MCU dev-kits and SBC (single board computer) products, that would make the choice easy and actually enable people to get started with the technology in a reasonable way. It seems so bizarre to me that this isn't a front-page item for Adacore. I guess there are hidden obstacles in their business model and the way the incentives are arranged in their social organization. I suppose it could have something to do with European culture. In France, does pedagogy have the demeanor of a wood- chipper (e.g., is it based in punishment, toil, and obscurity)? <smirk> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-25 4:45 ` Adam Jensen @ 2018-05-25 10:50 ` Brian Drummond 2018-05-26 5:06 ` Adam Jensen 0 siblings, 1 reply; 15+ messages in thread From: Brian Drummond @ 2018-05-25 10:50 UTC (permalink / raw) On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote: > On Thu, 24 May 2018 12:12:26 +0000, Brian Drummond wrote: > >> The error you saw "Cannot find system.ads" and Simon's answer arise >> >> SPARK qualification would be excellent ... again, especially for the >> Hercules. And again, a SPARK proven ZFP RTS would be a good base to >> build on, and a relatively simple place to start. > > Is it common for developers to create their own run-time system for > embedded platforms? My inclination would be to look for hardware based > on 1) RTS availability/quality and 2) toolkit complexity/completeness > (completeness implies useful documentation). Not common, no. But RTS availability (esp. SPARK RTS) has to start somewhere, and for the MSP430 I didn't really develop one, just adapt from AVR-Ada. With remarkably little feedback on that project, I admit I've put remarkably little effort into pushing it further. But I want it for my own purposes, the watch is just a pretty by-product. > Given that, which seems > like an obvious thing to do, I am surprised that Adacore does not have > more apparent associations with hardware vendors where dev-kits and SBC > products are promoted. I bought the Nucleo-144 board because I thought > there was a BSP, RTS, and a tool-chain configuration tutorial. That > turned out to be a bit of a mistake and generally a poor choice. Not Adacore ... there isn't much hobbyist money for them, given their business model. They do publicise occasional hobby-level projects like Lego Mindstorms and Certyflie, but I don't see them making money off it. Meanwhile we have to support each other, perhaps your work on Nucleo can feed back into Simon's RTS and expand its supported platforms. -- Brian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-25 10:50 ` Brian Drummond @ 2018-05-26 5:06 ` Adam Jensen 2018-05-26 23:58 ` Brian Drummond 2018-05-30 19:52 ` JLotty 0 siblings, 2 replies; 15+ messages in thread From: Adam Jensen @ 2018-05-26 5:06 UTC (permalink / raw) On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote: > On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote: > >> Is it common for developers to create their own run-time system for >> embedded platforms? My inclination would be to look for hardware based >> on 1) RTS availability/quality and 2) toolkit complexity/completeness >> (completeness implies useful documentation). > > Not common, no. But RTS availability (esp. SPARK RTS) has to start > somewhere, and for the MSP430 I didn't really develop one, just adapt > from AVR-Ada. > > With remarkably little feedback on that project, I admit I've put > remarkably little effort into pushing it further. But I want it for my > own purposes, the watch is just a pretty by-product. Super cool. Are your project's documents posted/hosted anywhere for others to view and use? >> Given that, which seems like an obvious thing to do, I am surprised >> that Adacore does not have more apparent associations with hardware >> vendors where dev-kits and SBC products are promoted. I bought the >> Nucleo-144 board because I thought there was a BSP, RTS, and a >> tool-chain configuration tutorial. That turned out to be a bit of a >> mistake and generally a poor choice. > > Not Adacore ... there isn't much hobbyist money for them, given their > business model. They do publicise occasional hobby-level projects like > Lego Mindstorms and Certyflie, but I don't see them making money off it. They have the "Make with Ada" competition: <https://www.makewithada.org/> And the Adacore University: <http://university.adacore.com/> If there is not a large vibrant community of people who understand and use the technology it will fade and collapse. It seems like maybe they recognize this but it doesn't seem like they know what to do. (Only an idiot would have advertisers involved in technical communication). C'est la vie. > Meanwhile we have to support each other, perhaps your work on Nucleo can > feed back into Simon's RTS and expand its supported platforms. The Nucleo-144 board was selected as a gentle starter kit to develop some confidence and familiarity with the tool-chain and the work-flow. It was a total failure in this role. However, I have been keeping notes and at some point I might create a tutorial for Ada/Spark development on Ubuntu x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I will probably move to a platform with more resources. Eventually, I need a processor coupled with an FPGA - the FPGA is where most of the hard real- time activity (traction with physics) should take place, IMO. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-26 5:06 ` Adam Jensen @ 2018-05-26 23:58 ` Brian Drummond 2018-05-27 8:26 ` Jacob Sparre Andersen 2018-05-30 19:52 ` JLotty 1 sibling, 1 reply; 15+ messages in thread From: Brian Drummond @ 2018-05-26 23:58 UTC (permalink / raw) On Sat, 26 May 2018 05:06:40 +0000, Adam Jensen wrote: > On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote: > >> On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote: >> >>> Is it common for developers to create their own run-time system for >>> embedded platforms? My inclination would be to look for hardware based >>> on 1) RTS availability/quality and 2) toolkit complexity/completeness >>> (completeness implies useful documentation). >> >> Not common, no. But RTS availability (esp. SPARK RTS) has to start >> somewhere, and for the MSP430 I didn't really develop one, just adapt >> from AVR-Ada. >> >> With remarkably little feedback on that project, I admit I've put >> remarkably little effort into pushing it further. But I want it for my >> own purposes, the watch is just a pretty by-product. > > Super cool. Are your project's documents posted/hosted anywhere for > others to view and use? https://sourceforge.net/projects/msp430ada/ It's somewhat stuck in the past, using Peter Bigot's rather nice MSP430 backend, because gcc's own MSP430 backend built into newer versions have a considerably poorer code generator (last time I looked a couple of years ago). Revisiting it is on my to-do list, hopefully it has improved. > They have the "Make with Ada" competition: > <https://www.makewithada.org/> > > And the Adacore University: > <http://university.adacore.com/> Both good forms of publicity, though I wonder to what extent they manage to bring in new people as opposed to reaching to the converted. (and I know you've been involved with at least one Ada project for a few years :-) > The Nucleo-144 board was selected as a gentle starter kit to develop > some confidence and familiarity with the tool-chain and the work-flow. > It was a total failure in this role. However, I have been keeping notes > and at some point I might create a tutorial for Ada/Spark development on > Ubuntu x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I > will probably move to a platform with more resources. Eventually, I need > a processor coupled with an FPGA - the FPGA is where most of the hard > real- time activity (traction with physics) should take place, IMO. You'll know all about the bottlenecks between a nice fast FPGA engine and any embedded CPU then. -- Brian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-26 23:58 ` Brian Drummond @ 2018-05-27 8:26 ` Jacob Sparre Andersen 0 siblings, 0 replies; 15+ messages in thread From: Jacob Sparre Andersen @ 2018-05-27 8:26 UTC (permalink / raw) Brian Drummond wrote: > Both good forms of publicity, though I wonder to what extent they > manage to bring in new people as opposed to reaching to the converted. It is my impression that the Make with Ada competition actually has reached people, who didn't use Ada before. (Not that people who already know Ada aren't interested too.) Greetings, Jacob -- »Saving keystrokes is the job of the text editor, not the programming language.« -- Preben Randhol ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-26 5:06 ` Adam Jensen 2018-05-26 23:58 ` Brian Drummond @ 2018-05-30 19:52 ` JLotty 2018-05-30 21:58 ` Simon Wright 1 sibling, 1 reply; 15+ messages in thread From: JLotty @ 2018-05-30 19:52 UTC (permalink / raw) On Friday, May 25, 2018 at 11:06:41 PM UTC-6, Adam Jensen wrote: > On Fri, 25 May 2018 10:50:07 +0000, Brian Drummond wrote: > > > On Fri, 25 May 2018 04:45:16 +0000, Adam Jensen wrote: > > > >> Is it common for developers to create their own run-time system for > >> embedded platforms? My inclination would be to look for hardware based > >> on 1) RTS availability/quality and 2) toolkit complexity/completeness > >> (completeness implies useful documentation). > > > > Not common, no. But RTS availability (esp. SPARK RTS) has to start > > somewhere, and for the MSP430 I didn't really develop one, just adapt > > from AVR-Ada. > > > > With remarkably little feedback on that project, I admit I've put > > remarkably little effort into pushing it further. But I want it for my > > own purposes, the watch is just a pretty by-product. > > Super cool. Are your project's documents posted/hosted anywhere for > others to view and use? > > >> Given that, which seems like an obvious thing to do, I am surprised > >> that Adacore does not have more apparent associations with hardware > >> vendors where dev-kits and SBC products are promoted. I bought the > >> Nucleo-144 board because I thought there was a BSP, RTS, and a > >> tool-chain configuration tutorial. That turned out to be a bit of a > >> mistake and generally a poor choice. > > > > Not Adacore ... there isn't much hobbyist money for them, given their > > business model. They do publicise occasional hobby-level projects like > > Lego Mindstorms and Certyflie, but I don't see them making money off it. > > They have the "Make with Ada" competition: > <https://www.makewithada.org/> > > And the Adacore University: > <http://university.adacore.com/> > > If there is not a large vibrant community of people who understand and > use the technology it will fade and collapse. It seems like maybe they > recognize this but it doesn't seem like they know what to do. (Only an > idiot would have advertisers involved in technical communication). C'est > la vie. > > > Meanwhile we have to support each other, perhaps your work on Nucleo can > > feed back into Simon's RTS and expand its supported platforms. > > The Nucleo-144 board was selected as a gentle starter kit to develop some > confidence and familiarity with the tool-chain and the work-flow. It was > a total failure in this role. However, I have been keeping notes and at > some point I might create a tutorial for Ada/Spark development on Ubuntu > x86_64 targeting the ARM MCU on a Nucleo-144 board. After that, I will > probably move to a platform with more resources. Eventually, I need a > processor coupled with an FPGA - the FPGA is where most of the hard real- > time activity (traction with physics) should take place, IMO. You might also look into these codebases: https://github.com/lambourg/Ada_Bare_Metal_Demos https://travis-ci.org/AdaCore/Ada_Drivers_Library Both are supported by AdaCore and provide runtime systems for STM32F4 boards, as well as Raspberry Pi. The STM33F4 is a fairly inexpensive board. I would recommend beginning development on it to build confidence and learn the embedded Ada details, then begin porting to the Nucleo-144 board specifications as described in "Porting the Ada runtime to a new ARM board" <https://blog.adacore.com/porting-the-ada-runtime-to-a-new-arm-board> Both of these repositories worked out of the box for me on GNAT 2017. James ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-30 19:52 ` JLotty @ 2018-05-30 21:58 ` Simon Wright 2018-06-03 23:21 ` JLotty 0 siblings, 1 reply; 15+ messages in thread From: Simon Wright @ 2018-05-30 21:58 UTC (permalink / raw) JLotty <jlotspeich34@gmail.com> writes: > https://github.com/lambourg/Ada_Bare_Metal_Demos > https://travis-ci.org/AdaCore/Ada_Drivers_Library The Bare_Metal_Demos doesn't seem to have anything for STM3F4 The Ada_Drivers_Library is actually at github.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-30 21:58 ` Simon Wright @ 2018-06-03 23:21 ` JLotty 2018-06-04 7:11 ` Simon Wright 0 siblings, 1 reply; 15+ messages in thread From: JLotty @ 2018-06-03 23:21 UTC (permalink / raw) On Wednesday, May 30, 2018 at 3:58:34 PM UTC-6, Simon Wright wrote: > JLotty <jlotspeich34@gmail.com> writes: > > > https://github.com/lambourg/Ada_Bare_Metal_Demos > > https://travis-ci.org/AdaCore/Ada_Drivers_Library > > The Bare_Metal_Demos doesn't seem to have anything for STM3F4 > The Ada_Drivers_Library is actually at github.com The Bare_Metal_Demos contain: stm32f429_demos.gpr stm32f469_demos.gpr stm32f746_demos.gpr stm32f769_demos.gpr Choose the project to match your version of STM32F4 board. All of these follow the same base configuration/functionality. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-06-03 23:21 ` JLotty @ 2018-06-04 7:11 ` Simon Wright 0 siblings, 0 replies; 15+ messages in thread From: Simon Wright @ 2018-06-04 7:11 UTC (permalink / raw) JLotty <jlotspeich34@gmail.com> writes: > On Wednesday, May 30, 2018 at 3:58:34 PM UTC-6, Simon Wright wrote: >> JLotty <jlotspeich34@gmail.com> writes: >> >> > https://github.com/lambourg/Ada_Bare_Metal_Demos >> > https://travis-ci.org/AdaCore/Ada_Drivers_Library >> >> The Bare_Metal_Demos doesn't seem to have anything for STM3F4 >> The Ada_Drivers_Library is actually at github.com > > The Bare_Metal_Demos contain: > stm32f429_demos.gpr > stm32f469_demos.gpr > stm32f746_demos.gpr > stm32f769_demos.gpr > > Choose the project to match your version of STM32F4 board. All of > these follow the same base configuration/functionality. Yes, but AFAICR OP had what AdaCore's RTS's call an STM32F4, i.e. STM32F407. The board was called STM32F4DISCOVERY, current order code STM32F407G-DISC1 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-23 8:07 ` Simon Wright 2018-05-24 7:35 ` Adam Jensen @ 2018-05-25 3:29 ` Adam Jensen 2018-05-25 7:55 ` Simon Wright 1 sibling, 1 reply; 15+ messages in thread From: Adam Jensen @ 2018-05-25 3:29 UTC (permalink / raw) I am trying the "Digital Output" example described here: <http://www.inspirel.com/articles/Ada_On_Cortex_Digital_Output.html> Compilation seems to be successful with these commands: gprbuild -c -u -f utils.adb --target=arm-eabi --RTS=zfp-stm32f4 gprbuild -c -u -f pins.adb --target=arm-eabi --RTS=zfp-stm32f4 gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4 But linking fails like this: arm-eabi-ld -T ../flash.ld -o program.elf program.o pins.o utils.o pins.o: In function `pins__enable_output': pins.adb:(.text+0x20): undefined reference to `__gnat_last_chance_handler' pins.o: In function `pins__write': pins.adb:(.text+0x7a): undefined reference to `__gnat_last_chance_handler' The symbols in "pins" are: arm-eabi-nm pins.o U __gnat_last_chance_handler U GPIOA_BSRR U GPIOA_MODER 00000000 D pins_E 00000000 T pins__enable_output 00000060 T pins__write U RCC_AHB1ENR Eager to move forward, I cobbled together a GPR project file targeting the full Ravenscar profile. #ravenScar.gpr project Ravenscar is for Source_Dirs use ("src"); for Ignore_Source_Sub_Dirs use (".svn"); for Object_Dir use "obj"; for Exec_Dir use "."; for Main use ("program.adb"); for Runtime ("Ada") use "ravenscar-full-stm32f4"; for Target use "arm-eabi"; package Builder is for Executable_Suffix use ""; for Global_Configuration_Pragmas use "src/gnat.adc"; end Builder; package Compiler is for Default_Switches ("ada") use ("-O0", "-gnatwa", "-gnatQ", "- gnatw.X"); end Compiler; package Binder is for Required_Switches ("Ada") use Binder'Required_Switches ("Ada") & ("gnatbind_prefix=arm-eabi-") & ("--RTS=/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/ ravenscar-full-stm32f4/") & ("-nostdlib"); for Driver ("Ada") use "/home/hanzer/.local/gnat-arm/libexec/gprbuild/gprbind"; end Binder; package Linker is for Driver use Compiler'Driver ("Ada"); for Map_File_Option use "-Wl,-Map,"; for Response_File_Format use "GCC_GNU"; for Max_Command_Line_Length use "8192"; for Required_Switches use Linker'Required_Switches & ("-L/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/ravenscar- full-stm32f4/adalib", "-nostartfiles", "-lgnat", "-lc", "-lgnat", "-lgcc", "-L/home/hanzer/.local/gnat-arm/arm-eabi/lib/gnat/ravenscar- full-stm32f4/ld", "-T", "flash.ld"); end Linker; end Ravenscar; ------------------------------------------------------------------------- I didn't really expect it to work - I am well into the realm of wild-ass guesses at this point. This is what happens: gprbuild -P ./ravenscar.gpr Compile [Ada] program.adb [Ada] pins.adb [Ada] utils.adb [Ada] registers.ads Bind [gprbind] program.bexch [Ada] program.ali program.adb:1: Program cannot be used as a main program gprbind: invocation of gnatbind failed gprbuild: unable to bind program.adb On Wed, 23 May 2018 09:07:51 +0100, Simon Wright wrote: > I think that the reason why the tutorial works and your attempt doesn't > is that the tutorial was developed on a Raspberry Pi, which is already > an ARM-based machine, so the native compiler actually has a runtime > (i.e. system.ads etc etc) visible to it. This is so very relevant yet the tutorial seems rather vague [to me] on this point. It should be explicit, in bold, in a highlighted box on the front page, IMO. Thanks again for pointing that out. Even on a second reading, it isn't clear [to me] that using a Raspberry Pi as a software development platform is the environment of the tutorial. <http://www.inspirel.com/articles/ Ada_On_Cortex_Documentation_And_Tools.html> > but a simpler (more memorable!) procedure might be to construct your > own: > > 1. Create directories adainclude/, adalib/ > > 2. Copy $prefix/arm-eabi/lib/gnat/zfp-stm32f4/gnat/system.ads to your > adainclude/ ($prefix is the root of your compiler installation, I > think ~/.local/gnat-arm) > > The zfp- (zero footprint) runtime is the closest to what you need, and > the fact that the -stm32f4 part isn't quite right shouldn't matter; I > suspect that system.ads is the same for all the zfp runtimes. > > Now, > > $ arm-eabi-gcc --RTS=. -c program.adb I will try this next. It's a bit like learning to swim by jumping into the deep end of the pool (or being thrown in). This article might help: "Porting the Ada runtime to a new ARM board" <https://blog.adacore.com/porting-the-ada-runtime-to-a-new-arm-board> I also ordered a copy of this book (below) since I don't actually know the Ada programming language (I have plenty of experience with VHDL). <https://www.amazon.com/Programming-Ada-2012-John-Barnes/dp/110742481X/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: How to configure GNAT GPL on x86-64 Linux for ARM ELF development 2018-05-25 3:29 ` Adam Jensen @ 2018-05-25 7:55 ` Simon Wright 0 siblings, 0 replies; 15+ messages in thread From: Simon Wright @ 2018-05-25 7:55 UTC (permalink / raw) Adam Jensen <hanzer@riseup.net> writes: > I am trying the "Digital Output" example described here: > <http://www.inspirel.com/articles/Ada_On_Cortex_Digital_Output.html> > > Compilation seems to be successful with these commands: > gprbuild -c -u -f utils.adb --target=arm-eabi --RTS=zfp-stm32f4 > gprbuild -c -u -f pins.adb --target=arm-eabi --RTS=zfp-stm32f4 > gprbuild -c -u -f program.adb --target=arm-eabi --RTS=zfp-stm32f4 > > But linking fails like this: > arm-eabi-ld -T ../flash.ld -o program.elf program.o pins.o utils.o > pins.o: In function `pins__enable_output': > pins.adb:(.text+0x20): undefined reference to `__gnat_last_chance_handler' > pins.o: In function `pins__write': > pins.adb:(.text+0x7a): undefined reference to `__gnat_last_chance_handler' From the tutorial, towards the end, You should notice the -gnatp option when compiling the pins.adb file. This option instructs the compiler not to generate calls to range check functions that verify whether the values that are assigned to variables or converted between types fall within expected ranges and if not, an appropriate standard exception is raised. We have decided not to rely on the Ada run-time library and without this option the final program would not link properly (try it, you can also check the assembly output for the pins.adb file and see that indeed there are some calls to other, language-supporting subprograms). and then Instead, we can verify the code and conclude that all values are safe and therefore resign from run-time range checks altogether, which in the embedded context is a more robust approach anyway. Later on we will see how to automate such analysis, which with bigger programs could be much less straightforward when done manually. For the time being, we will rely on manual verification and the -gnatp option in such cases. I think Maciej is referring to proof techniques, which is laudable, but I find it necessary to let the exceptions happen if I make a mistake; I've tended to have a 'heartbeat' LED flash, so that if the last chance handler (which disables interrupts and loops) happens I can at least see that something's wrong. AdaCore's Certyflie[1] implementation for the Crazyflie brings some SPARK proof to the drone's firmware, but (a) it only applies to the application layer, not the drivers, (b) it crashes the 2017 CE SPARK package, (c) without expert assistance, I can't get my head round the contortions necessary to do SPARK (particularly the real-time aspects). [1] https://github.com/AdaCore/Certyflie ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-06-04 7:11 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-23 6:37 How to configure GNAT GPL on x86-64 Linux for ARM ELF development Adam Jensen 2018-05-23 8:07 ` Simon Wright 2018-05-24 7:35 ` Adam Jensen 2018-05-24 12:12 ` Brian Drummond 2018-05-25 4:45 ` Adam Jensen 2018-05-25 10:50 ` Brian Drummond 2018-05-26 5:06 ` Adam Jensen 2018-05-26 23:58 ` Brian Drummond 2018-05-27 8:26 ` Jacob Sparre Andersen 2018-05-30 19:52 ` JLotty 2018-05-30 21:58 ` Simon Wright 2018-06-03 23:21 ` JLotty 2018-06-04 7:11 ` Simon Wright 2018-05-25 3:29 ` Adam Jensen 2018-05-25 7:55 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox