Chicken or the egg. New targets & runtimes

Chicken or the egg. New targets & runtimes

[Patrick]

I would like to use Ada for a variety of tasks but the goal that drew me to the language in the first place was firmware hacking. I buy scientific instruments, used, I rebuild them and resell them(mostly to universities). I repair the circuit boards without schematics and it takes a long time. It is only worth it due to the low price defective instrumentation can be purchased at and the high price it can be sold at.

I would like to write firmware for my instruments for three reasons:

One, even if I fail, I will have spent more time learning the circuits and this is not a bad thing. Two, if I succeed then I will be able to control all manner of peripherals without ever having touched a breadboard and this will give me the skills I need to build my own one day. Three if I succeed, I can write my own diagnostic firmware to work in tandem with my logic analyzer and the repairs will go faster.

From the feedback in the thread "understanding runtimes", I now see that Ada+GCC does not work the same way as C+GCC were we get a runtime for each supported target with no extra effort.

mjs mentioned in this thread:
"there are 4 billion ARM chips produced each year, and Ada is an excellent fit for every one of those 4 billion chips"

and I couldn't agree more. It will be an uphill battle the whole way as it really seems that people just go with the flow and use languages for what they are already being used for regardless of their appropriateness for other purposes.

However, if Ada is not supported out-of-the-box like C, then people will never try it and even if this support is there, theyu won't try it unless it's promoted. I am willing to help on all these fronts.

So there is enough bitch'in on the internet, I want to get to work on a solution instead.

Luke already has a cool project:
https://github.com/Lucretia/tamp

and he has help me A LOT. Between his project and:

http://sourceforge.net/projects/arm-ada/

and

http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=AVR-Ada

and RTOS's that support Ada on various targets like:
http://www.rtems.com/

Maybe I(or we) could build a standard, just supports full, multitasking Ada on bare metal and nothing else, mini OS / Runtime, that everyone could use for ARM development. Once accomplish I(we) could move onto porting as many other targets as possible too.

The problem is I have a lot of catching up to do.

My first issue, is that I don't even understand how Ada gets to a new target.

From what I have read, gnat must be compiled on the target that it needs to create executables for. Assuming gnat was written on X86 to begin with, how did it even get onto a 64 bit system or ARM for that matter?

I know very little about runtimes but would it be such a big deal if the runtime was actually written in C? Could I take existing C runtimes and rework them to support Ada? I really don't have a clue at this point but if someone could point me to some helpful resources, i will try.


I have more courage then brains :)

-Patrick

Re: Chicken or the egg. New targets & runtimes

[Dmitry A. Kazakov]

On Tue, 15 May 2012 07:05:38 -0700 (PDT), Patrick wrote:

> I know very little about runtimes but would it be such a big deal if the
> runtime was actually written in C?

No. But it was not.

> Could I take existing C runtimes and
> rework them to support Ada?

You can, but that won't help you in getting what the BSP does not have.
Chances to get:

1. tasking 1/99
2. networking 1/2
3. reasonable time services 1/999

> I really don't have a clue at this point but
> if someone could point me to some helpful resources, i will try.

This highly depends on the board you have and the BSP coming with the
board.

Typically (in industry) there are third party firms contracted to roll out
the BSP. That is why unless you are Microsoft or planning to buy and then
sell many thousands of boards, it is economically infeasible to take
anything for which there is no a ready-to-use BSP.

Presently you can get a single board x86-compatible PC for 20-50 EUR.
Install Debian as Ludovic suggested, or VxWorks if you are a bit snobbish.
Otherwise, yes, you are in trouble.

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

Re: Chicken or the egg. New targets & runtimes

[Lucretia]

You don't need to get the compiler onto the target, you can use a cross compiler, which runs on whatever OS you have on your dev machine which spits out binaries for your target hardware.

That's basically the process for targeting a new machine. In gcc/ada/gcc-interface/Makefile.in, there are a number of lines that look like:

ifeq ($(strip $(filter-out m68k% wrs vx%,$(targ))),)

these match particular filters, that one is matching vxworks for m68k. To target new hardware, you would need to add a new section there, they define which packages are to be built for that target's runtime.

Luke.

Re: Chicken or the egg. New targets & runtimes

[Rego, P.]

> http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=AVR-Ada

Patrick, 

On AVRs you have also the GNAT-AVR Windows cross-compiler (you can generate the target .hex on a Windows machine), you can download the GPL version from Adacore Libre http://libre.adacore.com/download/configurations?config=avr-elf-windows&version=2011. The only limitation I see on it is that they only provide a ZFP (Zero Footprint Profile), not a complete RTS. So you cannot use tasking and exceptions (and several other Ada features). But with AVR-Ada you also cannot use it, so currently you do not have tasking support for AVRs, instead of using RTOSes approach. The tutorial http://student.agh.edu.pl/~mkucia/wiki/doku.php?id=avrada helps in using the GNAT-AVR, and you can use it under GPS, fortunately.

I also could not find much things respect to AVR RTS, but Brian Drummond told me that people from AVR-Ada project got some success in developing it over the non-yet-release AVR-Ada package. But these info are spread over the list http://news.gmane.org/gmane.comp.hardware.avr.ada, and I did not have 
time to study it. As he says, that's lot of reading (and now I agree). But it's  in my thread, so I intend to make it (hope) soon, if someone doesn't do it before :-)

Some time ago I had also looked for open-source RTOSes with Ada support, and I found:
- for AVRs, just RTEMS
- MaRTE OS, http://marte.unican.es/documentation.htm, but for other chips

and someone once suggested that making an Ada porting to FreeRTOS (which is written in C) would be easy, did not check it.

Re: Chicken or the egg. New targets & runtimes

[mjsilva]

On Tuesday, May 15, 2012 12:44:13 PM UTC-7, Rego, P. wrote:
> Some time ago I had also looked for open-source RTOSes with Ada support, and I found:
> - for AVRs, just RTEMS
> - MaRTE OS, http://marte.unican.es/documentation.htm, but for other chips
> 
> and someone once suggested that making an Ada porting to FreeRTOS (which is written in C) would be easy, did not check it.

We need to differentiate between AVR8 and AVR32.  I'm told that RTEMS size is in the hundreds of kB, so I'd guess their port is AVR32.

Getting Ada with simple tasking on AVR8 would be nice just because of the large Arduino world, but I don't see any big reason to focus on AVR32.  Unless, of course, somebody has an AVR32 board and wants to do the work. :)

Re: Chicken or the egg. New targets & runtimes

[Britt]

On May 15, 4:24 pm, mjsi...@scriptoriumdesigns.com wrote:

> Getting Ada with simple tasking on AVR8 would be nice just because of the large Arduino world, but I don't see any big reason to focus on AVR32.  Unless, of course, somebody has an AVR32 board and wants to do the work. :)

Someone has done the work:

http://folk.ntnu.no/gregerts/avr32gnat/
http://www.date-conference.com/archive/conference/proceedings/PAPERS/2009/DATE09/PDFFILES/IP5_07.PDF

Re: Chicken or the egg. New targets & runtimes

[Rego, P.]

> We need to differentiate between AVR8 and AVR32.  I'm told that RTEMS size is in the hundreds of kB, so I'd guess their port is AVR32.
Don't know. In RTEMS documentation it's not specified. Anyway, they (people from RTEMS group) say that the AVR RTEMS porting is not complete, so several RTOS features are not present on it.

> Getting Ada with simple tasking on AVR8 would be nice just because of the large Arduino world, but I don't see any big reason to focus on AVR32.  Unless, of course, somebody has an AVR32 board and wants to do the work. :)
For me it's more interesting to use tasking on AVR8. Actually would be very good to use it on an Arduino Duemilanove (Atmega328P).

Re: Chicken or the egg. New targets & runtimes

[Tero Koskinen]

On Wed, 16 May 2012 09:39:21 -0700 (PDT)
"Rego, P." <pvrego@gmail.com> wrote:

> > Getting Ada with simple tasking on AVR8 would be nice just because of the large Arduino world, but I don't see any big reason to focus on AVR32.  Unless, of course, somebody has an AVR32 board and wants to do the work. :)
> For me it's more interesting to use tasking on AVR8. Actually would be very good to use it on an Arduino Duemilanove (Atmega328P).

I am not so sure is it practical to use tasking on Arduino/Atmega328P.

For example, if you have 4 tasks and divide memory equally, each task
gets only about 512 bytes (2KB total / 4 = 512b and you need to
reserve a little for the scheduler also). In addition, task switching
overheard might become quite big, since you need to save quite many
registers in every switch and processor CPU frequency is limited to
20MHz at maximum.

But, I agree that (implementing) the tasking would be interesting,
whether or not it being useful. :)

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

Re: Chicken or the egg. New targets & runtimes

[Rego, P.]

> For example, if you have 4 tasks and divide memory equally, each task
> gets only about 512 bytes (2KB total / 4 = 512b and you need to
> reserve a little for the scheduler also). In addition, task switching
> overheard might become quite big, since you need to save quite many
> registers in every switch and processor CPU frequency is limited to
> 20MHz at maximum.

Well, 512B is exactly the amount of SRAM an AVR Minumus (AT90USB162 - 512B SRAM, 16KB Flash and 16MHz) has available, so it's not so few. I have one, and it's quite good for simple control/robotic applications even using as CDC (much more as standalone). With this 4-tasking scheme, we would simply have the equivalent to 4 AT90USB162 running in parallel, but a bit faster, since ATmega328P is 20MHz, and with more h/w resources. Also the 32KB Flash from the ATmega328p would be enough to allocate all the code for the tasks.

> But, I agree that (implementing) the tasking would be interesting,
> whether or not it being useful. :)

Yes, but I believe it will be useful :-)