Interfacing Ada With Full Runtime Directly to Electronic Chips

Interfacing Ada With Full Runtime Directly to Electronic Chips

[patrick]

Hi Everyone

Happy New Year!

Ada-AVR is a neat project and I am not knocking it. It doesn't have tasking support yet but this is of course a huge job.

If I want to connect any sort of computer running Linux directly to a circuit using "full Ada" with tasking support what are my options?

By circuit, I mean a variety of electronic components and in this case with no microcontroller, an A/D chip is a simple example.

I am thinking that single board computers like BeagleBone are my best bet, they have plenty of GPIO lines.

Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?

Is there any other options?

Thanks-Patrick

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dmitry A. Kazakov]

On 2017-01-02 03:42, patrick@spellingbeewinnars.org wrote:

> If I want to connect any sort of computer running Linux directly to
> a  circuit using "full Ada" with tasking support what are my options?
> By circuit, I mean a variety of electronic components and in this
> case  with no microcontroller, an A/D chip is a simple example.

I don't understand what you mean. Modern peripherals do not use 
dual-ported RAM, the only way you could have it connected without some 
sort of microcontroller.

> I am thinking that single board computers like BeagleBone are my
> best  bet, they have plenty of GPIO lines.
>
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO
> PCI card or GPIO-USB adapter ?

We access GPIO digital and analogue converters using Linux driver. 
Ada.Text_IO is basically all what is needed. Well, that's Linux. AFAIK, 
no decent Linux driver (with interrupts, IOCTL, asynchronous I/O) is 
available. But BB's AD/DA is garbage anyway. You could not use it 
without additional hardware which would in the end turn more expensive 
than other options.

> Is there any other options?

For quality I/O we are using EtherCAT and ModBus I/O terminals.

EtherCAT is very fast but extremely complicated. Don't believe people 
saying they have full EtherCAT stack implementations. That would be no 
more than a third of what is really needed to talk to complex terminals. 
I have implemented EtherCAT master myself.

ModBus is simple, the stack is free. Terminals are a bit sluggish. With 
the internal cycle of 3ms you cannot poll them faster than at 5ms. And 
if you have many of them it promptly becomes hundreds of milliseconds.

For both you will need tasking, of course.

There is 1-wire and OWFS. I didn't evaluate this option in depth but 
from the S/W design point of view it looks no better than GPIO text I/O. 
And it is not much cheaper than I/O terminals.

I would never use a USB adapter because of the nature of USB communication.

PCI card is out question for a BB.

Happy New Year!

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

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[patrick]

Hi Dmitry

Thanks yet again for your help and expertise.

Your suggestions are great and can help but let me give a little more background.

I have been servicing scientific instruments since 1999(or 1998 part time). I can repair them just fine but I have done very little circuit design. I have tinkered with the idea of building my own scientific instrument for years but I have always put it aside again due to the start up costs. I have figured out ways to lower these costs and the idea is back on again.

The circuits I work on feature tri-state logic and parallel digital buses. I want to use a serial bus instead. I don't have much hands on experience with SPI or IC2 but this is probably the way to go for communication with peripheral devices in-circuit.

I find myself in a strange place. I like Ada and I would like to use it for embedded design. It has everything that someone might need for controlling chips yet in the 53lsb of Ada books that I have printed or bought, I can't find a single example of someone doing this.

It seems to be used as embedded middleware most of the time. Jeol makes mass spectrometers and uses Ada as they were featured in an Adacore video:

https://www.youtube.com/watch?v=NiO7OOmwlrc

but I haven't worked with their instruments specifically and I am not sure how they control their circuits and if it's just C controlling peripherals.

Every single instrument I have worked with and this is well into the hundreds, is controlled by Windows(which could still be Ada) but I would like to uses Posix and probably Linux.

Every single instrument uses either a microcontroller or embedded processor with a small amount of external RAM and Firmware, nothing close to a computer with full OS at least not to my knowledge.

I was thinking that a single board computer with GPIO that ran Linux could still interface directly with a circuit through on-board GPIO pins. This would be a huge departure from the instruments I have worked on already and is a bit scary for a first design. However it would also provide valuable tools and might shorten the design period.


What does your GPIO setup look like? Is it not PCI based? Could you tell me more.

EtherCat and ModBus look fine but would this mean that Ada would end up as middleware with a C based microcontroller the likely product on the other end. I am hoping to stick to a solution without this.

Thanks for your input on quality issues too, this is priceless as this information is actually quite hard to find.

Happy new year to you too! -Patrick

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dmitry A. Kazakov]

On 2017-01-02 14:28, patrick@spellingbeewinnars.org wrote:

> Your suggestions are great and can help but let me give a little more background.
>
> I have been servicing scientific instruments since 1999(or 1998 part
> time). I can repair them just fine but I have done very little circuit
> design. I have tinkered with the idea of building my own scientific
> instrument for years but I have always put it aside again due to the
> start up costs. I have figured out ways to lower these costs and the
> idea is back on again.
>
> The circuits I work on feature tri-state logic and parallel digital
> buses. I want to use a serial bus instead. I don't have much hands on
> experience with SPI or IC2 but this is probably the way to go for
> communication with peripheral devices in-circuit.

Probably

> I find myself in a strange place. I like Ada and I would like to use
> it for embedded design. It has everything that someone might need for
> controlling chips yet in the 53lsb of Ada books that I have printed or
> bought, I can't find a single example of someone doing this.

Regardless how you wire your custom device to the main board you need a 
driver to deal with it.

> It seems to be used as embedded middleware most of the time. Jeol
> makes mass spectrometers and uses Ada as they were featured in an
> Adacore video:
>
> https://www.youtube.com/watch?v=NiO7OOmwlrc

Embedded as "bare board" or embedded as "small"?

> Every single instrument I have worked with and this is well into the
> hundreds, is controlled by Windows(which could still be Ada) but I would
> like to uses Posix and probably Linux.

Instrument as "a [small] computer" or as "a controller/adapter/useless 
junk if unconnected etc"

> Every single instrument uses either a microcontroller or embedded
> processor with a small amount of external RAM and Firmware, nothing
> close to a computer with full OS at least not to my knowledge.

That depends on the instrument. Some consist of not one but multiple 
full blown computers.

> I was thinking that a single board computer with GPIO that ran Linux
> could still interface directly with a circuit through on-board GPIO
> pins. This would be a huge departure from the instruments I have worked
> on already and is a bit scary for a first design. However it would also
> provide valuable tools and might shorten the design period.

That will need an interface to the outside world and an interface to the 
circuit.

> What does your GPIO setup look like?

Under Linux it is a virtual file system with a text file for each DIO 
pin. For AIO it is several virtual file system files. This stuff is 
provided through the standard Linux driver.

> Is it not PCI based? Could you tell me more.

BB does not have PCI.

In any case you have to write a driver to allow applications access the 
circuit. At least one application must run the outside-world interface 
allowing external PCs to communicate with the instrument. A network 
based interface is usually the best choice.

    [ PC ] <--- Ethernet interface ---> [ BB ]

Within the BB:

    [ Application ]
          |
       driver
          |
    [ SPI or other bus ]
          |
        wiring
          |
    [ Circuit ]

The driver represents the data in the desired form (device class). E.g. 
GPIO Linux driver represents GPIO pins as virtual files. Reading that 
file causes scanning the pin potential. CAN controller driver represents 
CAN messages exchange as a socket [SocketCAN]. The device class choice 
is up to you and the nature of data.

> EtherCat and ModBus look fine but would this mean that Ada would end
> up as middleware with a C based microcontroller the likely product on
> the other end. I am hoping to stick to a solution without this.

No, I don't suggested making your instrument an EtherCAT terminal. 
Though there are solutions for that too. Beckhoff sells small boards 
with EtherCAT slave stack and SPI you could use to attach your circuit. 
But you could not program that thing in Ada.

I thought you wanted to attach something like a digital input or 
incremental encoder. Forget it.

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

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[patrick]

Thanks again Dmitry and thanks everyone, this will keep me busy for some time-Patrick

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Shark8]

On Monday, January 2, 2017 at 6:28:50 AM UTC-7, pat...@spellingbeewinnars.org wrote:
>
> I have been servicing scientific instruments since 1999(or 1998 part time). I can repair them just fine but I have done very little circuit design. I have tinkered with the idea of building my own scientific instrument for years but I have always put it aside again due to the start up costs. I have figured out ways to lower these costs and the idea is back on again.

Nice.  
I'm looking into starting up manufacturing -- see: https://groups.google.com/forum/#!topic/comp.lang.ada/CYOHKtbeokA -- it involves some custom HW, designed from the ground up with formal methods and security.

> 
> The circuits I work on feature tri-state logic and parallel digital buses. I want to use a serial bus instead. I don't have much hands on experience with SPI or IC2 but this is probably the way to go for communication with peripheral devices in-circuit.

That's really interesting, because the system I want to do [ultimately] is a ternary computer -- for which tri-state logic is a perfect fit.

> 
> I find myself in a strange place. I like Ada and I would like to use it for embedded design. It has everything that someone might need for controlling chips yet in the 53lsb of Ada books that I have printed or bought, I can't find a single example of someone doing this.

Hm, really, not a single reference?

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dmitry A. Kazakov]

On 2017-01-03 06:33, Shark8 wrote:

> That's really interesting, because the system I want to do
> [ultimately] is a ternary computer -- for which tri-state logic is a
> perfect fit.

Out of curiosity, why tri-state logic and not full four-state one? 
Tri-state is incomplete in some operations (e.g. in implication).

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

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Shark8]

On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
> On 2017-01-03 06:33, Shark8 wrote:
> 
> > That's really interesting, because the system I want to do
> > [ultimately] is a ternary computer -- for which tri-state logic is a
> > perfect fit.
> 
> Out of curiosity, why tri-state logic and not full four-state one? 
> Tri-state is incomplete in some operations (e.g. in implication).

The completeness of the logic-system depends on which logic-system is being used -- there are several for three-valued logic -- but it is a non-issue because you can use full Boolean logic (e.g.) by defining 0 to be True and ±1 to be False (i.e. using inverse-logic).*

There are some advantages to using a trinary system as well: balanced ternary eliminates the need for an adjust-step like 2's complement has because negative and positive numbers share a representation, simpler construction of components (eg a not-gate can be done with a single transistor, instead of two transistors like a binary computer has), and certain operations become simpler as well (eg rounding and truncation are the same operation in balanced-ternary).

* While you might think that this is wasting the states, it need not. Consider the situation where where you have several related binary operations in a decision-tree -- by structuring your operator correctly you can reduce the number of comparisons needed. Example:

IF a And b THEN
 Procedure_1;
ELSIF a Or b THEN
 Procedure_2;
ELSE
 Procedure_3;
END IF;

We can represent the above with a single operator -- the only time the first condition is true is when both inputs are true (a=0,b=0 ==> 0), then in the second condition things are only true when a=0 [x]or b=0, so we 'commandeer' one of the false-values to represent "condition 1 is false, but true for condition 2", in this case choosing '1' for that value, and the remaining states get the other false-value ('J', so that the table below looks correct w/ monospaced font)
   |a=1|a=0|a=J
b=1| J | 1 | J 
b=0| 1 | 0 | 1 
b=J| J | 1 | J 

So there you have it -- demonstrable proof that the ternary system can simplify even code-implementation -- as the above combines two conditions into a single operator. (The same thing can be done when you want to check both 'implies' and whether or not the first operand was true, see the table below.)

   |a=1|a=0|a=J
b=1| 1 | J | 1 
b=0| 1 | 0 | 1 
b=J| 1 | J | 1 

corresponds to

IF a And b THEN
  statements;
ELSIF a >= b THEN -- Implies(a, b)
 statements;
ELSE
 statements;
END IF;

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dmitry A. Kazakov]

On 2017-01-03 19:02, Shark8 wrote:
> On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
>> On 2017-01-03 06:33, Shark8 wrote:
>>
>>> That's really interesting, because the system I want to do
>>> [ultimately] is a ternary computer -- for which tri-state logic is a
>>> perfect fit.
>>
>> Out of curiosity, why tri-state logic and not full four-state one?
>> Tri-state is incomplete in some operations (e.g. in implication).
>
> The completeness of the logic-system depends on which logic-system
> is  being used -- there are several for three-valued logic -- but it is a
> non-issue because you can use full Boolean logic (e.g.) by defining 0 to
> be True and ±1 to be False (i.e. using inverse-logic).*

[...]

I see, it is just a ternary system and not logic in the sense of lattice 
and inference, like {False, True, Unknown}.

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

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Shark8]

On Tuesday, January 3, 2017 at 1:34:31 PM UTC-7, Dmitry A. Kazakov wrote:
> On 2017-01-03 19:02, Shark8 wrote:
> > On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
> >> On 2017-01-03 06:33, Shark8 wrote:
> >>
> >>> That's really interesting, because the system I want to do
> >>> [ultimately] is a ternary computer -- for which tri-state logic is a
> >>> perfect fit.
> >>
> >> Out of curiosity, why tri-state logic and not full four-state one?
> >> Tri-state is incomplete in some operations (e.g. in implication).
> >
> > The completeness of the logic-system depends on which logic-system
> > is  being used -- there are several for three-valued logic -- but it is a
> > non-issue because you can use full Boolean logic (e.g.) by defining 0 to
> > be True and ±1 to be False (i.e. using inverse-logic).*
> 
> [...]
> 
> I see, it is just a ternary system and not logic in the sense of lattice 
> and inference, like {False, True, Unknown}.

You can model True/False/Unknown -- just map each value to one of {1,0,J}, obviously.

But how would a lattice & inference system look? Esp. at the gate-level.

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dmitry A. Kazakov]

On 2017-01-03 21:50, Shark8 wrote:
> On Tuesday, January 3, 2017 at 1:34:31 PM UTC-7, Dmitry A. Kazakov wrote:
>> On 2017-01-03 19:02, Shark8 wrote:
>>> On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
>>>> On 2017-01-03 06:33, Shark8 wrote:
>>>>
>>>>> That's really interesting, because the system I want to do
>>>>> [ultimately] is a ternary computer -- for which tri-state logic is a
>>>>> perfect fit.
>>>>
>>>> Out of curiosity, why tri-state logic and not full four-state one?
>>>> Tri-state is incomplete in some operations (e.g. in implication).
>>>
>>> The completeness of the logic-system depends on which logic-system
>>> is  being used -- there are several for three-valued logic -- but it is a
>>> non-issue because you can use full Boolean logic (e.g.) by defining 0 to
>>> be True and ±1 to be False (i.e. using inverse-logic).*
>>
>> [...]
>>
>> I see, it is just a ternary system and not logic in the sense of lattice
>> and inference, like {False, True, Unknown}.
>
> You can model True/False/Unknown -- just map each value to one of {1,0,J}, obviously.

Maybe

> But how would a lattice & inference system look? Esp. at the gate-level.

Logic gates? A lattice has "and", "or", "not", obeying de Morgan rules. 
They are same as Boolean when arguments are Boolean. E.g. the truth 
table for "and":

and F T U
--+------
F | F F F
T | F T U
U | F U U

I understood that this has little (if anything at all) to do with the 
system you had in mind. The similarity of names is coincidental.

Considering flow of control in a logical system with "unknown" state. 
Let you have

    if A and B then
       S1;
    else
       S2;
    end if;

Let A = U and B = T. Then A and B = U. So both S1 and S2 must be 
evaluated but their side effects kept aside until some point, where you 
become certain what path was to choose. Then you commit the effects of 
this only path.

In fuzzy systems it is called defuzzification. I am not familiar with 
quantum computing, but I guess it is kind of similar to this. You 
"calculate" all possible states and at some point collapse all of them 
into just one.

Now if you had a forth state you wold follow no path if A and B would 
evaluate it. So it is "one"/true, "another"/false, "any", "none", a 
complete set of choices.

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

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Brian Drummond]

On Sun, 01 Jan 2017 18:42:04 -0800, patrick wrote:

> Hi Everyone
> 
> Happy New Year!
> 
> Ada-AVR is a neat project and I am not knocking it. It doesn't have
> tasking support yet but this is of course a huge job.

There are ARM-Cortex development boards with a bit more resources, and 
Ada support including (Ravenscar) tasking, either bare-bones or over a 
small RTOS.

Look for work by Simon Wright in respect of these. 

Much simpler than Beaglebone, but not full Linux. 

Interfacing to hardware isn't difficult. Generally you abstract the 
hardware level into a package which knows where the register addresses 
are, and different (related) targets use different implementations of the 
packages.

For full Linux, I'd look at the Raspberry Pi. But then you get involved 
in writing device drivers - there's a project on the first steps on 
writing Linux device drivers in Ada, but it's more complex, and not as 
well trodden as Linux device drivers in C.

-- Brian

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Dennis Lee Bieber]

On Sun, 1 Jan 2017 18:42:04 -0800 (PST), patrick@spellingbeewinnars.org
declaimed the following:

>
>Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?
>
	Off hand, I'm fairly certain a simple USB to GPIO adapter won't do. Too
many timing idiosyncrasies for those protocols. The adapter would have to
have SPI or I2C (?) protocol logic at the far end, and the USB would be
transferring already processed protocol transfers.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Simon Wright]

patrick@spellingbeewinnars.org writes:

> If I want to connect any sort of computer running Linux directly to a
> circuit using "full Ada" with tasking support what are my options?
>
> By circuit, I mean a variety of electronic components and in this case
> with no microcontroller, an A/D chip is a simple example.
>
> I am thinking that single board computers like BeagleBone are my best
> bet, they have plenty of GPIO lines.
>
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO
> PCI card or GPIO-USB adapter ?
>
> Is there any other options?

You can talk I2C from a Raspberry Pi; see [1], [2]. It was simple to
install GNAT etc from libre.adacore.com, since Raspbian is a Debian
offshoot.

Beaglebone also supports Debian, see [3] for a report on this.

Both of the above use OS device support via file read/write/ioctl. If
you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
STMicroelectronics (e.g. [7]).

The AdaCore runtimes support Ravenscar tasking[8] and come in two
flavours, small footprint (-sfp-) and full (-full-). The -full- version
supports exception handling and finalization and includes
Ada.Numerics. Neither support containers (easy enough to copy into the
-full- version, I expect).

The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
full-GPL license. If this matters to you I have runtimes for Arduino Due
and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
Library Exception, allowing release of code on proprietary terms.

Just to indicate the flavour of this bare-metal code, I have some SPI
code for an STM32F427, using interface code generated by AdaCore's
SVD2Ada[10], at [11].

[1] https://sourceforge.net/projects/raspi-i2c-ada/
[2] http://raspi-i2c-ada.sourceforge.net
[3] https://groups.google.com/forum/#!topic/beagleboard/O5AU2XL6NJ8
[4] https://github.com/AdaCore/Ada_Drivers_Library
[5] https://sourceforge.net/projects/gnuada/files/GNAT_GPL%20Mac%20OS%20X/2016-arm-eabi-darwin-bin/
[6] https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/6.1.0/arm-eabi/
[7]
http://uk.farnell.com/stmicroelectronics/stm32f407g-disc1/dev-board-foundation-line-mcu/dp/2506840
[8] https://en.wikipedia.org/wiki/Ravenscar_profile
[9] https://sourceforge.net/projects/cortex-gnat-rts/
[10] https://github.com/AdaCore/svd2ada
[11] https://github.com/simonjwright/multiplexed-io/blob/master/drivers/spi1/src/spi1-device.adb

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[patrick]

Thanks Brian

And thanks Simon!

This will take a full day to read through properly, wow!

Thanks very much-Patrick

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[antispam]

Simon Wright <simon@pushface.org> wrote:
> 
> Both of the above use OS device support via file read/write/ioctl. If
> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
> STMicroelectronics (e.g. [7]).
> 
> The AdaCore runtimes support Ravenscar tasking[8] and come in two
> flavours, small footprint (-sfp-) and full (-full-). The -full- version
> supports exception handling and finalization and includes
> Ada.Numerics. Neither support containers (easy enough to copy into the
> -full- version, I expect).
> 
> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
> full-GPL license. If this matters to you I have runtimes for Arduino Due
> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
> Library Exception, allowing release of code on proprietary terms.

IIUC STM runtimes are incompatible with GPL.  So combining them
with GPL runtime means that result can not be distributed at
all.

-- 
                              Waldek Hebisch

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[Simon Wright]

antispam@math.uni.wroc.pl writes:

> Simon Wright <simon@pushface.org> wrote:
>> 
>> Both of the above use OS device support via file read/write/ioctl. If
>> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
>> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
>> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
>> STMicroelectronics (e.g. [7]).
>> 
>> The AdaCore runtimes support Ravenscar tasking[8] and come in two
>> flavours, small footprint (-sfp-) and full (-full-). The -full- version
>> supports exception handling and finalization and includes
>> Ada.Numerics. Neither support containers (easy enough to copy into the
>> -full- version, I expect).
>> 
>> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
>> full-GPL license. If this matters to you I have runtimes for Arduino Due
>> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
>> Library Exception, allowing release of code on proprietary terms.
>
> IIUC STM runtimes are incompatible with GPL.  So combining them
> with GPL runtime means that result can not be distributed at
> all.

Do you have a reference for this? the STM source licence that I see in
the STM32Cube firmware releases imposes very few restrictions on the
actual use of the software, only requiring inclusion of the STM
copyright notice. There's nothing like the restriction quoted in [1].

But in any case the RTS I'm talking about doesn't use any STM code, just
FreeRTOS. Which uses a GPLv2 licence, which doesn't include the usual
"or later version" test. Which may be a problem.

[1] https://github.com/d-ronin/dRonin/issues/928

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[antispam]

Simon Wright <simon@pushface.org> wrote:
> antispam@math.uni.wroc.pl writes:
> 
> > Simon Wright <simon@pushface.org> wrote:
> >> 
> >> Both of the above use OS device support via file read/write/ioctl. If
> >> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
> >> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
> >> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
> >> STMicroelectronics (e.g. [7]).
> >> 
> >> The AdaCore runtimes support Ravenscar tasking[8] and come in two
> >> flavours, small footprint (-sfp-) and full (-full-). The -full- version
> >> supports exception handling and finalization and includes
> >> Ada.Numerics. Neither support containers (easy enough to copy into the
> >> -full- version, I expect).
> >> 
> >> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
> >> full-GPL license. If this matters to you I have runtimes for Arduino Due
> >> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
> >> Library Exception, allowing release of code on proprietary terms.
> >
> > IIUC STM runtimes are incompatible with GPL.  So combining them
> > with GPL runtime means that result can not be distributed at
> > all.
> 
> Do you have a reference for this? the STM source licence that I see in
> the STM32Cube firmware releases imposes very few restrictions on the
> actual use of the software, only requiring inclusion of the STM
> copyright notice. There's nothing like the restriction quoted in [1].
> 
> But in any case the RTS I'm talking about doesn't use any STM code, just
> FreeRTOS. Which uses a GPLv2 licence, which doesn't include the usual
> "or later version" test. Which may be a problem.
> 
> [1] https://github.com/d-ronin/dRonin/issues/928

I did not look at STM32Cube (they make download awkward and I do
not need most of it).  Most of parts that I was able to
download outside of STM32Cube contain the restriction to
STM devices mentioned in [1].  AFAICS some STM libraries
are only available as C headers + binary blob.

Good to hear that you are independent of STM code.

-- 
                              Waldek Hebisch

Re: Interfacing Ada With Full Runtime Directly to Electronic Chips

[philip.munts]

On Monday, January 2, 2017 at 3:42:06 AM UTC+1, pat...@spellingbeewinnars.org wrote:
> Hi Everyone
> 
> Happy New Year!
> 
> Ada-AVR is a neat project and I am not knocking it. It doesn't have tasking support yet but this is of course a huge job.
> 
> If I want to connect any sort of computer running Linux directly to a circuit using "full Ada" with tasking support what are my options?
> 
> By circuit, I mean a variety of electronic components and in this case with no microcontroller, an A/D chip is a simple example.
> 
> I am thinking that single board computers like BeagleBone are my best bet, they have plenty of GPIO lines.
> 
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?
> 
> Is there any other options?
> 
> Thanks-Patrick

I suggest my own Linux Simple I/O Library (http://git.munts.com/libsimpleio).  It provides Pascal calling sequence wrappers around the Linux system calls for I2C, SPI, UART, and raw HID devices and includes some shim packages for GNAT.

I have tested it with both native and cross compilers on the BeagleBones Black and Green and Raspberry Pi 2 and 3.  I use it mostly with the Raspberry Pi 2 cross toolchain (which also works fine for the BeagleBone family) from AdaCore and targeted to my own embedded Linux distribution called MuntsOS (http://git.munts.com/arm-linux-mcu).

I also have a collection of packages and example programs for various Mikroelektronika click boards and Raspberry Pi hats that are not published yet.  I am in the middle of writing a paper about this very topic.

Phil