Assembler coding for ARM (Cortex-M0 and M3): is it possible/practical?

Question

Unfortunately there are no questions on Stack regarding ARM and assembler at all.

My concern -- is time critical devices. Let's take for an example one of my AVR-based device (program compiled with GCC) which should do something up to INT0 interrupt. It working with 8 MHz internal oscillator (125 ns one machine cycle) but it took up to 5 microseconds to react for the interrupt. After the code investigation I came to the conclusion that in the beginning of interrupt service routine processor make a lot of work to save it's state which is almost uncontrollable for high level programming languages (such as C is). If I'd use assembler I could for example throw a pin change in the very beginning and keep the rest of necessary calculations after that. Or I could have much more control over the registers' use and therefore much less time to save those registers.

If I'd go to ARM (which I'm planing to do soon) I will have much faster processor core with much more registers and memory space which looks promising. But will I ever be able to have any control over such time critical processes to obtain for example reaction time within let's say hundred nanosecs'?

Answer 1

It's very reasonable to program ARM in assembler. It's a straightforward RISC architecture with few surprises and plenty of registers. You can mix C and assembler provided you have a good understanding of the calling conventions.

There is a special low-latency ARM interrupt mode called FIQ, which swaps out some of the registers to a bank in hardware so they do not need to be saved in the ISR. 100ns latency to doing something useful is still going to be hard - at 100MHz that's 10 clock cycles, and FIQ takes up to 12 before it executes the first instruction.

Answer 2

Yes, it's certainly possible- all the startup code your C program uses will typically be written in assembler (.s files).

Many of the things that people want to do with ARM processors lean on existing infrastructure of protocol stacks and graphics libraries. If you're writing stand-alone applications, using it like a super 8051 or PIC you can certainly use assembler for everything (or write your own UDP stacks etc). You can hand code critical sections, of course, and use C for the bulk of the programming.

I looked at the ARM7DTMI core assembler coding some time ago, and it looked fairly pleasant to work with- I estimated it would take no longer to get up to speed than with any other new processor in assembler (but in fact we're using C exclusively with ARM cores- its very suitable lingua franca for domain experts, junior folk and expert programmers alike).

Keep in mind that typical ARM implementations are not as tightly coupled as simple processors- there is a peripheral bus that may run at a different frequency than the processor bus. You may not be able to, say, toggle a port pin at anything like as fast as you might expect from the clock frequency. Generally if something is really time critical it's best to have a peripheral handling it autonomously (or to use a helper FPGA).

Answer 3

This one is a bit old, but deserves a better answer. The original question was about interrupt latency. Since the original platform is an AVR, the ARM-based replacement part is going to be a Cortex-M3/M4 or M0. Both of these devices have interrupt latency of at most 12 instruction cycles. Thats the time from stimulus to running your code.

In practice, it will take longer to do anything useful. Its hard to write to an IO in much less than 3-5 instruction cycles (load the address, load the value, store the value). Longer if the device busses, ram, or flash have additional latencies.

If you truly need latencies in the .1us range, you need peripherals or custom logic rather than software. If the actual need is bounded/fixed response times, you can get that with proper interrupt system configuration. Cortex-Ms have features that can reduce the interrupt latency to 6 cycles under the right circumstances (late arrival and tail chaining). That can be turned off if you need a fixed 12-cycle latency.