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!feeder.eternal-september.org!aioe.org!.POSTED.Ax1plA92+M8knTe0tgy46Q.user.gioia.aioe.org!not-for-mail From: russ lyttle Newsgroups: comp.lang.ada Subject: Re: Ada in command / control systems Date: Wed, 27 Feb 2019 08:22:13 -0500 Organization: Aioe.org NNTP Server Message-ID: References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> NNTP-Posting-Host: Ax1plA92+M8knTe0tgy46Q.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US X-Mozilla-News-Host: news://news.aioe.org Xref: reader01.eternal-september.org comp.lang.ada:55694 Date: 2019-02-27T08:22:13-05:00 List-Id: On 2/26/19 6:09 PM, Simon Wright wrote: > lyttlec writes: > >> The "use linker script" part is where I am having difficulty with gnat >> targeting a PC. Haven't tried the STM32F4 yet. >> All I've found so far, including tutorial on AdaCore, apply only to >> Windows and produce errors in Linux. For example the advice to use >> "-Xlinker -Wl --stack = ..." is Windows only. > > gnatbind (try --help to get the full set of options) has these, which > might help. Bad idea to use these in a small MCU. > > -dnn[k|m] Default primary stack size = nn [kilo|mega] bytes > -Dnn[k|m] Default secondary stack size = nn [kilo|mega] bytes > >> We may have to give up and switch back to using Makefile, which >> probably isn't such a bad idea anyway. > > Don't see how this will help, you need to work out how to get the > compiler, binder and linker to cooperate. > Done that with Makefiles on other projects. Now looking for a way to do it with gpr files. I don't want to give up until I'm sure that I must. > I'm having a bit of trouble working out what you're trying to do. You > seem to be targeting a wide range of platforms, from Linux to embedded > MCUs. The need to control sizes etc is much less in a Unix-like > environment, and I doubt very much you'd want to use EEPROM (do you mean > that, by the way? MCUs seem to use Flash) or even bother to think about > how the linker arranges things so that the program starts up properly. > Should have said Flash. Watch https://www.youtube.com/watch?v=3jstaBeXgAs Not my project, but you get the idea. Lots of (small) computers networked. Penney's count so the lowest cost mcu must be used. At least one device has an OS, some need a scheduler, most are bare bones. All are going to be pushed to the limit. The life of the software will be long, even though some of the mcu might change. For example the mcu reporting tire air pressure might change between production runs or model year. > The same applies to more capable boards on the lines of the Raspberry Pi > - just another Unix-like platform. We will have one or more R-Pi class devices that need a provably secure and correct OS. While Raspbian is much better than Windows 10, how would you show that it is correct? > > But when it comes to MCUs like the STM32F4 with a megabyte of Flash and > 128K of RAM (actually, there's another 64K of close-coupled RAM, I see) > more care is needed. A lot of this will have been looked after by > whoever provides your runtime. The STM32F4 is one of the easy ones. Think of it as representing a class of target, rather than a specific target. STMicro today might be replaced with Freescale next year. "Whoever provides your runtime" is me. >