I discovered Ada 2 days ago, so stick with me.

I am starting a business which will focus on creating a cheap, modular, open source data logger/controller usable across multiple domains. At the moment I am in the prototyping stage, using the following hardware:

1. STM32F4 Discovery board
2. MikroElektronika STM32F4 Discovery shield (http://www.mikroe.com/stm32/stm32f4-discovery-shield/)
3. Various MikroElektronika click boards (http://www.mikroe.com/click/):
   * GPS click board (ublox LEA-6S receiver)
   * microSD
   * RS485
   * RS232
   * Ethernet

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!

So far I have investigated the following high level language alternatives:

1. www.espruino.com (JavaScript)
2. www.micropython.org
3. www.eluaproject.net

At the moment I am forging ahead with Espruino because:

1. it is quick to get code on the processor as it is interpreted
2. interfacing with external hardware via SPI/I2C/UART is easy...except when you want to access on-chip functionality that isn't yet supported by the Espruino interpreter (which is aimed at STM32F1 powered Espruino board, partially ported to the STM32F4).
3. www.npmjs.org has so many libraries and examples of how to get things done (e.g. MODBUS RTU library...done) which translates to many willing hands/minds.

but I see dragons on the horizon. Here are a few:

1. It is not hard real-time
2. Although you can minify the code, I am uncertain whether everything will fit on when the code base grows.
3. JavaScript on microcontrollers has no track record.

In short, nice for tinkering/prototyping but probably not a wise choice for the long run.

Today I started chatting to Mike Silva over at EmbeddedRelated:

http://www.embeddedrelated.com/showarticle/617.php

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 ;)

[Mike]
It is also true that you can link to C code in Ada with either thin or thick wrappers. A thin wrapper just converts each C function to an equivalent Ada subprogram, while a thick wrapper adds one or more higher-level layers on top of the basic subprograms.

3. [SOLVED] Direct access to chip functionality: STM32F4 RTC, Precision Time Protocol capabilities on chip, etc. I read that binding in C code is fairly easy? That would allow me to directly call the STM32 C drivers provided by STM?

[Mike]
In any case, you will have no problem accessing the chip hardware in Ada.

4. [SOLVED] Someone hosts an open forum to encourage the exchange of ideas, providing an alternative to the normally clandestine military/large corporate approach to code development. If Ada is going to grow then it needs to open up to your average Joe like me.

[Mike]
comp.lang.ada!


I'd appreciate any further feedback from members of this list.

Roy
---
www.infinitefingers.com

On Thursday, August 28, 2014 1:09:05 PM UTC-7, Dmitry A. Kazakov wrote:
> Not really. OS is more than tasking, it is also a queueing mechanism, which
> allows waiting for I/O completion in one task without blocking all other
> tasks.
> ......
> You could not implement an equivalent of I/O queueing under the Ravenscar 
> constraints.

Are you saying that a full Ada implementation on bare metal could not implement an equivalent of I/O queueing?

Or are you saying that Ravenscar tasking on bare metal could not implement such queueing?

On Thu, 28 Aug 2014 09:28:15 -0700 (PDT), Mike Silva wrote:

> On Thursday, August 28, 2014 6:00:12 AM UTC-7, Dmitry A. Kazakov wrote:
>> One of the responsibilities of the OS and the middleware is to perform I/O
>> on things like ModBus in background without blocking the application and
>> other I/O. Even a very lame board is usually much faster than any ModBus
>> terminal.
> 
> Maybe there is some confusion being caused by the term "OS" here.  Ada's
> concurrency and realtime functionality can run on top of an OS, but it can
> also run on bare metal (an "invisible" OS?).

Not really. OS is more than tasking, it is also a queueing mechanism, which
allows waiting for I/O completion in one task without blocking all other
tasks.

> The GNAT ARM Cortex M
> release does have Ravenscar tasking on bare metal.

You could not implement an equivalent of I/O queueing under the Ravenscar
constraints.

>> In short, an OS-less design is not suitable for handling many peripheral
>> devices simultaneously, especially when the devices are attached over slow
>> asynchronous communication channels.
> 
> How could this be reworded to remove the "OS"?  A single-task or
> single-thread design is not suitable...?

A design without a mechanism of postponing and synchronization to multiple
I/O events.

The most simple case is when a task can be blocked until the event happens.

Alternatively it could be an asynchronous system trap. That is when the
task is interrupted upon an I/O event. Such an event-driven schema may
deploy single task. It is frequently used in GUI design and is sufficiently
more difficult to use. It would still require an OS for switching contexts.

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

On Thursday, 28 August 2014 18:28:15 UTC+2, Mike Silva  wrote:
> 
> Maybe there is some confusion being caused by the term "OS" here.  Ada's
> concurrency and realtime functionality can run on top of an OS, but it can also 
> run on bare metal (an "invisible" OS?).  The GNAT ARM Cortex M release does 
> have Ravenscar tasking on bare metal.

Thanks for chiming in here Mike. I was getting a bit worried, thinking I'd misunderstood all I'd read about Ada being able to natively run concurrent processes on the Cortex M.

> How could this be reworded to remove the "OS"?  A single-task or single-thread design is not suitable...?

To get around the threading problem, a fellow collaborator (read C junkie) is trying out one of the free C RTOSs (www.chibios.org) and is starting to make some progress, although it has been tough going! Just getting a blinking LED took 3 days! Admittedly it was his first experience with an RTOS and setting up an open source toolchain.

I take back what I said about JavaScript and loads of libraries! Today I tried to quickly get MODBUS communication going and failed. I couldn't find a single one to use as a MODBUS RTU master :(

I must admit that I'm in a lot of doubt about the right way forward.

On Thursday, August 28, 2014 6:00:12 AM UTC-7, Dmitry A. Kazakov wrote:
> On Thu, 28 Aug 2014 03:12:16 -0700 (PDT), Roy Emmerich wrote:
> 
> 
> 
> > I want to use a finite state machine (FSM) approach. There will be a
> 
> > supervisor module which will instantiate sub-modules which communicate
> 
> > with peripherals. Each sub-module will be a separate sub-FSM, reporting
> 
> > its state to the supervisor. Each sub-module will make use of a protocol
> 
> > library (e.g. MODBUS RTU) and a hardware driver library (e.g. UART over
> 
> > RS485/232) to communicate with devices.
> 
> > 
> 
> > That is it. No OS, no middleware.
> 
> 
> 
> It is difficult to imagine working. Do you know how ModBus function? It is
> 
> basically a client-server protocol. You send a request, e.g. F15 and then
> 
> read the response. Whether the request is a read or write request does not
> 
> matter. Most of ModBus end devices are half-duplex. Which means one request
> 
> at a time. Many have internal cycles and interlocking which make things
> 
> much slower than the physical I/O already did. Some would crash if you
> 
> queried too frequently.
> 
> 
> 
> Anyway, without an OS you will have to wait for the response to come, which
> 
> in turn, will block the whole application. It will be extremely slow.
> 
> 
> 
> One of the responsibilities of the OS and the middleware is to perform I/O
> 
> on things like ModBus in background without blocking the application and
> 
> other I/O. Even a very lame board is usually much faster than any ModBus
> 
> terminal.

Maybe there is some confusion being caused by the term "OS" here.  Ada's concurrency and realtime functionality can run on top of an OS, but it can also run on bare metal (an "invisible" OS?).  The GNAT ARM Cortex M release does have Ravenscar tasking on bare metal.

> In short, an OS-less design is not suitable for handling many peripheral
> 
> devices simultaneously, especially when the devices are attached over slow
> 
> asynchronous communication channels.

How could this be reworded to remove the "OS"?  A single-task or single-thread design is not suitable...?

On Thu, 28 Aug 2014 03:12:16 -0700 (PDT), Roy Emmerich
 declaimed the following:


>I want to use a finite state machine (FSM) approach. There will be a supervisor module which will instantiate sub-modules which communicate with peripherals. Each sub-module will be a separate sub-FSM, reporting its state to the supervisor. Each sub-module will make use of a protocol library (e.g. MODBUS RTU) and a hardware driver library (e.g. UART over RS485/232) to communicate with devices.

	Your supervisor module will, in essence, be a minimal OS if it has to
handle switching among the I/O modules while also handling an upper level
application vs the "simpler" "direct" approach (if an application wants to
send something over a serial port, that is all it is doing until the
transaction is complete -- then it can look at some other device; or the
devices are all linked to an interrupt handler to collect inbound/transmit
outbound data through buffers that the application later reads/writes --
but that needs a protocol to identify when the application layer is allowed
to transfer data).

	They aren't cheap, and for being three volumes in a course sequence,
were written such that each duplicates most of the first third (how many
people working a microcontroller really need to see how to build a binary
full adder circuit from logic gates?) -- they also focus on the Texas
Instrument Launchpad boards -- but those are ARM Cortex-M4 so the
information should be portable.

http://www.amazon.com/Embedded-Systems-Introduction-Cortex-Microcontrollers/dp/1477508996/ref=sr_1_1?ie=UTF8&qid=1409231142&sr=8-1&keywords=valvano
http://www.amazon.com/Embedded-Systems-Real-Time-Interfacing-Microcontrollers/dp/1463590156/ref=sr_1_2?ie=UTF8&qid=1409231142&sr=8-2&keywords=valvano
http://www.amazon.com/Embedded-Systems-Real-Time-Operating-Microcontrollers/dp/1466468866/ref=sr_1_3?ie=UTF8&qid=1409231142&sr=8-3&keywords=valvano

	First and third may be the desired pair for your level. As mentioned,
the introductory material tends to be duplicated between them. Introduces
the ARM Cortex assembly language.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

On Thu, 28 Aug 2014 03:12:16 -0700 (PDT), Roy Emmerich wrote:

> I want to use a finite state machine (FSM) approach. There will be a
> supervisor module which will instantiate sub-modules which communicate
> with peripherals. Each sub-module will be a separate sub-FSM, reporting
> its state to the supervisor. Each sub-module will make use of a protocol
> library (e.g. MODBUS RTU) and a hardware driver library (e.g. UART over
> RS485/232) to communicate with devices.
> 
> That is it. No OS, no middleware.

It is difficult to imagine working. Do you know how ModBus function? It is
basically a client-server protocol. You send a request, e.g. F15 and then
read the response. Whether the request is a read or write request does not
matter. Most of ModBus end devices are half-duplex. Which means one request
at a time. Many have internal cycles and interlocking which make things
much slower than the physical I/O already did. Some would crash if you
queried too frequently.

Anyway, without an OS you will have to wait for the response to come, which
in turn, will block the whole application. It will be extremely slow.

One of the responsibilities of the OS and the middleware is to perform I/O
on things like ModBus in background without blocking the application and
other I/O. Even a very lame board is usually much faster than any ModBus
terminal.

In short, an OS-less design is not suitable for handling many peripheral
devices simultaneously, especially when the devices are attached over slow
asynchronous communication channels.

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

On Thursday, 28 August 2014 03:48:59 UTC+2, Dennis Lee Bieber  wrote:

> 	I wasn't referring to the three you mentioned -- but rather to your
> plaint that you wanted libraries for accessing various communications
> devices, etc.
> 
> 	THOSE libraries are probably being written for proprietary products in
> support of a higher level (though still minimal) OS --
> http://en.wikipedia.org/wiki/Integrated_modular_avionics -- The OS is in C
> or Ada, the processor board is provided with a board support package (BSP)
> that handles extremely low hardware access (driving GPIO,
> enabling/disabling memory management, other stuff), and libraries/drivers
> are written to provide an interface between the OS and the BSP. The BSP
> tends to come from the board manufacturer, the OS from somewhere else
> (Windriver, for example, or home-grown). By writing a new driver layer it
> is possible to rebuild the OS/applications on a new processor board without
> making changes to the high layers.
> 
> 	But those driver layers tend to only be useful in the environment (the
> application/OS) above them.

I have just read that Wikipedia link you sent. Wow! This is very high end stuff. I am not intending to control planes with my project.

My concept is actually very simple. Please, allow me to briefly explain:

I want to use a finite state machine (FSM) approach. There will be a supervisor module which will instantiate sub-modules which communicate with peripherals. Each sub-module will be a separate sub-FSM, reporting its state to the supervisor. Each sub-module will make use of a protocol library (e.g. MODBUS RTU) and a hardware driver library (e.g. UART over RS485/232) to communicate with devices.

That is it. No OS, no middleware.

I realise my approach probably goes against the grain of many classically trained computer scientists using Ada for highly critical systems. I'm largely self-taught and want to develop something quickly and simply for a very specific niche market a couple of levels above the tinkerer.

"Mike Silva"  wrote in message 
news:9620b2bd-9275-4273-b7ef-166c7227783b@googlegroups.com...
....
>Second is a brief comment I received from AdaCore, that they are looking at
>another tasking subset that removes some of the Ravenscar limitations while
>still allowing a small and fast bare-metal tasking implementation.  In my 
>own
>words, I think they are looking for another sweet spot re functionaliy vs 
>runtime
>complexity, one that will be useful to designers not requiring the 
>guarantees that
>Ravenscar allows.  It makes a lot of sense to think that there could be 
>other
>beneficial tasking/runtime profiles besides just Ravenscar and full Ada.

I know IRTAW (the people who designed Ravenscar in the first place) are 
considering a project like that. So that might not turn out to be an 
AdaCore-only thing, but rather an Ada thing.

                                      Randy. 

"Simon Clubley"  wrote in 
message news:ltqbhn$t94$1@dont-email.me...
> On 2014-08-29, Niklas Holsti  wrote:
....
> I have got to ask: how did Ravenscar ever get chosen for an Ada meeting
> place ?
>
> I can understand a place like (say) York, or another university town/city,
> but of all the places on the planet, how did a little coastal "town
> that never was" ever get chosen for an Ada meeting ?

I don't have any knowledge of how IRTAW picks it's meeting sites, but they 
do seem to pick smaller places for their meetings. I presume it was close to 
whoever was organizing it (probably someone from York).

Even ARG meetings have been held in some pretty weird places. There was one 
(before my time) held in Bennington, Vermont. And one held in Sydney, 
Canada. (Not to mention Madison, Wisconsin, but that doesn't seem weird to 
me. ;-) We've also met in Kemah, Texas, as well as Leuven, Belgium and 
Malloca, Spain, the latter of which I had to ask where the heck it was. (The 
former, I didn't have to ask because the meeting announcement included 
travel instructions.)

So unusual places aren't that unusual for Ada meetings, especially when one 
uses the names of suburbs rather than the nearby city.

                                            Randy.