-
Notifications
You must be signed in to change notification settings - Fork 6
AssemblyDevelopment
The idea that "Assembly language is too difficult to use" is common in the ARM space. But to some extent that's a self-fulfilling statement. Having spent about a decade of my career programming nearly exclusively in assembly language, on systems/areas where that was fairly normal, I've noticed that one of the problems trying to develop on a modern CPU in assembler is that the TOOLS for developing in assembler are lacking. The assembler I used to use had well defined and standardized capabilities for implementing data structures (including bitfields), code structures (if/else/while), all the needed symbolic constants, documentation, and ABIs. The first thing you notice when trying to program an ARM in assembler is that almost all of this is missing - ARM assembler is aimed at being an intermediate language for a compiler to produce, or for writing/optimizing small bits of code that might be annoying to implement in a higher level language. But it isn't impossible to create a better assembly language environment using the tools that ARE available. And while the most legitimate complaint against assembler is probably that LARGE programs are difficult, that shouldn't be as much of an issue if the target system only has 16k of program memory...
One of the nice things about using an assembler is that the macro capabilities of most assemblers are more powerful than the macro capabilities of most HLLs. The GNU Assembler allows macros to define other macros, to recurse, and to intelligently modify assembly-time symbols; features I've often wished were present in C. I'll be using these capabilities pretty extensively to build my assembly environment for ARM. Note that the assembler macro capability is in addition to the ability to use the C pre-processor before passing source code to the assembler. (I actually won't be using the C pre-processor, because that starts to require more and larger tools...)
CMSIS provides a mechanism for vendors to define symbols for the memory areas associated with the peripherals on their chips. Most vendors provide C files that include such definitions, but don't provide any equivalent definitions for any assembler. Fortunately, it is not too difficult to convert the C into assembler...
For an example, let's look at the USART definitions from the "CMSIS Peripheral Access Layer Header File" for STM32F10x. stm32f10x.h - here's an extraction of just the USART code.
The same mechanism used to convert the peripheral data structures from CMSIS files also allows use to define user-specific data structures.