Re: STM32F4 Discovery, communication and libraries

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 27 Aug 2014 06:35:19 -0700 (PDT), Roy Emmerich wrote:

> [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?
> 
It was regarding the "comm libraries". What such a library might provide is
reading and writing raw bytes from a serial port. This is less than 1% of
functionality needed to communicate with the hardware. It is not their
purpose.

What AdaCore libraries are good for is that they provide an OS abstraction
layer, another example of such a library is the GNAT sockets library. They
allow you writing OS-independent implementation of specific protocol stacks
like ModBus. This is a great help not to underestimate, but it has nothing
to do with implementation of higher-level protocols. That will be your job.
 
> [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.

I don't know what these implementations offer, usually very little, because
at this level (of OSI) you cannot have useful bindings without some
middleware framework.

> [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?

I know a lot of implementations of various industrial protocols stacks.
None of them you could use off-the-shelf. Not because they are bad, but
because of the nature of things.

> [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

That looks very basic, but at least there is a buffer for incoming frames.
A good CAN library provides:

1. callback for incoming frames with user data field. Polling CAN
controller buffer might a very expensive depending on the controller.

2. time stamping of the incoming frames. If you do some control or data
logging you need that.

3. means to reset the controller, e.g. the BUS HEAVY state.

4. frame filtering (handy if you have a heavy bus load and cleaning the
controller's buffer might very expensive, as I said)

> I thought a library was effectively that, a quasi 'middleware' abstracting
> away the messy stuff from the application?

No. The middleware like OPC, LabMap etc would abstract CAN as a set of
channels or process variables. When a CAN frame, considering it is a plain
CAN, comes its contents is split into process variables, these variables
are updated and the application can access them later. Similarly when an
application writes some variables that will have an effect of sending one
or series of CAN frames out with the IDs and data fields encoded as
required. This is a lot of work. There are semi-standard descriptions of
CAN frames built-up, e.g. Vector's DBC format or ASAP2 etc. You won't do
this in an application, each time.

> [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!

The library cannot take care of that. Such libraries (stacks) provide very
basic functionality, like transmitting and receiving CAN frames. This as
about much as reading/writing bytes from RS232 when you need to communicate
with a HTTP server over CSLIP.
 
> [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.

Yes, but this is no problem in most cases. BTW, the lower the level the
better. If the library starts playing things with threading you will be in
trouble soon.

> 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:

I would not adjust clocks, controlling algorithms don't like clocks jumping
forth and back. You may consider translation of timestamps of incoming and
outgoing data according to the estimated clock skew. Usually it is less
offending for the rest of the system.

> 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?

Yes. If you have a BSP (board support package) it is wasting time to
rewrite it in Ada. You can call C code directly from Ada, you don't even
need to wrap it.
 
> If somebody could show me how to achieve this quickly and simply I'd be
> jumping around like a kid in a candy store!

See:

http://www.ada-auth.org/standards/12rm/html/RM-B-3.html
 
> [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?

Power consumption was never a concern to us, but I don't see obvious
reasons why a bare board should consume sufficiently less than the same
board running Debian Linux.

[...]

> Total run time = 28 hours [only!!!]
> 
> That's a lot of energy!

BTW, I don't know how much juice CAN requires, as I said, our applications
have no problems with power supply, but I guess that CAN eats pretty much.
If you have an external power supply for CAN, you could use it for the
board as well. I suggest you should do some math in order not to run into
problems later.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de