Embedded development@Wyres : the importance of a CDE

Finally got some time to note down some thoughts on the whole 'embedded development for IOT objects' scene.

After 5 years of working directly in our startup on the development of STM32 based LoRa communicating devices, I have formed a few opinions... I apologise in advance for those of you for whom these are obvious points, but hopefully this may help some newbie somewhere.

Some background : I started in hardware dev 30+ years ago, then programming assembly code on 6502/Z80 processors. In my first proper job, I wrote a lot of C code running on 80186 processors with a custom OS, edited on a PC and built with makefiles. No code management, everything done by hand! Since then I have moved 'up' the code chain to C for W3.1, C++/C on UNIX (kernel and user space), java (everywhere), and JS/CSS/HTML for web applications! 

And now 30 years later, with Wyres, we're doing vertical applications and developing from the hardware right up to the web GUI and everything in between! So what did I find when coming back to the embedded environment? 

First up, the development environment. I was surprised to find that there is still an assumption of a very basic mode of development with each dev building the project on his PC, in principle with the same IDE/compiler/linker/debugger as the others. And in practice, they end up with specific versions of each tool, specific debug flag values etc etc.

This means of course that the project code, even when git controlled, can end up working for one developper and not for another (or worse, not in production!). The phrase 'but it works on my machine' can get tiring after a while.

For a long time we did not address this issue at Wyres, despite having a nice modern fully automated CI/CD environment for all the backend cloud services... it was just not possible to get a CI type build of the embedded code due to the IDE and other tools we were using. Specifically, a tool like Keil (or the ST Cude IDE) is totally focussed on the individual developer who writes the code, builds it, debugs it and then delivers the binary hex file directly from his PC! And getting the same build to run on a server kicked off by a git checkin was very hard... 

And with many build parameters set in the GUI of the IDE (rather than the makefile), its very hard to control their values and versions across different machines/installs especially if this is not a priority for the developer.... 

My first realisation:

From the start, pick your tools/environment dev to be able to deploy it onto the developer's machine exactly as you can deploy it to a CI server - and validate that a build on one environment produces EXACTLY the same hex as on the other. Once you have this, then you will save a lot of grief later on.

To achieve this, docker is definitely your friend. A docker image that runs on (say) WSL/Debian will let you control the installs of all the tools required to compile/link and even run unit tests.

This gives you the holy grail : a Common Developement Environment (CDE) that ensure the same version of the source, controlled by git, will give you the same bits out no matter who builds it...

And try to find a build system that is more sophisticated than makefiles! We were trying with mvn instead of make (as this was our choice for backend java code), but then moved to a tool called 'newt' due to our migration to the embedded OS environment Apache MyNewt. A controlled modular structure, with yaml config files and the ability to define 'configurable' elements in a module and override them at different integration levels. An enormous help in making generic/independant reusable blocks of code...