"Code. Test. Fix. Repeat. Towards v1"
by Federico Fiorini
It is almost the end of December, and here at Formula Student Team Delft we are all working a lot to finish the detailed design phase and finally start sending all the pieces to production.
This deadline is meant to be the end of our overall design of the car, so what has been done so far cannot be radically changed during 2019, as we will be focused more on testing our design instead of making a new one.
The electrics department has worked a lot to finish the design of the accumulator and other powertrain components, the wiring of the car, the PCBs and the software running on them.
As software engineers we have to make sure that our code works properly on the PCBs, so we need to be aware of all their functionalities and input/outputs, and we then have to make a detailed test case for each one of them.
The hardest part of this testing process is to get to know what are you working with, meaning microcontrollers, peripherals, protocols and interfaces... as well as a lot of electronic circuits and instruments.
I would say that Formula Student is giving me the kind of practical knowledge that is somewhat missing in some Master's degrees, and it is certainly going to help me in getting my dreams job.
At the moment we are testing the peripherals and the communication protocols between components, and this means that we have to continuously write code, test it, and fix any bug we find in it.
However, this also requires us to be able to understand whether the problem comes from our software or it is just because we set up the experiment in the wrong way, and you cannot imagine how long this simple process takes.
Another crucial part of this phase is to write code for the state machine we previously designed, in order to test how the PCB is reacting to signals and interrupts. And this is the time when things can get even more complex.
Testing such state changes can take up to days just to figure out why something went wrong, and most of the time is spent just trying to get the board to work again!
A few days ago, for example, I was testing low-power consumption states for the BMS, in which it has to go anytime the battery is not connected to the car. The big problems to overcome during this part of testing were getting some sort of debug opportunity when the processor was running in sleep mode, as well as checking the actual power consumption of the board.
Such test is something I have never done in my life, and first time I tried I obviously made some mistakes, but those eventually bricked the board I was using (needless to say how happy I was...). Luckily, we managed to recover such board, and next time I tested it I did it more cautiously and first I wanted to have clear understanding of the process step by step.
We are still working on such test planning and we are really looking forward to receive the actual PCBs so that we can test the software as if it is running on the car.
Stay tuned ;)