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.

I thought your question deserved a better answer so I spent some time going back over my notes and currently available ARM microcontrollers including the new Cortex designs that would be suitable. Here are some of my complaints in no particular order:

1. I do not like the packaging. DIP and SO are fine, PLCC (J-lead) would be ideal, and smaller quad flat packs with larger pin spacing might be acceptable. Only the last include enough memory to be an upgrade. BGAs and similar under fill packages are an inspection and design diagnostic nightmare.

2. Large amounts of memory are only available in packages I have no interest in using. As it is, in the right packages, the 8 bit microcontrollers effectively have just as much or *more* memory than the ARM microcontrollers. A microcontroller with direct support for an asynchronous SRAM interface would be fun even if it limited performance.

3. The ARM microcontrollers are significantly more expensive, like 3 to 4 times, for less performance (see 4), functionality, and memory.

4. For code that can take advantage of 32 bit operations and DSP, ARM would be faster but working with 8 bit data or even worse, bit oriented I/O can be slower. The bit oriented I/O is impacted by the peripheral I/O problem I mentioned in my other post which as far as I could tell still exists in the newer Cortex designs.

ISA differences like lack of auxiliary carry are ultimately irrelevant for the reason Linus identifies. There are better ways to write the code when you have a bank of 32 bit registers, orthogonal instructions, and high clock speeds with pipelining.

If you want it, then the lack of parity support when dealing with 8 bit serial and parallel I/O has a significant performance impact though high clock speeds should make up for it. More complex error detection would have a direct impact on latency and oddly enough power requirements in my case but I am sure it is a solvable problem.