Building it ¶

As an example, building a typical “make the internal LED of the Arduino blink” solution will be as simple as:

• Downloading the docker image

docker pull fsmunoz/avr-ada

• Create the container with something like the following (I use alias for most docker containers and then just use them as commands in the terminal):

alias avr-ada="docker run -it --rm \
 -v $HOME/src:/src:Z \
 --device /dev/ttyACM0 \
 --name avr-ada \
 --group-add dialout \
 fsmunoz/avr-ada"

• Create an initial project; I would suggest Tero’s blinking led repository. To get an idea of what the code looks like, here it is (also, here’s the gist in GitHub:

-- Blink the internal LED of an Arduino (and others) using AVR-Ada
--
-- Code by Tero Koskinen
-- http://arduino.ada-language.com/blinking-led.html

with AVR;
with AVR.MCU;
with AVR.Real_Time.Delays;

use AVR;

procedure Blink is
   Led_On : Boolean := False;
   LED_PIN : constant := 5;

begin
   MCU.DDRB_Bits (LED_PIN) := DD_Output;
   loop
      Led_On := not Led_On;
      MCU.PORTB_Bits (LED_PIN) := Led_On;
      delay 8.0;
   end loop;
end Blink;

• In the docker image navigate to the source dir (which is why in the example above you can see I mapped ~/src to /src in the container).
• Do a “make” and a “make upload”; something like this:

$ make blink.prog
avr-gnatmake -XMCU=atmega328p -p -Pbuild.gpr -XAVRADA_MAIN=blink
avr-gnatmake: "/src/ada/arduino/blink/blink.elf" up to date.
avrdude -p atmega328p -P /dev/ttyACM0 -c arduino -U flash:w:blink.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
 To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "blink.hex"
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: writing flash (1096 bytes):

Writing | ################################################## | 100% 0.19s

avrdude: 1096 bytes of flash written
avrdude: verifying flash memory against blink.hex:
avrdude: load data flash data from input file blink.hex:
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: input file blink.hex contains 1096 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.15s

avrdude: verifying ...
avrdude: 1096 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done. Thank you.

• Relaxen und watchen das blinkenlichten.

On a more general note I confess that I find the typical objections to Ada tiresome, especially the “bondage and discipline language designed by committee”. I also read the Jargon File and I was raised in that very same culture, but it comes a time when one needs to go a bit deeper, and the “designed by committee” objection is more of an ideological statement than a practical one. Additionally, I have read some comments on how AdaCore (the main company behind Ada technoloy, but no the only one) is somehow "wrong" in supplying all the tools (GNAT) but not providing an exception clause to the GPL. I must say that I find this usage perfectly natural and to the spirit of the GPL: the exception clause on GCC was always a tactical measure, not a strategic one, and AdaCore is as far as I know working steadily on the GPL edition, and this is actually the whole idea behind the GPL.

This is a completely different topic but the “business friendly” mantra that BSDers in general like to use is mostly the liberty for companies to use code and then close it up and profit, and this is seen as good – but when a company opens up the code by using the GPL and thus benefits users it is seen as "unfriendly". As with most things an analysis of good and bad is dependent on who has to gain — cui bono? This is perhaps worthy of a different post.