Re: STM32F4 Discovery, communication and libraries

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Tue, 26 Aug 2014 15:38:33 -0700 (PDT), roy.emmerich@gmail.com declaimed
the following:


>I don't have experience in C/C++ but I do have a lot of experience in Java, python, structured text (read PLCs) and a few other bits and pieces. I REALLY don't want to develop in C. From what I can make out it looks like a nightmare once the code reaches any substantial size, which mine will. I've started quite a few beginner C books and never got very far before throwing in the towel. However what I've read about Ada has certainly caused me to sit up!
>
	Do you have any experience with assembler (any) -- since so much of C
mapped to the PDP series instruction set (pre/post increment/decrement
operators, for example).

	C, itself, is a fairly small language -- it's main feature being also
its main problem: it assumes the programmer knows what they are doing and
offers easy access to (mis)treating data as addresses in memory.

	If you are familiar with Java AND with disciplined software
development, a copy of the K&R book for C should be all you need to learn
the language itself (in my world, it was the even smaller first edition K&R
with my experience of FORTRAN, COBOL, Pascal, and Assembler -- circa 1982).

	C++, OTOH... THAT is a nightmare language to pick up... Do NOT think of
it as just a more powerful C.

>So far I have investigated the following high level language alternatives:
>
>1. www.espruino.com (JavaScript)

	Interpreted... And not even full Java... I've not looked at the link --
JavaScript is the "native" language for the BeagleBone Black, as I recall.

>2. www.micropython.org

	Interpreted (byte-code)...

>3. www.eluaproject.net

	Based on LUA?, probably interpreted.

	All will require you to have an interpreter running on the board (you
are entering the world of the old BASIC Stamp and PICAxe chips -- PIC
variants with a byte-code interpreter running as the program, and your
program loaded into data memory; the Parallax Javelin didn't last long --
it had a Java interpreter on the chip, supposed to run regular Java byte
code).

>but I see dragons on the horizon. Here are a few:
>
>1. It is not hard real-time

	Few interpreted languages are... Especially if they have dynamic
behavior (that is, you can modify class methods on the fly).

	"Real-Time Systems and Programming Languages" covers Ada, C with a
POSIX Real-Time package, and something titled "Real-Time Java"... Might be
of interest...

>
>For Ada to be a viable option for my project, this is what I think I need [with Mike's comments]:
>
>1. [IN PROGRESS] Easy communication: SPI, I2C, Serial, Ethernet,
>
>[Mike]
>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.
>
>[Roy]
>If they want adopters then they'd better get a move on!
>
>2. [UNSOLVED?] Libraries/examples: MODBUS RTU/Eth at the very least
>
>I have yet to find a repository of libraries covering the major protocols (e.g. MODBUS, CAN, one-wire). There are quite a few in C. Would it be viable to just wrap these in Ada? It seems like a great short term solution but if we are using Ada to make things more stable, it hardly makes sense to use it merely to wrap (flakey) C libraries ;)
>

	I suspect a lot of those are being developed by companies for
proprietary products, possibly using some internal core "OS" for
interfacing between application code and the board support layer. As a
result, even if one got their hands on the driver source, one would have to
replicate the OS environment to make use of it. At work, I believe the
common route is to use IOCTL() calls to manipulate the hardware specific
drivers, leaving a common POSIX (?) interface to C, and wrapping the C
calls for Ada (if not directly wrapping the assembler entry point to the
same functionality).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/