Elder Costa wrote:> Jim Granville wrote: > >> The newer single cycle C51s (SiLabs, Atmel et al) have very nimble >> interrupt handling, it would be a shame to do all the porting, only >> to find the ARM is too slow.. > > > Would you mind to define "too slow" in this context, in particular > interrupt latency? I am considering Philips LPC213x family for some > applications and I may have missed something. >8 bit traditional MCU like the 8051/AVR/6811 typically take minimal processing from HW receiving an interrupt to your handler. Some micros provide vectored interrupts for various IRQ sources so it is very fast even if you multiple types of interrupt sources. ARM architecture itself defines a single IRQ vector. Most ARM7 MCU provides some sort of fast vectored interrupt processing unit so it can handle multiple sources, but it still mean that it needs to take at least couple hops before it gets to your handler. Then of course you have to save the volatile registers which of course is more expensive on the ARM (32 bits registers times X numbers to save/restore)... -- // richard http://www.imagecraft.com
8051 to ARM - code size differences?
Started by ●March 16, 2005
Reply by ●March 17, 20052005-03-17
Reply by ●March 17, 20052005-03-17
> ARM architecture itself defines a single IRQ vector. Most ARM7 MCU > provides some sort of fast vectored interrupt processing unit so it > can handle multiple sources, but it still mean that it needs to take > at least couple hops before it gets to your handler. Then of course > you have to save the volatile registers which of course is more > expensive on the ARM (32 bits registers times X numbers to > save/restore)...The interrupt in the ARM7 will jump to address 0x18. The IRQ vector is immediately followed by the FIQ vector at 0x1c. Since you enter 32 bit ARM mode immediately, you have precisely one instruction to handle the interrupt so it obviously have to be a jump/branch. In the AT91SAM7S series you can do an indirect jump to the highest priority interrupt, pc := (pc + displacement); The displacement allows you to select the interrupt vector from the AIC (Advanced Interrupt Controller). So you need two jumps to enter the interrupt routine. At 48 MHz, that should be pretty quick. If you need even faster interrupts, you can connect a single interrupt in the AIC to the FIQ (Fast Interrupt). This gives you 5 registers for free, which do not need to be pushed or popped. A MOVEM (Move multiple) could solve some problems in push/pop. Your trouble starts if you want to support nested interupts. This will cost some code. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by ●March 17, 20052005-03-17
Elder Costa wrote:> Jim Granville wrote: > >> The newer single cycle C51s (SiLabs, Atmel et al) have very nimble >> interrupt handling, it would be a shame to do all the porting, only to >> find the ARM is too slow.. > > > Would you mind to define "too slow" in this context, in particular > interrupt latency? I am considering Philips LPC213x family for some > applications and I may have missed something.It's mostly an issue when you work very close to the iron... The typical modern 80c51 allows 4 levels of INT priority, and has direct data and boolean opcodes - which mean you can get deterministic direct (limited) action in interrupts, without any PUSH/POP. The jitter on the int time is also relatively low. ARM's tend to have better peripheral buffering, which helps tolerate a more elastic response time, so the areas to watch are where the better peripherals don't help, like SW DACs or SW current protection, or SW modulation. Some 32 bit uP/uC have separate 'co-processors' for handling the timers, and critical IO, so their main CPU response time ( and importantly, how that changes over time with Sw revisions ) is insulated from the real IO. IIRC the TI ARMs have this ? If you have special areas like that, their code is normally small, so I'd suggest a tiny 80C51 as a real time co-processor/peripheral. -jg
Reply by ●March 17, 20052005-03-17
Hello Jim,> It's mostly an issue when you work very close to the iron...I like that phrase...> ARM's tend to have better peripheral buffering, which helps tolerate a > more elastic response time, so the areas to watch are where the > better peripherals don't help, like SW DACs or SW current protection, > or SW modulation.Or when there is something in the hardware around the uC that absolutely has to have an interrupt handled in x clock cycles. There is stuff that could blow up if this doesn't happen. I remember a big wall-to-wall crack in a concrete floor that was the result of a phase synchronizer not being synchronized in time. No idea who dunnit but this was expensive. Before a dead-stick switch from one uC to another I'd carefully look at all the hardware that it supports, in all designs that are current.> > If you have special areas like that, their code is normally small, > so I'd suggest a tiny 80C51 as a real time co-processor/peripheral.That is a great idea. But then you'd have to do what Lewin's company wants to avoid: Maintain the 80C51 tools and local expertise. In that case they might as well leave such designs to the 51 architecture altogether. Regards, Joerg http://www.analogconsultants.com
Reply by ●March 18, 20052005-03-18
Jim Granville wrote:>> Would you mind to define "too slow" in this context, in particular >> interrupt latency? I am considering Philips LPC213x family for some >> applications and I may have missed something. > > > It's mostly an issue when you work very close to the iron...I guess it's not my case. I am going to use Philips LPC213x as a replacement for PICs, AVRs and 80C188EC and a latency on the order of microsseconds is more than adequate for all of my applications. We are going to purchase IAR tools. I hope their MakeApp generate decent code. Regards. Elder.
