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

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?

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

[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

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

[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.

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

[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

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

[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
      .      @       .

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

[Simon Clubley]

On 2012-10-07, Dmitry A. Kazakov <mailbox@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

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

[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?

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

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

[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.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mailbox@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 ?

Simon.

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

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

[kalvin.news]

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

- Kalvin

The Ada community's attitude, was: Re: Ada, the best language with the not-so-best tool chain

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

Simon.

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

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

[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?

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

[Dmitry A. Kazakov]

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

> On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

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

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

[Dmitry A. Kazakov]

On Mon, 08 Oct 2012 14:40:17 +0200, Georg Bauhaus wrote:

> 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?

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...

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

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

[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.

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

[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.

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

[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.

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

[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.

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

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

[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.

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

[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.

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

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

[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.

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

[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.

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

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

[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

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

[Simon Wright]

Patrick <patrick@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/>

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

[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.

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

[kalvin.news]

maanantai, 8. lokakuuta 2012 21.22.37 UTC+3 Dmitry A. Kazakov kirjoitti:
> 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.
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

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

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

[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.

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

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

[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.

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

[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 :-)

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

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

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

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

[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.


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

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

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

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

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

[Simon Clubley]

On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

Simon.

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

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

[Niklas Holsti]

On 12-10-08 15:02 , kalvin.news@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).

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

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

[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.

Simon.

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

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

[Ludovic Brenta]

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.

* 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.

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

[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....

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

[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.

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

[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 !

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

[Stephen Leake]

Patrick <patrick@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

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

[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 :)

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

[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
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

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

[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.

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

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

[kalvin.news]

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

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

[kalvin.news]

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

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

[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

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

[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.

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

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

[Dmitry A. Kazakov]

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

> On 2012-10-08, Dmitry A. Kazakov <mailbox@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.

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

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

[pavel.klinkovsky]

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

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

[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.

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

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

[kalvin.news]

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

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

[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.

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

[Simon Clubley]

On 2012-10-09, Dmitry A. Kazakov <mailbox@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.

Simon.

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

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

[Dmitry A. Kazakov]

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? 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... (:-))

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

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

[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

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

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 02:57:44 -0700 (PDT), kalvin.news@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.

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

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

[kalvin.news]

tiistai, 9. lokakuuta 2012 15.30.39 UTC+3 Dmitry A. Kazakov kirjoitti:
> On Tue, 9 Oct 2012 02:57:44 -0700 (PDT), kalvin.news@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/

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

[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.

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

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

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 05:51:51 -0700 (PDT), kalvin.news@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.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[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�s. 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�s are doable. Not
for an ARM of course.

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

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

[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!

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

[kalvin.news]

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

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

[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.

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

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

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 08:53:01 -0700 (PDT), kalvin.news@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

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

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

[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"
> <mailbox@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.

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

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

[kalvin.news]

tiistai, 9. lokakuuta 2012 20.08.16 UTC+3 Dmitry A. Kazakov kirjoitti:
> On Tue, 9 Oct 2012 08:53:01 -0700 (PDT), kalvin.news@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

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

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

[Dmitry A. Kazakov]

On Tue, 9 Oct 2012 11:26:52 -0700 (PDT), kalvin.news@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...

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

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

[Simon Clubley]

On 2012-10-09, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 9 Oct 2012 08:53:01 -0700 (PDT), kalvin.news@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 ?

Simon.

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

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

[Stephen Leake]

Patrick <patrick@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

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

[Stephen Leake]

kalvin.news@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

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

[Niklas Holsti]

On 12-10-10 08:56 , Stephen Leake wrote:
> kalvin.news@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
      .      @       .

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

[Ludovic Brenta]

Niklas Holsti writes:
> On 12-10-10 08:56 , Stephen Leake wrote:
>> kalvin.news@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.

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

[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.

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

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

[Niklas Holsti]

On 12-10-10 10:06 , Ludovic Brenta wrote:
> Niklas Holsti writes:
>> On 12-10-10 08:56 , Stephen Leake wrote:
>>> kalvin.news@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.

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

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

[kalvin.news]

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

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

[Simon Clubley]

On 2012-10-10, Dmitry A. Kazakov <mailbox@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.

Simon.

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

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

[kalvin.news]

keskiviikko, 10. lokakuuta 2012 16.13.41 UTC+3 Simon Clubley kirjoitti:
> On 2012-10-10, Dmitry A. Kazakov <mailbox@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.
> 
> 
> 
> Simon.
> 
> 
> 
> -- 
> 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> 
> Microsoft: Bringing you 1980s technology to a 21st century world

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.

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

[Tero Koskinen]

On Tue, 9 Oct 2012 08:10:44 +0000 (UTC)
Brian Drummond <brian@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/

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

[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.

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

[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 :-)

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

[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

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

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

[Simon Clubley]

On 2012-10-10, Rego, P. <pvrego@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 :-)

:-)

Simon.

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

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

[Yannick Duchêne (Hibou57)]

Le Sun, 07 Oct 2012 20:43:10 +0200, Dmitry A. Kazakov  
<mailbox@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

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

[Yannick Duchêne (Hibou57)]

Le Tue, 09 Oct 2012 15:18:29 +0200, Dmitry A. Kazakov  
<mailbox@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).


-- 
“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

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

[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  
> <mailbox@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.

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

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

[mjsilva]

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.

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

[mjsilva]

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

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

[Yannick Duchêne (Hibou57)]

Le Thu, 11 Oct 2012 17:22:33 +0200, <mjsilva@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.

-- 
“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

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

[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.

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

[Dmitry A. Kazakov]

On Thu, 11 Oct 2012 08:44:39 -0700 (PDT), mjsilva@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.

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

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

[mjsilva]

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.

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

[Dmitry A. Kazakov]

On Thu, 11 Oct 2012 08:22:33 -0700 (PDT), mjsilva@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.

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

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

[Niklas Holsti]

On 12-10-11 19:31 , Dmitry A. Kazakov wrote:
> On Thu, 11 Oct 2012 08:22:33 -0700 (PDT), mjsilva@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.

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.

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

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

[mjsilva]

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), mjsilva@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.

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

[mjsilva]

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

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

[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.

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

[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.

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

[Simon Clubley]

On 2012-10-12, Lucretia <laguest9000@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.

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

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

[Simon Clubley]

On 2012-10-12, Lucretia <laguest9000@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.

Simon.

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

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

[Lucretia]

On Friday, 12 October 2012 13:45:20 UTC+1, Simon Clubley  wrote:

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

I know of one MIPS INSN macros that was removed, I notified the PIC32 GCC maintainer on Github about it, there could be a ton more. I don't know as this stuff isn't documented and the source *is not* documentation in this case.
 
> Is it something which affects C code as well or just any future potential
> 
> Ada port ?

It's code gen, so all front-ends.

> 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

Yup, and seeing as GCC can generate MIPS16e it should be possible.

Luke.

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

[Lucretia]

On Friday, 12 October 2012 13:47:09 UTC+1, Simon Clubley  wrote:

> > is here: https://github.com/Lucretia/tamp/tree/master/blink
> 
> Thanks. I will have a look at what you have there.

The code that does the general set up was a very fast "port" of the existing C file which does this. It's certainly not what would be used in final code as the interfacing is terrible also. A quick hackup to get it to work, and it does.

Luke.

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

[kalvin.news]

perjantai, 12. lokakuuta 2012 15.09.54 UTC+3 Lucretia kirjoitti:
> 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.

Hi Luke,

Just placed an order for the STM32F4DISCOVERY at eBay. I am really looking forward to this one :)

Br,
Kalvin

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

[Simon Clubley]

On 2012-10-12, Lucretia <laguest9000@googlemail.com> wrote:
> On Friday, 12 October 2012 13:47:09 UTC+1, Simon Clubley  wrote:
>
>> > is here: https://github.com/Lucretia/tamp/tree/master/blink
>> 
>> Thanks. I will have a look at what you have there.
>
> The code that does the general set up was a very fast "port" of the existing C
> file which does this. It's certainly not what would be used in final code as
> the interfacing is terrible also. A quick hackup to get it to work, and it
> does.
>

Thanks. I have now had a look at this.

Over the years I have thought about trying to do a bare metal Ada port for
ARM, but I never actually got around to looking in detail to see what is
required. Instead, I have either done something on top of RTEMS or just
used C.

Even if you do nothing else with it, this code of yours is a useful
starting point to see what steps are required to make gcc and friends
support bare metal Ada.

Simon.

PS: BTW, The System_Name in stm32f4/system.ads is wrong. :-)

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

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

[phone.john.kern]

On Monday, October 8, 2012 2:22:37 PM UTC-4, Dmitry A. Kazakov wrote:

> 
> ... I believe there was a GNAT for ARM
> somewhere. Maybe others could point out its status.

GNAT for Lego Mindstorms is a Free/Open Source ARM targeted Ada (2005/12) cross compiler that runs on either ORK, or in the earlier version some kind of Open OSEK thingy which, by example, cannot be all that heavyweight.

http://libre.adacore.com/academia/mindstorms/

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

[phone.john.kern]

On Tuesday, October 16, 2012 4:05:27 PM UTC-4, Simon Clubley wrote:

> 
> 
> 
> Over the years I have thought about trying to do a bare metal Ada port for
> 
> ARM, but I never actually got around to looking in detail to see what is
> 
> required. Instead, I have either done something on top of RTEMS or just
> 
> used C.
> 
> 

Again, see http://libre.adacore.com/academia/mindstorms/

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

[phone.john.kern]

On Thursday, October 11, 2012 1:44:11 PM UTC-4, (unknown) wrote:
> 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

http://libre.adacore.com/academia/mindstorms/

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

[phone.john.kern]

On Thursday, October 11, 2012 11:22:33 AM UTC-4, (unknown) wrote:
> 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.

http://libre.adacore.com/academia/mindstorms/

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

[Lucretia]

On Tuesday, 16 October 2012 21:05:27 UTC+1, Simon Clubley  wrote:

> PS: BTW, The System_Name in stm32f4/system.ads is wrong. :-)

Do you mean the fact that GNAT uses an enum by default or the fact that the text is wrong?

Luke.

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

[Simon Clubley]

On 2012-10-18, Lucretia <laguest9000@googlemail.com> wrote:
> On Tuesday, 16 October 2012 21:05:27 UTC+1, Simon Clubley  wrote:
>
>> PS: BTW, The System_Name in stm32f4/system.ads is wrong. :-)
>
> Do you mean the fact that GNAT uses an enum by default or the fact that the
> text is wrong?
>

I meant the text itself was wrong.

It was just a minor little thing I noticed while looking at the code which
I thought I would just mention in passing.

Like I said previously however, the code itself looks like it will be a
useful starting point for someone wanting to do a bare metal Ada port.

Simon.

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

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

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:k4ve02$g5a$1@dont-email.me...
...
> 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.

I hate to break this to you, but no *professional developer* cares what a 
"hobbyist" needs for software development. AdaCore has made a lot of useful 
things available, but all of those were developed for big, paying, 
professional developers.

Those of us in the software business can't develop things only needed by 
hobbyists (who aren't likely to be able to pay for it) -- what are we going 
to do to pay for our groceries, our gas, our mortgage, etc.? We can only 
build things needed by paying customers, and hopefully those will be useful 
for others as well.

There's an old saying: "beggars can't be choosers". That surely applies to 
"free software". Either pay for it, build it yourself (or convince some 
other hobbyist to build it for you), or use what's available.

In any case, I've never heard of Ada being seriously used on 8-bit 
processors. Ever! Our old Z-80 compiler (for a subset of Ada 83) was 
certainly 8-bit, but I don't recall anyone using it as an embedded system. 
We did have customers for our 16-bit 8086 compilers (usually on 186 boards) 
to develop bare machine products (mostly in the late 1980's and ealry 
1990's). Today, as Dmitry has noted, paying customers are only interested in 
various RTOSes; no one seems interested in bare machines (for any target). I 
personally think this is sad; an Ada run-time is all the RTOS that you need 
for most purposes -- but fighting the market is a losing game.

After all, nothing is truely "free"; you *always* pay for it somehow. Either 
in a lack of functionality, or by loss of privacy (think ads), or by a loss 
of competion (by forcing competitors out of the market), or by folding it 
into the price of something else (hardware boards).

                            Randy.

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

[Randy Brukardt]

<mjsilva@scriptoriumdesigns.com> wrote in message 
news:a929d92c-6f33-4c9b-8a1c-1a43ba403758@googlegroups.com...
...
>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.

Simple math. The expectation is that development systems for this sort of 
board are free (or more accurately, included in the purchase price). (more 
below).

>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.

You're not trying too hard if you "can't fathom" why this makes no sense. 
There's no money to be made, and as with everything, it comes down to money. 
As I noted, such development systems are typically free. Simple math shows 
the problem: $0*<enormous number> = $0. I'm pretty sure that AdaCore's many 
employees don't work for free, so there has to be a higher revenue 
projection than this in order to make a project viable. If people were 
actually willing to pay for such systems, it might be worth taking a chance 
(because $49*<enormous number> does work; that was Borland's model back in 
the day) -- but in today's software climate, no way.

A company might develop something if a major customer pays for part of the 
development (RRS usually split the development costs with customers if we 
retained the rights to the resulting products). But in tha absence of that, 
it simply doesn't make any sense.

Obviously, some group of hobbyists could get to together and create 
something (which is where the AVR-Ada and Mindstorms Ada came from), but 
it's a big job and its unlikely that many targets would come from it. And 
the Ada community just isn't large enough to have all of the bases covered 
(or even a reasonable percentage).

That's the reality -- and it isn't likely to change. Unless the board 
manufacturers themselves start supporting Ada development systems, I don't 
think there will ever be many choices for bare/small targets. (Especially as 
Ada *never* has been used for small targets, even back in the 1980s when 
there was a lot of pressure from the DoD to do so.)

Feel free to prove me wrong. I'd surely be happy if that was the case - I 
want to see Ada succeed. (I spent most of my younger years fighting against 
economics -- and economics *always* wins in the end.)

                                       Randy.

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

[Jeffrey Carter]

On 10/18/2012 03:33 PM, Randy Brukardt wrote:
 >
 > That's the reality -- and it isn't likely to change. Unless the board
 > manufacturers themselves start supporting Ada development systems, I don't
 > think there will ever be many choices for bare/small targets. (Especially as
 > Ada *never* has been used for small targets, even back in the 1980s when
 > there was a lot of pressure from the DoD to do so.)

Wasn't the "Ada Beats Assembler" project a small target? I recall that the 
expectation was that Ada would be neither small enough to fit in the available 
memory nor fast enough to meet the real-time deadlines; in the end, Ada was 
faster and smaller than assembler.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

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

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:k5q16s$jmv$1@dont-email.me...
> On 10/18/2012 03:33 PM, Randy Brukardt wrote:
> >
> > That's the reality -- and it isn't likely to change. Unless the board
> > manufacturers themselves start supporting Ada development systems, I 
> > don't
> > think there will ever be many choices for bare/small targets. 
> > (Especially as
> > Ada *never* has been used for small targets, even back in the 1980s when
> > there was a lot of pressure from the DoD to do so.)
>
> Wasn't the "Ada Beats Assembler" project a small target? I recall that the 
> expectation was that Ada would be neither small enough to fit in the 
> available memory nor fast enough to meet the real-time deadlines; in the 
> end, Ada was faster and smaller than assembler.

I remember such a project from AETech. They were using a repackaged version 
of our MS-DOS compiler (that is, Janus/Ada), and thus the target had to be 
an 8088 or 80186. Neither of which is 8-bit, or all that "small". (We had a 
number of customers using our compiler for bare 80186 targets.) Those 8088 
systems usually had 64K or more of ROM, which is plenty for a 16-bit 
Janus/Ada program. (After all, we started out fitting the entire compiler 
into 48K on CP/M systems; a little control program is a piece of cake. ;-)

As I said earlier, I'm not aware of anyone using our Z-80 compiler on a bare 
board (although someone might have been able to do so without telling us - 
in those days, we provided the run-time source with the compiler, so someone 
could have modified it themselves). And so far as I know, our Z-80 compiler 
(and a couple of other Z-80 compilers on CP/M) was the only 8-bit target 
available. (I don't think there ever was a validated 8-bit target; plenty of 
16-bit targets, but no 8-bit.)

                                 Randy.

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

[Yannick Duchêne (Hibou57)]

Le Fri, 19 Oct 2012 00:52:09 +0200, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:

> On 10/18/2012 03:33 PM, Randy Brukardt wrote:
>  >
>  > That's the reality -- and it isn't likely to change. Unless the board
>  > manufacturers themselves start supporting Ada development systems, I  
> don't
>  > think there will ever be many choices for bare/small targets.  
> (Especially as
>  > Ada *never* has been used for small targets, even back in the 1980s  
> when
>  > there was a lot of pressure from the DoD to do so.)
>
> Wasn't the "Ada Beats Assembler" project a small target? I recall that  
> the expectation was that Ada would be neither small enough to fit in the  
> available memory nor fast enough to meet the real-time deadlines; in the  
> end, Ada was faster and smaller than assembler.

Something you made me remember about:
[Ada Outperforms Assembly: A Case  
Study](http://www.seas.gwu.edu/~adagroup/sigada-website/lawlis.html)

-- 
“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

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

[Jeffrey Carter]

On 10/18/2012 04:14 PM, Randy Brukardt wrote:
>
> I remember such a project from AETech. They were using a repackaged version
> of our MS-DOS compiler (that is, Janus/Ada), and thus the target had to be
> an 8088 or 80186. Neither of which is 8-bit, or all that "small". (We had a
> number of customers using our compiler for bare 80186 targets.) Those 8088
> systems usually had 64K or more of ROM, which is plenty for a 16-bit
> Janus/Ada program. (After all, we started out fitting the entire compiler
> into 48K on CP/M systems; a little control program is a piece of cake. ;-)

No, as pointed out in the article Duch�ne referenced, this was a Tartan compiler 
targeting a TI DSP. The code had to fit in 2K.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

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

[Mark Lorenzen]

Den torsdag den 18. oktober 2012 23.53.55 UTC+2 skrev Randy Brukardt:
> 
[...]
> 1990's). Today, as Dmitry has noted, paying customers are only interested in 
> 
> various RTOSes; no one seems interested in bare machines (for any target). I 
> 
> personally think this is sad; an Ada run-time is all the RTOS that you need 

We are actually using GNAT Pro for LEON 3 bare-board development. All the juicy goodness of the Ravenscar tasking in Ada and no RTOS :-)

Regards,

Mark L

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

[Patrick]

> I hate to break this to you, but no *professional developer* cares what a
> "hobbyist" needs for software development. AdaCore has made a lot of useful
> things available, but all of those were developed for big, paying,
> professional developers.

I think this is exactly what is wrong with Ada and what needs to be fixed or it will die. I don't think we should look to private companies to solve our community problems, they have to think of their own survival. My suggestions might have been silly but can anyone, please, make a technical suggestion as to what we could do as a community to make Ada more portable and/or suitable for bare metal use ?

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

[Yannick Duchêne (Hibou57)]

Le Fri, 19 Oct 2012 16:09:26 +0200, Patrick  
<patrick@spellingbeewinnars.org> a écrit:

>> I hate to break this to you, but no *professional developer* cares what  
>> a
>> "hobbyist" needs for software development. AdaCore has made a lot of  
>> useful
>> things available, but all of those were developed for big, paying,
>> professional developers.
>
> I think this is exactly what is wrong with Ada and what needs to be  
> fixed or it will die.
Will die for whom? Not for every‑one, and certainly not for people to  
which it values enough. Note how the standard is in better health than  
that of some more widespread languages (just thing of what's broken with  
the switch to Python 3). In some way, it is less dying than some more  
noisy.

> I don't think we should look to private companies to solve our community  
> problems, they have to think of their own survival. My suggestions might  
> have been silly but can anyone, please, make a technical suggestion as  
> to what we could do as a community to make Ada more portable and/or  
> suitable for bare metal use ?
Always the same story as for many other things too… Could make things  
viable and valuable be an option too?


-- 
“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

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

[Patrick]

> Will die for whom? Not for every-one, and certainly not for people to  
> which it values enough.

This is just my uneducated opinion but I am guessing that companies like Adacore are "riding out" projects started before the DOD dropped the Ada mandate. It's great that the boeing 787 has Ada but if the 777 was C++ would they have switched to Ada? I think for the language to stay viable there has to be a "grass roots" base and that starts with it being easy to use for the everyday hobbyist.

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

[Vinzent Höfler]

Patrick <patrick@spellingbeewinnars.org> wrote:

> This is just my uneducated opinion but I am
> guessing that companies like Adacore are
> "riding out" projects started before the DOD
> dropped the Ada mandate.

Can't speak for Adacore, but there's never been an «Ada mandate» in 
Europe and we're just one of Adacore's customers there.


Vinzent.

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

[Dmitry A. Kazakov]

On Fri, 19 Oct 2012 07:09:26 -0700 (PDT), Patrick wrote:

>> I hate to break this to you, but no *professional developer* cares what a
>> "hobbyist" needs for software development. AdaCore has made a lot of useful
>> things available, but all of those were developed for big, paying,
>> professional developers.
> 
> I think this is exactly what is wrong with Ada and what needs to be fixed
> or it will die.

If you want to fix it you must run for President or at least Senate,
because it is the problem of software industry, not Ada's problem.

> I don't think we should look to private companies to solve
> our community problems, they have to think of their own survival.

So have individuals as well. If not private companies then academia, but
contributors must get money for living. Unfortunately academia is even less
interested in doing anything useful than private companies.

> My
> suggestions might have been silly but can anyone, please, make a technical
> suggestion as to what we could do as a community to make Ada more portable
> and/or suitable for bare metal use ?

You need many volunteers and a backdoor to the board vendor (usually they
are very uncooperative). As for technicalities, it seems that you want OS
functionality for bare board. Making an OS without naming it so?

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

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

[Simon Clubley]

On 2012-10-19, Patrick <patrick@spellingbeewinnars.org> wrote:
>> Will die for whom? Not for every-one, and certainly not for people to  
>> which it values enough.
>
> This is just my uneducated opinion but I am guessing that companies like
> Adacore are "riding out" projects started before the DOD dropped the Ada
> mandate. It's great that the boeing 787 has Ada but if the 777 was C++ would
> they have switched to Ada? I think for the language to stay viable there has
> to be a "grass roots" base and that starts with it being easy to use for the
> everyday hobbyist.

Patrick is absolutely correct about the latter bit and I've strongly believed
for some time there's a good element of truth to the first bit as well.

I was going to have another go at trying to explain things, but instead I
will just ask a simple question: What are the dominant programming languages
on the F-35 and why ?

If people here will not listen to me, try listening to one of your own:

https://journal.thecsiac.com/issue/53/158

|About the Author:
|
|John H. Robb is the Senior Manager of the F-35 Joint Strike Fighter Air
|Vehicle Software team at Lockheed Martin Aeronautics Fort Worth.

He says Ada was the better language. I certainly agree with that.

He also says (on choosing C and C++ instead of Ada) :

|Primary factors in this choice were training availability, tool support, and
|processor support. Another key factor was type casting, not as a language
|feature, but as a hiring feature. Many of the university students simply
|refused to work Ada as it was not seen as a marketable experience base. When
|all factors were considered, C++ and C emerged as the languages of choice
|(these depending on the processor chosen).

That's exactly what I and others have been trying to tell people here.
I wish I had known about this article a couple of weeks ago.

It's easy to ride on inertia for a while when you have a installed base and
can convince yourself that everything is ok. Unfortunately, in the end, that
usually only turns out to be a temporary thing.

Ada is going to be around for existing systems for a long time. If you want
Ada to actually _grow_ instead of declining however, you need to expose
people to Ada early on before the above opinions have had a chance to form,
and for the most part that means:

(a) catching them while they are doing projects on their own time,

(b) giving them tools which will work on the hobbyist/low end boards they
will be experimenting with, and

(c) understanding that hobbyists have a different ecosystem to the ones you
are used to, but which serves them well given the environment they operate
within and the projects they are typically interested in.

Simon.

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

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

[Yannick Duchêne (Hibou57)]

The picture you summarised is too much simplified. Programming as a Human  
Activity is a lot impacted by human behaviours (*). May be more explicit  
tomorrow, as I feel tired right now, and will read the document you  
pointed, in its entirety in the mean time. Good pointer otherwise.


(*) Economy and the relation to it, is one part of the behaviour.


Le Fri, 19 Oct 2012 19:30:22 +0200, Simon Clubley  
<clubley@remove_me.eisner.decus.org-earth.ufp> a écrit:

> On 2012-10-19, Patrick <patrick@spellingbeewinnars.org> wrote:
>>> Will die for whom? Not for every-one, and certainly not for people to
>>> which it values enough.
>>
>> This is just my uneducated opinion but I am guessing that companies like
>> Adacore are "riding out" projects started before the DOD dropped the Ada
>> mandate. It's great that the boeing 787 has Ada but if the 777 was C++  
>> would
>> they have switched to Ada? I think for the language to stay viable  
>> there has
>> to be a "grass roots" base and that starts with it being easy to use  
>> for the
>> everyday hobbyist.
>
> Patrick is absolutely correct about the latter bit and I've strongly  
> believed
> for some time there's a good element of truth to the first bit as well.
>
> I was going to have another go at trying to explain things, but instead I
> will just ask a simple question: What are the dominant programming  
> languages
> on the F-35 and why ?
>
> If people here will not listen to me, try listening to one of your own:
>
> https://journal.thecsiac.com/issue/53/158
>
> |About the Author:
> |
> |John H. Robb is the Senior Manager of the F-35 Joint Strike Fighter Air
> |Vehicle Software team at Lockheed Martin Aeronautics Fort Worth.
>
> He says Ada was the better language. I certainly agree with that.
>
> He also says (on choosing C and C++ instead of Ada) :
>
> |Primary factors in this choice were training availability, tool  
> support, and
> |processor support. Another key factor was type casting, not as a  
> language
> |feature, but as a hiring feature. Many of the university students simply
> |refused to work Ada as it was not seen as a marketable experience base.  
> When
> |all factors were considered, C++ and C emerged as the languages of  
> choice
> |(these depending on the processor chosen).
>
> That's exactly what I and others have been trying to tell people here.
> I wish I had known about this article a couple of weeks ago.
>
> It's easy to ride on inertia for a while when you have a installed base  
> and
> can convince yourself that everything is ok. Unfortunately, in the end,  
> that
> usually only turns out to be a temporary thing.
>
> Ada is going to be around for existing systems for a long time. If you  
> want
> Ada to actually _grow_ instead of declining however, you need to expose
> people to Ada early on before the above opinions have had a chance to  
> form,
> and for the most part that means:
>
> (a) catching them while they are doing projects on their own time,
>
> (b) giving them tools which will work on the hobbyist/low end boards they
> will be experimenting with, and
>
> (c) understanding that hobbyists have a different ecosystem to the ones  
> you
> are used to, but which serves them well given the environment they  
> operate
> within and the projects they are typically interested in.
>
> Simon.
>


-- 
“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

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

[Anh Vo]

On Friday, October 19, 2012 7:56:45 AM UTC-7, Patrick wrote:
> > It's great that the boeing 787 has Ada but if the 777 was C++ would they have switched to Ada?

777 has Ada in critical control systems including breaking systems.

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

[Adam Beneschan]

On Friday, October 19, 2012 11:24:07 AM UTC-7, Anh Vo wrote:
> On Friday, October 19, 2012 7:56:45 AM UTC-7, Patrick wrote:
> 
> > > It's great that the boeing 787 has Ada but if the 777 was C++ would they have switched to Ada?
> 
> 777 has Ada in critical control systems including breaking systems.

I'm not aware of any systems in the 777 that got broken by Ada.  (Did you mean "braking"???  :) :) :)

                              -- Adam

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

[Georg Bauhaus]

On 19.10.12 19:30, Simon Clubley wrote:
> before the above opinions have had a chance to form

Opinions and CVs. Interesting observation. CVs affecting
the software crisis.

An important task, then, from the hiring organisation's
perspective (as well as from a general perspective),
is twofold, I think:

1) Make HR people more open to the idea that a good
programmer is a good programmer. The language does
not matter that much, as long as he/she know the basics
of programming.

2) Make programmers and managers open to the idea that
spending both company money and company time on getting
acquainted with "the" tools/special libraries, and other things
of medium half life will help mostly those who sell tools,
special libraries, and things of medium half life.
Not the hiring organisation.

Consequence of 1 + 2:
Everyone understands that programmers are working as
programmers because nothing else can work like a programmer.
No tool, no library, and no things of medium half life in
particular. A niche language in a CV is then just a good
as the currently popular thing, as long as the programmer
is able to demonstrate sufficient programming abilities.

Of course, I'm overly optimistic. Everyone is pointing
at everyone else.

I should start producing things good for this kind of pointing.
Like they rich ones had build hotels and like Goodyear had sold
rubber boots during the gold rush.

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

[Jeffrey Carter]

On 10/19/2012 10:30 AM, Simon Clubley wrote:>
 > |Primary factors in this choice were training availability, tool support, and
 > |processor support. Another key factor was type casting, not as a language
 > |feature, but as a hiring feature. Many of the university students simply
 > |refused to work Ada as it was not seen as a marketable experience base. When
 > |all factors were considered, C++ and C emerged as the languages of choice
 > |(these depending on the processor chosen).

Developers who won't use Ada are not worth hiring. Willingness to use Ada is a 
good indication that a developer is a software engineer, not a coder.

S/W quality in a fighter is not as important as it is in an airliner, provided 
the ejection seat works. My experience with DoD contracts is that they are 
"cost-plus": the more the work costs, the more profit the contractor makes. 
Using C/++ costs more than using Ada. To my mind, this is the factor that drives 
defense projects to use lousy languages: they drive the cost up, thus making 
more money for the contractor. The reasons the contractor gives are rarely the 
truth.

Meanwhile, Ada is still the language of choice for systems that have to work 
correctly.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

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

[Jeffrey Carter]

On 10/19/2012 07:56 AM, Patrick wrote:
 >
 > This is just my uneducated opinion but I am guessing that companies like
 > Adacore are "riding out" projects started before the DOD dropped the Ada
 > mandate. It's great that the boeing 787 has Ada but if the 777 was C++ would
 > they have switched to Ada? I think for the language to stay viable there has
 > to be a "grass roots" base and that starts with it being easy to use for the
 > everyday hobbyist.

"Uneducated" appears to be correct.

Boeing doesn't use Ada in its commercial airliners because of the Ada mandate. 
It chose Ada as the cheapest way to achieve the quality it requires to avoid 
killing passengers. If Boeing had used C++ in the 777, they'd be out of business 
now.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

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

[Brian Drummond]

On Fri, 19 Oct 2012 07:09:26 -0700, Patrick wrote:

>> I hate to break this to you, but no *professional developer* cares what
>> a "hobbyist" needs for software development. AdaCore has made a lot of
>> useful things available, but all of those were developed for big,
>> paying, professional developers.
> 
> I think this is exactly what is wrong with Ada and what needs to be
> fixed or it will die. I don't think we should look to private companies
> to solve our community problems, they have to think of their own
> survival. My suggestions might have been silly but can anyone, please,
> make a technical suggestion as to what we could do as a community to
> make Ada more portable and/or suitable for bare metal use ?

Yes. Randy is absolutely right that professional developers and their 
tool chain suppliers can't afford to cater to amateurs. $49 * a lot may 
work as a business model, but $49 * the current Ada hobbyist market - or 
even $499 * a smaller segment of it ... no way.

But we are fortunate in FSF Gnat and in Adacore's Libre products. SO what 
can we do? Run with them, and devote a little of our own time to making 
them better. Build avr-gcc with Ada support and report any problems or 
improvements in the build process to the project. Or ... Document a neat 
example program. Fix a bug. Or even report one (with testcase) to Adacore 
or on the relevant mailing list.

At an individual level it doesn't matter what, as long as we put 
something back.

When I reported a way of crashing the GtkAda test program, it was fixed 
the next day. (Reporting a minor bug to Adacore, it took a bit longer!)

I have done a little for AVR-Ada - hopefully improve the experience of 
building it - and still have to write up a stepper motor driver for the 
AVR-Ada wiki.

As I am between jobs, I managed to spend three weeks on a sizeable open-
source Ada project (ghdl, a VHDL front end for gcc) bringing it back into 
a usable state. (It was mostly C work, as gcc has changed a fair bit 
since 4.3...)

I want to build Gnat for the Arm, and return to the problem of targeting 
Android with it. Don't know if I'll find the time, but...

Specifically for bare metal? Learn to build Arm-Ada, or the "bare bones 
OS" introductions, 
http://wiki.osdev.org/Ada_Bare_bones
Read the AVR-Ada RTS, maybe try to port something like it to the 
equivalent Arm board (LPC Expresso, or the $5 Stellaris Launchpad.

We (mostly) don't have the time to do much, but each of us can make a 
small difference.

- Brian

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

[Brian Drummond]

On Fri, 19 Oct 2012 07:56:44 -0700, Patrick wrote:

>> Will die for whom? Not for every-one, and certainly not for people to
>> which it values enough.
> 
> This is just my uneducated opinion but I am guessing that companies like
> Adacore are "riding out" projects started before the DOD dropped the Ada
> mandate. It's great that the boeing 787 has Ada but if the 777 was C++
> would they have switched to Ada? 

I'm pretty sure this is NOT the case. Dropping the mandate just meant 
that Ada now has to stand on its own merit. And in some sectors, it 
certainly does - well outside the US DOD remit..

> I think for the language to stay viable
> there has to be a "grass roots" base and that starts with it being easy
> to use for the everyday hobbyist.

now THIS on the other hand, I absolutely agree with. There needs to be a 
culture of learning, using and enjoying Ada, and people need to be aware 
of it. And that can best come from hobbyists, students, ... people, not 
corporations.

One point that occurs while writing this : a lot of Ada textbooks 
approach Ada purely from a top down design model, that looks highly 
formal and very dated to either a hobbyist, or someone schooled in agile 
programming, refactoring, and so on. 

What is missing here? I find Ada to be very useful for rapidly putting 
something together. And the language is so clean and regular it is an 
absolute dream to refactor. When all those quickly hacked together 
subprograms resolve themselves into a few packages, refactoring into 
packages is remarkably easy, with much less rewriting than I remember in 
C... (Whaddya mean I have to change all those .s into ->s? ;-)
I wouldn't want to design a large system that way, but that's not the 
point. 

There is practically nothing describing how modern software practices 
might relate to Ada.

- Brian

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

[Tero Koskinen]

On Thu, 18 Oct 2012 17:33:55 -0500
"Randy Brukardt" <randy@rrsoftware.com> wrote:

> Obviously, some group of hobbyists could get to together and create 
> something (which is where the AVR-Ada and Mindstorms Ada came from), but 
> it's a big job and its unlikely that many targets would come from it. And 
> the Ada community just isn't large enough to have all of the bases covered 
> (or even a reasonable percentage).
> 
> That's the reality -- and it isn't likely to change. Unless the board 
> manufacturers themselves start supporting Ada development systems, I don't 
> think there will ever be many choices for bare/small targets. (Especially as 
> Ada *never* has been used for small targets, even back in the 1980s when 
> there was a lot of pressure from the DoD to do so.)
> 
> Feel free to prove me wrong. I'd surely be happy if that was the case - I 
> want to see Ada succeed.

I think developers at Atmel now and then take a peek at AVR-Ada 
(Atmel is the manufacturer of AVR chips).

For example,
http://sourceforge.net/mailarchive/message.php?msg_id=26696632

ARM also helps various open source projects (by having people
working in the projects, for example). If someone seriously wants
to maintain open source Ada compiler for a smaller or bigger ARM
processor, I am quite positive that they would provide some support (on
best effort basis, if nothing else) when asked.

> 
>                                        Randy.

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

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

[Yannick Duchêne (Hibou57)]

Le Sat, 20 Oct 2012 00:28:59 +0200, Brian Drummond  
<brian@shapes.demon.co.uk> a écrit:
> One point that occurs while writing this : a lot of Ada textbooks
> approach Ada purely from a top down design model, that looks highly
> formal and very dated to either a hobbyist, or someone schooled in agile
> programming, refactoring, and so on.

It's already good at refactoring. And to me, agile is quasi‑permanent  
refactoring. This may not appears in course presenting top‑down approach,  
but that's not that hard to guess error checking is an aid for refactoring  
and agile. There's no need for a big book, just tell “remember the tones  
of stupid or vicious errors you had to fix during days of testing after  
you moved that from here to there? Ada would had caught near to all the  
error in in a second.”. When testing is so many time used to workaround  
the lack of type checking (should really be a fundamental basis to  
everyone) and proper dependency declaration between modules, …. You see,  
it needs just two sentences.

-- 
“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

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

[Brian Drummond]

On Sat, 20 Oct 2012 12:57:48 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Sat, 20 Oct 2012 00:28:59 +0200, Brian Drummond
> <brian@shapes.demon.co.uk> a écrit:
>> One point that occurs while writing this : a lot of Ada textbooks
>> approach Ada purely from a top down design model, that looks highly
>> formal and very dated to either a hobbyist, or someone schooled in
>> agile programming, refactoring, and so on.
> 
> It's already good at refactoring. 

Exactly. Though how is a C-taught programmer, schooled in Agile and 
(cough) "test-driven development", going to appreciate that before he 
tries Ada?

> “remember the tones of stupid or vicious errors you had to fix during
> days of testing after you moved that from here to there? Ada would had
> caught near to all the error in in a second.”. When testing is so many
> time used to workaround the lack of type checking (should really be a
> fundamental basis to everyone) and proper dependency declaration between
> modules, …. 

A better way of making my point.

>You see, it needs just two sentences.

Well, it also needs programmers to READ those two sentences...

Where can we put them?

- Brian

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

[mjsilva]

On Thursday, October 18, 2012 3:33:58 PM UTC-7, Randy Brukardt wrote:
> You're not trying too hard if you "can't fathom" why this makes no sense. 
> 
> There's no money to be made, and as with everything, it comes down to money. 
> 
> As I noted, such development systems are typically free. Simple math shows 
> 
> the problem: $0*<enormous number> = $0. I'm pretty sure that AdaCore's many 
> 
> employees don't work for free, so there has to be a higher revenue 
> 
> projection than this in order to make a project viable. If people were 
> 
> actually willing to pay for such systems, it might be worth taking a chance 
> 
> (because $49*<enormous number> does work; that was Borland's model back in 
> 
> the day) -- but in today's software climate, no way.

In the first place, *I* never said it must be free.  In fact, I said that I would personally be willing to pay up to $1000 for Ada on bare-metal ARM (meaning of course I'd have to fill in the HW-specific bits).  That's quite a bit more than $49.

So how did the LEGO Mindstorms port happen?  I doubt (but I could be wrong) that LEGO paid for it.

So again I say I cannot fathom why a potential market of over 6 billion devices (2010 figures) is ignored.  You say nobody is interested in bare metal ports, but I suspect that is only because at AdaCore pricing levels, nobody thinks of using it on low-cost, moderate volume hardware.  I suspect, that is, that it is a chicken-and-egg issue.

Is it not the case, BTW, that AdaMagic can do full Ada 95 on just about any hardware without any OS support?  

Nobody is asking AdaCore folks to work for free.  I'm just amazed that they don't see opportunity out there in the 99.9% of the market that they do not now target.

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

[Yannick Duchêne (Hibou57)]

Le Mon, 22 Oct 2012 17:00:23 +0200, <pavel.klinkovsky@gmail.com> a écrit:

>> I'm just amazed that they don't see opportunity out there
>> in the 99.9% of the market that they do not now target.
>
> Well, I think you should just wait, and not too long... ;)
>
> Pavel

Why?


-- 
“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

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

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> In any case, I've never heard of Ada being seriously used on 8-bit 
> processors. Ever! Our old Z-80 compiler (for a subset of Ada 83) was 
> certainly 8-bit, but I don't recall anyone using it as an embedded system. 

I don't understand the reason for that.  C is used for 8 bit embedded
cpu's all the time.  Is Ada inferior to C for embedded targets in terms
of resource requirements?  That's not the impression its proponents try
to give.

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

[Simon Clubley]

On 2012-10-24, Paul Rubin <no.email@nospam.invalid> wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> In any case, I've never heard of Ada being seriously used on 8-bit 
>> processors. Ever! Our old Z-80 compiler (for a subset of Ada 83) was 
>> certainly 8-bit, but I don't recall anyone using it as an embedded system. 
>
> I don't understand the reason for that.  C is used for 8 bit embedded
> cpu's all the time.  Is Ada inferior to C for embedded targets in terms
> of resource requirements?  That's not the impression its proponents try
> to give.

When Ada is used in a zero footprint runtime configuration, you get a
restricted set of functionality comparable to that available with C.
Ada code with a zero footprint runtime (or even a minimal runtime) will
fit just fine into a 8-bit environment.

The problem occurs when you try to use the full Ada functionality and need
a appropriately sized runtime to support that additional functionality.

Simon.

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

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

[kalvin.news]

keskiviikko, 24. lokakuuta 2012 14.21.37 UTC+3 Simon Clubley kirjoitti:
> On 2012-10-24, Paul Rubin <no.email@nospam.invalid> wrote:
> 
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> >> In any case, I've never heard of Ada being seriously used on 8-bit 
> 
> >> processors. Ever! Our old Z-80 compiler (for a subset of Ada 83) was 
> 
> >> certainly 8-bit, but I don't recall anyone using it as an embedded system. 
> 
> >
> 
> > I don't understand the reason for that.  C is used for 8 bit embedded
> 
> > cpu's all the time.  Is Ada inferior to C for embedded targets in terms
> 
> > of resource requirements?  That's not the impression its proponents try
> 
> > to give.
> 
> 
> 
> When Ada is used in a zero footprint runtime configuration, you get a
> 
> restricted set of functionality comparable to that available with C.
> 
> Ada code with a zero footprint runtime (or even a minimal runtime) will
> 
> fit just fine into a 8-bit environment.
> 
> 
> 
> The problem occurs when you try to use the full Ada functionality and need
> 
> a appropriately sized runtime to support that additional functionality.
> 
> 
> 
> Simon.
> 
> 
> 
> -- 
> 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> 
> Microsoft: Bringing you 1980s technology to a 21st century world

Well, I wouldn't see that as a problem. For instance the Ravenscar profile provides only limited set of Ada features. If 8-bit controllers require more constricted subset, it is just fine. The end result is still a language with strict type checking etc. that C/C++ lack.

-Kalvin

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

[Paul Rubin]

kalvin.news@gmail.com writes:
> For instance the Ravenscar profile provides only limited set of Ada
> features. If 8-bit controllers require more constricted subset, it is
> just fine. The end result is still a language with strict type
> checking etc. that C/C++ lack.

OK, I guess this sounds reasonable, though I thought Ravenscar was
closer to something like MISRA C, basically a subset of C.

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

[Yannick Duchêne (Hibou57)]

Le Wed, 24 Oct 2012 18:16:07 +0200, Paul Rubin <no.email@nospam.invalid> a  
écrit:

> kalvin.news@gmail.com writes:
>> For instance the Ravenscar profile provides only limited set of Ada
>> features. If 8-bit controllers require more constricted subset, it is
>> just fine. The end result is still a language with strict type
>> checking etc. that C/C++ lack.
>
> OK, I guess this sounds reasonable, though I thought Ravenscar was
> closer to something like MISRA C, basically a subset of C.

Ravenscar ≠ SPARK ;)

Talking about Ravenscar, you may better think of it as a profile, while  
SPARK, as _based_ on an Ada subset.

-- 
“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

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

[Paul Rubin]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> Talking about Ravenscar, you may better think of it as a profile,
> while SPARK, as _based_ on an Ada subset.

As another matter, if GCC can compile C for a given target, is it likely
to be terribly difficult to use GNAT on that target?  I'm thinking of
the AVR processors (8-bit) and maybe the TI MSP430 (16 bit).  Both of
these work with GCC/GDB.

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

[Yannick Duchêne (Hibou57)]

Le Wed, 24 Oct 2012 18:41:56 +0200, Paul Rubin <no.email@nospam.invalid> a  
écrit:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> Talking about Ravenscar, you may better think of it as a profile,
>> while SPARK, as _based_ on an Ada subset.
>
> As another matter, if GCC can compile C for a given target, is it likely
> to be terribly difficult to use GNAT on that target?

My personal thinking is not a lot reliable, but I would notice two things.  
The first is that GCC stands for GNU C Compiler; and the second is that  
there were indeed some issue with the intermediate language it use, which  
shown (in the past), to not be very well suited for Ada or at least GNAT  
(or just its runtime?). There use to be some tweakeries to make it work  
properly with GCC, if my mind is right. Porting GCC or creating one which  
can target a platform, is one thing, doing the same for GNAT, although it  
uses GCC, is another. And that still not counting the libraries issues…  
(same story for both Ada and C, by the way). Porting or targeting, is not  
so simple, it involves many things, not just an intermediate language.  
This also depends a lot on the requirements, as you may understand (and as  
some people already pointed).


-- 
“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

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

[Paul Rubin]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>  I would notice two things. The first is that GCC stands for GNU C
> Compiler;

GCC = GNU Compiler Collection ;-).  That includes C, C++, Java, and some
other languages that I thought included Ada.

> and the second is that there were indeed some issue with the
> intermediate language it use, which shown (in the past), to not be
> very well suited for Ada or at least GNAT (or just its
> runtime?). There use to be some tweakeries to make it work properly
> with GCC, if my mind is right.

Hmm, ok, but I'd expect that is already in GCC by now?  I.e. it was
added and kept and it works.  

There is of course the matter of the runtime, and I guess that is
non-trivial if it hasn't already been done.  I wonder how much
difference there is between a basic Ada runtime (no multitasking etc.)
and an embedded libc, and whether it might be possible to re-use a libc
somehow.

I've never used Ada but have been a little bit interested in it, and had
sort of hoped that I could automatically use it on anything I could use
GCC.  I guess that was too optimistic.  It would have been nice ;-).

I agree that it would probably help Ada's popularity if this type of
port were available.

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

[Niklas Holsti]

On 12-10-24 19:57 , Yannick Duchêne (Hibou57) wrote:
> Le Wed, 24 Oct 2012 18:41:56 +0200, Paul Rubin <no.email@nospam.invalid>
> a écrit:
> 
>> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>>> Talking about Ravenscar, you may better think of it as a profile,
>>> while SPARK, as _based_ on an Ada subset.
>>
>> As another matter, if GCC can compile C for a given target, is it likely
>> to be terribly difficult to use GNAT on that target?
> 
> My personal thinking is not a lot reliable, but I would notice two
> things. The first is that GCC stands for GNU C Compiler;

Just to pick a nit, that may have been the original meaning of "GCC",
but the current expansion is "GNU Compiler Collection", I believe. Or
sometimes "GNU Compiler Caller", to emphasize that the gcc program is
not a compiler itself, but calls the suitable compilers from the GNU
Compiler Collection.

> and the second
> is that there were indeed some issue with the intermediate language it
> use, which shown (in the past), to not be very well suited for Ada or at
> least GNAT (or just its runtime?).

There is, or at least used to be, a general belief that GCC internals
are better suited for 16-bit, 32-bit, and wider processors, than for
small 8-bit processors. Even the C compiler part of GCC is not so often
used for 8-bit processors; the AVR is an exceptional case.

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

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

[Brian Drummond]

On Wed, 24 Oct 2012 09:41:56 -0700, Paul Rubin wrote:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> Talking about Ravenscar, you may better think of it as a profile,
>> while SPARK, as _based_ on an Ada subset.
> 
> As another matter, if GCC can compile C for a given target, is it likely
> to be terribly difficult to use GNAT on that target?  I'm thinking of
> the AVR processors (8-bit) and maybe the TI MSP430 (16 bit).  Both of
> these work with GCC/GDB.

It's not likely to be easy.

For the AVR, things were rocky with certain versions of GCC and better 
with others. However, GCC4.7 builds for AVR with Gnat support relatively 
easily and seems to work well, and the AVR-Ada runtime (at version 1.2) 
is very usable.

For the MSP, which is not an official GCC target, (the MSP backend is not 
part of the official gcc tree)... well I plan to try it, but I'm not 
expecting it to be easy. The sort of things that fail are just down to 
the extreme complexity of the GCC build process, and the fact that : 
building with Ada support is fairly well tested, and building with (MSP/
AVR) support is fairly well tested, but building with both together ... 
you sometimes get the impression you are alone on that path (really basic 
build failures with quite obscure causes)

And there is no equivalent to the AVR-Ada runtime. One would probably 
have to start a port from scratch, using the AVR one as a guide.
(It's not really a *run*time so much as providing compile time support 
for access to the AVR's peripherals and I/O pins etc...)

- Brian

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

[Paul Rubin]

Brian Drummond <brian@shapes.demon.co.uk> writes:
> And there is no equivalent to the AVR-Ada runtime. One would probably 
> have to start a port from scratch, using the AVR one as a guide.
> (It's not really a *run*time so much as providing compile time support 
> for access to the AVR's peripherals and I/O pins etc...)

Thanks for the informative post.  One question about the runtime: how
much different is Ada from C, in terms of what the runtime is expected
to do?  In particular, I gather there is some kind of interface for
calling C functions from Ada.  Could that be used to interface an
existing C library for those i/o pins and so on?  What about using a
regular libc (through a wrapper) for basic i/o?

Also, is it reasonably straightforward and efficient to call Ada modules
from C applications?

Maybe improved cross-language interfaces is another area that could help
Ada.

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

[Paul Rubin]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
> 	But do you intend to use Ada tasking and/or protected objects...
> Both may require Ada specific run-time features (even if the "common"
> implementations defer to OS threads for tasks). For bare-board we'd be
> looking at some implementation of locking (for protected objects --
> semaphores, event flags, conditions...); and some sort of pre-emptive
> scheduler for general tasking.

Right, the comparison here is with embedded C, i.e. no operating system,
and probably no preemptive multitasking.  Maybe cooperative
multi-tasking with an asm call to do a stack switch.

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

[Brian Drummond]

On Wed, 24 Oct 2012 15:08:58 -0700, Paul Rubin wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
>> And there is no equivalent to the AVR-Ada runtime. One would probably
>> have to start a port from scratch, using the AVR one as a guide. (It's
>> not really a *run*time so much as providing compile time support for
>> access to the AVR's peripherals and I/O pins etc...)
> 
> Thanks for the informative post.  One question about the runtime: how
> much different is Ada from C, in terms of what the runtime is expected
> to do?  In particular, I gather there is some kind of interface for
> calling C functions from Ada.  Could that be used to interface an
> existing C library for those i/o pins and so on?  What about using a
> regular libc (through a wrapper) for basic i/o?

Full Ada is very different, but that is not what we are talking about 
with the AVR. 

I haven't explicitly tried calling C or vice-versa, I don't have any C 
code for the AVR! However the C interface seems to be there and working; 
it is currently used (instead of the normal Ada syntax) for installing 
interrupt routines (written in Ada, naturally!).

The Ada RTS with AVR has a lot of restrictions (naturally, enforced by 
the compiler, there is a file full of restriction pragmas) including no 
tasking. Exceptions are allowed within a block, but you cannot propagate 
them out of the block, etc etc. 

And you do need avr-libc, so it is likely that the AVR RTS uses avr-libc 
(it is probably mostly a wrapper as you suggest) Others may be able to 
fill in more of the details...

- Brian

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

[mjsilva]

On Wednesday, October 24, 2012 4:21:37 AM UTC-7, Simon Clubley wrote:
> On 2012-10-24, Paul Rubin <no.email@nospam.invalid> wrote:
> 
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> >> In any case, I've never heard of Ada being seriously used on 8-bit 
> >> processors. Ever! Our old Z-80 compiler (for a subset of Ada 83) was 
> >> certainly 8-bit, but I don't recall anyone using it as an embedded system. 
> >
> > I don't understand the reason for that.  C is used for 8 bit embedded
> > cpu's all the time.  Is Ada inferior to C for embedded targets in terms
> > of resource requirements?  That's not the impression its proponents try
> > to give.
> 
> When Ada is used in a zero footprint runtime configuration, you get a
> restricted set of functionality comparable to that available with C.
> Ada code with a zero footprint runtime (or even a minimal runtime) will
> fit just fine into a 8-bit environment.
> 
> The problem occurs when you try to use the full Ada functionality and need
> a appropriately sized runtime to support that additional functionality.
> 
> Simon.

One thing to keep in mind (and something that makes me optimistic that Ada-on-more-targets is not an intractable problem), is that (according to my understanding) AdaMagic translates full Ada 95 to C source.  That's full as in tasking, exceptions, etc, with no underlying OS required.

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

[Kristoffer Nyborg Gregertsen]

kl. 19:34:51 UTC+2 søndag 7. oktober 2012 skrev Patrick følgende:
> 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?

If you want to run Ada on a bare-metal embedded system try GNATforAVR32. I ported GNAT to the Atmel AVR32 architecture and a Ravenscar bare-board run-time enviroment to the AVR32 UC3 microcontroller series as a part of my PhD at NTNU.

I have not had time to work on the system after finishing my PhD, but it works very well on the UC3A series, and can be updated to newer parts without much effort.

https://github.com/gregerts/GNATforAVR32

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

[Jacob Sparre Andersen]

Stephen Leake wrote:

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

Because it is hard to find a well supported OS that does what you need?
We are using Linux on ARM underneath an application we are developing at
the moment, but I'm a bit worried about the timing properties of having
a full OS running.  We may end up solving the problem by having a
hardware or a kernel-space clock triggering the microcontrollers running
the jitter-sensitive parts of the application.  This way we may miss
some measurements, but those we get will be from well-defined times.

In many cases this kind of work-around can be an easier solution than
attempting to create a full/Ravenscar run-time and the drivers required
for an application.

Greetings,

Jacob
-- 
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.

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

[Jacob Sparre Andersen]

Brian Drummond wrote:

> 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.

It would be easier to promote, if we could point people to an
easy-to-install IDE, where the less command-line-habituated users could
click and select their way to selecting boards, compiling applications,
and installing them on the boards.  It is my impression that GPS and
GNAT AVR are pretty close to this for Microsoft Windows.  For Unix there
is still a bit more work to do.

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

I hope you'll get a good offer soon.  (Even if more Ada compiler targets
is a good thing.)

> 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.

I see the two challenges for Ada in the Arduino community as:

1) Not being integrated in the Arduino IDE.
2) Not having a book about Arduino development with Ada.

I'm not sure how hard it would be to integrate Ada in the Arduino IDE
compared with making and packaging an AVR-aware GPS for the same
operating systems as the Arduino IDE is available for.

Once people are on the hook, I think an AVR-aware GPS is the better
tool, but newcomers to Arduino are more likely to download the Arduino
IDE, so from a recruiting point of view, I think it might be worth the
work to make the Arduino IDE Ada-aware.

Greetings,

Jacob
-- 
"Banning open source would have immediate, broad, and
 strongly negative impacts on the ability of many sensitive
 and security-focused DOD groups to protect themselves
 against cyberattacks"                        -- Mitre Corp.

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

[Rego, P.]

Jacob Sparre Andersen wrote:
> It would be easier to promote, if we could point people to an
> easy-to-install IDE, where the less command-line-habituated users could
> click and select their way to selecting boards, compiling applications,
> and installing them on the boards.  It is my impression that GPS and
> GNAT AVR are pretty close to this for Microsoft Windows. 

You are right, Jacob. I use GNAT AVR on Windows, it's pretty easy to install.

> > 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.

I guess AVR-Ada is more likely to the Ada community than to the Arduino community. Mainly because many of the Arduino guys are not yet software guys, and Arduino IDE is very intuitive to the ones who never programmed anything. In AVR-Ada you have to build much thing before starting to program the chip. And at first they are just concerned in moving a stepper motor, blinking a led, transmitting some bits; at first they just don't need reliability, safety, strong typing, ... . This is necessary (to these guys) just when they leave the "Arduino paradigm", and go to the "AVR paradigm". Actually now we do not program Arduinos in Ada, we program AVRs; with Arduino IDE, we really program Arduinos, because of the IDE is dependent not to the chip, but to the board.

> I see the two challenges for Ada in the Arduino community as:
> 1) Not being integrated in the Arduino IDE.
Arduino IDE gets the most part of Arduino community. I think Ada [GNAT AVR]-based concurs more with Atmel Studio (which is Visual Studio + Atmel libraries).  Even with Ada integrated on Arduino IDE, I would prefer continuing to use GNAT AVR + GPS GPL, but certainly having Arduino IDE with Ada would help to bring part of Arduino community guys to the Ada community.

> 2) Not having a book about Arduino development with Ada.
Yes. I agree. I've been teaching and encouraging much as I can some students and friends to use Ada for the Arduino projects. But the path has been always the same, teach basic Ada, teach Arduino/Arduino IDE/Atmel Studio, teach Ada on AVR, use it now. A book like this is a very good idea.

> I'm not sure how hard it would be to integrate Ada in the Arduino IDE
> compared with making and packaging an AVR-aware GPS for the same
> operating systems as the Arduino IDE is available for.
> Once people are on the hook, I think an AVR-aware GPS is the better
> tool, but newcomers to Arduino are more likely to download the Arduino
> IDE, so from a recruiting point of view, I think it might be worth the
> work to make the Arduino IDE Ada-aware.

I totally agree. I would love to see more Arduino people beginning to program using Ada.

Regards.

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

[Brian Drummond]

On Thu, 08 Nov 2012 13:36:27 +0400, Jacob Sparre Andersen wrote:

> Brian Drummond wrote:
> 
>> ... the AVR has an Ada toolchain. It may not be mature but it is very
>> usable.
> 
> It would be easier to promote, if we could point people to an
> easy-to-install IDE, where the less command-line-habituated users could
> click and select...

On Unix, even having pre-built binaries rather than building gcc from
source would be a big step in the right direction.

Integrating into an IDE ...

I kept trying with Eclipse (Hibachi and an old-ish Gnatbench) and failing,
a couple of years ago. I don't know if Eclipse has improved any?

There's GPS but I don't know how to set it up for AVR as opposed to
native.

Any other candidates?

>> Or me, unless I get a job offer soon...
> 
> I hope you'll get a good offer soon.  (Even if more Ada compiler targets
> is a good thing.)

Hasn't happened yet...

> I see the two challenges for Ada in the Arduino community as:
> 
> 1) Not being integrated in the Arduino IDE.

I agree with you about this one, though the maker community is a bit
bigger than just Arduino users... I may have to take a look at it to see
if there is any way to convince it to speak another language...

> 2) Not having a book about Arduino development with Ada.

Ahem...

http://www.nanowrimo.org/en/participants/igor-s-personal-trainer

My wife is the ML looking after NanoWrimo participants in rural Scotland 
and she's sometimes hard to ignore. Nevertheless I am making no promises
whatsoever...

Cheers,
- Brian

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

[Randy Brukardt]

> Brian Drummond wrote:

> 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.

That's not quite true, in that there surely exists a Z80 toolchain (early 
Janus/Ada) - it just hasn't been updated or supported in more than a decade 
and it only runs on CP/M. I suppose it might run on some emulator. (Another 
issue is that I don't think the binary exists on anything other than 8" 
floppy disks, which might be hard to read today.)

Not practical, I realize.

                                       Randy.

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

[Brian Drummond]

On Thu, 08 Nov 2012 19:24:36 -0600, Randy Brukardt wrote:

>> Brian Drummond wrote:
> 
>> 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.
> 
> That's not quite true, in that there surely exists a Z80 toolchain
> (early Janus/Ada) - it just hasn't been updated or supported in more
> than a decade and it only runs on CP/M. I suppose it might run on some
> emulator. (Another issue is that I don't think the binary exists on
> anything other than 8" floppy disks, which might be hard to read today.)

Depends how you parse "of these" - I did mean "of these latter" when I 
wrote it, having drooled over the Grey Matter catalogue in my younger 
days. If the source exists in any modern form, it can probably be 
compiled on a Z80-CP/M emulator. I would offer to help convert the 
floppies, but I abandoned a very nice CP/M system in a loft several house 
moves ago.

I kept a box of 8" floppies though, mostly to see the look on people's 
faces when they asked to borrow a floppy, and I said "help yourself"!

In any case, there is now an executable claiming to be an Ada compiler 
for the TI MSP430. Currently it just says "cannot locate system.ads" and 
falls over, but you have to start somewhere. Now I have to write a 
system.ads, and (probably more complicated) figure out where to put it...

- Brian

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

[Stephen Leake]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Stephen Leake wrote:
>
>> Which raises the question; why insist on "bareboard", instead of a
>> well supported OS that does what you need?
>
> Because it is hard to find a well supported OS that does what you need?
> We are using Linux on ARM underneath an application we are developing at
> the moment, but I'm a bit worried about the timing properties of having
> a full OS running.  

Linux is certainly not suitable for hard realtime. Use VxWorks or Lynx.

-- 
-- Stephe

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

[Dmitry A. Kazakov]

On Fri, 09 Nov 2012 07:29:54 -0500, Stephen Leake wrote:

> Jacob Sparre Andersen <sparre@nbi.dk> writes:
> 
>> Stephen Leake wrote:
>>
>>> Which raises the question; why insist on "bareboard", instead of a
>>> well supported OS that does what you need?
>>
>> Because it is hard to find a well supported OS that does what you need?
>> We are using Linux on ARM underneath an application we are developing at
>> the moment, but I'm a bit worried about the timing properties of having
>> a full OS running.  
> 
> Linux is certainly not suitable for hard realtime. Use VxWorks or Lynx.

What in your opinion makes VxWorks more suitable? Except that you could
have your own scheduler there is little advantages over Linux. Monolithic
kernel? VxWorks is slightly faster. But as for hard real-time, it depends
on the definition of. With its miserable RT clock support VxWorks is barely
usable for things I do. (This is going to change with the coming version,
AFAIK)

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

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

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:k7il5s$gql$1@dont-email.me...
...
>> That's not quite true, in that there surely exists a Z80 toolchain
>> (early Janus/Ada) - it just hasn't been updated or supported in more
>> than a decade and it only runs on CP/M. I suppose it might run on some
>> emulator. (Another issue is that I don't think the binary exists on
>> anything other than 8" floppy disks, which might be hard to read today.)
>
> Depends how you parse "of these" - I did mean "of these latter" when I
> wrote it, having drooled over the Grey Matter catalogue in my younger
> days. If the source exists in any modern form, it can probably be
> compiled on a Z80-CP/M emulator. I would offer to help convert the
> floppies, but I abandoned a very nice CP/M system in a loft several house
> moves ago.

I did find part of the source on some ancient 5 1/4" floppies. One disk 
wasn't readable, unfortunately, and I had tossed the redundant backups in 
one of our previous moves (I had always keep two copies of every master 
floppy, but decided to save on space by getting rid of the extra ones). I 
did retrieve the backend and runtime library, and put those into our version 
control. I always figured it would make more sense to tie those to a modern 
front-end rather than try to get the 1985 version running, so they were my 
primary target anyway.

The 8" floppy versions probably are worthless; I still have one set of 8" 
floppy drives and our "best" Z-80 computer, but the last time I tried that I 
couldn't get it to boot -- probably corroded somewhere from sitting around 
in basements. And I'm sure its in worse shape now (10 or so years later).

I've got the compiler on various weird 5 1/4" formats (like the Apple II 
CP/M), but probably nothing that a PC could read. If there was enough 
interest, I dig out all of the disks that we have and see if I can read any 
of the binaries. Might have to find a CP/M floppy reading program (I expect 
it exists).

Anyway, if someone is seriously interested, they ought to contact me and I 
can try to figure out how much work it would be to get it to run and/or find 
the binary.

                                                      Randy.

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

[Randy Brukardt]

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message 
news:ulat9855qcom15kt7lk68rsidf44uau4q5@invalid.netcom.com...
> On Sat, 10 Nov 2012 02:05:23 -0600, "Randy Brukardt"
> <randy@rrsoftware.com> declaimed the following in comp.lang.ada:
>
>> The 8" floppy versions probably are worthless; I still have one set of 8"
>> floppy drives and our "best" Z-80 computer, but the last time I tried 
>> that I
>> couldn't get it to boot -- probably corroded somewhere from sitting 
>> around
>> in basements. And I'm sure its in worse shape now (10 or so years later).
>>
>
> I'm afraid to look into my old systems... I suspect the R/W head on
> the floppy drive will snap right off if I power up my TRS-80 Model III/4
> (the one with the whopping 128kB of bank-swapped RAM <G>). My Amiga
> A-1000 and A-2000 are probably not much better.
>
>> I've got the compiler on various weird 5 1/4" formats (like the Apple II
>> CP/M), but probably nothing that a PC could read. If there was enough
>> interest, I dig out all of the disks that we have and see if I can read 
>> any
>> of the binaries. Might have to find a CP/M floppy reading program (I 
>> expect
>> it exists).
>>
> Heh... The one place the Amiga was great. Since it did "whole track"
> I/O, rigging it for alternate file systems was strictly software
> decoding. Though I don't have a 5.25" drive for it -- I did have
> CrossDOS to read MS-DOS, and I think CP/M format floppies.

That was true of almost all 5.25" drives, including those in the early IBM 
PC's. We had a program that wrote some 200 different CP/M 5.25" disk 
formats. (Why there were so many never made much sense.) I know we sold 
compilers on many of those formats.

[I wrote such a program in my early days; programming the disk controller 
chip was relatively easy and the most important thing was making sure that 
the data got dumped to the controller fast enough.]

However, the Apple II with its variable speed drive motor was not one of 
those. The only way to copy disks for an Apple II was to use an Apple II. 
(We used a friend's Apple II; we had to buy him a new disk drive after 
wearing out one copying a thousand or so disks.) Probably someone did that 
commercially, and that would have made more sense if we hadfound them, but 
that was nearly impossible in those pre-Internet days -- you never found out 
about anything unless you saw an article or ad about something.

                                            Randy.

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

[Tero Koskinen]

On Thu, 08 Nov 2012 12:07:34 +0400
Jacob Sparre Andersen <sparre@nbi.dk> wrote:

> Stephen Leake wrote:
> 
> > Which raises the question; why insist on "bareboard", instead of a
> > well supported OS that does what you need?
> 
> Because it is hard to find a well supported OS that does what you need?
> We are using Linux on ARM underneath an application we are developing at
> the moment, but I'm a bit worried about the timing properties of having
> a full OS running.  We may end up solving the problem by having a
> hardware or a kernel-space clock triggering the microcontrollers running
> the jitter-sensitive parts of the application.  This way we may miss
> some measurements, but those we get will be from well-defined times.

If you don't need accurate real-time properties, Linux+Ada on ARM
is the easiest and the cheapest way to run Ada on ARM device.

Cheapest ARM boards capable of running Linux(Debian) are something like
24 euros[1], about same as Arduinos and cheaper than Raspberry Pi.

About a year ago I asked from AdaCore how much it would cost
to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
board (cortex-m3). As you can probably guess, the price was high,
which led me to port GNAT to Debian/armhf myself[2]. But at least now,
they (AdaCore) cannot say there has been no demand for ARM. ;)

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

[1] https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/
[2] http://lists.debian.org/debian-ada/2012/04/msg00027.html

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

[Niklas Holsti]

On 12-11-20 23:25 , Tero Koskinen wrote:

> About a year ago I asked from AdaCore how much it would cost
> to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
> board (cortex-m3). As you can probably guess, the price was high,
> which led me to port GNAT to Debian/armhf myself[2]. But at least now,
> they (AdaCore) cannot say there has been no demand for ARM. ;)

Hmmm... I think they can say that, since they probably define "demand"
as "demand from customers who are willing to pay our price".

(I don't mean to criticize AdaCore. They have the right to set their own
prices to fit their business model.)

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

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

[Lucretia]

On Tuesday, 20 November 2012 21:25:56 UTC, Tero Koskinen  wrote:

> About a year ago I asked from AdaCore how much it would cost
> to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
> board (cortex-m3). As you can probably guess, the price was high,
> which led me to port GNAT to Debian/armhf myself[2]. But at least now,
> they (AdaCore) cannot say there has been no demand for ARM. ;)

Getting Ada on ARM isn't the hard part, the hard part is the zero-cost exceptions.

Luke.

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

[Brian Drummond]

On Thu, 08 Nov 2012 13:36:27 +0400, Jacob Sparre Andersen wrote:

> Brian Drummond wrote:
> 
>> 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.

> I hope you'll get a good offer soon.  (Even if more Ada compiler targets
> is a good thing.)

Been playing... It turns out that msp-gcc builds remarkably easy with Ada 
enabled, it only needed one additional patch to build gnattools without 
building libada...

Next I stole the AVR-Ada RTS and tried building it with minimal changes 
for just one family of MSP430 processor. 

Now I *really* don't know what I am doing with setting up project files, 
so there is a horrid sequence of commands to build an executable with 
these tools...

but I have a "port" of the AVR "blinky" example running away on an MSP430!

It actually tried to work first time, except that I didn't know that the 
watchdog timer is enabled by default on an MSP...

I have a feeling that the difficult part will be packaging all the 
peripherals for 450 different processor models...

Don't know if there will be any interest in Ada on the MSP430?

- Brian

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

[Shark8]

On Monday, December 17, 2012 10:33:47 AM UTC-6, Brian Drummond wrote:
> On Thu, 08 Nov 2012 13:36:27 +0400, Jacob Sparre Andersen wrote:
> 
> 
> 
> > Brian Drummond wrote:
> 
> > 
> 
> >> 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.
> 
> 
> 
> > I hope you'll get a good offer soon.  (Even if more Ada compiler targets
> 
> > is a good thing.)
> 
> 
> 
> Been playing... It turns out that msp-gcc builds remarkably easy with Ada 
> 
> enabled, it only needed one additional patch to build gnattools without 
> 
> building libada...
> 
> 
> 
> Next I stole the AVR-Ada RTS and tried building it with minimal changes 
> 
> for just one family of MSP430 processor. 
> 
> 
> 
> Now I *really* don't know what I am doing with setting up project files, 
> 
> so there is a horrid sequence of commands to build an executable with 
> 
> these tools...
> 
> 
> 
> but I have a "port" of the AVR "blinky" example running away on an MSP430!
> 
> 
> 
> It actually tried to work first time, except that I didn't know that the 
> 
> watchdog timer is enabled by default on an MSP...
> 
> 
> 
> I have a feeling that the difficult part will be packaging all the 
> 
> peripherals for 450 different processor models...
> 
> 
> 
> Don't know if there will be any interest in Ada on the MSP430?
> 
> 
> 
> - Brian

Nicely done!

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

[Paul Rubin]

Brian Drummond <brian@shapes.demon.co.uk> writes:
> Don't know if there will be any interest in Ada on the MSP430?

Yes!  What you've done is way cool.  I got a TI Launchpad recently and
haven't had time to set it up yet, but it would be awesome to program it
in Ada.  Can the compiler make code for something that small?  The
bigger of the two cpu's (it comes with two) has 16k of program flash and
512 bytes of ram, and the smaller has 2k/128b.

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

[Niklas Holsti]

On 12-12-17 18:33 , Brian Drummond wrote:

> Don't know if there will be any interest in Ada on the MSP430?

Very possibly. See

http://www.cubesatlab.org/Lunar_Lander/Space-Grant-Dinner-2010-Poster-SPARK-Ada-for-CubeSats.pdf

or

http://www.adacore.com/academia/projects/buoy/

for two uses of Ada on MSP430.


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

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

[Brian Drummond]

On Tue, 25 Dec 2012 01:29:04 -0800, Paul Rubin wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
>> Don't know if there will be any interest in Ada on the MSP430?
> 
> Yes!  What you've done is way cool.  I got a TI Launchpad recently and
> haven't had time to set it up yet, but it would be awesome to program it
> in Ada.  Can the compiler make code for something that small?  The
> bigger of the two cpu's (it comes with two) has 16k of program flash and
> 512 bytes of ram, and the smaller has 2k/128b.

Well, my own target device has 2k/128B (MSP430F20102) so, yes.
I haven't even begun to trim executables, so "Blinky" is about 300 bytes 
vs 65 for AVR-Ada. But you lose 32 bytes to interrupt vectors, there's a 
74 byte section full of unnecessary strings, and a full C startup so 
there's room for improvement...

The entire Ada program is 77 bytes with no optimisation flags. I don't 
know how MSP430 code density generally compares to AVR, but as a starting 
point this looks hopeful.

- Brian

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

[Brian Drummond]

On Tue, 25 Dec 2012 12:11:41 +0200, Niklas Holsti wrote:

> On 12-12-17 18:33 , Brian Drummond wrote:

>> Don't know if there will be any interest in Ada on the MSP430?
> Very possibly. See
> 
> http://www.cubesatlab.org/Lunar_Lander/Space-Grant-Dinner-2010-Poster-
SPARK-Ada-for-CubeSats.pdf
> http://www.adacore.com/academia/projects/buoy/

Heh - the team behind these beat you to it... :-)
Thanks,
- Brian

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

[Diogenes]

On Sunday, October 7, 2012 1:34:51 PM UTC-4, Patrick wrote:
> Does anyone have some more ideas?

Yes. I'll probably piss off a lot of the community here by saying this...the GNAT system SHOULD be just as portable as it's GCC counterpart.

Fortunately I'm learning all about the internals of the GNAT runtime environment. Writing my own verions of some of the low level code.

Resisting the temptation to dive in and chop, chop, chop the codebase up and make my own derived Compiler/Runtime.

Really, as long as all the low level primitives produce behavior that is consistent with the RM, your good to go.

The other good news though is that AdaCore has been making strides in breaking the Compiler and Runtime  down into more manageable pieces. Kudos to them. 

Yes, you can cross compile with Ada, but you need to take some time out and understand how it's done.

Check out the Ada Bare_Bones project at OSDev.org