Is Assembly Language Still Relevant for Embedded Software Development?

As a programmer from the late 70’s that started with the 8080 and 6800 series processors using a mix of assembler and other languages, I’d say that the commercial need to code in assembler is very rare and very very specific. The modern C/C++ compilers for embedded or small architecture devices is very efficient for 90% of applications. It’s only down in the device driver, high performance codecs for audio/video that you occasionally need to augment the compiled code with a hand written or hand optimised piece of code. The last time I touched assembly language was in 2007 for a Texas Instruments DSP for a software defined radio, where I needed to squeeze every bit of performance out of the chip. Knowing how assembler works is great and gives you insight but actually coding in that world is somewhat painful. It’s a bit like tweaking a high performance car for that last 10% extra boost. The other thing that needs to be understood is that each Microprocessor manufacture group has it’s own mnemonic language and structure, it’s with it’s own unique quirks. Which can be not unlike how different high level languages such as Java/NodeJS Python and C++ can share similarities but also have their own unique weirdness and require considerable learning investment.

When I started out in this game with PDP8 and Nova in the late 60s and developed my first microprocessor product ca 1973 there was one choice: Assembler. And if you needed it you wrote it, including in my case a floating point arithmetic package. I started out in assembler and got through a whole career of bare metal programming without using a high level language.

But since retiring I have enjoyed learning and using C/C++ (TBH all wrapped up nice and cozy in an Arduino comfort rug). I was familiar with some aspects of OOP, having used it on PCs with VB.NET, but had never done any high level language programming on MCUs.

In the 80s I did one project in particular that needed every trick in the book to get a 2.5MHz Z80 to drive a thermal printer with a 40uS update rate while still carrying on with other stuff. That required some mean and nasty code that no HLL could ever have imagined doing. If I were doing that today, with say a 240MHz ESP32 (my goto choice of platform now) it would probably be a walk in the park with basic bit banging in C and a 40uS interrupt.

As a hobbyist I pay fewer dollars for an ESP32 module today than I used to pay for a Z80 chip in the 80s. The grunt is plentiful and the grunt is cheap.

So this old dog would certainly not be teaching old tricks to the majority of students.

One other consideration. Many older projects that are now still running in a maintenance mode, especially older military and space systems are written in assembler or require a good understanding of assembly language especially fixed point arithmetic techniques. Though new projects are replacing some of them older systems persist. So a the very least a clear appreciation of such techniques would be an advantage to engineers tasked with such maintenance. In a similar vein maintenance of some low level drivers for modern computers and devices connected to legacy peripherals would benefit from knowledge of assembler.

I agree with CyberDragon, knowing how the machine deals with code is beneficial. I am an assembler junkie, started with IBM360/30 many years ago. At one time I taught COBOL and had the students use a program I had written (in COBOL) to disassemble parts of itself. The students could then see, by altering statements, what the compiler generated. They all thought it was interesting, many thought it showed them something that they knew in theory but making it happen made it much clearer in their mind. They may never write a line of assembler themselves, but that lesson goes with them.
I’ve had fun writing bits of assembler for weird applications - making a Z80 based PC look like a remote card reader to a mainframe - mounting ICL (6-bit character - 4 per 3 byte frames) tapes on a PDP11/70 (8 bit character - 3 per 3 byte frames) drive, and have the PDP think it was reading its native format. I’d assume there’s still some need for those low level routines. I took up the challenge some years back to turn an Atmega328P into a top octave generator (generate 12 frequencies 4.4kHz to 8.3kHz simultaneously) on 12 pins. Nobody could get close with a high level language - IIRC one used non standard 20MHz clock and hardware assist to get an octave down. With assembler it was possible to do it with a stock 16MHz clock at the correct frequencies with no hardware assist. https://community.atmel.com/projects/emulate-top-octave-generator-ic-eg-mk50242 . My current project has a lot of interrupt driven code (5 regular interrupts and some not usually triggered) of which the 40kHz interrupt must be serviced every time, also a 9600 baud software serial receiver that needs timely servicing. It also threads. I think it would be a nightmare fiddling with a high level language to ensure the bits didn’t trip over each other. Assembler gives 100% control at the expense of a lot of coding. But yes, I’m a junkie and don’t make a living from it. Probably a dinosaur these days.

I think the main conclusion should be: If you are a embedded systems programmer you should know the assembly language of the CPU/MCU you are programming for. Even in the highest level development will some day end at the register level and you need to understand why reading from an odd address crashes your application, or why a NULL pointer deference provides garbage.

Portability? It’s a complete myth that software is “portable” between different microcontrollers. Whoever says it is is quoting out-of-date comments from people who program computers, and have never tried it themselves.
I have just finished moving several projects from NXP LPC15 to Renesas RA4M1, and it took six months; the vast majority of that due to the different peripherals.
Being written in assembler probably made it easier because I was just dealing with different hardware, rather than different hardware AND different “drivers”.

For me, the assembly language thing is here nor there, and I’m sure there’s a place for it.  I’m certainly no expert at assembly but a funny story comes to mind.  Years back, one of my first entries into the ‘desktop’ computers was the Commodore64 as pictured in this article.  I programmed a few things, nothing important, but then tried my luck at assembly on the thing.  Simple program, start with the cursor at a default location and move it to various locations on the screen, then back to the origin.  Didn’t seem to work and when the program ran, nothing happened.  Spent hours trying to debug the code as to why it wouldn’t work.  Started adding delays and finally got to a point where I could see the cursor movement.  The program worked, but even at only 1Mhz it didn’t occur to me that was too fast to see.  Other than classroom exercises, that would be my extent of using assembly.

Interesting article. I think the answer depends at which level of the stack you are focused on! If you are developing new processors, or compilers, of course you need assembly skills. And likely to write drivers as well (given efficiency is extremely important, though ‘C’ (aka portable assembler) may be enough for most purposes. Hard real-time applications may also need some assembly skills to squeeze out cycles. But for the majority of control applications where a modest increase in cost of the BOM is preferable to substantial NRE (i.e. low volume product) it likely won’t make sense to get down to the machine code level.

I write firmware for mid scale PIC processors (8 bit). I use assembler exclusively and find it is faster to code than C given the need for real time operation. I have seen people use C for a processor then spend two months debugging a commercial compiler.  I use C++ a lot for general programming and I prefer the GCC tools for 32 bit processors and Arduino test fixtures. But firmware developed on the Arduino is not professional grade, it leaves too much performance on the table.
There is a learning curve for each new processor and it is an illusion that the ISE or C or C++ allows one to avoid that learning experience.

I think it is useful to learn assembly language to understand the hardware architecture of the microprocessor. At the lowest level, it is reading from memory into a register, adding that value to another register, storing the result in the same, or another memory location. IF statements contain branch instructions. If you display the mixed C statement and assembly code, you may see that while the C statement compiles without error, it does not do what you intended. If you set a breakpoint, is the processor stopping on the statement that you expected ?

Experimenting using gcc c compiler to write transparent portable machine code for x86 and arm platforms. 

Use disassembled c machine code to move into small modules.  Compliant with Boeing hardware engineers’ software standards.
Using Raspberry Pi 4B Broadcom ARM .  RPiOS run gcc c compiler and test x86 ports.

Using Intel Celeron N4020 and AMD Ryzen 5 3500U laptops running Ubuntu to host gcc c.

Best Buy $100 4020 Lenovo Windows 11 laptop running Ubuntu.

Working on 64-bit port of Intel MCS BASIC-52 to both arm and x86 platforms.  And maybe RSIC-V if a sbc running a Linux which run gcc c.

Maybe I’m a dummy, but I tried and tried every trick I could to get a C compiled program to feed a waveform table to a DAC but it defeated my every attempt to get the rate correct and steady.  I ended up writing a small assembly routine that actually pushed the data out and it worked perfectly.

Like many others here, I was creating code well before efficient trustworthy compilers were available.  My last big project in 2004 required best possible execution speed {at one point my nine assembly language instructions for a PIC16F876 left exactly two instruction cycles remaining before an external high-speed counter chip incremented & over-wrote the sub-nanosecond timestamp I needed to fetch.  I could have run the processor faster with a higher-frequency crystal, but my application {isolated deep-ocean-bottom instruments running on a big primary lithium battery} needed to use the least possible power.  One must anticipate hiccups in the schedule of the ROV from the service ship & allow for at least a full year of operation beyond the planned deployment period.  Exhausting the battery would make it impossible to re-rate the real-time clock at instrument recovery, so the data would have an undesirable, almost useless, rubbery time-base.  Major trade-offs.  Today I might well benefit from a modern C compiler, but I’m now retired & unlikely to repeat my 2004 experience.  The processor had ample program memory for my needs, so I made generous use of macros rather than subroutines, again for best execution speed & easier code readability.  Many of these instruments are now connected to undersea power/data cables so that these constraints no longer apply, but there are still many ocean floor geophysical observatories that run entirely on batteries…  Great fun!

If you need to know *exactly* what code is being used (extremely common when communicating with both on-chip and off-chip peripherals), then assembly is your only _supportable_ choice. Sure, you can probably coerce the compiler you’re currently using to generate the needed code, but what happens when a compiler upgrade changes that code? Do you really want to spend ages debugging why things don’t work now?

If you want to use a HLL to get the code right during development, that’s fine, but then you must copy that generated code into assembler and use that in production. Feel free to include the HLL code as comments.

This is painful experience speaking.

If you ever decide to stop teaching assembly in your course, please tell us so we can avoid your graduates from that year on. Assembly is critical for understanding embedded systems. Period.

One or two weeks out of fifteen devoted to assembler and some ISA would seem to me to be time well spent since it opens the door to understanding what goes on up the chain:  the principles behind ISAs,  assembly, compilation, abstraction, data structures. higher-level languages and so on.  It prepares the mind, and that’s the penultimate tool in the programmer’s tool box.

That said, I confess that it’s been a long time since I undertook any significant ASM programming.  But—only a few weeks since I had to go to a data sheet to understand the inner workings of an ARM processor’s I/O—and I don’t see how you could read a data sheet of that sort without some understanding of ASM.

of course it´s still needed. at least the basics so kids can really understand the machine.
plus… it´s also a humbling process comparing how you solve simple code with its high level solution… I enjoy programming asm it´s really cool. and sometimes it´s easier than high level dealing with variable types, structures, casting ,pointers, structures , etc ,etc !!!!!!

The Commodore 64 does not use the 6502. It uses a MOS 6510 - A derivative of the 6502.