By: Michael S (already5chosen.delete@this.yahoo.com), March 8, 2013 6:25 am
Room: Moderated Discussions
David Hess (davidwhess.delete@this.gmail.com) on March 7, 2013 6:30 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.
What you mean by 16-bit land? MPC430?
I can not recollect anything else that is
1. 16-bit
2. Alive
3. Not called DSP.
> 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.
>
In my book, not having to deal with Microchip development tools is a huge plus for STMicro and NXP that outweigh just about any minuses.
TI tools? Well I, personally, don't like them, but they are still far less strange than Microchip's.
About combination of package/RAM/price: can you give me an example of 8-bitter in a package you like, with amount of memory you like, that can't be matched feature-for-feature with LQFP from either STMicro STM32 series or by TI Piccolo or Delfino series (well, those are not ARM-Cortex, but also small 32-bitters) while the later only x1.5 or so more expensive?
Oh, and don't forget yet another small 32-bitter - Freescale Coldfire-based V1 and V2 series. It is still alive, too, and still has features that others don't have. Like on-chip Ethernet phy.
As to your other points, I don't quite understand a point about bit-oriented I/O.
Do you mean bit-banging? IMHO, GPIO modules on both TI C28 and STM32 are pretty well designed. What features you found are absent?
About parity: we are in violent disagreement. But you already figured it out from the previous posts.
> 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.
What you mean by 16-bit land? MPC430?
I can not recollect anything else that is
1. 16-bit
2. Alive
3. Not called DSP.
> 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.
>
In my book, not having to deal with Microchip development tools is a huge plus for STMicro and NXP that outweigh just about any minuses.
TI tools? Well I, personally, don't like them, but they are still far less strange than Microchip's.
About combination of package/RAM/price: can you give me an example of 8-bitter in a package you like, with amount of memory you like, that can't be matched feature-for-feature with LQFP from either STMicro STM32 series or by TI Piccolo or Delfino series (well, those are not ARM-Cortex, but also small 32-bitters) while the later only x1.5 or so more expensive?
Oh, and don't forget yet another small 32-bitter - Freescale Coldfire-based V1 and V2 series. It is still alive, too, and still has features that others don't have. Like on-chip Ethernet phy.
As to your other points, I don't quite understand a point about bit-oriented I/O.
Do you mean bit-banging? IMHO, GPIO modules on both TI C28 and STM32 are pretty well designed. What features you found are absent?
About parity: we are in violent disagreement. But you already figured it out from the previous posts.