EmbeddedRelated.com
Forums

32-bit Microcontroller for $1.00 -Guy Macon

Started by Guy Macon July 21, 2008


nico@puntnl.niks (Nico Coesel) wrote:

>Well, a second source usually takes over when the original >manufacturer quits or is about to quit. I deal with low volume long >running products every now and then. After a couple of years a second >source is required because the original manufacturer quits making >certain parts.
That is not a second source. That is a new primary source. A second source gives you redundancy -- you can buy part B if part A is unavaulable, buggy, etc.

rickman wrote:

> Which large corporations? Do you really think that anyone other than > automotive and Military care about multiple sourcing? In my career of > about 30 years, the only time I have been asked about second sourcing > is in DOD type jobs. Even those have mostly given up on the idea of > second source and are trying to go the route of using more > commercially oriented designs where possible. Some 15 or 20 years ago > I worked on a design for a graphics terminal that was still going to > be "old school", but they looked hard to going COTS.
The automotive need for second sourcing seems to have faded. I have had quite bit of automotive work and since 2000 I don't recall a single requirement that second sourcing was a factor. A lot of the second sourcing I am seeing now is about developing markets that a second vendor has expertise in and distributing silicon development costs. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com walter@bytecraft.com
On Tue, 22 Jul 2008 10:47:31 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>Jim Stewart wrote: >> Anders.Montonen@kapsi.spam.stop.fi.invalid wrote: >> >>> In comp.arch Joerg <notthisjoergsch@removethispacbell.net> wrote: >>> (Luminary Micro's website) >>> >>>> Log in just to get a datasheet? Yeah, right ... >>> >>> >>> If you just keep clicking on "I really really don't want to register, >>> just shut up already" you'll get a download link without having to >>> register. Annoying, but far preferable to those sites that actually do >>> force you to register (I'm looking at you, ARM.) >> >> >> Which is far preferable to the ones that >> make you register then promise to email >> you the datasheet and never do. (I'm looking >> at you, NXP) > > Which part of NXP does that ? > I can download any PDF just fine - PDF access at NXP is good, >it is the middle-ground, between the overview and detail, that >NXP needs to work on! > >I did find they have a nice uC selector as 'clickable pdf', that I >suggested they make more visible, and it is now at: > >http://www.nxp.com/acrobat/literature/9397/75016140.pdf > >With that, you can sidestep almost the entire web site ;) > >-jg > > >
Which i can almost read through the glitzy colors and small type.
Hans-Bernhard Br&#4294967295;ker wrote:
> Jim Granville wrote: > >> That's correct from a strict logistics viewpoint, but Asians also >> operate on a less tangible area, and like to see things >> like commitment. > > Speaking of "less tangible": how exactly does one "see" commitment? One > can believe in some company executive's statement of commitment --- or > one might opt not to. But how do you see commitment other than after > the fact, when it's no use to anybody?
Usually by the enthusiasm of the employees. If one opts not to believe in a company's mission statement it's time to be looking for a new job. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
Jim Stewart wrote:
> Jim Granville wrote: >> Jim Stewart wrote: >>> Anders.Montonen@kapsi.spam.stop.fi.invalid wrote: >>> >>>> In comp.arch Joerg <notthisjoergsch@removethispacbell.net> wrote: >>>> (Luminary Micro's website) >>>> >>>>> Log in just to get a datasheet? Yeah, right ... >>>> >>>> >>>> If you just keep clicking on "I really really don't want to register, >>>> just shut up already" you'll get a download link without having to >>>> register. Annoying, but far preferable to those sites that actually do >>>> force you to register (I'm looking at you, ARM.) >>> >>> >>> Which is far preferable to the ones that >>> make you register then promise to email >>> you the datasheet and never do. (I'm looking >>> at you, NXP) >> >> Which part of NXP does that ? >> I can download any PDF just fine - PDF access at NXP is good, >> it is the middle-ground, between the overview and detail, that >> NXP needs to work on! > > RF.
Huh? I just downloaded this datasheet from their RF section and was not asked to register or anything: http://www.nxp.com/acrobat_download/datasheets/BGA2012_2.pdf -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
Joerg wrote:
> Hans-Bernhard Br&#4294967295;ker wrote:
>> Speaking of "less tangible": how exactly does one "see" commitment? >> One can believe in some company executive's statement of commitment >> --- or one might opt not to. But how do you see commitment other than >> after the fact, when it's no use to anybody?
> Usually by the enthusiasm of the employees.
... of a company on the other side of the planet? Yeah, right.
Hans-Bernhard Br&#4294967295;ker wrote:
> Joerg wrote: >> Hans-Bernhard Br&#4294967295;ker wrote: > >>> Speaking of "less tangible": how exactly does one "see" commitment? >>> One can believe in some company executive's statement of commitment >>> --- or one might opt not to. But how do you see commitment other >>> than after the fact, when it's no use to anybody? > >> Usually by the enthusiasm of the employees. > > ... of a company on the other side of the planet? Yeah, right. >
I can get a really good feel for that during longer discussions with app engineers. Analog Devices, for example, excels here. Scores every time. A certain company in Texas, well, that has become a whole 'nother story. When you do not get any answers on stuff that requires a little gusto on their part you can pretty much see where the enthusiasm of the employees stands. Which in my case had and still has sales consequences for them. Their stock hit a 52-week, 2nd quarter earnings dropped 4%, upon which shares plummeted another 14%. I am not surprised. And no, I did not have to fly to Texas to figure this out ;-) -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
On Wed, 23 Jul 2008 11:10:34 +0100, "Wilco Dijkstra"
<Wilco.removethisDijkstra@ntlworld.com> wrote:

> >"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:488668ad$1@clear.net.nz... >> Wilco Dijkstra wrote: >>> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:4884e753$1@clear.net.nz... >>> >>> >>>>Conclusion: Yes the M3 is significant, but it is a >>>>_very_ long way from dominating the MCU market, it is not even >>>>close to dominating the 32bit MCU market. >>> >>> >>> "M3 is significant" - wow, that's quite a change from what you said a >>> few years ago :-) >> >> Don't get too excited ;) >> >> I would also call the Coldfire, SuperH, MIPS, PowerPCB, Numerous DSPs >> (and even the AVR32) also significant, but do NOT confuse 'being on the radar', with dominating a sector. > >Some are more significant than others though... MIPS for example joined >the MCU game only recently, and they have (like PPC) major codesize >issues, so you need a bigger and more expensive device.
Actually in my very limited experience CISC machines need much more initialization than Regular Instruction Set Computers. Moreover CISC needs much more protection from errant processes, and much more dedicated register saving. Code size may be a compiler issue or a practitioner issue.
> >> This recent news item, shows how much more power matters, than cores, these days.... > >Sure power consumption matters. But it's nothing new though - ARM wouldn't >be where it is today if it hadn't been low power from the start. The core matters >a lot of course as it uses much of the power. Intel have recently found out >again how bad CISC is for power with their Atom core (one can run an ARM >at full speed on the power it wastes when it is in its deepest sleep!). >Having good process technology helps, but it doesn't "fix" a bad core. > >>> Of course just about all of the MCU manufacturers have licensed the >>> M3 since then as expected, including Atmel... >> >> True, and NONE are yet offeringn pin-compatible second sources, but >> Freescale and ST ARE now offering PowerPC second sourcing, for >> their demanding Automotive customers. > >Well that's their claim anyway... Could you point me to just one device that >is actually pin compatible? A look at the ST/FS websites doesn't prove there >exist any identical devices. The only thing they have in common is the e200 >core, that's about it. As I've said before, making identical devices in every >aspect doesn't make any commercial sense. > >Wilco >
On Thu, 24 Jul 2008 11:31:56 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>Wilco Dijkstra wrote: >> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:48871863@clear.net.nz... >> >>>It can make very good commercial sense - after all, they are not duplicating R&D, all they are doing is an extension >>>of Dual_Fab, >>>which some companies offer now, as a Psudeo Second Source. >> >> >> Well maybe you explain why it is a good idea to make X devices in one fab >> and Y in another when you could make X+Y in just one fab and get the >> advantage of higher volumes? It only becomes necessary to use another >> fab if one is maxed out (highly unlikely given the volumes for automotive >> are small compared to other market segments). > >Talk to the big players that do this already. > >Xilinx is one good example. > >Some large corporates (and military too) see the bigger picture, and >have quite strict risk management policies, that dictate an earthquake >or other single point event, cannot be allowed to disrupt their total >business. > >When you are making cars, that processor suddenly gets extremely >expensive if that ONE fab is taken out, halting your vehicle line! > > >> >> Given the high costs involved to align two processes and qualify identical >> designs on them and the resulting lower volumes I'd say it's a good way to >> ensure the devices will cost more than they really need to. Also we're not >> talking about true second source with price and performance competition >> (like when you could replace an Intel 286 or 386 with an AMD clone that >> was faster) but a joint venture by two companies. > >Spanning two continents, and with multiple fabs. > >I'd say that has some appeal to the risk-managers in the large >corperations. > >You see, there is a LOT more to chip selection decisions, than just >"which core"? > > >-jg
Perzactly. Separation and regularization of fab / process and design.
"JosephKK" <quiettechblue@yahoo.com> wrote in message news:tskn841juifoem0nnu69unba2levtouial@4ax.com...
> On Wed, 23 Jul 2008 11:10:34 +0100, "Wilco Dijkstra" > <Wilco.removethisDijkstra@ntlworld.com> wrote:
>>Some are more significant than others though... MIPS for example joined >>the MCU game only recently, and they have (like PPC) major codesize >>issues, so you need a bigger and more expensive device. > > Actually in my very limited experience CISC machines need much more > initialization than Regular Instruction Set Computers. Moreover CISC > needs much more protection from errant processes, and much more > dedicated register saving. Code size may be a compiler issue or a > practitioner issue.
I meant ISA differences. Each instruction set has a different maximum density (assuming perfect compilers). This density depends on how many registers are available, how powerful instructions are, and how they are encoded. The original RISCs like MIPS and PPC went for all out performance with simple instructions, while ARM added more powerful instructions (such as load/store multiple). The result is ARM has far better codesize (when I last measured it, MIPS was about twice as big as ARM, even MIPS16 was larger than ARM). As Microchip is now making MIPS MCUs this is an issue as you need a bigger flash (ie. a more expensive device). Wilco