Paul A. Clayton (paaronclayton.delete@this.gmail.com) on March 7, 2013 7:59 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on March 7, 2013 6:30 pm wrote:
> [snip]
> > 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:
>
> Thank you for taking that extra effort! I hope I am not the only beneficiary!

I benefited as well. I do a periodic review of the available options and this just prompted me to renew it.

> The packaging and memory capacity issues seem like they would be easy to solve technically,
> but I could see that targeting high-volume uses (where BGA might be more attractive [guessing,
> forgive my ignorance]) might delay the descent of ARM into such forms.

I have considered designing a little plug-in wide DIP format module with the ARM microcontroller, extra external memory, and support circuitry for development work. That would at least help with the package problem although I would still avoid BGA and similar leadless packages. There are some existing products like that but invariably they are missing the right type of clock and power management support. The ARM people like to talk about low power but without proper support and maybe even with it, they are not in the same power domain as the low power microcontrollers and the lack of development board support just makes this worse.

> With respect to pricing, it is not clear what makes the pricing that much higher. 32-bit processors might
> well be more attractive to certain developers new to microcontrollers, which might allow some premium to be
> charged. I would also guess that the Cortex-M core licenses might decrease in price somewhat over time, but
> I was under the vague impression that such only accounted for a tiny fraction of the product cost--even with
> tight margins in the microcontroller market, such would seem unlikely to account for a 4x difference.

The pricing would not be that big of a problem if I could find the right product since I have been considering using multiple small microcontrollers within the same design. What I definitely do not want to do is use multiple processor with different instruction sets and development tools but it may come down to that at some point. Aggregation of lower level microcontroller logic into an FPGA is always a possibility but unless some type of real time DSP is required, I am more comfortable with multiple microcontrollers.

> I seem to recall reading that ARM was working on a more direct connection between the core and peripherals,
> but I could see ARM (and those using ARM cores) not making that an especially high priority as existing
> Cortex-M products are doing very well and 8- and 16-bit processors are very unlikely to move upward.
> (There might be some threat to future ARM downward migration if 8- or 16-bit processors become established
> in certain domains that became popular, especially for something like implanted medical devices for
> which changing the processor might require a complete revalidation of the system.)

I think I remember hearing that as well. I am more concerned about the bit-bang I/O problem because of the lack of documentation and acknowledgement of it. I think it betrays a lack of thoroughness and honesty. I have not directly experienced it though so I could be overstating the issue. Tracking down some real details would be fun but might take a better oscilloscope than I have. All of mine, including my digital storage ones, are old enough to drink. :)

Such bugs and attitudes *have* shown up in the industry before (I am thinking of you Texas Instruments) but maybe I am optimistic in hoping they are less prevalent now with greater communication between customers.

> (I thought it would be neat if a 32-bit processor could be used in a 16-bit mode, possibly even using the upper
> 16-bits for a secondary thread. The idea of a scalable/flexible implementation [and ISA/family of architectures]
> has some appeal to me, whether such is technically or economically practical is a different matter.)

I suspect that would be a waste of time because of the impact it would have on the basic instruction cycle time. Register files and access to them are already complex enough.

> It sort of sounds like the ARM microcontroller vendors might be taking the most attractive portions
> of the microcontroller market and not bothering with some less profitable areas. The vendors
> behind established alternatives which do address these areas may not have much incentive to adopt
> ARM, especially if it makes migrating to a competitor's ARM-based products easier and encourages
> other customers to move to a vendor that is perceived as more firmly standing behind its legacy
> 8- or 16-bit products (and even paying 1% of revenue to ARM may be unattractive).

I have seen the 8 and 16 bit vendors make the same mistake with product segmentation if it a mistake. Invariably I am always looking for as much SRAM as possible in the most convenient package. Sometimes they accidentally break the mold and provide a product that becomes a classic and ends up being used everywhere and driving new design wins with other parts like the old PIC 16C84 although at the time, they were relatively expensive so that may not be a good example.