An avian carrier's blog – Geek

Every year since 2003, Alexis Polti and myself run a course named "ROSE" (Robotique et Systèmes Embarqués, Robotics and Embedded Systems) for future engineers at Télécom ParisTech. During this 120 hour curriculum, students have to design and buid embedded systems, including designing their own electronic boards and programming them. Classical courses are limited to the minimum (real-time operating systems, signal integrity), and students must learn by themselves all the other topics while the two teachers offer lots of assistance (we are physically with the students most of the time to answer their questions).

As every year, the 2011 occurrence introduced some changes (hopefully for the better), that I now want to analyze.

Afterthoughts

Git vs. Hg

Until last year, we were using Mercurial as our revision control system because we thought it was simpler to use than Git for the students although the teachers both used it. We decided to try Git with the Gitolite backend tool that we already used for research projects. The outcome was unexpectedly successful: every project used lots of branches for their development, merging and rebasing at will.

The presence of Clément Moussu, a student who had previously done an internship at Gostai where Git is used intensively (they even use "git notes" that almost noone knows about), has been a tremendous help, and has been acknowledged during the debriefing session by other students. He and three other students explained Git to the others, and spoke about the best practices right from the beginning. So we plan to keep using Git as our preferred revision control system.

Linux-based boards

For the first time, we accepted that some projects use Linux-based boards in addition to the micro-controllers boards they had to design. The mix of those Linux-based boards (one Armadeus APF27, one BeagleBoard xM and one Gumstix Overo FE COM) allowed them to use high-level languages (Python), libraries (OpenCV, 0MQ) and cloud-based processing capabilities (Google Appengine) very easily. We plan to keep this possibility as well, but we need to ensure that every project needs to build additional micro-controller based boards as we want our students to really know how to design a board from scratch.

Best programming practices

This is something we did not do: ensure that our students know the best programming practices. Next year, we plan to do a live-coding session where we will collectively try to write the best possible code. The teacher will write, compile and run the code as suggested by the students, and explain how the code may be improved and what needs to be done to guarantee reliability and ease of maintenance. Tricky exercises will be proposed, to ensure that students need to know when volatile needs to be used, and when it is not needed. Also, lockless algorithms, depending on the underlying hardware, will be used whenever possible. The effect of inlining some functions (and when not to inline and let the compiler work it out) will be studied intensively, and methods to avoid any code duplication will be taught.

Some students naturally know how to write good code, but some don't and just write code that works but is unmaintainable. Instead of having them fix the code afterward, we will make sure that they write proper code from day one. So next year, the students will learn this skill at the beginning of the class rather than along its course.

The projects

If you are curious to see what has been done, here are links to the various projects done by the students in 2011 during this 2.5 month course:

• Casper: a talking and listening robot shaped like an elephant trunk
• Copterix: a helicopter with eight engines
• IRL: a nightclub laser that displays your tweets and let you control via Twitter the color of the club as well as other equipment such as the smoke machine
• MB Led: a very nice set of blocks letting you play games by moving them around
• Rosewheel: a Segway clone, remotely controlled using an Android phone
• TSV Safe Express: control a model railroad layout using cheap components (unfortunately, the web site is almost empty)

Every new year, on January 1st, a good friend of mine sends automated greeting emails at midnight sharp. However, this year, he forgot to set the subject correctly. While the message body appropriately contains "Meilleurs vœux à toutes et à tous pour 2011 !" (Best wishes to all for 2011!), the mail subject reads "Bonne année deux mille dix !" (Happy new year two thousand and ten!).

Fortunately, Factor will allow me to send similar greeting emails without making the same mistake. It is easy to translate an integer value such as "2011" into a French string ("deux mille onze") by using the math.text.french vocabulary that I wrote in 2009, based on math.text.english from Aaron Schaefer and a lot of complicated French language rules.

The following code lets me send a mail to a targeted recipient containing the correct year both in the subject and in the body. I hope my friend does not mind that I stole the text from his email.

USING: accessors arrays calendar combinators io.encodings.utf8
io.sockets kernel make math.text.french math.parser namespaces smtp ;
IN: newyear

: subject ( -- string )
    [ "Bonne année " % now year>> number>text % " !" % ] "" make ;

: body ( -- string )
    [
       "Meilleurs vœux à toutes et à tous pour " %
        now year>> number>string %
        " ! Que cette année soit pour\n" %
        "tout le monde riche d'heureuses " %
        "surprises en toutes choses !\n\n" %
        "Amitiés,\nSamuel" %
    ] "" make ;

: new-email ( recipients sender -- email )
    <email>
      [ from<< ] keep
      [ to<< ] keep
      subject >>subject
      body >>body ;

: send-greetings-from-sam ( email-address smtp-host -- )
    25 <inet> smtp-server set
    [
        1array "Samuel Tardieu <sam@rfc1149.net>" new-email
        send-email
    ] with-smtp-connection ;

If you want to try it, you can copy-paste it into a Factor listener and run

"Your name <your-email-address>" "your-smtp-host"
send-greetings-from-sam

to receive greetings from me.

If everything goes well, you should receive something like this in your mailbox:

From: Samuel Tardieu <sam@rfc1149.net>
To: Your name <your-email-address>
Subject: Bonne année deux mille onze !
Date: Sat, 1 Jan 2011 01:24:49 +0100
Message-Id: <15391953945985082941-1293841489599214@spyke>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Meilleurs vœux à toutes et à tous pour 2011 ! Que cette année soit pour
tout le monde riche d'heureuses surprises en toutes choses !

Amitiés,
Samuel

Do not hesitate to run this every year. I mean it.

What would be a mnemotechnic and catchy name for this blog? Years ago, I named it Dr Jekyll and Mr Hyde to reflect the fact that it could contain both French and English posts as well as geeky or non-geeky issues.

However, keeping this name while I use Jekyll to format my posts seemed weird to me. A simple and descriptive "Samuel Tardieu's blog" feels oddly out of place in my blogroll.

Pierre came up with a new name, An avian carrier's blog, which fits perfectly into the RFC 1149 theme. Long live avian carriers!

Am I the only one who would have loved to see a second season of Battle Programmer Shirase coming?

I was watching an Alias episode when I saw Jennifer Garner set a bomb clock to 4 minutes. At that time, I thought about my rforth1 compiler and realized that the code that writes a constant value into a timer register was probably doing things in the wrong order regarding the PIC timers internal latches.

It was an easy thing to fix. Thank you Jennifer for making me think about it.

As a low-level software guy, I often have to work with electrical engineers to build custom hardware and software systems. I am constantly amazed by the tricks necessary to make the hardware part work and the experience needed to build reliable electrical components. I decided to apply the same techniques to my software.

First of all, I have noticed that electrical engineers often use ground planes on their boards. A ground plane is just a large area connected to the ground. This reduces the crosstalk effect, where the signal on two wires located near to each other may influence each other.

I did the same thing in my C programs. I have inserted large areas of zeroes between my functions:

    int f (...)
    {
       ...
    }

    char _ground_plane_1[1024] = {0};

    int g (...)
    {
       ...
    }

    char _ground_plane_2[1024] = {0};

    int h (...)
    {
       ...
    }

The second important thing was about metastability. In a FPGA (an electronic device that you can customize so that it does what you want in hardware, to make it short), if you sample a signal while it is going from GND to Vcc and store it in a register, the register may take a value of Vcc/2 (I've seen this happen when sampling the input of a digital video camera). This value will be propagated and will eventually be resolved after passing through some gates into either GND or Vcc. The problem is that it may be resolved into different values at different places. To avoid this problem, you insert intermediate registers between the sampling of the signal and its propagation in the FPGA. There is a good chance that you get GND or Vcc after the first register. A better chance after the second one. A very good chance after the third one.

So in my code, I changed every assignment from a function result from:

   int a = f (x, y);

into

   int _a0 = f (x, y);
   int _a1 = _a0;
   int _a2 = _a1;
   int a   = _a2;

I ran my test programs and noticed that they were much more stable than before! I encourage everyone to do the same thing, in every programming language.

We have so much to learn from electrical engineering...

« Connecter son réseau d’entreprise à l’Internet », un livre publié par deux amis et moi-même en 1997, est maintenant disponible en ligne sous une licence libre Creative Commons. Une bonne partie du contenu est évidemment obsolète, mais d’autres sections peuvent être réutilisées.