matheusmbar

The last step ended with the IO library source/header files created and the STM32Cube project created and able to cross compile for the microcontroller, although executing nothing but some peripheral initializations. The next step is adding some lines in the test Makefile telling it to compile the IO library and find some STM32 headers. This will allow the development of a test for this library and the HAL GPIO mock library.

Now that TDD and the hardware got explained we are allowed to start creating the firmware project and the first library. It couldn’t go other way than a library that will allow to blink LEDs, the traditional hello world for embedded firmware. It may sound crazy but no LEDs will be required for this tests neither any microcontroller.

The mock library will be included to simulate the calls to the HAL (Hardware Abstraction Layer) that usually interacts with the microcontroller peripherals. This is a powerful resource that allows building, executing and testing functions that are in the lower levels of the firmware architecture and wouldn’t run outside the target device.

The Cpputest repository comes with the Cppumock framework and provides special configurations to inform which source codes are included just as mocks for other source codes. The mock’s function is to provide a way to monitor how the code under test is interacting with other libraries, capturing information about which functions got called, which parameters were provided to them and choose the return values for each call.

I’ve already spent so many sequential articles talking about TDD, Cpputest and codes that can run for applications anywhere. It is time to take a break on that and show up some details about the hardware that this firmware is being developed to.

The objective of this firmware is (at first) to run in a line follower robot. This kind of robot is intended run autonomously in a track looking for completing it as fast as possible in competitions. The track is usually drawn with a white tape over a black rubber mat glued to a wood plain surface. It is composed by straight lines and some curves and each competition lists some rules about the minimum straight lengths, curve radius, line width and crossings.

The tracks use to provide indications at start and end of the curves and start/end of the track. These marks can be used to help the robot dividing the track in sections and optimizing its behavior to get faster in each section. A common strategy is accelerating to high speeds in long straight sections and braking before the next curve to avoid losing it. Encoders are recommended to allow distance measurements and the latter strategy.

The Makefile created for the project in the last article is simple but the $(CPPUTEST_HOME)/build/MakefileWorker.mk included at the end provides a lot of useful tools. They can help checking how the tests are built and executed. These tools are called as parameters to the make command on terminal and will trigger specific actions detailed on the Makefile that often won’t build and run the tests but execute something else.

The available options are listed typing make in the terminal and pressing TAB twice. This will trigger the auto-complete command in you terminal and list some options. For me it shows these ones:

$ make 
all           clean         format        objs/         start         test_runner   
all_no_tests  debug         gcov          realclean     test          vtest         
check_paths   flags         lib/          run           test-deps 

I will describe how to and when to use some of those.

The next step on this process is creating a Makefile and the first test source code. The Makefile is something that many developers never took some time to learn about and create, myself included until some time ago. It is a really powerful tool that I even dare to describe as: limitless.

While building our test project it will execute these functions:

• define build flags and tools
• define source codes and includes
• compile all source files in the project
• compile all the test sources
• link all the files following its includes and dependencies
• link the Cpputest binary and libraries to built test files
• create the final test application
• execute the test application
• print the test result

The last post showed an example of coding and running tests with Cpputest, without revealing the ugly part of putting it to work. It is now time to reveal those secrets by explaining how to set a project with Cpputest, code and run the tests. Open you terminal and get ready to run commands on it!

The way I’m used to build projects with TDD is including the Cpputest inside the project directory, it helps on setting the build environment and replicating it consistently along the development team. I recommend it even for one man projects so it works the same way in both situations.

I strongly recommend creating a repository on Github or Gitlab to host you project. It will allow a future step of running a continuous integration build server, that will check every commit executed for failures on the tests. More on that in a future post (EDIT from the future: check it here after reading this one).

Making sure that the source code functions are running and executing everything they are expected to is a really great challenge. The importance of that gets bigger every time a new library is built and depends on other functions. A basic function that fails can cause serious damage inside a complete firmware.

Test Driven Development (TDD) is a technique intended to make sure that the source code is correctly coded and tested in most of the possible use cases for it. The programmer will write the test code that calls the functions and check their behavior and return values with different input parameters. The objective is to add as many tests as required to let no unmapped scenario to fail.

The development process can be summarized in:

1. Understand a new code requirement
2. Code the a new test
3. Make it compile
4. Run the tests
5. Check that it failed
6. Implement the source code (just enough to make the test pass)
7. Compile and run
8. Check if the tests passed
9. Repeat

This post is the start of a new personal/educational project that motivated me to start this blog. It will be developed as kind of tutorial, guidance and general tips/tricks about coding for embedded systems using Test Driven Development (TDD) and some other techniques.

I’ve being coding microcontrolers for several years and it can be really challenging due to many reasons like:

• define what it is supposed to execute
• model the system’s architecture so it is able to run all its tasks
• make sure it won’t fail while running…
• it WILL fail sometime, so make sure that is is able to recover from failures (gracefully as they use to say)
• check if all the functions are behaving correctly running by themselves and inside the full firmware
• understand and control correctly the microcontroller peripherals and the other components on the hardware
• be able to add features and change behaviors in the system and many times they will require big changes in the way other parts or it are planned and coded
• (add here your own frustrations, there are many more on the road)