Michael S (already5chosen.delete@this.yahoo.com) on March 2, 2013 5:11 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on March 1, 2013 7:49 pm wrote:
> > Paul A. Clayton (paaronclayton.delete@this.gmail.com) on March 1, 2013 6:56 pm wrote:
> > > David Hess (davidwhess.delete@this.gmail.com) on March 1, 2013 1:58 pm wrote:
> > > [snip]
> > > > I still live in 8 and 16 bit land. The more I play with ARM the more annoyed
> > > > I get with it but not only because of the instruction set.
> > >
> > > What makes ARM annoying from the perspective one used to developing for 16-bit systems? Are
> > > the "not only" reasons related to the ecosystem (e.g., implementers not providing microcontroller
> > > features appropriate to specific uses or long-term supply guarantees) or to ARM, Ltd. (perhaps
> > > awkward licensing restrictions or aggressive patent litigation??) or something else?
> > >
> > > I am curious about the ISA and the "not only" reasons as I was under the impression that the
> > > Cortex M series was making progress in meeting requirements for 16-bit microcontrollers (at the
> > > ISA level--code density, bit manipulation, fast interrupts, etc.--and the implementation level--e.g.,
> > > decent peripheral selection [though perhaps not yet good support for variable voltage??]); but
> > > I am extremely ignorant in this and would appreciate a little bit of education.
> >
> > At least with the ARM based microcontrollers I have looked at, because of the
> > way the peripherals and I/O are connected to the ARM core, the I/O performance
> > and latency is several times slower than the clock frequency would indicate.
> >
> > Maybe the Cortex ones improve the situation.
> >
>
> ST and NXP Cortex-M3/M4 based uCs look not bad at all.
> Stellaris/TI had not bad M3-based offerings either, but decided to EOL
> them in favor of M4-only lineup, that so far looks less complete.
> And there are dozens of smaller companies in M3/M4 camp.

I have not checked the Cortex based ones yet but NXP was one of the offenders. The problem appears to be how the peripherals including just the I/O ports interface to the ARM bus. Oddly enough, I encountered a similar problem with ISA peripheral boards many years ago where I/O accesses got lost or corrupted in the north bridge. In both cases the solution was to add delays between accesses which is painless enough but other non-ARM microcontrollers do not suffer from that issue.