Re: STM32F4 Discovery, communication and libraries

[Roy Emmerich <roy.emmerich@gmail.com>]

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 opinions. 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 flame wars. I'm new, inexperienced but keen to learn and curious as to why you 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 beginners?

[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 (reluctantly) 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 vendor
> 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 abstracting
> away the mess.

[Roy]
CANOpen is very complicated, I agree. The STM32F4 comes with built-in support for vanilla CAN which is exposed in this C driver:

https://github.com/espruino/Espruino/blob/master/targetlibs/stm32f4/lib/stm32f4xx_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 library can take care of it, great!

[Dmitry]
> You will need lower-level vendor libraries, which are vendor (Vector, IXXAT
> 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 protocols
> 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 accurately 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 using 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 series of MCUs
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00025071.pdf


2. Use the "zero on write" method as described in the "Clock Synchronisation Methods" here:

http://hairy.geek.nz/projects/hardware-ntp-server/clock-synchronisation-methods/

3. Figure out RFC2783 and RFC1589 and hack something using the GPS time pulse 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-board RTC you will notice most of the hard work has already been done:

https://github.com/espruino/Espruino/blob/master/targetlibs/stm32f4/lib/stm32f4xx_rtc.c

I presume this could be rewritten in Ada but to get started why not just wrap this code and get cracking doing useful stuff?

If somebody could show me how to achieve this quickly and simply I'd be jumping 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 create 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 used of course, with the option of including a solar panel and mini charge controller for operation completely independent of other power sources. My gut feeling tells me your solution would be somewhat more power hungry?

Without spending too much research effort, I took a look at the Raspberry Pi FAQ and found that running it on batteries would be a challenge to say the 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=1294

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 = 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 have to use a pretty big battery!

Regards
Roy
---
www.infinitefingers.com