Things are never what they seem to be

By Cyril Trap

As the other half  of the Software Department, I'm fairly busy with writing software. Well, that's obvious you're thinking, but there is actually more to it than it seems at first glance. Since we have to build the car from scratch every year, as stated by the rules, the car changed quite a lot. That includes the hardware as well. This meant we, as the Software Department, had to test whether all our wishes were compatible with the new hardware, before we actually could write a single useful character of code.

I focused on giving the car some memory. This is useful for analysing performance, but most of all for figuring out what went wrong. We do this by writing information about the state of the car to a SD Card. This was supposed to be an easy job since our real time operating system had libraries I could use, but unfortunately it turned out that these libraries used a rather slow interface which meant that we could not write our data fast enough to the SD Card in order to keep up with the car producing it. So I had to write some software myself to make sure that the process was fast enough. I did a little calculation with last year's data to set the requirements regarding speed. The writing also had to be non-blocking, which means that the microprocessor can do other useful things while the writing process progresses instead of dumb waiting for the writing to complete. I started off with searching for existing solutions or solutions to very similar problems as good engineering practices prescribe. This search proved to be pretty fruitless however, so I had to start with building from the ground up. One thing that complicated the search quite a lot was the fact that opposed to the slower protocol used by the library the protocol that I was looking for has remarkably many names, or in other words it has no name, since everybody is calling it different. After a couple of frustrating and confusing days I came across something promising, although it was out-dated and for some other microprocessor than the one we use in our car, it was reasonably documented and also of great importance it happened to be using the correct faster protocol. So filled with good hope I set out to discover the mechanism behind all of this. After some start up issues with getting things in the right place and getting the right things in place, it became clear that the world had moved on since the writing of this practical piece of information and a couple of new versions had been released meanwhile. But on the bright sight at this point I had at last an example which used to work and most important of all within time constraints. So now at that was left was the tedious task of rewriting a driver to be compatible with the current state of art regarding software. For everyone who ever went through this task I don't have to explain anything, for the others, most of you I presume, just take my word for it that it is quite a nightmare to do so.

Some headaches, long days and little sleep later the code finally compiled, this means that the computer could make sense of it and the code is not complete gibberish according to the computer. This however does not guarantee that the code is correct and working, just that the computer understood a sequence of instructions. Whether the result of executing this sequence will result in desired behaviour is completely unknown and it is up to the programmer to test his code to verify this. As often in programming my first try did not succeed so I had to fix some so-called bugs, minor errors in the code resulting in some times major failures. But after some more time and short nights the code worked as intended and it is ready to be put into the car to give it some memory. So after all a task that appeared to be a no-brainer turned out to be a great challenge.