In this short summary I’m going to give you and overview of training courses that will help you be more proficient in building software for embedded systems.
This training is for you if you are:
- An embedded engineering professional working with hardware/firmware.
- You are building electronic products (such as IoT devices, industrial automation and computer systems for industrial control)
- You want your firmware to be top notch and you want to have a simple process for quality assurance.
What problems this training solves
The main goal of all of this training is to help you build high quality firmware that you can easily update and improve over long period of time.
The days of "throw away" firmware are over. Firmware today represents complex applications that are evolved and updated over several years and have to continue to work even as the underlying hardware changes.
From over one and a half decade of software development I can tell you with absolute certainty that the primary driver of quality in software development is automated testing. The reason for this is that writing "easily testable" code requires massive overhaul in how developers build software. And these changes in development workflow directly correlate with producing better quality software.
This includes:
- Automated CI which is able to catch any regressions in function during development.
- Object oriented design (even in C) which primarily makes testing very easy but as a consequence also makes code very easy to use across the code base.
- Trunk based development with focus on continuous delivery which ensures that everybody on the team is on the same page working as a unit (without diverging in their own directions).
And much more.
Making sure your code is easy to verify is key
If your firmware is hard to verify, it is generally a good indicator that your design is very bad. It is likely that your files have many cross dependencies and the whole code base is completely out of control.
The complexity involved in creating verification tests is an amplified version of developer pains that developers will inevitably face during development FOR THE LIFETIME OF THE PROJECT.
If writing a test is hard, requires many dependencies, requires a lot of corner case management - then the same will be true for writing code that uses the code that is being tested. Every ticket, every task will take longer and cost more to accomplish - FOR THE LIFETIME OF THE PROJECT.
This is the primary means by which testing reduces development cost. If full test coverage is mandated by your CI pipeline then developers are directly incentivized to write simple code because it is the developer himself and not somebody else that has to use the code first hand in a test - before others get to use it.
Thus better development decisions are made and code quality improves.
But in order to implement effective testing you need everything else in place: CI, automated quality checks and most importantly a highly object oriented approach to writing software. Say goodbye to global variables, out of control dependencies, static variables inside functions and many other things that literally lead to bugs in your software.
If you don’t implement this you are doomed
If you don’t look at your development as a mechanical, well oiled machine and just "wing it", you will inevitably face problems which you are probably already facing today. Including:
- Things break and you can not guarantee absence of hidden problems. Your source code works really well for several years until a change needs to be made and it breaks in one or more places (regression) but you can not be sure that nothing broke in any other places as well. You run it on your production device it it "seems" to work - but guessing is not professional and neither are you if you keep guessing whether your software works or not. You need automation that helps you verify your requirements at all times so that you don’t have to guess. Developers spend valuable time chasing down what broke - but they don’t remember every requirement that needs to be satisfied - so they inevitably miss problems and these result in further expensive support tickets in the future. You are incurring technical debt without even knowing about it.
- Developers can not manage versioned set of requirements. Your product evolves. Several versions have been released. You need to add a fix in one version and port it to multiple other versions. However, each release has its own set of requirements (features) that have been promised in that release and without automation you have to manually check that changes work in every single release to which they apply. This wastes valuable developer time and is never 100% watertight. So you once again - you lose.
- You can not create a release on demand - your developers have to work tediously to "prepare" a release because your trunk is never in a releasable state (because you don’t have comprehensive CI in place that guarantees quality). So you can not make a quick release to a customer and be sure that it is top quality and works 100% because you simply do not have technology in place in your project that is able to give you these guarantees. Putting it in place requires a drastically different approach to development which I’ll be sharing with you in these series of training.
How do we make sure that you win every single day?
Well, first we need educate you about the basics of DevOps and most importantly trunk based development. It sounds simple (and it is) but it is also very different from how some companies work with git. Of course market leaders like Google use trunk based development extensively and even have customized systems to handle the massive flow of commits that all need to pass code review. You probably aren’t even doing code review yet. So you need to be educated about DevOps practices first.
- Embedded DevOps: In this training you will learn about version control, trunk based development and continuous delivery. These are abstract and philosophical concepts that you absolutely must have in place before you implement tactics. You must understand "why" we want to have a single straight "trunk" in our git repository and not just do it without understanding why. Click here to go to devops training.
Next, you will need to learn practical tools that we use to implement our CI infrastructure. This builds upon the philosophy of trunk based continuous delivery and adds the tactics.
- Embedded CI Infrastructure: In this training I show you how to use tools like Zephyr RTOS, robot framework, python, CMock and Unity for building a powerful RTOS infrastructure that scales to hundreds of devices and enables you to implement 100% verification for all important aspects of your software, including booting and interacting with multiple devices in CI by use of simulation (renode). Here I also share with you source code that you can use as reference. Click here to go to Embedded CI training.
With CI and testing infrastructure in place, the next thing you must know are common design patterns for C programming that make your kernel level development easy. You need to understand object oriented design in C because it will make your further software development infinitely easier and faster if you learn and apply just a few simple concepts to all of your C code.
- Design patterns in C: In this training I cover most important design patterns for C programming that you will see me use across all of my source code. Applying these patterns has a direct effect on reducing bugs because your code is simpler, easier to quickly grasp and so also easier to keep in excellent shape. Learn them and go back to this section as you progress through further training. Click here to go to C Programming Design Patterns training.
Once you have a grasp of both CI and programming patterns, it is now time to dive into firmware development where we cover hardware and software that controls that hardware.
- Embedded firmware development: In this training we look at embedded hardware and how we can control it. Click here to go to embedded firmware development training.
For a full list of available training content go here.
What else is included
Of course most of the content is digital and there is nothing stopping you from subscribing for a month, downloading all the content and then leaving (which incidentally will leave you with out of date content because all content on this site is gradually evolving).
But most importantly, what you get as a subscriber is the weekly Q&A where we can discuss your specific issues that you are facing and you can get ideas and suggestions that apply specifically to you. This is not possible to achieve with a general course - it is best delivered through face to face conversation.
The earlier you start the better
It is of highest important to get CI in place early in your project because everything you do every day should ideally be verified using CI. If you don’t do it then you will have to eventually deal with all of the incurred technical debt all at once (which can take weeks to sort out).
There is nothing wrong with taking an already developed firmware and adding CI to it after the fact. It still helps you to find and eliminate bugs (such as when we add static analysis and have to fix hundreds of problems that it discovers in your source code). In fact, I help companies do this all the time. They come to me when the pain becomes too great. Maybe you are feeling the same.
But ideally you should be implementing CI before you get the pain - meaning from the very start. Do it right and it will help your development proceed without allowing issues to creep in. This training provides you with the information you need in order to start right away.
Subscription and pricing
All of the training mentioned above, including weekly live Q&A, is provided to you on a monthly subscription basis.
If you have any questions email info@swedishembedded.com.