What if you have already learned how to program microcontrollers?

Hi Khabrovchanin,



In this article I want to speculate on how to develop a microcontroller programmer. This article is a little reading matter for those who, like me once, did not know where to develop further in their profession. Perhaps you can pick up something interesting here.



At the moment I have been working as a programmer for 3 years, and until recently, I did not see what to do next. However, then I met a person with 20+ years of experience in programming embedded systems, and communicating with him, I identified some aspects in which you can develop. Here I want to share them, as well as my personal experience. In no case do I want to teach anyone, I will just share my best practices, and you can decide for yourself whether these tips are useful or not.



Every month there is another article for beginners with a blinking LED. In turn, there are simply no articles for intermediate programmers. Here I want to show that programming microcontrollers correctly is not a trivial task. This cannot be learned in a couple of years. In 2020, it is not much different from the task of programming conventional systems, as MCs are becoming more powerful and more powerful. Of course, I'm talking about projects of a million lines or more.



It seems that the introduction was somewhat delayed, so I'll get down to business. In this article, only the aspect of programming will be considered, I do not touch on circuitry. I tried to prioritize the items, but the difference between the first and the last is small, all items are important.



1. Learn the C ++ language.

This is a trivial advice, however, I saw fit to highlight it. The fact is that almost everyone I know continues to program in pure C even now. Why is that bad? According to various sources, a project with more than 100,000 lines (which is not a large number) becomes practically unsupported in C. In 2020, compilers for MK reached such a level of compilation of source code that the exhaust from C and C ++ will not differ. But the readability of the code will be completely different. Classes, OOP, virtual functions, smart pointers, etc. - all these are powerful assistants to the programmer. Unfortunately, it is not possible to single out and recommend a single book, as there are too many of them.



2. Study design patterns.

It's no secret that writing a good C ++ program is still a challenge. This language is too vast, it abounds in too many tools. What is a design pattern? This is some kind of guide to solving frequently repetitive tasks. Here I can recommend the classics, namely the work of the gang of four "Patterns of object-oriented design Gamma Erich, Helm Richard". It's hard to find an ordinary C ++ programmer who hasn't read this, why are we worse?



3. Discover the wonderful world of STL

I think this library needs no introduction. For those who still do not know what it is, this is the standard template library. It allows you to make your code shorter and clearer through generic programming. This tool is already built into C ++. However, for some unknown reason, it is very difficult to find a project for MK, where it is used. Although modern compilers (the same IAR) support it.



4. Add Unit tests to your projects.

Here I have nothing special to write. Countless works have been written about what it is and why. The effect of unit tests and development through testing is significant. These tests allow you to catch many bugs even before the fixes are sent to OT. In addition, there is a great book on the subject: Jeff Langr - Modern C ++ Programming with Test-Driven Development (2013).



5. Explore the Kernel

Although we program different microcontrollers, most have CortexM series kernels. Kernels have many different features, such as bitmasks or debug timers. All this can come in handy. It is also useful to know how RONs are saved when interrupted, for example. Here I can recommend “ARM Cortex-M3 core. The Complete Guide by Joseph Yu. "



6. Learn Assembler

It may seem ridiculous, but I believe that knowing the assembler for debugging applications is essential. Plus it's pretty fun to write on. With the help of Assembler, you can clearly understand what is happening at this particular breakpoint. The book from the previous paragraph is also suitable here.



7. A few words about IDE

Recently I switched to VS + VGDB bundle. This bundle has a bunch of advantages, and together they outweigh the only advantage of IAR, the size of the binary. In gcc, you can set flags for extended warnings, as well as a flag that the warning should be considered an error (IAR also has this, by the way). With this approach, your IDE itself helps you code cleanly. There is a good article about this .on habr. By the way, I have met such companies that for a test task (during an interview) oblige to write code with these flags.



That's probably all. Hopefully, if you followed the link, you found what you were looking for. Please share in the comments what other development paths Embedded programmers can have.



PS In this article, there are things that are not mentioned, for example, programming complex peripherals through registers or RTOS. It is assumed that the reader already possesses these skills, or at least knows about their existence.