What Skill set should a low level programmer possess?

Question

I am an embedded SW Engineer, with less than 3 yrs of experience. I aim to "sharpen the saw" continuously. I was wondering if there was anything specific to low level programming that C/C++ coders should be proficient with.

What comes to my mind is familiarity with the hardware's architecture and instruction set. Knowing how to fiddle with bits is also important, resource management and performance have been part of my job, is there anything else?

EDIT: I work with an in-house customized RTOS, not embedded Linux.

Answer 1

I'd study the electronics of the actual chips. Learn how they work internally (such as architecture), interface with peripherals, electrical and timing characteristics, etc.

Basically, read the data sheet start to finish a few times and dig into anything you've not seen/used before.

By the way, what chips do you work with?

Answer 2

Having great familiarity with pointers, the checks these languages don't do much (like buffer overflow and stuff like that), digital electronics. Operational systems internals might also help.

Get to know how stuff is represented internally, specially ready-made data structures (supposing you won't build your own one).

Above all, practice a lot. Doing it brings much more to you than just reading about it ;)

Answer 3

If you haven't yet I think every Software Engineer should read The Pragmatic Programmer and Code Complete. I know these are not specific to low level programming, but have a large wealth of knowledge in them that applies to all sub disciplines.

Answer 4

Specific concepts like,

1. Endianness (this link is to an old but good linuxjournal article)
2. Effective use of multithreading architectures (the Embedded site is good in general)
3. Debugging embedded and multithreaded systems
4. Understand, Learn and Follow good programming techniques (the link is very old and the point very generic and subjective, but think about it)
5. Other things (this IBM page on embedded linux sums up most of the other points I want to make)
6. One more thing -- never underestimate testing! or, planning test cases!!

Use the reference links I give as concepts,
please followup further for deeper knowledge.

Answer 5

Similar to what Brian said, learn how to create unit tests and automated builds.

These skills are are good for all levels of software engineers to be proficient in. They will help improve the quality of your code while also making it easier to refactor and improve the code base.

Answer 6

• bit operations
• processor architectures (caches, etc)
• wcet analysis
• scheduling

Edit: What I forgot to mention is model based development. Today, the control algorithms are often implemented as some kind of automaton from which C code is generated afterwards. Commercial available tools are for example MATLAB/Simulink, ASCET or SCADE.

Answer 7

Get yourself a copy of the MISRA-C book. It was originally written by members of the automotive industry, and attempts to make software written in C more robust by applying a number (quite a large number!) of rules and guidelines.

Then, buy PC-Lint (or another static analysis tool) to check your code for MISRA and other rules.

These are particularly relevant to low-level and embedded C, as between them they deal with the causes of a lot of bugs in such software, such as issues relating to pointers, memory leaks, integer promotion (there's a whole chapter on that in the MISRA book), endianness, and undefined behaviour.

Answer 8

I see a lot of high-level operating system answers here, but you specifically said low-level.

Some scattered thoughts: Design for test. As you work through a problem only change one thing at a time per test. You need to understand busses and interfaces, spi, i2c, usb, ethernet, etc. Number one interface, today, yesterday, and tomorrow, the uart, serial. The steps involved in programming a flash. Tricks to avoid making the product easily brickable. Bootloaders in general. Bit-banging above said interfaces on various families of parts (different chip vendors have different ideas about io pins, pull ups, direction controls, etc). Board and chip bring up, you certainly never want to boot a many tens of thousands of lines of code program on the first power up (think led on, led off). How to debug a product without using too much test equipment (logical analyzers and scopes), at the same time you have to learn to use a scope for debugging, you are far more valuable if you dont HAVE TO have a tech or engineer in the lab with you. How would you reprogram the unit in the field? What would you do to minimize human error when allowing the user to field upgrade the unit? Remember field downgrades as well. What would you do to discourage hacking (binaries, etc). Efficient use of the flash/rom (dont wear out one bank or section, spread the wear around, or see if the flash is doing it for you). How and when to use a watchdog timer. State machines, very useful with bytestreams (serial and ethernet), design packet structures that stream well and are tailored to a state machine, and that have a header and checksum or other structure that insures you do not interpret partial packets or random data as a good packet.

Answer 9

Good question. Some that haven't been mentioned...

Learn your various options for achieving low-level multitasking. From basic round-robin (non-preemptive) schedulers, with timing ticks from a hardware timer, up to a preemptive RTOS. Learn why you might need an RTOS, and why you might not. If you use an RTOS, learn that beginners with a PC background probably tend to want to create too many tasks.

Getting visibility into the internals for debugging can be a challenge. There's no screen typically, so no throwing in "printf" calls wherever you want. An emulator or JTAG interface is ideal--you can set breakpoints and step through your program (as long as halting the micro doesn't make hardware go crazy, like swinging a robot arm around at full speed!). If emulator/JTAG is not available, learn how to use a spare serial port (or maybe even bit-bash a pin to make a serial port) for a debug channel, with some simple memory peek/poke commands.