By: Ungo (a.delete@this.b.c.d.e), March 8, 2013 4:37 pm
Room: Moderated Discussions
David Hess (davidwhess.delete@this.gmail.com) on March 8, 2013 11:24 am wrote:
> We were already using PIC after a switch from 68HC11 because of supply problems when AVR came out so switching
> again (from PIC to AVR) would have meant giving up what we were already using and there just was not enough
> advantage in doing so even though I would have prefered the AVR ISA. I am between project series now
> so switching is a possibility whether to AVR or ARM or something else but switching from one 8 bit to
> another 8 bit seems like wasted effort so ARM gets a lot of the benefit of any doubt.
Have you investigated AVR32? It's been a while since I worked with uCs so I haven't ever looked at it in deep detail, but it looks interesting. I've been wondering how well it will do against ARM MCUs (including Atmel's own!).
I suspect the reason Atmel is even bothering to offer a 32-bit update of AVR is exactly what you've been talking about. When you need to bit-bang IO, there is a lot of value to tight, low-latency CPU-peripheral integration (preferably using one clock domain for both, or an integer ratio at worst), no caches, and fixed-latency program and data memories.
> We were already using PIC after a switch from 68HC11 because of supply problems when AVR came out so switching
> again (from PIC to AVR) would have meant giving up what we were already using and there just was not enough
> advantage in doing so even though I would have prefered the AVR ISA. I am between project series now
> so switching is a possibility whether to AVR or ARM or something else but switching from one 8 bit to
> another 8 bit seems like wasted effort so ARM gets a lot of the benefit of any doubt.
Have you investigated AVR32? It's been a while since I worked with uCs so I haven't ever looked at it in deep detail, but it looks interesting. I've been wondering how well it will do against ARM MCUs (including Atmel's own!).
I suspect the reason Atmel is even bothering to offer a 32-bit update of AVR is exactly what you've been talking about. When you need to bit-bang IO, there is a lot of value to tight, low-latency CPU-peripheral integration (preferably using one clock domain for both, or an integer ratio at worst), no caches, and fixed-latency program and data memories.
