My impression is that Microchip faltered for a few years inbetween the
original line of PICs "maturing" and coming out with dsPICs and other
interesting parts. At the time, some core employees left, such as the guys
who started up Scenix (later Ubicom -- pipelined 50MHz PICs, essentially), and
I recall reading that they mentioned they motivation was due to Microchip
management having no interest (at the time) in their ideas.
What does a company that no longer has the technical leadership to produce
interesting new products do?
Sue the guys who do, if it's at all possible that a link can be established
between what the new guys are doing and what you were doing back in your
heyday, regardless of how tenuous that link might be.
I could be completely wrong about this, of course... I just remember those
years where it seemed that Microchip had lost its way.
---Joel
Reply by Guy Macon●August 1, 20082008-08-01
Jim Granville wrote:
>
>Guy Macon <http://www.GuyMacon.com/> wrote:
>
>> 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...
>
>You forgot to mention that such Pin-snip can be
>legally dangerous!!.
>
>So, as well as wearing the appropriate goggles, be sure to
>do so only in the presence of your lawyer!!
>
>For the element of truth to this, see:
>http://www.microcontroller.com/news/luminary_micro_lawsuit.asp
> 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...
You forgot to mention that such Pin-snip can be
legally dangerous!!.
So, as well as wearing the appropriate goggles, be sure to
do so only in the presence of your lawyer!!
For the element of truth to this, see:
http://www.microcontroller.com/news/luminary_micro_lawsuit.asp
-jg
Reply by Stephen Fuld●August 1, 20082008-08-01
Guy Macon wrote:
> 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...
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)
Reply by Guy Macon●August 1, 20082008-08-01
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?
>
>
>
>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?
Reply by Wilco Dijkstra●July 28, 20082008-07-28
"Nico Coesel" <nico@puntnl.niks> wrote in message news:488cc317.78543549@news.planet.nl...
> "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.
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
>
>"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.
--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
Reply by Wilco Dijkstra●July 27, 20082008-07-27
"JosephKK" <quiettechblue@yahoo.com> wrote in message news:tskn841juifoem0nnu69unba2levtouial@4ax.com...
>>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
Reply by JosephKK●July 26, 20082008-07-26
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.