Science and Technology news... :: View topic - 32-bit Microcontroller for $1.00

Hans-Bernhard Bröker · Guest

Joerg wrote:
[quote]Hans-Bernhard Brö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.
[/quote]
.... of a company on the other side of the planet? Yeah, right.

Joerg · Guest

Hans-Bernhard Bröker wrote:
[quote]Joerg wrote:
Hans-Bernhard Brö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.

[/quote]
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.

JosephKK · Guest

On Wed, 23 Jul 2008 11:10:34 +0100, "Wilco Dijkstra"
<Wilco.removethisDijkstra@ntlworld.com> wrote:

[quote]
"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.
[/quote]
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.

[quote]
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
[/quote]

JosephKK · Guest

On Thu, 24 Jul 2008 11:31:56 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

[quote]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
[/quote]
Perzactly. Separation and regularization of fab / process and design.

Wilco Dijkstra · Guest

"JosephKK" <quiettechblue@yahoo.com> wrote in message news:tskn841juifoem0nnu69unba2levtouial@4ax.com...
[quote]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.
[/quote]
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

Nico Coesel · Guest

"Wilco Dijkstra" <Wilco.removethisDijkstra@ntlworld.com> wrote:

[quote]
"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
[/quote]
Got any references to support this? I work with both ARM7 and MIPS32
using the 'same' compiler (GCC 4.2.1) but I>m not under the impression
that the code size for MIPS32 is considerably larger then for the
ARM7.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Wilco Dijkstra · Guest

"Nico Coesel" <nico@puntnl.niks> wrote in message news:488cc317.78543549@news.planet.nl...
[quote]"Wilco Dijkstra" <Wilco.removethisDijkstra@ntlworld.com> wrote:

"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

Got any references to support this? I work with both ARM7 and MIPS32
using the 'same' compiler (GCC 4.2.1) but I>m not under the impression
that the code size for MIPS32 is considerably larger then for the
ARM7.
[/quote]
It>s well known MIPS32 has codesize problems due to its simple instructions.
I measured it myself on a huge codesize benchmark, you can try doing the
same for your code (although GCC is obviously not the best compiler for ARM,
so the difference won>t be as large). This is a good post from Anton comparing
various backends of GCC showing that MIPS is the worst of all RISCs:

http://newsgroups.derkeiler.com/Archive/Comp/comp.arch/2007-12/msg00433.html

Wilco

Ben Bradley · Guest

On Mon, 21 Jul 2008 19:10:31 +0000, Guy Macon
<http://www.GuyMacon.com/> wrote:

[quote]

While researching something else, I ran into the
following rather interesting opinions:

Consolidating the MCU market around the ARM architecture
("It>s inevitable. ARM>s Cortex-M3 processor core is going
dominate the MCU market.")
http://www.embedded.com/columns/guest/207001013

Luminary Micro Announces 32-bit Microcontrollers for $1.00
[/quote]
Okay, but can you get it in an 8-pin package?

Guy Macon · Guest

Ben Bradley wrote:
[quote]
Guy Macon <http://www.GuyMacon.com/> wrote:

While researching something else, I ran into the
following rather interesting opinions:

Consolidating the MCU market around the ARM architecture
("It>s inevitable. ARM>s Cortex-M3 processor core is going
dominate the MCU market.")
http://www.embedded.com/columns/guest/207001013

Luminary Micro Announces 32-bit Microcontrollers for $1.00

Okay, but can you get it in an 8-pin package?
[/quote]
Certainly. Just take your wire cutter and snip off 40
of the 48 pins.

http://www.luminarymicro.com/products/lm3s811_microcontroller.html

IIRC, they also have a 28 pin SOIC version, so you might only
have to snip off 20 pins.

I hope this helps...

--
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>

Stephen Fuld · Guest

Guy Macon wrote:
[quote]Ben Bradley wrote:
Guy Macon <http://www.GuyMacon.com/> wrote:

While researching something else, I ran into the
following rather interesting opinions:

Consolidating the MCU market around the ARM architecture
("It>s inevitable. ARM>s Cortex-M3 processor core is going
dominate the MCU market.")
http://www.embedded.com/columns/guest/207001013

Luminary Micro Announces 32-bit Microcontrollers for $1.00
Okay, but can you get it in an 8-pin package?

Certainly. Just take your wire cutter and snip off 40
of the 48 pins.

http://www.luminarymicro.com/products/lm3s811_microcontroller.html

IIRC, they also have a 28 pin SOIC version, so you might only
have to snip off 20 pins.

I hope this helps...
[/quote]
And if you choose carefully and cut off the power pins, you should
reduce power
consumption also, which might be a further help. :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Electronics - design Forum	Goto page Previous 1, 2, 3, 4
Page 4 of 4