VOX для «зомбоящика». Пет-проект

After switching to C code from assembly language for firmware development, it’s hard to go back. You still have to know the target processor’s machine code to be an effective firmware developer for resource-limited microcontrollers like the ATtiny15L, but I find that being able to program in C makes me more productive and results in a much more maintainable product.
Plus, with careful work and planning, there’s no net loss of efficiency with respect to how much functionality you can stuff into the target microcontroller.

My C compiler of choice has always been GNU’s open-source GCC compiler, which is supported in some form on almost every operating system. It targets virtually every instruction set in the universe, and it has generated good machine code every time I’ve used it. There is an AVR version of GCC with a full complement of support tools, including an assembler and a linker. For years, I’ve used AVRGCC to develop firmware for Atmel AVR chips, using both Windows and Linux.
The machine code it has generated has been especially good. However, when it was time to start working with the ATtiny15L, I was disappointed to discover that AVR-GCC didn’t support the low-end Atmel microcontrollers like the ATtiny15L that have no RAM. What was I to do?

I have years of experience with the AT90S8515 microcontroller, which has only 512 bytes of RAM, so I knew I could write C code for the chip, which uses almost no RAM. In fact, the hard part about using AVR-GCC for AVR microcontrollers like the AT90S18515 is writing C code in a way that conserves the precious small amount of RAM.

The AVR-GCC generates AVR code that uses the 32 8-bit hardware registers for local variables. It passes parameters to and from subroutines and functions using the same registers. Therefore, it’s reasonably easy to write complex C programs that use little or no RAM. The reward for doing this well is tightly coded machine code that tends to run fast. Like many firmware developers, I always generate a mixed listing from the compiler that shows the compiler’s machine code interspersed with my C source code lines.
This way I know exactly what the compiler is doing. By reviewing this output on a regular basis, I can learn what the compiler does well and what it has problems with.

My experiences with the code generator from the AVR-GCC taught me that, in fact, the compiler should work with a microcontroller without RAM. The key is making sure that AVR instructions that reference RAM never make it into the target microcontroller’s executable image. I solved this problem by putting together a simple Perl script that post-processes the C compiler’s output and checks for illegal instructions.

I use the GNU make program (supplied with the AVR-GCC) to cause the assembler to automatically generate a mixed listing and then check it for bad instructions using the Perl script. If problems are detected, the Perl script outputs an error message, which includes the C source line that generated the problem instruction along with the bad assembly language instructions. The make file logic then deletes the resultant object file and aborts the entire process.

Therefore, bad code never makes it to the linker.

With these checks in place, it’s now a simple matter of coding in such a way as to completely avoid any use of RAM. Also, remember that the ATtiny15L has only a three-deep call-return stack. Let’s consider some tricks for programming AVRs without RAM. These tricks tend to yield fast and efficient machine code, no matter which AVR processor your C program targets.
Constant data that would otherwise need to be placed in RAM is stored in program memory using some special compiler attributes. It’s then retrieved with the load program memory (LPM) instruction when needed.

The main program is declared naked to inhibit the generation of subroutine entry/exit code. The project is structured to include no more than two (or three) levels of subroutine calls (depending on whether or not interrupts are enabled). Without this declaration, registers used for local variables would be pushed and popped from the (nonexistent) stack.
Any storage needed in the interrupt handler is globally declared both in the interrupt handler and in the main program and subroutines:

register unsigned char foo asm("r2");

Note that r2 specifies one of the AVR hardware registers. In this case, the register selected in this way must not be one of the registers reserved by the AVR-GCC for special uses, such as parameter passing or temporary storage.
Use a special in-line assembly macro in situations where the AVRGCC uses a RAM location and an lds instruction to load constant data into one of the AVR lower registers
(r0–r15). For example:

foo = 1; // May generate a "lds"
foo = BYTE(1); // Uses "ldi/mov"

The in-line assembly macro BYTE() causes the compiler to first load the constant into one of the high registers (r16–r31) using an ldi instruction. It then moves the data into the variable’s assigned low register.
Keep all subroutines and functions simple enough so that they don’t require any local variable storage other than those registers reserved by the AVRGCC for parameter passing and temporary storage. Basically, this includes 12 of the 16 upper 8-bit AVR registers (r18–r27 and r30–r31). Plus, avoid nonleaf C subroutines and functions that include any state. A routine with no local storage meets this requirement, which is needed to avoid push and pop instructions needed to save and restore this state before and after calling another routine.
Use static in-line routines and in-line assembly macros liberally. Such code is expanded in-line by the compiler. It completely eliminates subroutine calls, which
serves to avoid some of the aforementioned restrictions.
In fact, it’s more efficient for routines that are called from only one place.

Of course, your other option is to use an ATtiny device that has RAM. That would be way too easy for me!
Besides, not having RAM tends to make the microcontroller cheaper, and in the embedded world, cheaper is always better.