Programming an STM32F4DISCOVERY with Ada and GPS in Linux

Niels Huisman & Peter Chapin
VTC CubeSatLab

This tutorial was created using Linux Mint 17.1 Rebecca, and has been tested using Ubuntu 14.04. This information should also work with other Ubuntu-based distros, but that has not been tested.

Shorthand used:

<user> - Your username.
<filename> - Generic file name placeholder. Use whatever file name you wish.

 To make sure we have the required dependencies, get the following packages:

    $ sudo apt-get install autoconf
    $ sudo apt-get install automake
    $ sudo apt-get install pkg-config
    $ sudo apt-get install libusb-1.0
    $ sudo apt-get install git

This can also be done on one line:

    $ sudo apt-get install autoconf automake pkg-config libusb-1.0 git

Go to https://libre.adacore.com, click on the banner to download GNAT GPL select "Free Software for Academic Development", click on the button that says "Build Your Download Package", select "ARM ELF format (hosted on Linux)" from the drop-down menu, and download the GNAT GPL tarball for Linux.

Once downloaded, open a terminal (Ctrl+Alt+T), and navigate to the folder where it was downloaded (usually /home/<user>/Downloads). Once there, extract the file as follows:

    $ tar -xvf gnat-gpl-2015-arm-elf-linux-bin

This will create a folder of the same name.  Navigate to that folder using a command such as:

    $ cd gnat-gpl-2015-arm-elf-linux-bin

If you list all the files,  you will see a file called doinstall.  Execute that file using a command such as:

    $ sudo ./doinstall

You will need to enter your root password here. At some point during the install, you will be asked to specify the installation directory. If you already have GNAT installed for native development, you will need to somehow differentiate between the two. Here we use /opt/ARMgnat as the installation directory. If you have two separate GNAT installations, you will need to write a shell script to set the correct path when using GNAT for ARM. Open a text editor of your choice, write:

    export PATH=/opt/ARMgnat/bin:$PATH
    export ARMRUNTIME=/opt/ARMgnat/lib/gnat/arm-eabi/ravenscar-sfp-stm32f4

The first line makes the tools available at the shell prompt. The second line sets an environment variable used to locate the runtime system to be used in the programs. The idea is that Windows users could set ARMRUNTIME appropriately for their system and thus it is possible to share project files between Linux and Windows. For example in the GNAT project file for a project you might include:

    package Builder is
       for Default_Switches ("ada")
          use ("-g", "--RTS=" & external("ARMRUNTIME", ""));
    end Builder;

Save the shell script as <filename>.sh in /home/<user>/bin. Before using GNAT for ARM, you will need to run:

    $ source <filename>.sh

This will set the correct path for the ARM tool chain.

Now that we have GNAT and GPS installed, we need a way to communicate with the STM board, such as ST-Link. Fortunately, we can retrieve Texane STLink using Git using a command such as:

    $ git clone https://github.com/texane/stlink stlink

This will make a directory in /home/<user> called stlink. You can use any target directory name you like. Enter that director using a command such as:

    $ cd stlink


and run the following:

    $ ./autogen.sh
    $ ./configure
    $ make install

This will install st-flash, st-info, st-term, and st-util (the one we care about the most) in /usr/local/bin. To ensure that when st-util is run it behaves as though it was run as root, we need to modify it slightly. Change the owner (should be root already, but just to be sure), and the permissions as follows:

    $ sudo chown root /usr/local/bin/st-util
    $ sudo chmod 4755 /usr/local/bin/st-util

To check that everything took the way it's supposed to, run:

    $ ls -l /usr/local/bin

You should see an output similar to the following (the file size and, of course, date/time may be somewhat different):

    $ -rwsr-xr-x 1 root root 299527 May 14 12:11 st-util

Now that we have everything installed, connect your STM board using the USB mini B port, open a terminal, and run:

    $ /usr/local/bin/st-util

You should see a number of messages giving some information about your board and ending with "Listening at *:4242..." Open a separate terminal, navigate to the directory containing your project, run the script created earlier if necessary, and open GPS.

    $ source /home/<user>/bin/ARMgnatpath.sh
    $ gps

This will open up the GPS startup window where you can begin working.

VirtualBox Notes

If you are running Linux inside a VirtualBox virtual machine, you may wish to set up a USB filter so VirtualBox automatically recognizes the STM board. To do this, open up the virtual machine settings dialog box and select "USB." Click on the '+' symbol on the right to add a new USB filter. If you have the board plugged into your host, you should see it listed among the USB devices in the menu that appears. Selecting the board will set up a filter automatically.

Alternatively the filter can be set up manually using parameters such as the ones below. These values are appropriate for the STMF4DISCOVERY board. We suggest leaving the Serial Number field blank so the settings will work for any instance of the board (useful for sharing boards).

    Name: STMicroelectronics STM32 STLink [0100]
    Vendor ID: 0483
    Product ID: 3748
    Revision: 0100
    Manufacturer: STMicroelectronics
    Product: STM32 STLink
    Remote: No

After configuring a USB filter, boot the virtual machine with the board plugged into the host and VirtualBox should automatically make the board available to the VM.

CubedOS

To help support future missions we are currently working on a CubeSat "operating system" that we are calling CubedOS. Despite the name, CubedOS is really more of an application framework than a true operating system. It builds on the services provided by the underlying Ada runtime system, namely tasking support, which in turn are built (may be built) on top of some underlying host operating system.

Yet the intent of CubedOS is to serve an operating system-like role in the construction of CubeSat flight control software. It provides several common services needed by most, if not all, missions such as non-critical timing and background processing, a file system, a high level runtime library, and a driver model. CubedOS thus simplifies the construction of flight software by relieving the application developer of the burden of repeatedly providing these basic services.

At its core CubedOS provides a general purpose, asynchronous message passing facility that is used by CubedOS modules for inter-module communication. Because of the asynchronous messages, CubedOS applications can easily exhibit a high degree of concurrency. In addition, application developers do not need to separately design every communication path between interacting tasks; pre-built CubedOS messages should often be sufficient.

However, the message passing design of CubedOS also presents some challenges. The overhead of message passing may be unacceptable in some situations. We anticipate that some time critical interactions between tasks will still need to be hand designed. Furthermore the effect of the message passing architecture on the static analysis of CubedOS programs has yet to be fully explored. There is a potential loss of static type safety in the current architecture. Furthermore the ability for any module to asynchronously send a message to any other module (using potentially non-empty mailboxes) will likely complicate any real-time analysis required by the application. We intend to explore these issues further as we go forward. In the meantime our preliminary experiments with CubedOS do indicate that the architecture can simplify the construction of highly concurrent systems.

One might reasonably ask: why not just use the services of some suitable embedded operating system and be done with it? The main reason is our requirement to use SPARK and to insist on verifying freedom from runtime errors (at least). Most existing embedded operating systems are written in C and thus prone to errors that verified SPARK programs are not. That said, there do exist certified embedded operating systems that could potentially take over some of the functionality offered by CubedOS. Their use would allow us to replace certain packages in CubedOS with wrappers that simply enclose services provided by an underlying system while maintaining compatibility with CubedOS applications. We intend to explore this option in the future as well.