The washing machine is a code kata designed specifically for embedded systems developers. It's a hardware sandbox for learning and exploring test-driven development, evolutionary design, and continuous integration. The hardware design is released under the GNU General Public License.
Hi. Welcome to the Washing Machine kata. This is a code kata for embedded systems developers. Unlike most code katas, this one also has hardware. As ever, embedded is a little unusual.
Kata is a term borrowed from the world of martial arts. It’s a form of repeated practice - of kicks, punches and moves. Perfection is achieved through repetition and deliberate practice, so goes the theory.
The idea of using a code kata as a form of deliberate practice in software development has gained currency over the years, especially for test-driven practitioners. There are valid parallels: some design and test approaches are similar to “muscle memory”, and practice of these helps for more fluid work in real-life situations.
Embedded, it’s fair to say, is a niche technical domain. Although every programmer can get value from generic code kata exercises, both the challenge and the implementation that you end up with might be a world away from the types of problem you deal with in your day job. Generic practice is good, but so are realism and relevance - the Washing Machine kata aims to get a little closer to your day job, but still with flexibility to experiment freely.
Like any other code kata, this one specifies functionality that you have to implement. Where it differs is that there’s also a stable hardware platform simulating a washing machine control system. Your code is expected to run on your workstation as unit tests, and also compile, link and deploy to the hardware as embedded firmware: this is dual target TDD.
It’s a realistic embedded challenge, with a variety of peripheral interactions, design challenges and technical constraints. There are also a mix of programming models that you need to contend with - interrupts, polling, timers, and potentially DMA from analog sensors. Again, these are all real-world design challenges in embedded.
The difficulty is calibrated to a level where doing design can’t be avoided. It’s easy enough to implement, but it’s also challenging enough that it’ll be painful to try and solve by crude hackery. This is not an accident.
The washing machine concept was chosen because it has this mix of challenges, but also because it’s a recognisable, everyday object, where the requirements are easy for everyone to understand. It’s a generic problem, specifically for embedded.
This is a kata designed for people working in embedded systems development who want to learn and experiment with TDD and different design ideas. The material in this site makes some assumptions about knowledge, because the challenge is focused on TDD and design more than bare fundamentals:
If you’re starting out in embedded, but with good level of fluency in C++ or C and some software design skills, this should also be fine - you’ll need to build familiarity with some embedded concepts, but that’s do-able.
If you’re starting out without C++ or C knowledge, and no experience of embedded, then it’s likely that you’ll find it a real stretch. That doesn’t mean “don’t try it”, it’s just that you’ll need to hunt around a lot for documentation and samples. You might want to think about another platform like Arduino or the BBC micro:bit to build familiarity with the basic ideas.
You’ll need the hardware, and you’ll also need to understand how the hardware design works, so read the tour of the hardware.
Next, you’ll need to get set up with a starter project, and get toolchains configured. For dual-target development, you need to be able to compile, link, and run code both on the host system (your workstation or laptop) and also on the target device, including using a debugger.
Of course, everyone needs to look at the kata specification to see what the challenge is!
If you’re unfamiliar with test-driven development, read the embedded TDD primer. If you’re familiar with test-driven development, but not on embedded, read the embedded TDD primer. If you’re familiar with test-driven development on embedded, still read the embedded TDD primer. Basically, just read the embedded TDD primer.
Optionally, you can get a Continuous Integration (CI) build running locally in a Docker container. If CI for embedded is new to you, this can be an excellent introduction. The CI build will give you good feedback on your code, run your tests for you, and even automate the deployment of binaries to the target hardware.