Gradation of skills in Embedded programming

In microcontroller programming, there is no generally accepted gradation for Junior->Middle->Senior as such. Let’s try to figure out where the watershed occurs. Next, we will focus mainly on programming microcontrollers. Embedded Linux, FPGA development will not be affected here.

Schoolboy from the circle of robotics (8th grade)

He can run examples for Arduino PCB (UNO/Mega) in Arduino IDE on Windows. Can change the constant and flash from under the IDE. Provided that the sun is at an angle to the horizon of 38 degrees. The whole program is written in only one main.c file. Not interested in circuitry.

junior embedded programmer

Junior can only work in some refined IDE (IAR, Keil, Atolic True Studio, Code Composer Studio). Usually only one single microcontroller from one family can program. For example STM32F2xxxx. And that’s it. He does not know about the existence of *.ld *.o *.elf files. It only knows about *.c, *.cpp and *.h.

The maximum that can be entrusted to Junior (y) is to write a driver for GPIO, SPI, UART and other BSPs. Or write a simple driver, for example, for an RTC chip where there are 7-12 registers. And then everything will have to be checked Middle (y).

Junior can debug the firmware step by step only in IDE. Be it IAR or Keil. It’s very difficult for a junior to even master the Eclipse IDE. Junior(a) starts to panic if the IDE cannot open a damaged *.xml or *.ewp file with a project for the IDE.

For him, there is nothing outside and beyond the IDE. He sees only what is within a radius of 2-3 centimeters around and near the cursor. He has no idea how to work on a computer without a mouse, cursor and GUI.

Junior can write single-threaded code at most. Junior doesn’t realize that there is a UART-CLI and unit tests.

Junior does not know English well and therefore I write in transliteration in the comments and in company chats (watchdog, use, inline, header, define, tula).

Junior can’t read schematics. If he is advised to find something in the topology file, he will consider that he was insulted.

Junior passes configs to the assembly through (pro) hardcode (wife) constants scattered throughout the firmware.

When Junior(s) need to find a specific feature, they open the IDE’s built-in search and type in a keyword.

Junior has no idea that there is a console and console utilities. He even words such as “console” has not yet heard.

Junior doesn’t understand 80% of the acronyms he hears at work.

Junior can only create projects by downloading examples from the internet and tinkering with them.

In the Junior world, the microcontroller is just “the box that runs my C code”.

Junior works with code only locally. Junior doesn’t know how to use version control systems like SVN or GIT. And when you need to transfer the sources to another developer, then Junior will copy everything to a USB flash drive, the entire SDK with 16+ gigabyte objects. Or send this multi-gigabyte *.zip archive by e-mail. At best, put the archive in DropBox. Even if Junior suddenly found out about GIT, he would only version control *.c and *.h files.

Junior does not write posts because he does not really know anything yet.

Middle Embedded Programmer

Middle writes in C or C ++, Assembler and clearly understands what path the sorts go through in the digestive system of the ToolChain (a) from the moment they are written to the execution in the flash of the microcontroller. Middle can write not only C-code, but also build scripts for make, ninja and СMake. He also covers the code with unit tests and knows how to use the command line interface on top of the UART. He knows how to write a good bootloader with encryption and authentication. Knows how to use GIT (th). Can distinguish a hardware error from a software error. Can bring-up boards from production.

Middle is well versed in electronic circuit design. It can even find the best place in the topology to place the oscilloscope probe to verify the signal.

Middle uses clang-format for automatic indentation alignment. Its code is neat and modular.

Middle collects code from a common reusable codebase. Adding a new assembly for him comes down to simply writing a tiny makefile with configs.

Middle clearly represents what happens to the microprocessor between pressing the button and triggering an interrupt on an external interrupt, and how the processor then returns back to the main function.

Middle actively uses console utilities from CygWin: cat, grep, find, awk, sed, sort, curl, wc, uniq. He also knows how to compose and apply non-trivial regular expressions.

Middle has a good understanding of the architecture of a single processor core down to the ALU level and knows what happens to the microcontroller between power supply and the start of the main function.

Middle practically does not use step-by-step debugging. Is it to run the UART. Next, he focuses on the command line interface and unit tests that he added to the assembly and called from the command line on top of the UART.

Middle can modify an existing assembly with RTOS, but it cannot start any RTOS itself.

Midle can design a state machine and implement it in firmware.

It can debug platform independent code on a laptop in a separate x86 firmware build.

Middle can add Job(s) to the Jenkins build server.

Middle passes configs to the assembly via *.mk files.

Middle does not write posts on habr because he is afraid to share knowledge. Middle is very afraid of competition.

Senior Embedded programmer

Senior clearly understands the differences between 8051, ARM, SPARC, PowerPC, MIPS, RISC-V, Xtensa processor architectures.

Senior quietly writes firmware with RTOS(s): Zephyr RTOS, TI-RTOS, FreeRTOS, RTEMS. Moreover, it can raise RTOS on any MCU of any vendor from scratch, rather than taking examples from the Internet.

It compiles code with two or three compilers at once: GCC, Clang, etc.

Senior knows how JTAG works under the hood (setting a breakpoint).

Senior passes configs to the assembly through the Device Tree and Kconfig mechanisms.

Senior(s) don’t need a mouse to work on the computer. He can quickly do everything from consoles or far manager utilities.

Senior understands what is happening at the ABI level. Senior can add functionality to the firmware by adding binaries to memory directly at run-time without rebuilding the entire project, similar to how modules are loaded in Linux.

He knows how to set up full DevOps from scratch, for example in Jenkins. Moreover, the OS does not matter, what is Linux, what is Windows. He writes Python auto-build scripts, auto-deployment scripts via loaders, and scripts for running autotests from the CLI. Transfers data between boards via Protobuff.

He knows how to remove code coverage after passing tests. Finds code that is not executing.

Senior writes generator code. For example, for parsing CAN packets, or register maps of complex chips.

Senior can debug the firmware step by step from the command line, without an IDE.

Senior writes embedded code considering industry standards ISO26262, DO-178C, MISRA, AUTOSAR.

Senior writes posts on habr. He is interested in making his environment capable and comfortable to work with.

Conclusion

This is how I roughly imagine the gradation of skills in the development of microcontrollers. Of course, everything is very conditional.

If you know other attributes of a Junior->Middle->Senior microcontroller programmer, then write in the comments.

Here in this registry I gave a summary analysis of Junior-> Middle-> Senior

https://docs.google.com/spreadsheets/d/1uqG5bdRZa1dhgYn0LmwPrP3w1EBb_TEhEz9JpXjmhJw/edit#gid=0

Dictionary