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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Wed, 27 Aug 2014 18:00:32 +0200 Organization: cbb software GmbH Message-ID: <8w11t1ag06h1.qj04bp5cpxwx.dlg@40tude.net> References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <16yza1ilbvqht.13yvkjtrl3l2.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: etnUhctbDQ6U1zAlbX4CBw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.dca.giganews.com comp.lang.ada:188681 Date: 2014-08-27T18:00:32+02:00 List-Id: 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