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!newspeer1.nac.net!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Mon, 01 Sep 2014 23:15:44 +0300 Organization: Tidorum Ltd Message-ID: References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com> <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net> <929e9226-e4aa-474e-843c-68ed800eefad@googlegroups.com> <6db74417-a977-4d10-a792-18a94a14c68f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 3aql/gzFmRUBp7bEugmCsQ3taa/b+jBXjxIw3QNwHznGnpfTLO Cancel-Lock: sha1:sItaEiQxirSXt+3eMCcP6drXunc= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <6db74417-a977-4d10-a792-18a94a14c68f@googlegroups.com> Xref: number.nntp.dca.giganews.com comp.lang.ada:188786 Date: 2014-09-01T23:15:44+03:00 List-Id: On 14-08-31 01:00 , Roy Emmerich wrote: > On Friday, 29 August 2014 21:41:18 UTC+2, Niklas Holsti wrote: >> On 14-08-29 19:47 , Roy Emmerich wrote: ... >>> This device will effectively aggregate the data from all of these >>> devices into one, unified format and send control signals to the >>> generator/inverters. >> >> What is the highest control frequency, or shortest deadline or >> response time, required of the SW? > > Okay, some new terminology for me here. For this particular > application the response time doesn't have to be very fast (a few > seconds). Then you can probably ignore all interrupt-handling and just poll for I/O completion -- if that is much simpler to do. > ... As this kind of control is > a lot more dynamic, a much faster response time would be required (20 > ms thumb suck value, considering one 50 Hz period is 20 ms long). That might or might not require interrupt-handling -- depends on your overall design. >>> ... making it important for it to be a low power device (e.g. >>> much less than say a beaglebone black embedded Linux board), able >>> to run on a battery for at least 3 days, preferably much more >> >> You may have to modify the Board Support Package and/or the kernel >> to let the processor sleep between clock interrupts. I don't know >> if the AdaCore ARM BSP has that ability off-the-shelf. > > Is there an AdaCore ARM BSP yet? I thought this is what Mike Silva > was referring to when he said: > > "I know that AdaCore is working on comms libraries for the ARM Cortex > M parts, but I don't know anything about the projected > availability." > > assuming this would include stuff such as I2C, SPI, UART, etc. which > is normally also part of the BSP? In my experience (space domain), the BSP (at least when it comes from a compiler vendor) usually includes only the functions needed to make the compiler's run-time system work. For Ada/Ravenscar, this means mainly that task switching and protected objects work as expected (including POs used as interrupt handlers) and that some timer or clock HW is configured to drive Ada.Real_Time and the "delay until" statements. I/O drivers are not (in my domain) typically included in the BSP -- well, perhaps the BSP contains a simple serial-port driver to make some emasculated form of Ada.Text_IO work. I/O drivers typically come separately. For ground-based embedded systems, I have seen that some compiler or chip vendors package I/O drivers with their BSPs. Perhaps Mike Silva is talking about some AdaCore activity in that direction. > Speaking of which...in order to feel like I'm making progress and Ada > is going to work for me, I really need to get connecting to my > peripherals. The only way I can see it happening within the next week > is to call the STM C drivers supplied with their BSP. Does this make > sense? Very much so, at least if the C drivers are designed as a passive library which does not rely on any specific kernel. >>> It must keep accurate time (syncing once a day via GPS) Must the SW actions be accurately synchronized with GPS -- for example, sample something exactly at the GPS pulse-per-second pulse -- or is it enough that the SW can accurately label each action/sample with the GPS time when the sample was taken? >>> and >>> (periodically/in emergency) make the data available remotely >>> (via GPRS). >> >> Time in a Ravenscar system is provided by the predefined package >> Ada.Real_Time. It is good for relative timing in seconds and ticks, >> but does not provide calendar date and time. Probably you will have >> to write your own Calendar-like package which is synchronised with >> GPS. Not a very big job. > > Maybe not if you know what you're doing ;) > > This is where it gets a bit vague for me. The STM32F4 has an on-board > RTC with full calendar functionality. Nice. > My thinking is at start up and > then once a day to enter a "clock_sync" state, fire up the GPS > receiver, somehow sync the processor's RTC and then continue with > normal operation. By "processor's RTC", you mean the one with full calendar functionality? Sounds like a good plan, if that RTC device allows such synchronisation. I would not try to sync or adjust whatever HW is driving Ada.Real_Time, but would let that run in its own time. If necessary, I would adjust the period of the cyclic tasks to keep them in phase with the GPS and/or the RTC. That is, if a 1 Hz task finds that it is falling behind -- doing fewer cycles than there are GPS/RTC 1-second ticks -- it would do a few "delay untils" with a smaller period than 1 s until it has caught up. > If I need the absolute date/time I can just get it > from the RTC, so I don't know why I would want to use the > Ada.Calendar functionality in the first place. Could you shed some > light on this? I agree, you don't need Ada.Calendar if you have a calendar-capable RTC and do not need to do date/time calculations such as finding the calendar date of "now + 100_000 seconds". >From what I understand of your application, I think you should be fine with Ada.Real_Time and the RTC. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .