Home > Tracks > Embedded Systems Programming

Flexible and Layered Embedded Firmware through Test Driven Development (TDD)

Alexopoulos Ilias - Watch Now - Currently watching: 0

Recent years the software industry has developed different methodologies with camps to support them many of them claiming better quality of work and speed. Embedded real-time firmware due to it's challenges makes adoption of these tools more difficult as we need to test systems interacting with the hardware that have timing constraints. Not all methods work well or there is often the question if the effort is worth the benefit.

In this session we will discuss the application of TDD,

  • what is TDD and the difference with unit testing,
  • example application of the method,
  • how we can model the hardware registers transparently,
  • how to tackle challenges porting to different architectures,
  • using object oriented techniques for configurability
  • the benefits and pitfalls of the method,

The session will be based on actual application of the method on real medium scale bare-bones systems projects.

italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 5 days ago | 1 reply

Really a very good webinar. I got a few ideas how to overcome some problems I have doing TDD within our projects.

Score: 0 | 4 days ago | no reply yet

Glad to see that the provided information was useful. If you have specific problems we can discuss them.

Score: 1 | 5 days ago | 2 replies

What other test frameworks other than CppUTest have you used? And what are your thoughts and experience using them?

Score: 1 | 5 days ago | 1 reply

I'm doing my test stuff with ceedling which is using CMock and Unity for the test stuff. It's very easy to setup. Maybe you want to give it a try (http://www.throwtheswitch.org/ceedling)

Score: 0 | 4 days ago | no reply yet

Thanks for the pointers. I believe many people will find these useful.
I have heard of those and looked at them. I did not see the merit myself as it is really straight forward in CppUTest to do all the stuff with not much copying of headers etc. In fact I only need to create the mock/test doubles functions only and headers only for very special cases. So my test setup uses all the headers of my actual code and I just put stubs of functions (or actual mock functions) for the doubles. No really time consuming. I haven't researched much myself to these tools, though.

Score: 0 | 5 days ago | no reply yet

I personally haven't tried other ones. I guess there should not be much different. I know that Unity is very similar, and that's why CppUTest has conversion scripts. The important thing I would like to have is to be able to test double through the linker instead of having to modify sources etc.

Score: 1 | 5 days ago | 1 reply

I think a big challenge in adopting TDD in embedded systems, is that abstracting hardware, is only going to be achievable for rather simple cases like simulating the contents of a register or a GPIO as demonstrated in your video. Embedded systems keep on getting more sophisticated, so simulating all their functions properly is really hard, or really long. And the requirements keep changing, so a team that does a good job at completing that task, may find themselves with an inoperative set of tests in a surprisingly short time. But still, I do think TDD is applicable in many cases, and should always be considered, for making products that are highly reliable.

Score: 0 | 5 days ago | no reply yet

In my video I also show part of the more complex queued SPI module that Coldfire has. I also have created USB tests as well and actually I can say USB implementation of the mocks was much simpler than Queued SPI. In a presentation like this it is not possible to show all the parts and the complexity. The reason I found USB easier, is that the hardware engine provides a packetized approach (per USB also principles) that was much easier to replicate. So although theoretically we have more complex hardware, it is not necessarily more difficult to mock. For standard microcontroller applications you use SPI, I2C/TWI, Uarts, Timers, maybe DMA. You can cover lots of these as standard devices. Of course if you change platforms around all the time, yes then you have to re-develop or modify. On the other hand having programmable logic with standard components (or your own components) can keep the longevity of the code easier as the hardware is controlled by you (another approach though). You may also stick with TDD up to the driver level, depends on how confident you are about them. Sometimes of course there is no option.

Score: 3 | 5 days ago | 1 reply

I would like to see a systematic way of creating mocks that can test the system timing and synchronization of data.

Score: 0 | 5 days ago | no reply yet

Do you mean actual timing or sequencing? Mocks will allow you sequencing. Timing does not make sense in absolute ways on your PC, your system will differ. If you are concerned about relative timings the method proposed on the top level could work also. Can you provide an example case to help me understand your problem?

Score: 0 | 5 days ago | no reply yet

Welcome to this session. I hope you enjoy it!