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.182.166.73 with SMTP id ze9mr2897931obb.4.1409146519148; Wed, 27 Aug 2014 06:35:19 -0700 (PDT) X-Received: by 10.140.83.180 with SMTP id j49mr646993qgd.1.1409146519122; Wed, 27 Aug 2014 06:35:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!uq10no5797892igb.0!news-out.google.com!j6ni8038qas.0!nntp.google.com!m5no3565153qaj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 27 Aug 2014 06:35:19 -0700 (PDT) In-Reply-To: <16yza1ilbvqht.13yvkjtrl3l2.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=77.176.215.183; posting-account=Fmp50goAAAA9sbkA2aX-X9YQy6-lkg3J NNTP-Posting-Host: 77.176.215.183 References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <16yza1ilbvqht.13yvkjtrl3l2.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: STM32F4 Discovery, communication and libraries From: Roy Emmerich Injection-Date: Wed, 27 Aug 2014 13:35:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21931 Date: 2014-08-27T06:35:19-07:00 List-Id: Hi Dmitry, Thanks for your post. Please note that I reply with the utmost respect and = humility. I have very little low level microcontroller experience but it is= growing quickly as I get stuck into this stuff. Having flown through this forum last night for the first time and checking = your website, I noticed you have vast experience and accompanying strong op= inions. That is not bad, just a bit difficult for some to digest :) So with this background, I will attempt to probe a bit deeper. Please, no f= lame wars. I'm new, inexperienced but keen to learn and curious as to why y= ou hold the opinions you do. [Dmitry] > Basically it does not make sense to have a library > beyond system's port I/O driver, because higher-level protocols have > nothing in common, e.g. AK, CSLIP, ModBus. [Roy] Would you mind explaining what you mean in a bit more detail...for beginner= s? [Dmitry] > ModBus is very straightforward to implement from scratch. There exist > commercial libraries of course, but you want it for free, I guess... [Roy] There are MANY implementations but I prefer reuse, allowing me to focus my = efforts elsewhere. If I really can't find something then I will (reluctantl= y) roll my own. [Dmitry] > Usually middle-layer transports like ModBus, CAN have no use > without integration into some middleware framework. It is a bad idea to > communicate directly to them from the application, even if through a vend= or > library. [Roy] Why? It seems to be done in many other projects. Are they all wrong? [Dmitry] > Then, regarding CAN, the real problems are in the configuration, e.g. DBC > parsing or handling CANOpen. It is a very complicated stuff, which would = be > very difficult to handle in an application without a middleware abstracti= ng > away the mess. [Roy] CANOpen is very complicated, I agree. The STM32F4 comes with built-in suppo= rt for vanilla CAN which is exposed in this C driver: https://github.com/espruino/Espruino/blob/master/targetlibs/stm32f4/lib/stm= 32f4xx_can.c I thought a library was effectively that, a quasi 'middleware' abstracting = away the messy stuff from the application? [Dmitry] > And all protocols have issues with polling/event handling policy, you > wouldn't burden the application with that. [Roy] Why? One of the software layers has to take care of it somehow. If the libr= ary can take care of it, great! [Dmitry] > You will need lower-level vendor libraries, which are vendor (Vector, IXX= AT > etc, I don't know what is the status of Linux CAN driver for ARM boards) > dependent and higher-level libraries implementing the upper-level protoco= ls > like CANOpen. [Roy] Lower level vendor libraries implemented in which language? From what I can= see that will invariably be C. The STM32F4 comes with a bunch of them for = low level access to the chip functionality, some of which I would very much= like to use directly in my application. Let's take an example of something I want to achieve soon, namely accuratel= y synchronising the STM32F4 RTC with GPS time/time pulse. From what I have = seen there are a few options to do this accurately: 1. The RTC calendar can be synchronized to a more precise, remote clock usi= ng the RTC shift feature (see page 19 of the ST RTC manual for more details= ): STM Application note AN3371 Using the hardware real-time clock (RTC) in STM32 F0, F2, F3, F4 and L1 ser= ies of MCUs http://www.st.com/st-web-ui/static/active/en/resource/technical/document/ap= plication_note/DM00025071.pdf 2. Use the "zero on write" method as described in the "Clock Synchronisatio= n Methods" here: http://hairy.geek.nz/projects/hardware-ntp-server/clock-synchronisation-met= hods/ 3. Figure out RFC2783 and RFC1589 and hack something using the GPS time pul= se signal (e.g. as used in the gpsd Linux project). * http://tools.ietf.org/html/rfc2783 * http://tools.ietf.org/html/rfc1589 * http://git.savannah.gnu.org/cgit/gpsd.git/tree/ppsthread.c If you take a look at the relevant STM C firmware to get access to the on-b= oard RTC you will notice most of the hard work has already been done: https://github.com/espruino/Espruino/blob/master/targetlibs/stm32f4/lib/stm= 32f4xx_rtc.c I presume this could be rewritten in Ada but to get started why not just wr= ap this code and get cracking doing useful stuff? If somebody could show me how to achieve this quickly and simply I'd be jum= ping around like a kid in a candy store! [Dmitry] > I would try to use a Linux instead of running bare board. Debian for ARM = is > available. It has a fully working GNAT FSF. [We successfully ran our > middleware (100% Ada) on an ARM board.] [Roy] This does sound very convenient! Thanks for the tip. However my aim is to c= reate a device which can run on a small (e.g. 2000 mAh) lithium battery for= weeks or months, depending on the connected peripherals and how they are u= sed of course, with the option of including a solar panel and mini charge c= ontroller for operation completely independent of other power sources. My g= ut feeling tells me your solution would be somewhat more power hungry? Without spending too much research effort, I took a look at the Raspberry P= i FAQ and found that running it on batteries would be a challenge to say th= e least: http://www.raspberrypi.org/help/faqs/#powerBatteries This intrepid fellow put a lot more effort into power saving: http://www.daveakerman.com/?page_id=3D1294 Conclusion: Assuming: * each AA battery has 3000 mAh * 70% efficiency * 6 AAs (i.e. 18 Ah in total) * using an more efficient switching regulator Total run time =3D 28 hours [only!!!] That's a lot of energy! For my device I am aiming for an energy autonomy of 3 days at least. I'd ha= ve to use a pretty big battery! Regards Roy --- www.infinitefingers.com