By: David Hess (davidwhess.delete@this.gmail.com), March 8, 2013 8:47 pm
Room: Moderated Discussions
Ungo (a.delete@this.b.c.d.e) on March 8, 2013 4:37 pm wrote:
> 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.
My notes show that I did at least a cursory evaluation of AVR32 a couple years ago. They only support an external memory interface on 144 pin (and larger?) packages and the smaller packages do not have that much memory. I would have difficulty justifying that large a jump and *not* going to something ARM based.
> 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.
My notes show that I did at least a cursory evaluation of AVR32 a couple years ago. They only support an external memory interface on 144 pin (and larger?) packages and the smaller packages do not have that much memory. I would have difficulty justifying that large a jump and *not* going to something ARM based.