Ada, the best language with the not-so-best tool chain

[Patrick]

I think Ada is the best language ever. I have a subset I like now(just 95 really ) and I find it so easy to read other peoples Ada code.

However.. I am I think all this goodness has come with a price. A difficult to implement language.

I wanted to use it for embedded design(as in baremetal) but no free of cost version lets me do that.

There is a new driver tutorial out for Minix3 and I was thinking about writing a driver but I can't do that either. There is no gnat on Minix and you can't cross compile for minix from Windows/Linux etc.. so I don't know how to get ada on it...

So basically I have Linux/BSD/Windows/OpenIndiana but these are all pretty heavy and quite complex relative to RTOS or Minix3.

Actually it does not really matter what /*I want */ the community as a whole doesn't have enough options when compared to C.

No solution will be easy but I was hoping to start a hypothetical discussion on solutions.

For instance:

1)If we had a Ada runtime written in C, then we could cross compile with GCC as-is no?

2)ASM is not really portable but surely some flavours must be, If we had a converter, we could cross compile at the ASM stage no?

I have only two :(

Does anyone have some more ideas?

[Dmitry A. Kazakov]

On Sun, 7 Oct 2012 10:34:51 -0700 (PDT), Patrick wrote:

> I wanted to use it for embedded design(as in baremetal) but no free of
> cost version lets me do that.

Why would you expect that? I mean the evaluation board, BSP, C cross
compiler, they are not free. Why Ada compiler should be?

> There is a new driver tutorial out for Minix3 and I was thinking about
> writing a driver but I can't do that either. There is no gnat on Minix and
> you can't cross compile for minix from Windows/Linux etc.. so I don't know
> how to get ada on it...

Ask AdaCore or switch to VxWorks. Neither would be for free, of course.

> No solution will be easy but I was hoping to start a hypothetical discussion on solutions.
>
> For instance:
>
> 1)If we had a Ada runtime written in C, then we could cross compile with GCC as-is no?

No

> 2)ASM is not really portable but surely some flavours must be, If we had a
> converter, we could cross compile at the ASM stage no?

No

> I have only two :(
>
> Does anyone have some more ideas?

3) Don't buy any hardware for which there is no Ada compiler. It is
economically infeasible unless you are going to ship thousands of boards.
In the latter case, you would have enough funding to order a BSP and an Ada
compiler for it.

There is a mental block most people have. They see only the hardware,
assuming software kind of non-essential. But the costs of software
developing, testing and maintenance are far bigger than ones of the
hardware. Except for hard physical constraints (e.g. power consumption,
weight, durability etc), hardware choice is subordinate.

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

[Shark8]

On Sunday, October 7, 2012 11:34:51 AM UTC-6, Patrick wrote:
>
> 1)If we had a Ada runtime written in C, then we could cross compile with GCC as-is no?

Maintenance would quickly become a nightmare. Just yesterday there was someone talking about a large project and having difficulty with porting it to gnat/gcc 4.6 [IIRC] and the people in charge of the project are debating porting the code to C/C++... only they don't realize that the only portion of the project that's giving them trouble *is* the small portion written in C/C++. -- The reason the runtime is written in Ada is precisely to avoid multi-language dependence; yes you have the added trouble of bootstrapping, but the payoff is that your tools become independent of flaws in other tools.

> 2)ASM is not really portable but surely some flavours must be, If we had a converter, we could cross compile at the ASM stage no?

See the above.

[Patrick]

Thanks Dimitry

Now I can see where you are coming from but 11 months ago I had no idea that Ada, the language designed for embedded work, was not able to be embedded via GCC and was largely confined to the desktop unless the programmer or his/her company is quite wealthy. Others have mentioned the disconnect as well.

THanks for the feedbaack Shark8

[Niklas Holsti]

On 12-10-07 20:34 , Patrick wrote:
> I think Ada is the best language ever. I have a subset I like
> now(just 95 really ) and I find it so easy to read other peoples Ada
> code.

Nice to hear. For me, being able to easily read my own code, written a
few years ago, is also important :-)

> However.. I am I think all this goodness has come with a price. A
> difficult to implement language.
>
> I wanted to use it for embedded design(as in baremetal) but no free
> of cost version lets me do that.

AVR-Ada? Or GNAT for AVR? Granted, there is no tasking... Or MaRTE OS,
that has tasking, but it is only for x86 targets. Well, you can get
pretty small x86 systems for embedded applications.
http://marte.unican.es/index.htm.

> There is a new driver tutorial out for Minix3 and I was thinking
> about writing a driver but I can't do that either. There is no gnat
> on Minix and you can't cross compile for minix from Windows/Linux
> etc.. so I don't know how to get ada on it...

You could use the Ada-to-C version of the AdaMagic compiler. But it is
not free. However, I'm sure that there are lots of languages that are
not available on Minix3, so Ada is not alone...

Minix3 claims to supports POSIX, gcc, a cross-compiling gcc
(http://wiki.minix3.org/en/DevelopersGuide/Crosscompiling), and the
binary format is ELF. This suggests to me that a port of GNAT may be no
more difficult than for some Unix-like system.

> So basically I have Linux/BSD/Windows/OpenIndiana but these are all
> pretty heavy and quite complex relative to RTOS or Minix3.
>
> Actually it does not really matter what /*I want */ the community as
> a whole doesn't have enough options when compared to C.

Many of us want or wish for free or low-cost Ada systems on bare-metal
microcontrollers; we have GNAT on AVR and MaRTE OS on x86. My favourite
for a target would be ARM Cortex M0-M4.

> No solution will be easy but I was hoping to start a hypothetical
> discussion on solutions.
>
> For instance:
>
> 1)If we had a Ada runtime written in C, then we could cross compile
> with GCC as-is no?

No. Standard (portable) C does not have all the features needed for an
Ada run-time, in particular for tasking. POSIX could help on the tasking
part. But since the system needs an Ada compiler anyway, we might as
well or better write the run-time in Ada. There already are free
run-times: the Open Ravenscar Kernel ORK, and the run-time system in
MaRTE OS.

> 2)ASM is not really portable but surely some flavours must be, If we
> had a converter, we could cross compile at the ASM stage no?

In theory, yes. In practice, it seems quite difficult for an
assembly-level or binary-level translator from machine A to machine B to
translate dependencies and uses of the run-time environment, which is
very machine-specific in its details. It would probable be simpler to
write an emulator for machine A, using some programming language
available on machine B, thus creating a virtual A-machine running in the
B-machine. That would of course slow down programs by some factor.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[Simon Clubley]

On 2012-10-07, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
> On Sun, 7 Oct 2012 10:34:51 -0700 (PDT), Patrick wrote:
>
>> I wanted to use it for embedded design(as in baremetal) but no free of
>> cost version lets me do that.
>
> Why would you expect that? I mean the evaluation board, BSP, C cross
> compiler, they are not free. Why Ada compiler should be?
>

The hardware costs money, but it's the only thing in that list which
you are forced to pay money for.

gcc/binutils/gdb, as well as been a native toolchain, is also a cross
compiler capable toolchain.

RTEMS provides support for using Ada on ARM boards (if you are willing
to run under a RTOS instead of bare metal) and there are plenty of
example BSPs in the RTEMS source kit for you to use as a template for
your own BSP.

If you want true bare metal, then there is a port of GNAT for AVR.

So, while the embedded options for Ada with gcc are not nearly as
numerous as those for pure C, they do exist.

Someone here in c.l.a has also done some work on making GNAT run on
bare metal ARM boards. I do not know the current status of that work.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Dmitry A. Kazakov]

On Sun, 7 Oct 2012 13:21:52 -0700 (PDT), Patrick wrote:

> Now I can see where you are coming from but 11 months ago I had no idea
> that Ada, the language designed for embedded work, was not able to be
> embedded via GCC and was largely confined to the desktop unless the
> programmer or his/her company is quite wealthy.

Remember that Ada was designed 80's. Embedded changed drastically since
then. The "embedded" we do today is unthinkable without Ethernet and TCP/IP
stack, tasking support, USB and flash support, high-resolution clock. That
means a full-scale OS. To have a compiler for such a target is rather a
minor problem. Ada run-time, tons of drivers for the OS, the loader are
greater troubles.

Embedded became bigger than one-man hobby project. If that didn't scare
you, let you invested 10+ years in a board, which definitely will be out of
stock in just 2-5 years to come? What then? It just does not make sense
anymore. Sorry.

Why don't you buy a single board x86 PC, which could be under 30 EUR,
install Linux on it and spare most of the headache?

[Dmitry A. Kazakov]

On Sun, 7 Oct 2012 22:35:23 +0000 (UTC), Simon Clubley wrote:

> The hardware costs money, but it's the only thing in that list which
> you are forced to pay money for.

Yes, exactly this attitude.

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
> On Sun, 7 Oct 2012 13:21:52 -0700 (PDT), Patrick wrote:
>
>> Now I can see where you are coming from but 11 months ago I had no idea
>> that Ada, the language designed for embedded work, was not able to be
>> embedded via GCC and was largely confined to the desktop unless the
>> programmer or his/her company is quite wealthy.
>
> Remember that Ada was designed 80's. Embedded changed drastically since
> then. The "embedded" we do today is unthinkable without Ethernet and TCP/IP
> stack, tasking support, USB and flash support, high-resolution clock. That
> means a full-scale OS. To have a compiler for such a target is rather a
> minor problem. Ada run-time, tons of drivers for the OS, the loader are
> greater troubles.
>

What you describe above is the "big system" embedded type projects.

There are plenty of standalone embedded projects where bare metal
programming (or a small RTOS) and a 8-bit or low end 32-bit MCU is
perfectly acceptable and a appropriate choice.

BTW, do you actually do any embedded work, either professionally or as a
hobbyist ?

> Embedded became bigger than one-man hobby project. If that didn't scare
> you, let you invested 10+ years in a board, which definitely will be out of
> stock in just 2-5 years to come? What then? It just does not make sense
> anymore. Sorry.
>

How do you know he's doing this professionally instead of as a learning
exercise ?

> Why don't you buy a single board x86 PC, which could be under 30 EUR,
> install Linux on it and spare most of the headache?
>

How do you know such a board will meet his power consumption, form factor
and real time requirements ?

[kalvi...@gmail.com]

Ditto, I would like to see a bare metal LGPL Ada for ARM M0-M4 devices.

- Kalvin

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
> On Sun, 7 Oct 2012 22:35:23 +0000 (UTC), Simon Clubley wrote:
>
>> The hardware costs money, but it's the only thing in that list which
>> you are forced to pay money for.
>
> Yes, exactly this attitude.
>

[I'm a professional programmer, but my use of Ada is strictly limited to
my personal own time hobbyist projects unfortunately.]

The Ada community has a choice to make.

Do you want to encourage new blood to start using Ada and hence help
ensure the future of Ada or do you want to put down the efforts of
people expressing interest in Ada because they don't do things exactly
the way you would when you have a few million USD/Euro/GBP to throw at
a project ?

Dmitry's responses in this thread have made me annoyed because they
show a lack of understanding of the requirements and mindset of people
exploring Ada and embedded systems for the first time on their own
budget.

Ada is a good language and deserves to be used much more heavily than
it is, but, regardless of all other efforts you might make, that will
not happen unless you make the Ada community a welcoming place for
newcomers.

If someone new to, say, the embedded world, is made aware that Ada is
a option then the first thing they are going to do is look to see what
community resources are available for this "new thing called Ada".

If they see a friendly community they are liable to start asking questions
and consider Ada more seriously. If they see a group of people who like
to respond with distain because the newcomer wants to do their hobby
projects using free resources when possible, then guess what, they will
move to another non-Ada option where they are made welcome.

Those other options may not be as good as Ada, but they can be made to do
the job, and those other options are what a person will think about when
they move into the workplace.

The way you go about performing a hobby project is not the way you go
about performing a safety critical project, but unless you encourage
people to start using Ada in a hobby environment, you are not going to
have a pool of people aware of, and willing to use, Ada when they enter
the workplace.

[Georg Bauhaus]

On 08.10.12 09:31, Dmitry A. Kazakov wrote:
> Embedded became bigger than one-man hobby project.

Looking for embedded stuff around here, there is an electronic
$10,- scale. It happens to have destructive software built in.
(The scale refuses to operate now, resetting does not have any
effect.)
It does not have inputs or outputs, except maybe hidden on
its main boards, which measures about 2cm x 1cm, but I cannot
easily take a look.

Another item with digital electronics embedded is an older battery
charger that has an RS 232 serial connector. If you know the
prices of contemporary battery chargers then you know there
cannot be any $30,- PC hardware in it.

And we have a microwave oven. I doubt it has ethernet, although it
seems a likely candidate, given all the attempts at home automation;
I'm also guessing that it's got a very moderate, yet capable micro
controller in it, not a PC. (The user may operate 13 buttons and
two rotary knobs, and watch an LCD display.) Do microwave ovens
have HiRes timers?

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 11:28:56 +0000 (UTC), Simon Clubley wrote:

> On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>> On Sun, 7 Oct 2012 13:21:52 -0700 (PDT), Patrick wrote:
>>
>>> Now I can see where you are coming from but 11 months ago I had no idea
>>> that Ada, the language designed for embedded work, was not able to be
>>> embedded via GCC and was largely confined to the desktop unless the
>>> programmer or his/her company is quite wealthy.
>>
>> Remember that Ada was designed 80's. Embedded changed drastically since
>> then. The "embedded" we do today is unthinkable without Ethernet and TCP/IP
>> stack, tasking support, USB and flash support, high-resolution clock. That
>> means a full-scale OS. To have a compiler for such a target is rather a
>> minor problem. Ada run-time, tons of drivers for the OS, the loader are
>> greater troubles.
>
> What you describe above is the "big system" embedded type projects.

Yes.

> There are plenty of standalone embedded projects where bare metal
> programming (or a small RTOS) and a 8-bit or low end 32-bit MCU is
> perfectly acceptable and a appropriate choice.
>
> BTW, do you actually do any embedded work, either professionally or as a
> hobbyist ?

Professionally. We have an embedded middleware project (100% Ada 2005). It
must be "big" because industrial hardware protocols are big (EtherCAT, XCP,
CANOpen etc). Not much chance to stuff that into a bare-bone. Automotive is
moving away from bare bone anyway (e.g. AUTOSAR).

>> Embedded became bigger than one-man hobby project. If that didn't scare
>> you, let you invested 10+ years in a board, which definitely will be out of
>> stock in just 2-5 years to come? What then? It just does not make sense
>> anymore. Sorry.
>
> How do you know he's doing this professionally instead of as a learning
> exercise ?

In that case I would suggest that making some obscure board working is not
worth learning. There is much more exciting stuff to learn about Ada,
real-time, automation/control, hardware interfacing issues.

>> Why don't you buy a single board x86 PC, which could be under 30 EUR,
>> install Linux on it and spare most of the headache?
>>
>
> How do you know such a board will meet his power consumption, form factor
> and real time requirements ?

By reading the specifications? Yes, physical constraints do exist. But I
guess they are not much relevant for a hobby/learning project. For anything
serious one would likely change boards many times. Hardware is a very short
living thing. One of the major reasons why we did it in Ada was because we
knew in advance that we would have to port our stuff so frequently. In 5
years there will be other boards available, smaller, faster etc. The
strength of Ada is that you need not choose it now.

[Dmitry A. Kazakov]

If you were a vendor of microwave herds, I bet you would have money to buy
a license from AdaCore. You could even afford developing an Ada 2012
compiler from scratch. (:-))

It all about how many boards come in question and how complex the software
has to be. One of our customers develops all software from scratch for each
new device. When we asked them, would not it be better to have a portable
layer for the stuff, they answered that by the numbers they have in
production, they need not to care about software costs...

[Patrick]

so again this is just brainstorming. Might be useless....

So yes, Ada is not C and the runtime needs more. Does anyone think it might be possible for the community to come to some sort of near agreement on some ultra minimal OS/RTOS that would provide the needed functionality to implement all the Ada features but contain nothing else. This would sort of be a micro-kernel for embedded space that more facilities including full size operating systems would be built from.

I am interested in Minix3 these days. I don't really know anything yet but from what I understand it's kernel is only 10K lines of code. There is an ARM port getting close to being ready. It's not a RTOS by default though, that might kill the suggestion. It is however designed to be fault tolerant, which sounds like a nice pairing with Ada.

A common base of some sort, would give us all some direction. Maybe Minix3 is totally wrong but something like this might help us all organize under "one flag". Those who wanted to scale up to something half way to a full sized OS could and of course those who already need a full size OS are already satisfied and could skip this.

[Georg Bauhaus]

On 08.10.12 15:00, Dmitry A. Kazakov wrote:
> If you were a vendor of microwave herds, I bet you would have money to buy
> a license from AdaCore. You could even afford developing an Ada 2012
> compiler from scratch. (:-))

Does AdaCore offer a run-time system for one of the low cost
�controllers? Such as the ones offered by Freescale, Atmel, ...?
I know there is some effort to make GNAT an option on AVR,
but nothing mature so far, and surely not as convenient as
the alternatives that are packed with low cost boards.

http://sourceforge.net/p/avr-ada/wiki/Status/

So either look for one of the other Ada compilers,
or have some vendor write a run-time system, or write
one yourself. That's not for small shops, I should think.
Ada is a bit pricey, in comparison.

http://www.irvine.com/special.html
http://www.ghs.com/products/rtos/AdaMULTI_bare_board.html

On a managerial scale, estimating costs might show that porting
a compiler/writing a run-time system is well in reach of
a big-budget project (providing for long-term profit). But still,
I bet that they will call a manager an idiot if he/she
suggests any of this given the inexpensive, field-proven
alternatives. They'd see of huge risk associated with non-standard
(a.k.a. non-lemming) solutions: failure can easily be ascribed
to the non-standard solution, whatever the real causes are.

[Patrick]

doh! i just contradicted myself. I meant to say that a full size operating system COULD be built from.

What I was trying to get at, is that some people need baremetal and some people need half way to a full OS and maybe some people woudl like to even carry this to a full OS, aprat from what we already have.

[Dmitry A. Kazakov]

On Mon, 08 Oct 2012 16:00:15 +0200, Georg Bauhaus wrote:

> On 08.10.12 15:00, Dmitry A. Kazakov wrote:
>> If you were a vendor of microwave herds, I bet you would have money to buy
>> a license from AdaCore. You could even afford developing an Ada 2012
>> compiler from scratch. (:-))
>
> Does AdaCore offer a run-time system for one of the low cost

> µcontrollers? Such as the ones offered by Freescale, Atmel, ...?

If LG came to AdaCore asking for GNAT Pro for whatever crap they have in
their ovens?

> I bet that they will call a manager an idiot if he/she
> suggests any of this given the inexpensive, field-proven
> alternatives.

Right, this why we don't have many Ada compilers in supply.

But I am rather optimistic because embedded moves towards a few standard
platforms, which makes it much easier for Ada.

[Georg Bauhaus]

On 08.10.12 16:22, Dmitry A. Kazakov wrote:
>> Does AdaCore offer a run-time system for one of the low cost
>> > µcontrollers? Such as the ones offered by Freescale, Atmel, ...?
> If LG came to AdaCore asking for GNAT Pro for whatever crap they have in
> their ovens?

The next things to be said is that one cannot find any
qualified Ada programmers.

It does not matter that an ample supply of qualified
C programmers is a social fiction.

[Dmitry A. Kazakov]

On Mon, 08 Oct 2012 16:30:26 +0200, Georg Bauhaus wrote:

> On 08.10.12 16:22, Dmitry A. Kazakov wrote:
>>> Does AdaCore offer a run-time system for one of the low cost
>>> > µcontrollers? Such as the ones offered by Freescale, Atmel, ...?
>> If LG came to AdaCore asking for GNAT Pro for whatever crap they have in
>> their ovens?
>
> The next things to be said is that one cannot find any
> qualified Ada programmers.

Sure. The assumption was that they wished Ada in first place.

The point is that for a project aimed at 1-5 installations 30 EUR board
should be no problem. Well-supported hardware, OS, a mature Ada compiler
are other advantages. Aren't they 30 EUR worth?

> It does not matter that an ample supply of qualified
> C programmers is a social fiction.

Computing industry lives from fictions. Google may develop a web browser
and give it for free. There is no such thing as a functioning software
market. This allows odd things to happen. Some are profiting from that,
most are paying.

[Patrick]

Hi Dmitry

"The point is that for a project aimed at 1-5 installations 30 EUR board
should be no problem. Well-supported hardware, OS, a mature Ada compiler
are other advantages. Aren't they 30 EUR worth? "

I don't have so much experience with embedded design. Most of it comes from the eLua project. Lua could be used to control hardware on top of a full OS but eLua was born out of the desire to run Lua on bare metal.

The project brings full Lua plus all sorts of features. I would prefer to program in Ada but this is my back up plan. I can't see what is missing from what an full OS would bring except the GUI.

Boards like cherryPI offer an easy entry point for people but they don't have nearly the general purpose I/I pins I would need and I suspect many others feel this way too.

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 09:54:29 -0700 (PDT), Patrick wrote:

> Boards like cherryPI offer an easy entry point for people but they don't
> have nearly the general purpose I/I pins I would need and I suspect many
> others feel this way too.

Why are people so obsessed with ARM? You could have a decent Atom-based
board for same money. AMD Geode LX could be an alternative.

Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
somewhere. Maybe others could point out its status.

[Patrick]

"Why are people so obsessed with ARM? You could have a decent Atom-based
board for same money. AMD Geode LX could be an alternative.

Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
somewhere. Maybe others could point out its status. "

Yes but my main point was the lack of GPIO, please comment on this

[Simon Wright]

Patrick <pat...@spellingbeewinnars.org> writes:

> Boards like cherryPI offer an easy entry point for people but they
> don't have nearly the general purpose I/I pins I would need and I
> suspect many others feel this way too.

Raspberry Pi?

I/O?

Anyway, you can run an MCP23017 I/O multiplexer from an RPi (over the
I2C bus), giving you 16 extra ports[1]; and (although the expander board
I'm using[2] doesn't support this) you could attach up to 8 MCP23017
chips to an RPi.

[1] <https://sourceforge.net/projects/raspi-i2c-ada/>
[2] <http://shop.ciseco.co.uk/k002-slice-of-pi-o/>

[Patrick]

Hi Simon

Sorry thinking of dessert last night....

Yes, expansion I/O is good but there is a performance penalty for that and if expansion is already needed that would be even worse.

Most of the scientific instruments I work with already have expansion to assist with ti-state logic.

[kalvi...@gmail.com]

Embedded systems are usually price, memory, footprint (pcb size) and power constrained. Typically x86 system requires quite a few components around the CPU which consume power, board space and cost money. You can get a nice single-chip ARM M4 based all-in-one microcontroller for few dollars. For example http://www.st.com/internet/mcu/product/252140.jsp

As more applications are considered as mission critical, the interest in robust programming techniques will grow all the time. I would like to see Ada to become popular language among embedded systems programmers.

- Kalvin

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 11:29:15 -0700 (PDT), Patrick wrote:

> Yes but my main point was the lack of GPIO, please comment on this

From my point of view it looks just useless. We are using modular I/O
systems EtherCAT-, XCP-, ModBus-, CAN-/CANOpen-based.

It does not make sense to me to have an integrated I/O or some stackable
I/O board (PC104). Too expensive, non-extensible, unmaintainable, unsafe,
never meets any requirements etc.

BTW, for low-cost digital I/O you could take parallel port or some pins of
RS232, if the board has them.

[Rego, P.]

> So yes, Ada is not C and the runtime needs more. Does anyone think it might be possible for the community to come to some sort of near agreement on some ultra minimal OS/RTOS that would provide the needed functionality to implement all the Ada features but contain nothing else. This would sort of be a micro-kernel for embedded space that more facilities including full size operating systems would be built from.

This would be very good. I use Ada also as a hobby for programming AVR 8-bits chips in bare metal, such minimal RTOS would be very good. RTEMS is an option, but it does not implement all Ada features (for 8-bits AVRs), and it seems not to be very light for these chips.

[Rego, P.]

> Does AdaCore offer a run-time system for one of the low cost

> �controllers? Such as the ones offered by Freescale, Atmel, ...?

> I know there is some effort to make GNAT an option on AVR,
> but nothing mature so far, and surely not as convenient as
> the alternatives that are packed with low cost boards.
> http://sourceforge.net/p/avr-ada/wiki/Status/

Yes. For AVRs, Adacore provides as opensource the avr-elf-windows, which implements RTS as zero footprint profile (no tasking, no exception propagation, and other limitations), so we have to include a tasking mechanism due to ZFP limitations. I use it for hobby and academic purposes, think it's good to have this option besides avr-ada. Avr-ada is also good, but avr-elf-windows is simpler to begin to code, since you just have to run an Windows installer.
http://libre.adacore.com/download/configurations#

BTW, you can get an Arduino (8-bit AVR development board) by $10-20, so not expensive I think. But having Ada available for it certainly was a strong reason for me to continue to use it. Also I'm waiting my Raspberry Pi to come, which is taking far several months..., and I expect to use Ada on it in free/academic mode, but I do not intend to abandon my Arduinos :-)

[Niklas Holsti]

On 12-10-08 16:57 , Patrick wrote:
> so again this is just brainstorming. Might be useless....
>
> So yes, Ada is not C and the runtime needs more. Does anyone think it
> might be possible for the community to come to some sort of near
> agreement on some ultra minimal OS/RTOS that would provide the needed
> functionality to implement all the Ada features but contain nothing
> else. This would sort of be a micro-kernel for embedded space that
> more facilities including full size operating systems would be built
> from.

To my knowledge, there are already two such, or at least two starting
points:

- MaRTE OS, http://marte.unican.es/: GPL real-time kernel, supports Ada
out of the box. Take it and port it to the AVR, combine with AVR-Ada or
GNAT for AVR.

- Open Ravenscar Kernel, http://web.dit.upm.es/~str/ork/index.html.

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:

> On Mon, 8 Oct 2012 09:54:29 -0700 (PDT), Patrick wrote:
>
>> Boards like cherryPI offer an easy entry point for people but they don't
>> have nearly the general purpose I/I pins I would need and I suspect many
>> others feel this way too.
>
> Why are people so obsessed with ARM? You could have a decent Atom-based
> board for same money. AMD Geode LX could be an alternative.
>

You can run a number of the ARM boards off a 7805 powered by a PP3 battery.
Try doing that with a x86 based board.

They are also cheap, very small in size, and have various I/O options
including (usually) plenty of GPIO pins.

Take a look here:

https://www.olimex.com/Products/

Olimex are very popular with hobbyists here in Europe and they produce a
large range of boards including, but not restricted to, ARM.

> Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
> somewhere. Maybe others could point out its status.
>

Why ? For a number of projects, running Linux would be serious overkill
and, on a technical level, would not be suitable if you have hard real
time requirements (although there are various RT extensions which might
be suitable in some circumstances).

GNAT is running on ARM under RTEMS. I don't know what the current bare
metal status is for ARM, although people have posted in the past in
c.l.a about work they have done on this.

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:

> On Mon, 8 Oct 2012 09:54:29 -0700 (PDT), Patrick wrote:
>
>> Boards like cherryPI offer an easy entry point for people but they don't
>> have nearly the general purpose I/I pins I would need and I suspect many
>> others feel this way too.
>
> Why are people so obsessed with ARM? You could have a decent Atom-based
> board for same money. AMD Geode LX could be an alternative.
>

You can run a number of the ARM boards off a 7805 powered by a PP3 battery.
Try doing that with a x86 based board.

They are also cheap, very small in size, and have various I/O options
including (usually) plenty of GPIO pins.

Take a look here:

https://www.olimex.com/Products/

Olimex are very popular with hobbyists here in Europe and they produce a
large range of boards including, but not restricted to, ARM.

> Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
> somewhere. Maybe others could point out its status.
>

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:

> On Mon, 8 Oct 2012 11:29:15 -0700 (PDT), Patrick wrote:
>
>> Yes but my main point was the lack of GPIO, please comment on this
>
> From my point of view it looks just useless. We are using modular I/O
> systems EtherCAT-, XCP-, ModBus-, CAN-/CANOpen-based.
>

You are still thinking like a professional engineer doing safety
critical work on large systems. :-)

To understand what people like me are telling you, you need to start
thinking like a hobbyist interested in things like robotics and paying
for their experiments out of their own pockets.

> It does not make sense to me to have an integrated I/O or some stackable
> I/O board (PC104). Too expensive, non-extensible, unmaintainable, unsafe,
> never meets any requirements etc.
>

Speaking as a hobbyist (at least in embedded work), I can tell you I
consider the PC104 to be too bulky and yesterday's technology.

> BTW, for low-cost digital I/O you could take parallel port or some pins of
> RS232, if the board has them.
>

They are too limited for this for general purpose work.

I am using both serial ports (for a AVR programmer) and parallel ports
(for a JTAG interface) in this way on my home development PC. However,
that's about using what is currently available to avoid having to buy
more expensive programmers.

When it comes to the board itself, to do this correctly, you need
dedicated GPIO pins.

[Niklas Holsti]

On 12-10-08 15:02 , kalvi...@gmail.com wrote:
> Ditto, I would like to see a bare metal LGPL Ada for ARM M0-M4 devices.

Maybe it is well known, but for ARM7 there is the Lego Mindstorms NXT
GNAT, http://web.dit.upm.es/~str/proyectos/mindstorms/2011. It is
however based on the GPL GNAT, not LGPL. It uses ORK, so it is limited
to Ravenscar tasking. I don't know if it supports Cortex (probably not).

[Simon Clubley]

On 2012-10-08, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

[snip]

Sorry for the duplicate post. Eternal September was playing up.

[Ludovic Brenta]

Patrick writes on comp.lang.ada:

The Raspberry Pi has, IIRC, 17 GPIO ports. See it in action here:

http://www.youtube.com/watch?v=RuYLTudcOaM

For what it's worth, here is my opinion on your problem as you describe
it.

* bare-metal programming is _very_ difficult in any language.

* there are so many options to choose from that none is "standard"
enough to gather a community around it; whatever "bare metal" you
chose, you'll be alone or almost alone with it. The various
processors and µcontrollers are just one aspect of this diversity; at
the bare metal level, each and every other device on the board
(e.g. Flash storage, USB, GPIO, whatnot) has its own peculiar
programming interface. That's why GNAT supports so few bare-metal
targets.

* learning bare-metal programming (especially the most difficult part:
the bootstrapping process) can distract you from building software
that works.

* I think you should consider basing your development on the Raspberry
Pi. It is inexpensive and has the necessary GPIO ports. It is
powerful enough that you can program natively on it, avoiding the
pesky issues of cross-compiling and programming in an environment with
no memory protection or filesystem. Yes, that means you'll run
GNU/Linux on it. Why should that be a problem?

* once you have built *software* that satisfies your needs on the
Raspberry Pi, you can *then* look at porting it to an even smaller
device. Then you will tackle the difficult bootstrapping and
toolchain problems.

* Nobody has yet mentioned the Lego Mindstorms, which AdaCore (with
their staffing and expertise) have programmed to the bare metal. They
provide a multitasking kernel and a cross-compiler, for free! If that
particular target doesn't meet your hardware requirements, you can at
least base your hypothetical bare-metal toolchain on it.

Last thing: I think your quest is so noble that it deserves
encouragement and help; but you are getting distracted by hardware and
toolchain problems that you imagine and do not fully understand; I think
you should rather spend your time solving the problem that you do
understand - helping children with disabilities to communicate. It
doesn't matter if your first device has wires all over it, so long as it
works. If you can demonstrte such a device, you'll be in a position to
attract funding to develop dedicated hardware and bare-metal software.

--
Ludovic Brenta.

[Patrick]

I know we have talked about the uselessness of the work "embedded. Can we use the term EDA embedded for bare metal programming that will also likely require a custom circuit board?

I hope this list is not obnoxiously long but here is a list of topics I planned on doing screencasts for with the eLua project. Family responsibilities have caught up and I have not been able to finish them but I still plan too. This list will give some idea of what I mean by EDA(electronic design automation) embedded:

Basics
microcontrollers vs processors vs microprocessors, what exactly is embedded?
briefly what elua offers
basic set up costs needed for working on embedded systems
flashing your board with Windows and closed source programs
run a prefabricated elua program
writing elua programs
using webuilder


Intermediate
background-other languages used in embedded design, what elua offers in more depth
background-microcontrollers overview, arm, avr, pic etc
background-types of memory, flash, sram, etc
background-data buses, control buses, address buses etc
background-serial communication protocols, SPI, I2C, RS232,CAN, RS485 etc
background-External communication, USB, IrDA, Wireless
background-Sensors, light, hall-effect etc
background-open source toolchains and commercial ones
background-optional hardware, logical analyzers, oscilloscopes, chip burners etc..
jtag/flashing with Linux
writing elua programs continued
cross compiling programs on the desktop
modules-Programmable input/output
modules-Serial peripheral interface
modules-Universal asynchronous receiver transmitter
modules-Physical and virtual timers
modules-Pulse width modulation
modules-TCP/IP networking
modules-Low level system access
modules-Analog to digital converter
modules-Platform data
modules-ANSI terminal access
modules-Bitwise operations
modules-Inter-integrated circuit protocol
modules-Remote procedure call
modules- elua system control
optional modules-OLED display support
optional modules-Extended PIO configuration
optional modules-Real time clock
other features-Embedded HTTP web server
other features-FP module (for integer Lua)
other features-XMODEM protocol support for console file transfer
other features-Embedded ROM (Flash) file system
other features-FAT File System layer for mmc/sd cards
other features-Terminal / Console over UART or Ethernet
other features-eLua command shell
other features-Lua interrupt handlers
other features-C interrupt handlers
other features-eLua LTR (Lua Tiny RAM) patch
other features-eLua EGC (Emergency Garbage Collection) patch
other features-Remote (PC) File Sharing
other features-eLua web build service


Advanced
lua internals, "dragon book stuff" parsing, tokenizing etc
elua internals
creating a new port
highjacking circuit boards
demo-valve control
demo-stepper motors
demo-heating control
demo-A/D photodiodes
demo-A/D photomultiplier tubes
demo-LED displays
demo-digital to Analog conversion
demo-relay control
demo-more ideas to come....
ecad-open source tools for PCB design
ecad-tutorials more to come....

[Patrick]

"From my point of view it looks just useless. We are using modular I/O
systems EtherCAT-, XCP-, ModBus-, CAN-/CANOpen-based. "

Hi Dmitry

I might be misreading this post but it sounds like you are not interested in discussing Ada on low level (EDA) embedded. This is a loss for me and the list. You are very bright and your feedback could help secure another generation of Ada programmers. It seems to me that most of the notable Ada projects are continuations from when Ada was in the spotlight.

[Patrick]

Hi Ludovic

Thanks again for yet another answer to one of my post

I am working on two groups of projects. One is for children with special needs. I am doing lots of non-programming stuff with it, like sorting a dictionary by age appropriateness(kids might need to know hippopotamus but why genocide?)and organizing phonetic spellings of these words too. l am learning to prompt children to produce missing syllables with hand prompts and lots of little things like this. This project is pretty straight forward and I will not fail. I would like to do as much of it in Ada as I can so that I can practice with the language but I could easily do the whole thing in Tcl/Tk too if I get stuck.

My business projects are spinning in circles. There are multiple projects and they end being being put on hold, started again and then put on hold again.

One project that is back on hold is designing a spectrofluorometer. I service these instruments and if I could figure out the embedded design (as in EDA) end of things it would be back "on" again. There are quite a lot of peripherals, to contend with(photomultiplier tubes, monochromators, heating/cooling sample holder etc) and as such, a lot of peripheral chips.

Right now I am also trying to put together an application to control scientific instruments. Some difficult problems I am trying to overcome are related to licensing and other non-technical stuff, I am struggling to come up with a viable business plan.

One topic is after sales support.In my industry all software to control scientific instruments runs on Windows. If I did the same, things would go somewhat smoothly.

However I've been using Linux now for 8 years and don't really know Windows well. Having said this, does anyone really know Windows well. If something goes wrong and there are no internet posts about it, I bet lots of experts get stuck.

I would like it to run on a posix system. Right now I am thinking that designing everything on Minix3 would actually be very helpful as it is small and easy to understand. Drivers can be written from userland and I may need to write my own driver for a GPIB board. It's posix compliant but minimal compared to other systems. It should not be hard to move the application over to other posix systems afterwards.

I was also thinking that if I dual booted Minix and BSD/Linux, I could use Minix3 as a debugging platform and BSD or Linux as something more presentable.

So my concerns with Ada are varied but mostly revolve around portability issues.

Thanks for your encouragement and expertise !

[Stephen Leake]

Patrick <pat...@spellingbeewinnars.org> writes:

> I think Ada is the best language ever. I have a subset I like now(just
> 95 really ) and I find it so easy to read other peoples Ada code.
>
> However.. I am I think all this goodness has come with a price. A
> difficult to implement language.
>
> I wanted to use it for embedded design(as in baremetal) but no free of
> cost version lets me do that.

I don't understand. If your baremetal board is running a processor that
GNAT GPL supports, why can't you use that?

--
-- Stephe

[Patrick]

Hi Stephen

I don't think that GNAT GPL supports any bare metal boards, no ? (i.e Luminary Micro)

At present it requires a posix OS underneath. It's working on Raspberry PI on top of Linux but I haven't heard of anyone running GNAT GPL with tasking, exceptions etc, on bare ARM

I would love to be wrong :)

[Niklas Holsti]

On 12-10-09 06:24 , Patrick wrote:
> but I haven't heard of anyone running
> GNAT GPL with tasking, exceptions etc, on bare ARM
>
> I would love to be wrong :)

Ada for LEGO Mindstorms NXT under Linux:

http://web.dit.upm.es/~str/proyectos/mindstorms/2011/index.html

Something for you to love, then...

[Niklas Holsti]

On 12-10-09 00:28 , Ludovic Brenta wrote:
> Patrick writes on comp.lang.ada:
>> "Why are people so obsessed with ARM? You could have a decent
>> Atom-based board for same money. AMD Geode LX could be an alternative.
>>
>> Anyway, the thingy should run Linux. I believe there was a GNAT for
>> ARM somewhere. Maybe others could point out its status. "
>>
>> Yes but my main point was the lack of GPIO, please comment on this
>
> The Raspberry Pi has, IIRC, 17 GPIO ports. See it in action here:
>
> http://www.youtube.com/watch?v=RuYLTudcOaM
>
> For what it's worth, here is my opinion on your problem as you describe
> it.
>
> * bare-metal programming is _very_ difficult in any language.

Yes and no; some small bare metal systems are easy (on reset, the
processor starts running from address zero with a workable initial
state); others are much harder to get running (as you say in a later
point, not quoted).

But every small board or processor-on-a-USB-stick that I have seen comes
with a C toolchain that handles the bootstrap, and you can get a
LED-blinker running very easily. Not so for Ada, except for the small
number of systems already mentioned (MaRTE OS; Ada for Lego Mindstorms;
GNAT for AVR).

> * there are so many options to choose from that none is "standard"
> enough to gather a community around it; whatever "bare metal" you
> chose, you'll be alone or almost alone with it. The various
> processors and µcontrollers are just one aspect of this diversity; at
> the bare metal level, each and every other device on the board
> (e.g. Flash storage, USB, GPIO, whatnot) has its own peculiar
> programming interface. That's why GNAT supports so few bare-metal
> targets.

Yet the commercial C compilers, such as the ones from IAR Systems,
support a zillion different target processors, boards, JTAG systems and
other debuggers... out of the box. The full compiler is expensive, but
size-limited versions are usually free.

If you need threads, add one of the free RTOSes... but get only C support.

I don't think this problem is a consequence of the Ada language
properties, but shows the relative commercial success and penetration of
C and Ada in small embedded systems.

[kalvi...@gmail.com]

tiistai, 9. lokakuuta 2012 8.59.27 UTC+3 Niklas Holsti kirjoitti:
> On 12-10-09 00:28 , Ludovic Brenta wrote:
>
> > Patrick writes on comp.lang.ada:
>

> > * bare-metal programming is _very_ difficult in any language.
>
>
>
> Yes and no; some small bare metal systems are easy (on reset, the
>
> processor starts running from address zero with a workable initial
>
> state); others are much harder to get running (as you say in a later
>
> point, not quoted).
>
>
>
> But every small board or processor-on-a-USB-stick that I have seen comes
>
> with a C toolchain that handles the bootstrap, and you can get a
>
> LED-blinker running very easily. Not so for Ada, except for the small
>
> number of systems already mentioned (MaRTE OS; Ada for Lego Mindstorms;
>
> GNAT for AVR).
>

I agree with Niklas. Some bare metal system require that the (C language) startup code does some initialisation for the runtime system. Typically the startup code initialises the chip selects etc. and then allocates RAM for the runtime system, and finally calls each modules' initialisation code. It is not *that* difficult. Basically you need to know how to configure the chip select and where the RAM is located and how much RAM you have.

It is a shame, that we don't have Ada support for these bare metal boards. If we could have an Ada compiler for popular microcontrollers like ARM and MIPS (PIC32), Ada might get more popular as the hobbyist engineers could play with Ada and see its strength, and dispel the myths regarding Ada.

- Kalvin

[kalvi...@gmail.com]

tiistai, 9. lokakuuta 2012 11.02.44 UTC+3 kalvi...@gmail.com kirjoitti:
> I agree with Niklas. Some bare metal system require that the (C language) startup code does some initialisation for the runtime system.

Oops. I meant that some bare metal system require that the startup code (typically small peace of assembly code) does some initialisation for the runtime system.

- Kalvin

[Brian Drummond]

On Tue, 09 Oct 2012 08:59:25 +0300, Niklas Holsti wrote:

> On 12-10-09 00:28 , Ludovic Brenta wrote:
>> Patrick writes on comp.lang.ada:
>>

>> * bare-metal programming is _very_ difficult in any language.
>
> Yes and no; some small bare metal systems are easy (on reset, the
> processor starts running from address zero with a workable initial
> state); others are much harder to get running (as you say in a later
> point, not quoted).

Yes. Bare metal programming on a Z80 is easy. Ditto PIC, AVR, etc etc,
and of these only the AVR has an Ada toolchain. It may not be mature but
it is very usable. (We need to get Warren's thread library into the
mainstream though)

Bare metal on a typical ARM SOC ... not so much.

Though with an ARM dev board "available" for $5, ("available" stays in
quotes until mine arrives, probably in November)
http://hackaday.com/2012/08/31/preorder-tis-arm-cortex-m4-launchpad-for-5-
delivered/
the ARM in all its varieties would be a good next target for the Ada
community to focus on. There certainly are ARM Ada compilers, but I'm not
sure they are even as mature as AVR-Ada. It's not immediately clear to me
which variant I would start with for any particular ARM processor or
board, or what RTS it provides. (With one exception : Debian on the R-
Pi). The Gnat Android project would be part of this family, and it too
seems to have stalled.

> But every small board or processor-on-a-USB-stick that I have seen comes
> with a C toolchain that handles the bootstrap, and you can get a
> LED-blinker running very easily. Not so for Ada, except for the small
> number of systems already mentioned (MaRTE OS; Ada for Lego Mindstorms;
> GNAT for AVR).

What other small targets does gcc support? One approach would be to build
for another of these with Ada support, and provide a minimal library
along AVR-Ada lines. This would be an approachable project for a small
community or a class project.

Or me, unless I get a job offer soon...

> I don't think this problem is a consequence of the Ada language
> properties, but shows the relative commercial success and penetration of
> C and Ada in small embedded systems.

I think with ARM and AVR covered, Ada should be in a better place than it
is. But even in the Arduino community, AVR-Ada goes almost unnoticed.
So part of the problem is publicity and exposure, and those need not be
expensive to address.

- Brian

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 16:07:48 -0700 (PDT), Patrick wrote:

> I might be misreading this post but it sounds like you are not interested
> in discussing Ada on low level (EDA) embedded.

Well, I am very infrequently involved in such stuff. I cannot remember any
case we did that in Ada.

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 20:44:51 +0000 (UTC), Simon Clubley wrote:

> On 2012-10-08, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>> On Mon, 8 Oct 2012 11:29:15 -0700 (PDT), Patrick wrote:
>>
>>> Yes but my main point was the lack of GPIO, please comment on this
>>
>> From my point of view it looks just useless. We are using modular I/O
>> systems EtherCAT-, XCP-, ModBus-, CAN-/CANOpen-based.
>
> You are still thinking like a professional engineer doing safety
> critical work on large systems. :-)

We install such systems for example, for CHP. It is a low cost board with
EtherCAT terminals to measure temperature, digital I/O to control the
boiler and a GPRS to communicate the central station. Is it "large"? From
the software point of view it is, because you cannot make it working
without a lot of software. All embedded moves in this direction.

> To understand what people like me are telling you, you need to start
> thinking like a hobbyist interested in things like robotics and paying
> for their experiments out of their own pockets.

I understand them because this sort of calculation we have to do all the
time. We found out that modular I/O terminals are sufficiently cheaper than
GPIO, even if one does not count software costs.

The real problem for a hobbyist lies elsewhere. The protocols used to
communicate such terminals are incredibly complex. The masters required to
talk to them are commercial products, like ours. There is a free EtherCAT
master for Linux, but it does barely over 20% of the work required to
configure the terminals, and it is in C. ModBus (over TCP/IP) is much less
complicated, but ModBus terminals are more expensive and ModBus systems are
relatively slow (5ms is the limit). Still ModBus could be a good start.

http://www.beckhoff.com/english.asp?bus_terminal/bc7300.htm

Ludovic wrote it much better than me. People are paying too much attention
to the hardware.

>> It does not make sense to me to have an integrated I/O or some stackable
>> I/O board (PC104). Too expensive, non-extensible, unmaintainable, unsafe,
>> never meets any requirements etc.
>
> Speaking as a hobbyist (at least in embedded work), I can tell you I
> consider the PC104 to be too bulky and yesterday's technology.

Yes. Any integrated or semi-integrated solution will be bulky because of
cabling. With terminals you need just one Ethernet port. The sensors and
actuators can be placed directly near the machine.

[pavel.kl...@gmail.com]

Dne pondělí, 8. října 2012 0:35:24 UTC+2 Simon Clubley napsal(a):
> RTEMS provides support for using Ada on ARM boards (if you are willing
> to run under a RTOS instead of bare metal)

RTEMS seems very good for my purposes.
But it lacks SMP support, AFAIK. :(

Pavel

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 20:16:12 +0000 (UTC), Simon Clubley wrote:

>> Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
>> somewhere. Maybe others could point out its status.
>
> Why ? For a number of projects, running Linux would be serious overkill
> and, on a technical level,

Networking

> would not be suitable if you have hard real
> time requirements (although there are various RT extensions which might
> be suitable in some circumstances).

Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
even 10ms cycle is more than enough. Linux can easily deliver you 1ms
cycle.

Furthermore, I didn't see the specifications of the GPIO, but I suspect
that the time it needs to multiplex (how many A/D converters it actually
has?) and to convert all inputs and outputs could be well over 10ms.

And who is talking about performance while choosing an ARM?

> GNAT is running on ARM under RTEMS. I don't know what the current bare
> metal status is for ARM, although people have posted in the past in
> c.l.a about work they have done on this.

The real trouble with an OS like Linux is the boot time. Some applications,
in automotive, for example, require boot time under 1s. Which is quite a
challenge.

[kalvi...@gmail.com]

tiistai, 9. lokakuuta 2012 12.32.31 UTC+3 Dmitry A. Kazakov kirjoitti:

> And who is talking about performance while choosing an ARM?

ARM M3/M4 based automotive microcontrollers are available at least up to 200MHz from various manufacturers. And multi-core Cortex A15 ARM are running up to 4GHz (TI OMAP series). Performance is not an issue. :) Running on bare metal with a small RTOS will give quite impressive performance in small PCB footprint, cost and power consumption.

- Kalvin

[Georg Bauhaus]

On 09.10.12 11:13, Dmitry A. Kazakov wrote:
> People are paying too much attention
> to the hardware.

Which in many cases is exactly what people in question want to do:
understand a real computer, not something modeled atop it.

[Simon Clubley]

On 2012-10-09, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
> On Mon, 8 Oct 2012 20:16:12 +0000 (UTC), Simon Clubley wrote:
>> would not be suitable if you have hard real
>> time requirements (although there are various RT extensions which might
>> be suitable in some circumstances).
>
> Huh, are you building bombs, guys? (:-))

Since you have asked the question, I will answer it. :-)

I'm a atheist liberal who values peace highly, so no, there are no
bombs involved.

There are plenty of hobbyist projects, such as model aircraft, or
robotics in general, which do have these timing constraints however.

> For most physical processes 1ms,
> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
> cycle.
>
> Furthermore, I didn't see the specifications of the GPIO, but I suspect
> that the time it needs to multiplex (how many A/D converters it actually
> has?) and to convert all inputs and outputs could be well over 10ms.
>

That GPIO figure is off by several orders of magnitude.

In most GPIO operations, it's a pure binary digital operation. In this
case, you get one bit set in a register per GPIO line. If the GPIO line
is above a MCU specific voltage, it's a logic one. If it's below that
voltage, it's a logic zero.

The GPIO lines are grouped together in registers so that you can read a
set of them at the same time as a atomic operation.

If, OTOH, you need to know what the voltage on the line actually is, then
you choose a GPIO line which can be reconfigured as a A/D converter input
and run it through the MCU's ADC. Sample rates of several thousand per
second are still commonly achievable in this case.

In one project, which was in C on a pair of 8-bit AVRs, I built a pseudo
full duplex communications module around a pair of low cost half duplex
transceivers. The incoming Rx line from the transceivers was fed directly
into a GPIO line, which I sampled at a rate of 9600 times per second
(as a digital signal, not a A/D conversion).

If I miss just one of those 9600Hz windows, then the incoming packet is
corrupted and therefore useless.

As part of another project, I use a AVR to directly control R/C servos
with their control lines connected to GPIO lines configured for output.

The length of the pulse sent to a servo controls it's position, which is
about 1ms for one position and 2ms for the position about 90 degress away.
The centre point is about 1.5ms.

Unless you can generate pulses with a accuracy of _well_ under 0.1ms at a
rate of about 50Hz, you will see major jitter. You can control the pulse
length on a AVR GPIO line to this degree of accuracy.

I don't usually attempt this level of control on a ARM board directly
however, as in these types of projects I would normally use a ARM board
for higher level decision making and let it pass off commands to smaller
dedicated 8-bit boards. I do RT work on ARM boards, but it's in the greater
than several milliseconds range.

> And who is talking about performance while choosing an ARM?
>

It's the difference between latency and raw performance.

[Dmitry A. Kazakov]

Is i7 unreal? It may explain the distortion, but not justify it. To me
these things are not real computers either. A real one must have the front
panel with LEDs and switches to enter the initial loader, which you have to
memorize in hex code... (:-))

[Vinzent Hoefler]

Dmitry A. Kazakov wrote:

> On Mon, 8 Oct 2012 20:16:12 +0000 (UTC), Simon Clubley wrote:
>
> Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
> cycle.

That wouldn't be nearly "good enough" for the project I was once involved
in. There we needed to deliver a constant data rate at a frequency of up to
10 kHz (interrupt triggered). No FIFO on the output side. CPU was a neat
little NEC V30 @ 8 MHz.

And no, it wasn't a bomb - actually I'd suspect the timing constraints
for a bomb-type project are much more relaxed. ;)


Vinzent.

--
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.
-- Nathaniel Borenstein

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 02:57:44 -0700 (PDT), kalvi...@gmail.com wrote:

> tiistai, 9. lokakuuta 2012 12.32.31 UTC+3 Dmitry A. Kazakov kirjoitti:
>
>> And who is talking about performance while choosing an ARM?
>
> ARM M3/M4 based automotive microcontrollers are available at least up to
> 200MHz from various manufacturers. And multi-core Cortex A15 ARM are
> running up to 4GHz (TI OMAP series). Performance is not an issue. :)

See, Linux should be no problem then.

It is also notable how people concerning about power consumption are
talking about multi-cores and single tasking applications, all in one
sentence. (:-))

Performance is another fiction. Since we are indeed forced to actually
measure the performance all the time, our customers are just obsessed with
that, I can say that it is virtually impossible to predict the latencies
the given board would have. One have to measure it in order to know. Which
again brings the main point back. Hardware is irrelevant and volatile.
Software is what one have concentrate efforts on. If the board appears too
slow, do code review. If that does not help try another board.

[kalvi...@gmail.com]

tiistai, 9. lokakuuta 2012 15.30.39 UTC+3 Dmitry A. Kazakov kirjoitti:
> On Tue, 9 Oct 2012 02:57:44 -0700 (PDT), kalvi...@gmail.com wrote:
>
>
>
> > tiistai, 9. lokakuuta 2012 12.32.31 UTC+3 Dmitry A. Kazakov kirjoitti:
>
> >
>
> >> And who is talking about performance while choosing an ARM?
>
> >
>
> > ARM M3/M4 based automotive microcontrollers are available at least up to
> > 200MHz from various manufacturers. And multi-core Cortex A15 ARM are
> > running up to 4GHz (TI OMAP series). Performance is not an issue. :)
>
>
>
> See, Linux should be no problem then.
>

Actually Linux is problem. Linux requires a few megabytes of RAM and Flash to be usable. Also, the boot time is typically way too long for some applications.

> It is also notable how people concerning about power consumption are
> talking about multi-cores and single tasking applications, all in one
> sentence. (:-))
>

That was just a reply to your concern about ARM performance ;) In small embedded projects, the 200MHz ARM single-chip microcontroller is a low-power and small foot-print solution, as it contains necessary Flash, RAM, GPIO, USB, A/D and D/A to host complete application. And real-time performance is typically sufficient. If not, then a small FPGA (which might contain a small controller, too) may do the trick. Of course, in some application even less powerful 20MHz ARM-based microcontroller is sufficient. And yes, you can easily attach LCD and touch panel, if you wish: http://www.mikroe.com/arm/development-boards/

[Dmitry A. Kazakov]

On Tue, 09 Oct 2012 14:29:57 +0200, Vinzent Hoefler wrote:

> Dmitry A. Kazakov wrote:
>
>> On Mon, 8 Oct 2012 20:16:12 +0000 (UTC), Simon Clubley wrote:
>>
>> Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
>> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
>> cycle.
>
> That wouldn't be nearly "good enough" for the project I was once involved
> in. There we needed to deliver a constant data rate at a frequency of up to
> 10 kHz (interrupt triggered). No FIFO on the output side. CPU was a neat
> little NEC V30 @ 8 MHz.

We have several projects where 10kHz sampling rate is required. Though it
is sampling and never the control loop. For pure sampling there exist
over-sampling solutions, so that you would not need to read data each
100�s.

> And no, it wasn't a bomb - actually I'd suspect the timing constraints
> for a bomb-type project are much more relaxed. ;)

Under a bomb I meant processes like explosion or burning. These are ones
for which you would have to dip under 1ms.

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 05:51:51 -0700 (PDT), kalvi...@gmail.com wrote:

> Also, the boot time is typically way too long for some applications.

Yes, it is a problem, though I don't know in which part is it a hardware or
a software issue. If somebody really wanted, I am sure, he would find a
solution.

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 12:04:29 +0000 (UTC), Simon Clubley wrote:

> If, OTOH, you need to know what the voltage on the line actually is, then
> you choose a GPIO line which can be reconfigured as a A/D converter input
> and run it through the MCU's ADC. Sample rates of several thousand per
> second are still commonly achievable in this case.

The problem is that an integrated I/O usually has only on ADC. So to
measure two inputs you need twice so much time plus the time needed to
switch the ADC to another line. This is how you quickly come over 10ms. Not
to forget inability to measure inputs and change the outputs synchronously.

> Unless you can generate pulses with a accuracy of _well_ under 0.1ms at a
> rate of about 50Hz, you will see major jitter. You can control the pulse
> length on a AVR GPIO line to this degree of accuracy.

Under VxWorks we were able to receive, process and then send Ethernet
frames with the latency about 100盜. We didn't do such tests for Linux,
though.

>> And who is talking about performance while choosing an ARM?
>
> It's the difference between latency and raw performance.

Yes. But even with many tasks active latencies under 100盜 are doable. Not
for an ARM of course.

[Georg Bauhaus]

On 09.10.12 14:16, Dmitry A. Kazakov wrote:
> On Tue, 09 Oct 2012 11:59:11 +0200, Georg Bauhaus wrote:
>
>> On 09.10.12 11:13, Dmitry A. Kazakov wrote:
>>> People are paying too much attention
>>> to the hardware.
>>
>> Which in many cases is exactly what people in question want to do:
>> understand a real computer, not something modeled atop it.
>
> Is i7 unreal?

I doubt that even Intel knows the i7.

> A real one must have the front
> panel with LEDs and switches to enter the initial loader, which you have to
> memorize in hex code... (:-))

Or tubes.

Or paper tape with holes in it.

Nothing wrong with these per se. The thing is, a computer that
is very simple is also very good for modelling software around
application problems, not hardware problems, until the programmers
are more familiar with all the technology involved. A simple
computer facilitates understanding what a computer does.
A complex beast full of legacy junk, things you don't need,
since not even made for small embedded systems is just a distraction.

If you have been lucky, you haven't ever touched a book
on the subject of IBM PC/DOS style assembly programming,
with its overabundance of distractions.

I understand that classy embedded systems programming involves
tables of conditions and thoroughly understanding and testing
the program under all conditions. Now imagine a programming
platform for garage style embedded programming. The platform will
be a hindrance if you'd first have to fight huge tables of
conditions solely filled by hardware issues and platform
idiosyncrasies.

Hence, no PC, please!

[kalvi...@gmail.com]

tiistai, 9. lokakuuta 2012 16.17.55 UTC+3 Dmitry A. Kazakov kirjoitti:
> The problem is that an integrated I/O usually has only on ADC. So to
> measure two inputs you need twice so much time plus the time needed to
> switch the ADC to another line. This is how you quickly come over 10ms. Not
> to forget inability to measure inputs and change the outputs synchronously.

Quite a few microcontrollers have two or more A/D inputs and D/A outputs that can sample simultaneously and update outputs synchronously. If one needs more simultaneous sampling A/D inputs or D/A outputs, then one may have to use an external IC for this. Some of the ICs have fast SPI interface so they don't require only few GPIO lines.

- Kalvin

[Dmitry A. Kazakov]

On Tue, 09 Oct 2012 17:06:11 +0200, Georg Bauhaus wrote:

> I understand that classy embedded systems programming involves
> tables of conditions and thoroughly understanding and testing
> the program under all conditions.

Tell that customers, who want to be able to access the device remotely, to
reconfigure it any time etc. The art of embedded systems you have in mind
is dying.

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 08:53:01 -0700 (PDT), kalvi...@gmail.com wrote:

> tiistai, 9. lokakuuta 2012 16.17.55 UTC+3 Dmitry A. Kazakov kirjoitti:
>> The problem is that an integrated I/O usually has only on ADC. So to
>> measure two inputs you need twice so much time plus the time needed to
>> switch the ADC to another line. This is how you quickly come over 10ms. Not
>> to forget inability to measure inputs and change the outputs synchronously.
>
> Quite a few microcontrollers have two or more A/D inputs and D/A outputs
> that can sample simultaneously and update outputs synchronously.

That is why GPIO is useless in my eyes.

> If one needs more simultaneous sampling A/D inputs or D/A outputs, then
> one may have to use an external IC for this.

http://www.beckhoff.com/english/ethercat/el3054.htm
http://www.beckhoff.com/english/fieldbus_box/ep3174.htm
etc

[Dmitry A. Kazakov]

On Tue, 09 Oct 2012 12:50:53 -0400, Dennis Lee Bieber wrote:

> On Tue, 9 Oct 2012 11:33:07 +0200, "Dmitry A. Kazakov"
> <mai...@dmitry-kazakov.de> declaimed the following in comp.lang.ada:

>
>> On Mon, 8 Oct 2012 20:16:12 +0000 (UTC), Simon Clubley wrote:
>>
>>> would not be suitable if you have hard real
>>> time requirements (although there are various RT extensions which might
>>> be suitable in some circumstances).
>>
>> Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
>> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
>> cycle.
>>

> Well, I did have an assignment a decade ago that actually would have
> worked better with an off-system processor. A Win98SE laptop is
> definitely not a real-time processor -- even with the program running at
> the highest available priority class the OS kept interrupting.

I don't remember Win98, wasn't it actually DOS 6.2 like Win95 before it?

Anyway, you can have up to 5ms under Windows, starting from Win2K. There
are some tricks, in particular the time slice should be set at 1ms. 10ms is
the default, which is the main reason for the "jitter." Setting the process
at the "RT priority" is not really needed. And yes, it won't prevent
drivers from preempting the process.

Actually we do lot of control straight under Windows. You may wonder but it
works fine.

[kalvi...@gmail.com]

Small embedded systems comes in this price range and consume very little power:
https://www.olimex.com/Products/ARM/ST/STM32-E407/
And, the real-time performance beats Windows by a decade or two. ;)

- Kalvin

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 11:26:52 -0700 (PDT), kalvi...@gmail.com wrote:

> Small embedded systems comes in this price range and consume very little power:
> https://www.olimex.com/Products/ARM/ST/STM32-E407/

It does not really matter. Power consumption is not a functional
requirement. Something like 4 DO, 2 DI, 8 AI, 4 AO, 1 Incremental Encoder
interface is. It all depends on the problem at hand. I have nothing against
Cortex, just cannot see any good application for it. For personal
protection devices, where power consumption is indeed a problem, our
customers use much smaller microcontrollers. If something has to talk CAN
while running on a battery? A car battery, maybe? Give me a break!

> And, the real-time performance beats Windows by a decade or two. ;)

We are OS-agnostic. This is one of the advantages of having it in Ada. Our
software runs under VxWorks, Linux and Windows too.

And, again, regarding performance, only tests can show it. Once you start
network services in background of the controlling loop, add publishers to
propagate data over the network, start active CAN-bus monitoring, only then
you will see if you really outperform, even lame Windows...

[Simon Clubley]

On 2012-10-09, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:

> On Tue, 9 Oct 2012 08:53:01 -0700 (PDT), kalvi...@gmail.com wrote:
>
>> tiistai, 9. lokakuuta 2012 16.17.55 UTC+3 Dmitry A. Kazakov kirjoitti:
>>> The problem is that an integrated I/O usually has only on ADC. So to
>>> measure two inputs you need twice so much time plus the time needed to
>>> switch the ADC to another line. This is how you quickly come over 10ms. Not
>>> to forget inability to measure inputs and change the outputs synchronously.
>>
>> Quite a few microcontrollers have two or more A/D inputs and D/A outputs
>> that can sample simultaneously and update outputs synchronously.
>
> That is why GPIO is useless in my eyes.
>

You are confusing GPIO for analogue operations with GPIO for digital
(logic 0/logic 1) operations. I have found the latter to be far more
common, at least for the things I do.

>> If one needs more simultaneous sampling A/D inputs or D/A outputs, then
>> one may have to use an external IC for this.
>
> http://www.beckhoff.com/english/ethercat/el3054.htm
> http://www.beckhoff.com/english/fieldbus_box/ep3174.htm
> etc
>

Let's make this discussion more tangible by using a specific example.

The scenario: a hobbyist/academic researcher/whoever is building a
small computer controlled model aircraft, in the order of up to about
a metre in length for the fuselage.

This size means that a PC-104 is way too bulky and heavy for the onboard
computer, but the latest ARM boards, with their integrated I/O, are a
very good fit.

Normal R/C electric engine controllers and servos are used in this
model aircraft and need to be interfaced to the onboard computer.

Question 1: if you could not use GPIO lines to control commodity
R/C components, how would you have the onboard computer control the
engine and flight control surfaces ?

To make this on topic for this newsgroup, this seems to be a common
hobbyist or researcher project in a number of circles, and is _exactly_
the type of project for which Ada would be very well suited indeed.

It's also the type of project which would raise Ada's profile big time
if hobbyist/researcher type people started using Ada on a regular basis
on them.

It's also the type of project generally done by people on restricted
budgets.

Question 2: how would you put the idea of using Ada for this project
into someone's head and what changes to the Ada ecosystem would be
needed to make it viable for people with different ranges of embedded
experience to actually use Ada in this case ?

[Stephen Leake]

Patrick <pat...@spellingbeewinnars.org> writes:

> I don't think that GNAT GPL supports any bare metal boards, no ? (i.e
> Luminary Micro)

It depends on what you mean by "supports".

> At present it requires a posix OS underneath.

It is easy to port to such a platform, yes.

But when you are say you want to use a "bareboard" system, then this
is what you are signing up for; implementing the functionality required
for the GNAT runtime. Or a subset of it, more likely.

Which raises the question; why insist on "bareboard", instead of a well
supported OS that does what you need?

--
-- Stephe

[Stephen Leake]

kalvi...@gmail.com writes:

> I agree with Niklas. Some bare metal system require that the (C
> language) startup code does some initialisation for the runtime
> system.

I'm confused. If you are using someone else's "runtime system", then in
what sense is this "baremetal"?

It sounds like you are just talking about the choice of what OS to use;
either a fully POSIX compliant one, or a small subset implemented by
some hardware vendor.

> It is a shame, that we don't have Ada support for these bare metal
> boards. If we could have an Ada compiler for popular microcontrollers
> like ARM and MIPS (PIC32), Ada might get more popular as the hobbyist
> engineers could play with Ada and see its strength, and dispel the
> myths regarding Ada.

If you are willing to settle for the "C subset" of Ada, getting it
running on a non-POSIX system is relatively straightforward. Usually
what happens then is the users say "but Ada promised tasking, fixed
point arithmetic, and exceptions!". That's why you need a real OS, not a
small subset.

TANSTAAFL.

--
-- Stephe

[Niklas Holsti]

On 12-10-10 08:56 , Stephen Leake wrote:
> kalvi...@gmail.com writes:
>
>> I agree with Niklas. Some bare metal system require that the (C
>> language) startup code does some initialisation for the runtime
>> system.
>
> I'm confused. If you are using someone else's "runtime system", then in
> what sense is this "baremetal"?

It was Ludovic who said that baremetal programming is hard in any
language, especially the bootstrap stage.

The bootstrap can indeed be complex. Some of the bigger, more complex
microcontrollers start up after reset in a kind of "safe mode" with
perhaps no usable SW stack, perhaps a very slow clock, and perhaps
unable to access off-chip memory. To enable normal operation, the clock
generator has to be configured, the off-chip memory controller has to be
configured, perhaps some parts of the app SW have to be copied from the
flash to RAM, etc.

The details of this processor configuration phase can be complex and
very different for different chips. For some chips, the bootstrap can
include setting up some standard interrupt/trap handlers, for example
register-file underflow and overflow handlers on SPARCs, that remain
active during app SW execution (unless the app SW deliberately
deactivates or modifies them).

And then the language-specific initialization has be done: initialize
statically allocated variables, set up a usable SW stack, elaborate Ada
library units, etc. The details depend on the language(s) and the
compiler(s), but not so much on the chip.

Finally, this bootstrap code jumps to main(), or its equivalent in Ada
app SW. And *then* the app SW is in full control of the processor - able
to access "bare metal" with no OS in between.

Processor development kits typically come with development environments
that handle the bootstrap automatically, for C programs and up to
entering main(). An Ada compiler could probably use the same bootstrap
and perform elaboration as the first step of main().

> It sounds like you are just talking about the choice of what OS to use;
> either a fully POSIX compliant one, or a small subset implemented by
> some hardware vendor.

Ludovic, Kelvin, and I were talking about the bootstrap, I believe. This
is not an OS, since it generally leaves the app SW in full control, and
does not try to manage or control further operation of the app SW.

For Ada, the situation is a little more complex, since the language
itself includes features (tasking) that, for other languages like C, are
usually provided by an OS. Should the code that implements Ada tasking
be seen as a language-specific library (like libc for C), or as an OS?

Are the standard C libraries like libc an OS or a "runtime"? You could
say they are a "runtime", since they come from the "system", and not
from the app developer, and they support the execution of the app SW at
runtime.

The difference is perhaps that the standard C libraries are pretty easy
to implement in a (mostly) portable way, while Ada tasking support is
more processor-dependent.

>> It is a shame, that we don't have Ada support for these bare metal
>> boards. If we could have an Ada compiler for popular microcontrollers
>> like ARM and MIPS (PIC32), Ada might get more popular as the hobbyist
>> engineers could play with Ada and see its strength, and dispel the
>> myths regarding Ada.
>
> If you are willing to settle for the "C subset" of Ada, getting it
> running on a non-POSIX system is relatively straightforward. Usually
> what happens then is the users say "but Ada promised tasking, fixed
> point arithmetic, and exceptions!". That's why you need a real OS, not a
> small subset.

I doubt that fixed-point arithmetic and exceptions need a "real OS". If
a C system supports setjmp/longjmp, you do not call it an OS.
Implementing tasking is certainly easier if you can delegate to a "real
OS", but traditionally Ada compilers for embedded systems provide a
Run-Time System that implements tasking directly, without a real OS
underneath. Some of these RTS have been quite small; IIRC the RTS in TLD
Ada 83 for the MIL-STD-1750 processor was something like 8 KB.

> TANSTAAFL.

Indeed. But there are cheap lunches (snacks, really) and expensive
lunches. As a lunch, I seems to me that an Ada RTS is closer to the
"snack" level.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[Ludovic Brenta]

Niklas Holsti writes:
> On 12-10-10 08:56 , Stephen Leake wrote:
>> kalvi...@gmail.com writes:
>>
>>> I agree with Niklas. Some bare metal system require that the (C
>>> language) startup code does some initialisation for the runtime
>>> system.
>>
>> I'm confused. If you are using someone else's "runtime system", then
>> in what sense is this "baremetal"?
>
> It was Ludovic who said that baremetal programming is hard in any
> language, especially the bootstrap stage.
>
> The bootstrap can indeed be complex. Some of the bigger, more complex
> microcontrollers start up after reset in a kind of "safe mode" with
> perhaps no usable SW stack, perhaps a very slow clock, and perhaps
> unable to access off-chip memory. To enable normal operation, the
> clock generator has to be configured, the off-chip memory controller
> has to be configured, perhaps some parts of the app SW have to be
> copied from the flash to RAM, etc.

Yes. When I mentioned bootstrap I meant it in two senses: the one you
just described i.e. bootstrap of the processor and other devices, and
also the bootstrap of the toolchain. If your target doesn't have a
compiler available, you must create one before you can do anything.
Practically speaking that means binutils and GNAT configured as
cross-tools for that particular board. Also the connection between the
host and target computers (USB? JTAG? RS-232? etc.) This doubles
complexity of the *initial* investment one has to do before even
starting to program their application.

I agree that it would be very nice if there were some preconfigured
cross-toolchain for Ada for some kind of "standard" bare-board target.
AVR-Ada and GNAT for Lego Mindstorms are currently the closest things to
such a "standard" but beyond that, programmers are on their own to
create a cross-toolchain. It is feasible (after all the ones who
created AVR-Ada and GNAT for Lego Mindstorms were "on ther own" too) but
not for the faint of heart and certainly not for beginners.

That's why I stand by my recommendation that hobbyists who have a
specific application in mind (rather than a specific target board they
want to play with) should avoid these two bootstrap stages altogether
and start programming their application on a Raspberry Pi or Lego
Mindstorms NXT. If and only if they make significant progress on the
application, they can justify the effort needed to port their app to a
bare board (thanks to Ada's portability, this cost should be almost
entirely confined to bootstrapping the toolchain and the board).

--
Ludovic Brenta.

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 23:23:11 +0000 (UTC), Simon Clubley wrote:

> Let's make this discussion more tangible by using a specific example.
>
> The scenario: a hobbyist/academic researcher/whoever is building a
> small computer controlled model aircraft, in the order of up to about
> a metre in length for the fuselage.

I have no idea about controlling an aircraft. Can one do it without a
multitude of analogue inputs and outputs, rotary encoders etc?

> Question 1: if you could not use GPIO lines to control commodity
> R/C components, how would you have the onboard computer control the
> engine and flight control surfaces ?

ARM boards look very much like a compromise. That rarely pays off. Likely
there exist better solutions for a model aircraft, but I cannot judge that.

> To make this on topic for this newsgroup, this seems to be a common
> hobbyist or researcher project in a number of circles, and is _exactly_
> the type of project for which Ada would be very well suited indeed.

How many people spend their time building model aircrafts? Could rail
transport modeling be a better candidate?

Anyway, if you need an altimeter instrument for the ground control system,
let me know. I maintain an instrumentation library in Ada.

> Question 2: how would you put the idea of using Ada for this project
> into someone's head and what changes to the Ada ecosystem would be
> needed to make it viable for people with different ranges of embedded
> experience to actually use Ada in this case ?

I would tell him that he could use the same software during modeling and
deployment phases, basically, doing much of the work in doors rather than
in field.

[Niklas Holsti]

On 12-10-10 10:06 , Ludovic Brenta wrote:
> Niklas Holsti writes:
>> On 12-10-10 08:56 , Stephen Leake wrote:
>>> kalvi...@gmail.com writes:
>>>
>>>> I agree with Niklas. Some bare metal system require that the (C
>>>> language) startup code does some initialisation for the runtime
>>>> system.
>>>
>>> I'm confused. If you are using someone else's "runtime system", then
>>> in what sense is this "baremetal"?
>>
>> It was Ludovic who said that baremetal programming is hard in any
>> language, especially the bootstrap stage.
>>
>> The bootstrap can indeed be complex. Some of the bigger, more complex
>> microcontrollers start up after reset in a kind of "safe mode" with
>> perhaps no usable SW stack, perhaps a very slow clock, and perhaps
>> unable to access off-chip memory. To enable normal operation, the
>> clock generator has to be configured, the off-chip memory controller
>> has to be configured, perhaps some parts of the app SW have to be
>> copied from the flash to RAM, etc.
>
> Yes. When I mentioned bootstrap I meant it in two senses: the one you
> just described i.e. bootstrap of the processor and other devices, and
> also the bootstrap of the toolchain.

Ah, I didn't understand that you meant also toolchain bootstrap, sorry.
I agree that is difficult, both for C and for Ada.

> If your target doesn't have a
> compiler available, you must create one before you can do anything.

Yep. And here is the main difference between C and Ada. C
cross-compilers for most targets exist; for Ada not.

> Practically speaking that means binutils and GNAT configured as
> cross-tools for that particular board. Also the connection between the
> host and target computers (USB? JTAG? RS-232? etc.) This doubles
> complexity of the *initial* investment one has to do before even
> starting to program their application.

Yes. And this leads to the interesting and (I think) crucial question:
assuming that GNU cross-tools exist for C for some target, how difficult
is it to add GNAT to those tools? With and/or without tasking? And how
difficult is it to maintain it when GNU and GNAT evolve? Apparently
quite difficult, since so few have been done.

> I agree that it would be very nice if there were some preconfigured
> cross-toolchain for Ada for some kind of "standard" bare-board target.
> AVR-Ada and GNAT for Lego Mindstorms are currently the closest things to
> such a "standard" but beyond that, programmers are on their own to
> create a cross-toolchain.

Agreed.

> It is feasible (after all the ones who
> created AVR-Ada and GNAT for Lego Mindstorms were "on ther own" too) but
> not for the faint of heart and certainly not for beginners.

I think the OP's concerns was that there seems to be little activity to
drive the creation of such Ada tool-chains, and what can we do about
that? Can we interest the chip-makers (e.g. Atmel) or cross-tool
providers (e.g. Crossworks) to do or support such activities? Can we
cooperatively provide how-to guides for adding cross-GNATs to
cross-GNU-C tools?

> That's why I stand by my recommendation that hobbyists who have a
> specific application in mind (rather than a specific target board they
> want to play with) should avoid these two bootstrap stages altogether
> and start programming their application on a Raspberry Pi or Lego
> Mindstorms NXT.

I strongly agree.

[kalvi...@gmail.com]

Here is one thread discussing about porting/using bare-metal Ada in AVR controllers:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=117076

[Simon Clubley]

On 2012-10-10, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
> On Tue, 9 Oct 2012 23:23:11 +0000 (UTC), Simon Clubley wrote:
>
>> Let's make this discussion more tangible by using a specific example.
>>
>> The scenario: a hobbyist/academic researcher/whoever is building a
>> small computer controlled model aircraft, in the order of up to about
>> a metre in length for the fuselage.
>
> I have no idea about controlling an aircraft. Can one do it without a
> multitude of analogue inputs and outputs, rotary encoders etc?
>

[Remember we are talking about model aircraft here, not large human
carrying multi-million dollar/euro/pound aircraft.]

The interface problem is actually two sub-problems: (1) gathering sensor
data and (2) commanding the aircraft to move as a result of processing
the sensor data.

The input sensors are generally (but not always) digital these days.
For example, the low cost gyros and accelerometers you would typically
use usually have a SPI or I2C interface.

Commanding a model aircraft to move is done in exactly one way: by
sending command pulses to a standard R/C aircraft servo. The following
explains how these servos work:

http://en.wikipedia.org/wiki/Servo_%28radio_control%29

The length of the pulse determines the position of the servo.

Electronic speed controllers (the controller used to regulate power
to the electric motor driving the propeller) work in the same way;
pulses are sent along a command line.

These pulses are digital in nature; driven to logic 1 for a period of
time and then driven to logic 0 to end the pulse. They are ideally
suited to be connected to a GPIO line in output mode.

>> Question 1: if you could not use GPIO lines to control commodity
>> R/C components, how would you have the onboard computer control the
>> engine and flight control surfaces ?
>
> ARM boards look very much like a compromise. That rarely pays off. Likely
> there exist better solutions for a model aircraft, but I cannot judge that.
>

I would welcome suggestions as I cannot currently think of any viable
alternatives to a small and low power general purpose onboard computer.

>> To make this on topic for this newsgroup, this seems to be a common
>> hobbyist or researcher project in a number of circles, and is _exactly_
>> the type of project for which Ada would be very well suited indeed.
>
> How many people spend their time building model aircrafts? Could rail
> transport modeling be a better candidate?
>

When you look around, it seems a surprising amount of people do (or at
least they consider it). Compared to making a aircraft fly through the
air, rail transport modeling seems kind of boring in comparison. :-)

> Anyway, if you need an altimeter instrument for the ground control system,
> let me know. I maintain an instrumentation library in Ada.
>
>> Question 2: how would you put the idea of using Ada for this project
>> into someone's head and what changes to the Ada ecosystem would be
>> needed to make it viable for people with different ranges of embedded
>> experience to actually use Ada in this case ?
>
> I would tell him that he could use the same software during modeling and
> deployment phases, basically, doing much of the work in doors rather than
> in field.
>

The answer would need to be more specific than that; there already exist
testing environments which allow you to do some work on your control systems
indoors. For example, have a look at Flightgear: http://www.flightgear.org/

Quite a few people use it for developing parts of their system within a
simulated environment.

A person would generally need to be using arguments along the lines of
suggesting that Ada based development would result in more robust and/or
quicker to develop code.

[kalvi...@gmail.com]

Here is a nice page about Drones: http://diydrones.com/
Maybe this will give some hints about the size and power consumption restrictions. Anyway, these projects are good candidates for bare-metal Ada: Embedded, robust real-time systems.

[Tero Koskinen]

On Tue, 9 Oct 2012 08:10:44 +0000 (UTC)
Brian Drummond <br...@shapes.demon.co.uk> wrote:
> > I don't think this problem is a consequence of the Ada language
> > properties, but shows the relative commercial success and penetration of
> > C and Ada in small embedded systems.
>
> I think with ARM and AVR covered, Ada should be in a better place than it
> is.

For bigger ARMs (which run Linux) there is always Debian and its GNAT.
I have been successfully using Debian armhf on Gumstix Overo (ARM Cortex-A8)
for a while.

But of course, it would be nice to have good quality toolchain+runtime
for those smaller ARMs (like LPC2xxx, Cortex-Mx, etc).

> But even in the Arduino community, AVR-Ada goes almost unnoticed.
> So part of the problem is publicity and exposure, and those need not be
> expensive to address.

Some time ago I setup http://arduino.ada-language.com/ and have written up
a few articles there.

If you wish to contribute, fork https://bitbucket.org/tkoskine/arduino-blog
repository and send a pull request when you want me to merge your stuff
back in :). (I am not sure does the author go right, but it is probably
something that can be fixed.)

Site stats are currently following:
% grep Aug/2012 arduino.ada-language.com-access_log|wc -l
3900
% grep Sep/2012 arduino.ada-language.com-access_log|wc -l
4533
% grep Oct/2012 arduino.ada-language.com-access_log|wc -l
1821

(Those are raw hits, crawlers and other bots are included.)

>
> - Brian


--
Tero Koskinen - http://iki.fi/tero.koskinen/

[Rego, P.]

On Wednesday, October 10, 2012 4:36:01 AM UTC-3, Dmitry A. Kazakov wrote:

> > To make this on topic for this newsgroup, this seems to be a common
> > hobbyist or researcher project in a number of circles, and is _exactly_
> > the type of project for which Ada would be very well suited indeed.

Yes. Why do not use Ada for making reliable sw for models? I don't know many people doing this in Ada, but I'm trying to encourage some friends and some students to do the same when they build robots and a/c models. But I have to admit that sometimes it's difficult, due to the majority of available library for Arduinos are written in C, and the C 8-bits AVR community is huge, so many times I had to code some basic libs myself, instead of focusing on the real application. People from AVR-Ada (and the own project) helps so much on this. But once I had to convert an Ada code to C (oh God, I agree!), because I had a question, but it was easier to some C guys to understand the situation in C.

> Anyway, if you need an altimeter instrument for the ground control system,
> let me know. I maintain an instrumentation library in Ada.

It would be good to take a look.

> > Question 2: how would you put the idea of using Ada for this project
> > into someone's head and what changes to the Ada ecosystem would be
> > needed to make it viable for people with different ranges of embedded
> > experience to actually use Ada in this case ?

> I would tell him that he could use the same software during modeling and
> deployment phases, basically, doing much of the work in doors rather than
> in field.

I use to say he will be very benefit using Ada, and that he will not have much difficult in learning it. So I send some tutorial links, some papers :-) The benefits are much bigger than the costs.

[Rego, P.]

On Wednesday, October 10, 2012 10:13:41 AM UTC-3, Simon Clubley wrote:
> >> Question 1: if you could not use GPIO lines to control commodity
> >> R/C components, how would you have the onboard computer control the
> >> engine and flight control surfaces ?
> > ARM boards look very much like a compromise. That rarely pays off. Likely
> > there exist better solutions for a model aircraft, but I cannot judge that.
>
> I would welcome suggestions as I cannot currently think of any viable
> alternatives to a small and low power general purpose onboard computer.

I do. I use AVR boards to make this kind of control as hobby. In general they are very simpler when you compare computational power, but it fits well, depending on the application, and depending on what you want to embed on the target model. For example, you can include a simple model of aircraft dynamics calculation on an Arduino Mega ATmega2560P, but as your architecture grows (more devices, more packages, include RT mechanism, etc), the chip limitations begin to appear. For example, ATmega2560 has only 250 kbytes of flash, while you can include a TFcard on an ARM1176JZFS used on a Rhaspbery PI (I don't have one yet, but the spec say this). In the first, just 8 kB SRAM, the other, 256 MB RAM. You can buy an Arduino Mega by ~$15, a Raspberry Pi by ~$35+taxes. Of course they are from different computing scales. In general, buy an AVR/Arduino is cheaper than an ARM, and easier. My new Raspberry Pi has not arrived yet, 4 months after I bought; an Arduino board gets home in a few days. And when you project an aircraft model you always try to reduce cost and get the devices as quick as you are allowed to.

> > How many people spend their time building model aircrafts? Could rail
> > transport modeling be a better candidate?
>
> When you look around, it seems a surprising amount of people do (or at
> least they consider it). Compared to making a aircraft fly through the
> air, rail transport modeling seems kind of boring in comparison. :-)

I agree, lots of people doing this. And as a friend once told me...cars are boring, they don't fly! That's the idea :-)

[Dmitry A. Kazakov]

On Wed, 10 Oct 2012 08:40:00 -0700 (PDT), Rego, P. wrote:

> On Wednesday, October 10, 2012 4:36:01 AM UTC-3, Dmitry A. Kazakov wrote:
>
>> I maintain an instrumentation library in Ada.
>
> It would be good to take a look.

http://www.dmitry-kazakov.de/ada/aicwl.htm

[Simon Clubley]

On 2012-10-10, Rego, P. <pvr...@gmail.com> wrote:
> On Wednesday, October 10, 2012 10:13:41 AM UTC-3, Simon Clubley wrote:
>> >> Question 1: if you could not use GPIO lines to control commodity
>> >> R/C components, how would you have the onboard computer control the
>> >> engine and flight control surfaces ?
>> > ARM boards look very much like a compromise. That rarely pays off. Likely
>> > there exist better solutions for a model aircraft, but I cannot judge that.
>>
>> I would welcome suggestions as I cannot currently think of any viable
>> alternatives to a small and low power general purpose onboard computer.
>
> I do. I use AVR boards to make this kind of control as hobby. In general they
> are very simpler when you compare computational power, but it fits well,
> depending on the application, and depending on what you want to embed on the
> target model.

[snip]

In this context, I would still regard a AVR board as a general purpose
computer, but just a limited capability one.

When I wrote that comment, I got the feeling that Dmitry didn't like the
whole idea of using GPIO lines to control servos, and I got the impression
that he was thinking along the lines of using some task-specific
communications hardware, protocols and aviation specific computer hardware
to link everything together.

Unfortunately, I don't know of anything which would fit this role, given
the weight and budget constraints, hence my question.

>> > How many people spend their time building model aircrafts? Could rail
>> > transport modeling be a better candidate?
>>
>> When you look around, it seems a surprising amount of people do (or at
>> least they consider it). Compared to making a aircraft fly through the
>> air, rail transport modeling seems kind of boring in comparison. :-)
>
> I agree, lots of people doing this. And as a friend once told me...cars are
> boring, they don't fly! That's the idea :-)

:-)

[Yannick Duchêne (Hibou57)]

Le Sun, 07 Oct 2012 20:43:10 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
> There is a mental block most people have. They see only the hardware,
> assuming software kind of non-essential. But the costs of software
> developing, testing and maintenance are far bigger than ones of the
> hardware. Except for hard physical constraints (e.g. power consumption,
> weight, durability etc), hardware choice is subordinate.

Will quote this with reference on some other place in the future.
Copied/pasted in my notes.


--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Yannick Duchêne (Hibou57)]

Le Tue, 09 Oct 2012 15:18:29 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
> Yes. But even with many tasks active latencies under 100µs are doable.

> Not for an ARM of course.

I may have not read the thread carefully enough, but why this “not for an
ARM of course”? Clock speed? Hardware interface? Other reason? (that
thread drove me to try to learn a bit about the topic, which is new to me).

[Dmitry A. Kazakov]

On Thu, 11 Oct 2012 11:41:44 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Tue, 09 Oct 2012 15:18:29 +0200, Dmitry A. Kazakov
> <mai...@dmitry-kazakov.de> a écrit:
>> Yes. But even with many tasks active latencies under 100µs are doable.
>> Not for an ARM of course.
>
> I may have not read the thread carefully enough, but why this “not for an
> ARM of course”? Clock speed? Hardware interface? Other reason? (that
> thread drove me to try to learn a bit about the topic, which is new to me).

It was not so simple for us to do with an i5, impossible with an Atom 330.
ARM is in a different league.

But you never know before you started. And even then there are many reasons
why some quite powerful processor could fail miserably. We had a quite
embarrassing experience with some Freescale PPC.

[mjs...@scriptoriumdesigns.com]

On Monday, October 8, 2012 11:22:37 AM UTC-7, Dmitry A. Kazakov wrote:
>
> Why are people so obsessed with ARM? You could have a decent Atom-based
>
> board for same money. AMD Geode LX could be an alternative.
>
>
> Anyway, the thingy should run Linux. I believe there was a GNAT for ARM
>
> somewhere. Maybe others could point out its status.

I'm late to this discussion, but your comment is really out of touch with a vast segment of the embedded world. ARM is everywhere, with perhaps a dozen or more sources of ucontrollers not including captive sources. Even the lowest end parts run near 50MHz and have good amounts of memory, but nothing close to what would be required for Linux. Ada can certainly run on these parts (how much memory did the MIL-STD-1750A designs have 20-25 years ago?) This is an enormous untapped market, and a lot of us wonder why the heck it is being ignored.

Furthermore, it is a market where the next generation of students and hobbyists are moving to. Arduino has been very big, and it is now expanding to 32 bits. ST sells development boards for $10-$15 built around very powerful ARM parts. This level of hardware is begging for Ada support, but it's not there. If people could program this level of hardware in Ada they'd quickly come to appreciate the vast advantage Ada offers in embedded & realtime work. I can't fathom why GNAT and Ada supporters don't want to get on board.

[mjs...@scriptoriumdesigns.com]

On Tuesday, October 9, 2012 2:32:31 AM UTC-7, Dmitry A. Kazakov wrote:
> Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
>
> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
>
> cycle.

I've got one AVR project with interrupts every 60us, and I need <1us latency. The entire board is about 8 sq. cm. Should I port that over to Linux with 1000x the memory requirements, and if so, could I even get that kind of response? I think you have a very myopic view of what people are doing with low end (but still remarkably powerful) hardware.
>

> And who is talking about performance while choosing an ARM?
>
>
>
> > GNAT is running on ARM under RTEMS. I don't know what the current bare
>
> > metal status is for ARM, although people have posted in the past in
>
> > c.l.a about work they have done on this.

RTEMS takes on the order of 1MB of memory, I believe. Way too big for a great many otherwise useful 32-bit parts. Did the MIL-STD-1750A designs that used to run Ada all require 1MB? I know the Lego port doesn't require that much memory (the ARM on that platform has 256k of flash and 64k of RAM).

[Yannick Duchêne (Hibou57)]

Le Thu, 11 Oct 2012 17:22:33 +0200, <mjs...@scriptoriumdesigns.com> a
écrit:

> I can't fathom why GNAT and Ada supporters don't want to get on board.

The expectation should better mention Ada, not Ada and GNAT (*), as Ada is
one thing, GNAT is another. By the way, GNAT's target does not seems to be
hobbyists.

(*) I mean Ada is a standardized language, and GNAT is company providing
Ada related services.

[Patrick]

This has been a great thread, thanks to everyone for their posts.

In the end, Adacore is a company and they will, and can, only do what's best for them. As a community it would be good to come up with more options. My proposals were probably silly but can we brainstorm about possible solutions? None of them will be easy and we won't have a consensus but at least if some of us can form a camp and start working towards a goal that would be good.

[Dmitry A. Kazakov]

On Thu, 11 Oct 2012 08:44:39 -0700 (PDT), mjs...@scriptoriumdesigns.com
wrote:

> On Tuesday, October 9, 2012 2:32:31 AM UTC-7, Dmitry A. Kazakov wrote:
>> Huh, are you building bombs, guys? (:-)) For most physical processes 1ms,
>> even 10ms cycle is more than enough. Linux can easily deliver you 1ms
>> cycle.
>
> I've got one AVR project with interrupts every 60us, and I need <1us
> latency.

Like I said, mechanical processes are slow. And, anyway, there is no
affordable AD-DC converters to deliver 1us forward and backward conversion
time combined.

> The entire board is about 8 sq. cm. Should I port that over to
> Linux with 1000x the memory requirements, and if so, could I even get that
> kind of response?

Controlling mechanical processes do not need such responses. I cannot
answer your question without knowing what are you going to achieve.

>> And who is talking about performance while choosing an ARM?
>>
>>> GNAT is running on ARM under RTEMS. I don't know what the current bare
>>> metal status is for ARM, although people have posted in the past in
>>> c.l.a about work they have done on this.
>
> RTEMS takes on the order of 1MB of memory, I believe. Way too big for a
> great many otherwise useful 32-bit parts.

How could 1MB be too big for 32-bit address space?

In any case, memory footprint is my least concern when designing an
embedded application.

[mjs...@scriptoriumdesigns.com]

On Sunday, October 7, 2012 1:33:13 PM UTC-7, Niklas Holsti wrote:
> My favourite for a target would be ARM Cortex M0-M4.

This one target (with limited e.g. Ravenscar tasking) would make Ada vastly more visible and accessible to its targeted audience of embedded, realtime developers. Personally I'd pay as much as $1000 for such a toolchain, simply for my own hobby and prototyping work. I'd probably make that back in a week.

[Dmitry A. Kazakov]

On Thu, 11 Oct 2012 08:22:33 -0700 (PDT), mjs...@scriptoriumdesigns.com
wrote:

> I'm late to this discussion, but your comment is really out of touch with
> a vast segment of the embedded world.

Certainly so.

> ARM is everywhere, with perhaps a
> dozen or more sources of ucontrollers not including captive sources.

As well as C, which is everywhere, and is making me wonder what kind of
problem people have, if they consider C as a part of the solution.

> Furthermore, it is a market where the next generation of students and
> hobbyists are moving to.

The students I am aware of are taught on DSP and SPS. Embedded world is
large.

[Niklas Holsti]

There seems to be a pretty clear division into two half-worlds: one that
is wall-socket-powered and uses powerful processors similar to PCs but
ruggedized and with more I/O, and the other that is battery-powered and
uses microcontrollers.

For some years I received a free magazine (possibly EDN?) that came
accordingly in two editions. The big-embedded edition advertised
gigahertz 32/64-bit processors with gigabytes of DRAM and two-level
caches, running embedded Linux or Windows; the small-embedded advertised
AVRs and the like, running some small RTOS or bare metal. Really, there
was a gulf in between, that was perhaps thinly filled with RTEMS-like
and ucLinux-like things, running on 32-bit microcontrollers with a
little external memory. This space now has Raspberry Pi and other
micro-PCs in it, which is a good development, I think.

[mjs...@scriptoriumdesigns.com]

On Thursday, October 11, 2012 9:20:25 AM UTC-7, Dmitry A. Kazakov wrote:
> On Thu, 11 Oct 2012 08:44:39 -0700 (PDT), mjs...@scriptoriumdesigns.com
>
> wrote:
>
>
> > I've got one AVR project with interrupts every 60us, and I need <1us
>
> > latency.
>
>
>
> Like I said, mechanical processes are slow. And, anyway, there is no
>
> affordable AD-DC converters to deliver 1us forward and backward conversion
>
> time combined.

I didn't say anything about ADC/DAC (though in fact the application is driving 18 software PWM channels, so it is an analog application).

> > The entire board is about 8 sq. cm. Should I port that over to
>
> > Linux with 1000x the memory requirements, and if so, could I even get that
>
> > kind of response?
>
>
>
> Controlling mechanical processes do not need such responses. I cannot
>
> answer your question without knowing what are you going to achieve.

One typical analog process that even an 8-bit device can control is brushless DC motor control. AVRs are used in this all the time, and certainly any low-end ARM can do it. These motors can run up to 50000 RPM, with control loops running at 1ms and control functions running every 40us (Atmel AVR492).

>
> >> And who is talking about performance while choosing an ARM?
>
> >>
>
> >>> GNAT is running on ARM under RTEMS. I don't know what the current bare
>
> >>> metal status is for ARM, although people have posted in the past in
>
> >>> c.l.a about work they have done on this.
>
> >
>
> > RTEMS takes on the order of 1MB of memory, I believe. Way too big for a
>
> > great many otherwise useful 32-bit parts.
>
>
>
> How could 1MB be too big for 32-bit address space?
>
>
>
> In any case, memory footprint is my least concern when designing an
>
> embedded application.

These 32-bit ARM parts can have as little as 8k of flash, and they range up from there to perhaps 1MB onboard for the largest of the lower-end parts. So the vast majority of them could not run an RTEMS-based Ada application.

[mjs...@scriptoriumdesigns.com]

Here's today's answer to "Why the focus on ARM?"

http://www.embedded.com/electronics-blogs/significant-bits/4397956/Toward-a-Two-Processor-World?cid=Newsletter+-+Whats+New+on+Embedded.com

[Lucretia]

On Sunday, 7 October 2012 23:35:24 UTC+1, Simon Clubley wrote:

> Someone here in c.l.a has also done some work on making GNAT run on
>
> bare metal ARM boards. I do not know the current status of that work.

That would be me. At present, no further along, but I've not really spent much time on it. The quick test results of STM32F4DISCOVERY board with Ada on is here: https://github.com/Lucretia/tamp/tree/master/blink

I spent last week documenting what I need to do to get a decent runtime going for Cortex boards (and similar other arches), so I am looking into it again. This would provide a port of CMSIS + a RTOS kernel which provides tasking support, enough for a Ravenscar RTS.

Luke.

[Lucretia]

On Tuesday, 9 October 2012 09:02:44 UTC+1, kalvi...@gmail.com wrote:

> It is a shame, that we don't have Ada support for these bare metal boards. If we could have an Ada compiler for popular microcontrollers like ARM and MIPS (PIC32), Ada might get more popular as the hobbyist engineers could play with Ada and see its strength, and dispel the myths regarding Ada.

I agree and this is something I want to do. I have a PIC32 board (Uno32) as well, but so far have not tried any Ada with it as the compiler for this is based on an ancient gcc and trying to create patches for newer gcc's is difficult due to the fact that there are bits that have been removed from the mips stuff in gcc and the pic32 compiler still has it. I will be trying gcc 4.8 once I get a new source tree going.

Luke.

[Simon Clubley]

On 2012-10-12, Lucretia <lague...@googlemail.com> wrote:
>
> I agree and this is something I want to do. I have a PIC32 board (Uno32) as
> well, but so far have not tried any Ada with it as the compiler for this is
> based on an ancient gcc and trying to create patches for newer gcc's is
> difficult due to the fact that there are bits that have been removed from the
> mips stuff in gcc and the pic32 compiler still has it. I will be trying gcc 4.8
> once I get a new source tree going.
>

Do you happen to know what bits have been removed from the FSF MIPS tree ?

Is it something which affects C code as well or just any future potential
Ada port ?

The PIC32MX MCUs are also on my list of things to look at in the future
and it would be nice to be able to use the mainline FSF gcc version instead
of the Microchip branch. It would be even nicer to be able to run Ada on
them as well. :-)

Thanks,

[Simon Clubley]

On 2012-10-12, Lucretia <lague...@googlemail.com> wrote:
>

> That would be me. At present, no further along, but I've not really spent
> much time on it. The quick test results of STM32F4DISCOVERY board with Ada on
> is here: https://github.com/Lucretia/tamp/tree/master/blink
>

Thanks. I will have a look at what you have there.