Searching \ for '[PIC]: Microchip 8-bit market article' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Microchip 8-bit market article'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Microchip 8-bit market article'
2006\05\17@095330 by Charles Craft

picon face
Guess these numbers are in the SEC docs they release but I never get around to reading those.

Interesting stats.

http://biz.yahoo.com/ibd/060516/general01.html?.v=1

<snip>

The company sells more 8-bit units than any of its rivals and counts 50,000 customers worldwide. These customers make everything from household appliances and office equipment to autos and disposable medical products.

Microchip Technology also spreads its business around. No one customer makes up more than 3% of overall sales.

<snip>


2006\05\17@101634 by Xiaofan Chen

face picon face
On 5/17/06, Charles Craft <spam_OUTchuckseaTakeThisOuTspammindspring.com> wrote:
> Guess these numbers are in the SEC docs they release but I never get around to reading those.
>
> Interesting stats.
>
> http://biz.yahoo.com/ibd/060516/general01.html?.v=1
>
<snip>
Meanwhile, Microchip Technology is gaining share in the market for
higher-priced 16-bit microcontrollers.

The company entered the 16-bit market two years ago. Its sales in the
sector rose 52% last quarter, though from a small base. It doesn't
break out total 16-bit sales.

Sanghi vows to become No. 1 in 16 bits, though he admits "it's going
to take a while."

"It took 12 years to become No. 1 (in 8 bits)," he said.

<snip>

This will be more interesting to watch. I will say Microchip will continue
to dominate in the 8-bit market. But I am not so sure about whether 16-bit
PIC24/dsPIC30/dsPIC33 will dominate the market or not given the
strong competition from incumbent players (Infineon, Freescale, Renesas,
Fujitsu, TI, ...) and new ARM based low cost 32-bit players (Philips, Atmel,
TI, ...)

Regards,
Xiaofan

2006\05\17@104618 by Wouter van Ooijen

face picon face
> The company sells more 8-bit units than any of its rivals and counts
50,000 customers worldwide.

I am not sure what that figure means. A few 100s different people are
buying PICs from me, but I think in Microchips view I am only 1 of those
50,000 (or maybe I am not counted at all).

But I am not so sure of their position in the >8 bit markets. If Philips
and Atmel are serious with thier ARM chips... (serious requires at least
that they don't drop any existing chip unless there is a real drop-in
replacement).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\17@184927 by Xiaofan Chen

face picon face
On 5/17/06, Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl> wrote:
>
> But I am not so sure of their position in the >8 bit markets. If Philips
> and Atmel are serious with thier ARM chips... (serious requires at least
> that they don't drop any existing chip unless there is a real drop-in
> replacement).
>

I am not sure either. But Atmel? They have AVR32 and they are not
known for keeping chips available, either old chips or even current chips...
I do not know much about Philips. But I know the guys in the local Philips
development center like to use Freescale MCUs and is trying Microchip.
That is not a good sign. ARM should enlist better partners.

Regards,
Xiaofan

2006\05\17@220135 by kravnus wolf

picon face
Xiaofan,

  How is Zilog MCU availability? Any better than AVR?

John

--- Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:

{Quote hidden}

> --

2006\05\17@220212 by kravnus wolf

picon face
Xiaofan,

  How is Zilog MCU availability? Any better than AVR?

John

--- Xiaofan Chen <EraseMExiaofancspam_OUTspamTakeThisOuTgmail.com> wrote:

{Quote hidden}

> --

2006\05\18@141750 by Paul James E.

picon face

All,

My 2 cents worth.  I believe that not only will Microchip take a
leadership position in 16 bit micros too, it will do that in only
8 years and not the 12 it took to gain the 8 bit leadership position.

My reasoning is in 1990, when Microchip was beginning to make their
comeback, there was virtually no market visibility or penetration.
However, now that they are the 8 bit leaders in the industry, their
market visibility and penetration is rather broad and deep respectfully.

And in my opinion, they have excellent products, excellent tools, and
excellent support.  Their products are relatively inexpensive and
reasonably easy to get (at least in the US).  Their development tools are
a little pricey, but when compared to other manufacturers products and
tools, they are still reasonably priced.

With all of that said, it stands to reason to me that with the
introduction of the 24 series parts, that their ability to get devices
into the marketplace by the integration of these devices in higher
performance embedded systems will be much easier.  And I believe that the
users of Microchips current product lineup will be some of the first to
utilize the newer chips because of performance gains in some applications.

There are currently applications out there that use the 8 bit parts and
that's enough horsepower for the job.  However, there are also some
applications out there that could use a slight boost in performance, and
the 16 bit parts will facilitate this performance increase.   Likewise,
there are applications where no microchip part heretofore has had the
performance and/or resources to make it practical.   With the 16 bit
parts, that situation has changed, so now those applications can be
realized.   And further still, new users will come on board because of the
release of the 16 bit parts.

And if the future leadership of Microchip's management team continues as
it has for the last 16 years or so, and given the reasoning stated above,
I see no compelling reason why Microchip's taking over the 16 bit market
couldn't be realized.   And, considering their experience so far in
growing something from virtually nothing, they should be able to do it in
record time.

Hence, my prediction that it will be done in 8 years or less versus the 12
years to take over the 8 bit market.

So, by 2014, Microchip should be first in the 16 bit market, and will
probably retain first place in the 8 bit market.

I guess time will tell.  

Sorry for the long winded talk, but I just wanted to give my opinion, for
whatever it's worth.   I'm done now, so back to the regular programming.

Does anyone agree?   Disagree?   Just checking.

                                               Regards,

                                                 Jim


{Quote hidden}

> --

2006\05\18@163140 by Bob Axtell

face picon face
Paul James E. wrote:
{Quote hidden}

I agree.

--Bob

{Quote hidden}

>> --

2006\05\18@184902 by Xiaofan Chen

face picon face
On 5/18/06, kravnus wolf <RemoveMEkravnusTakeThisOuTspamyahoo.com> wrote:
> Xiaofan,
>
>   How is Zilog MCU availability? Any better than AVR?
>
> John

I do not know since I am not familiar with them. I do not think
eZ8 can compete with PICs, AVRs and 8051s.

Regards,
Xiaofan

2006\05\18@190751 by Russell McMahon

face
flavicon
face
>>   How is Zilog MCU availability? Any better than AVR?

After my experiences with Zilog they would have to have an utterly
compelling product to tempt me back.

Availability was not the issue. Getting a part which met spec sheet
specs and did not vary from batch to batch, and getting them to
believe that the problems existed, were major hassles. YMMV.


       RM

2006\05\18@212742 by kravnus wolf

picon face


--- Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:

{Quote hidden}

 I guess as much. Quite hard to get them as it is.

John

> Regards,
> Xiaofan
>
> --

2006\05\19@093730 by Xiaofan Chen

face picon face
On 5/17/06, Paul James E. <RemoveMEjamespspamTakeThisOuTintertex.net> wrote:
>
>  My 2 cents worth.  I believe that not only will Microchip take a
>  leadership position in 16 bit micros too, it will do that in only
>  8 years and not the 12 it took to gain the 8 bit leadership position.
>

I am not so sure. I have spoken to quite some people who are using
AVRs/8051s/ARMs and their perception of PICs are in general staying
at PIC16C/16Fs. The response is in general "Oh PIC, I know they are
simple to use but the architecture sucks and they are not good at
more complicated tasks". Apparently they do not know much of the
existence of PIC24/dsPICs. And if I look into the current consumption
of dsPICs, I won't use them either in the applications where power
consumption will really be an issue in small housings.

Regards,
Xiaofan

2006\05\19@102615 by Wouter van Ooijen

face picon face
>>  My 2 cents worth.  I believe that not only will Microchip take a
>>  leadership position in 16 bit micros too, it will do that in only
>>  8 years and not the 12 it took to gain the 8 bit
>> leadership position.
>
> I am not so sure.

Neither am I. If I read my tealeaves right the 16-bit market will be
small because the >8 bit market will be dominated by 32 bit
architectures (ARM, probably others too).

OTOH (literally!) I don't see any real (readily available) alternatives
for the 10F's. Maybe Microchip should look down, not up.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\19@111424 by Xiaofan Chen

face picon face
On 5/19/06, Wouter van Ooijen <wouterEraseMEspam.....voti.nl> wrote:
>
> Neither am I. If I read my tealeaves right the 16-bit market will be
> small because the >8 bit market will be dominated by 32 bit
> architectures (ARM, probably others too).
>
> OTOH (literally!) I don't see any real (readily available) alternatives
> for the 10F's. Maybe Microchip should look down, not up.
>

Microchip has already got the low end market right. They are
already the No 1 in the 8-bit market in terms of unit shipment.
So they have to look up. They want to be a 2-billion company
so they got to be successful in the 16-bit market.

If Microchip would license the ARM core, then maybe it is
a different story. I think Microchip will beat Atmel and
Philips pretty easily in the ARM clone market if they
want to.

Regards,
Xiaofan

2006\05\19@114717 by Bob Axtell

face picon face
Xiaofan Chen wrote:
{Quote hidden}

I am inclined to agree with Wouter that Microchip is missing something
by not expanding
the very low end (PIC10Fxxxx). There are huge possibilities for
replacement of random
logic if the speed could be raised to at least 10Mhz (I think 8Mhz would
be easy),
and doubling code & RAM memory size.

This would allow the PIC16Fxxxx to be used as specialized counters /
timers and serial
protocol converters, such as standard serial to manchester converters,  
quadrature tach
converters, etc

--Bob
.

2006\05\19@124851 by Peter

picon face

On Fri, 19 May 2006, Wouter van Ooijen wrote:

> OTOH (literally!) I don't see any real (readily available) alternatives
> for the 10F's. Maybe Microchip should look down, not up.

But how low must one look before one starts having to use mask
programmed parts simply for lack of pins ? The 10F programming algorythm
is quite a piece as is.

Peter

2006\05\19@125714 by Herbert Graf

flavicon
face
On Fri, 2006-05-19 at 23:14 +0800, Xiaofan Chen wrote:
> Microchip has already got the low end market right. They are
> already the No 1 in the 8-bit market in terms of unit shipment.
> So they have to look up. They want to be a 2-billion company
> so they got to be successful in the 16-bit market.
>
> If Microchip would license the ARM core, then maybe it is
> a different story. I think Microchip will beat Atmel and
> Philips pretty easily in the ARM clone market if they
> want to.

See, that's where I disagree.

There seems to be a strong opinion that going 16bit/32bit means going
with ARM. I've seem this opinion quite alot and just can't quite agree
with it.

My experience with the ARM architecture is that it is more focused on
being a microprocessor instead of a microcontroller. This is an
important distinction that has allowed MCHIP to capture the 8bit market,
since the 8bit market no longer cares much about "processing" tasks and
is more focused on "controlling" tasks.

My prediction is as the 16/32bit markets progress this same shift will
occur. After all, if you need to do heavy processing and the price
difference between a 16bit part and a 32bit part was zero, you'd likely
go to the 32bit part.

Once this vaccum develops (in many ways it's well on it's way to forming
today) it will be Mchip's chance to take over the 16bit controller
market (which might be why there is such a push on Mchip's part into
their 16bit MCU lines).

If Mchip IS interested in getting into the MPU market then I agree,
going with an ARM type architecture is a good idea, simply because
development is so much quicker due to the established knowledge base.
But I don't think Mchip should go there, they do so well in the MCU
arena, and there is a LOT of room for expansion there IMHO.

TTYL

2006\05\19@131756 by William Chops Westfield

face picon face

On May 19, 2006, at 8:47 AM, Bob Axtell wrote:

>>> If I read my tealeaves right the 16-bit market will be
>>> small because the >8 bit market will be dominated by 32 bit
>>> architectures (ARM, probably others too).

I'm inclined to agree here.  I think the 8bit cores have gotten
faster and the 32bit cores have gotten cheaper, to the point
where 16bit cores are being squeezed out of existence (if there
ever were any true 16 bit cores. x86?  PDP11?)

Putting more into the very small chips would indeed be an
interesting strategy;  Large numbers of PWMs in a small package
is something that has come up several times, and has applications
in motor driving and etc...


>> If Microchip would license the ARM core...

Now THAT would be interesting...

BillW

2006\05\19@145132 by Wouter van Ooijen

face picon face
> > OTOH (literally!) I don't see any real (readily available)
> alternatives
> > for the 10F's. Maybe Microchip should look down, not up.
> >
>
> Microchip has already got the low end market right. They are
> already the No 1 in the 8-bit market in terms of unit shipment.
> So they have to look up.

Not necesarily. Staying No1 in an expanding market is interesting too. I
think the 8-bit market has still a big potential on the lower end.

> If Microchip would license the ARM core, then maybe it is
> a different story.

now that would be interesting! will you convince them? :)

I don't think James would object to an [ARM] tag?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\19@155433 by Spehro Pefhany

picon face
At 10:19 AM 5/19/2006 -0700, you wrote:

>On May 19, 2006, at 8:47 AM, Bob Axtell wrote:
>
> >>> If I read my tealeaves right the 16-bit market will be
> >>> small because the >8 bit market will be dominated by 32 bit
> >>> architectures (ARM, probably others too).
>
>I'm inclined to agree here.  I think the 8bit cores have gotten
>faster and the 32bit cores have gotten cheaper, to the point
>where 16bit cores are being squeezed out of existence (if there
>ever were any true 16 bit cores. x86?  PDP11?)

The ARM7 is a 16 bit core in Thumb mode. The MSP430 is called 16-bit, and
it's quite attractive in so

One point I didn't see touched upon is that of code density. The
cost of a 32-bit core and an 8-bit may be essentially equal with,
say, 0.18u technology (since it's such a tiny percentage of the total
die real estate), but if the required flash for a given application is
50% more then the chip will be noticeably more expensive to make.

>Putting more into the very small chips would indeed be an
>interesting strategy;  Large numbers of PWMs in a small package
>is something that has come up several times, and has applications
>in motor driving and etc...
>
>
> >> If Microchip would license the ARM core...
>
>Now THAT would be interesting...

They would certainly get a lot of sales. Especially with the right
peripherals on-chip. But Sandhi specifically wants to increase *margins*,
and that's maybe not the best way to do that. With a proprietary chip, the
customer is locked in, and competition is kept out to a greater extent.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffEraseMEspamEraseMEinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->>Test equipment, parts OLED displys http://search.ebay.com/_W0QQsassZspeff


2006\05\19@162241 by Wouter van Ooijen

face picon face
> >I'm inclined to agree here.  I think the 8bit cores have gotten
> >faster and the 32bit cores have gotten cheaper, to the point
> >where 16bit cores are being squeezed out of existence (if there
> >ever were any true 16 bit cores. x86?  PDP11?)
>
> The ARM7 is a 16 bit core in Thumb mode.

I think in the text you are referring to you should read '8bit' instead
of '8bit core'. I don't think any real '8bit cores' exist any more.

> One point I didn't see touched upon is that of code density. The
> cost of a 32-bit core and an 8-bit may be essentially equal with,
> say, 0.18u technology (since it's such a tiny percentage of the total
> die real estate), but if the required flash for a given application is
> 50% more then the chip will be noticeably more expensive to make.

True, but if you are comparing core (instruction) widths the 16F PICs
are 14-bit cores, so the difference with a 16-bit core thumb-mode-ARM is
vanishingly small.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\19@172531 by William Chops Westfield

face picon face

On May 19, 2006, at 1:20 PM, Wouter van Ooijen wrote:

>  I don't think any real '8bit cores' exist any more.
>
For the sake of this discussion, let's define "core size"
based on the registers and the add instruction.  If it has
16bit registers and a 16bit add instruction, it's a 16bit
processor.  32bit registers and add makes it a 32bit processor,
and only 8 bits makes it an 8bit core.  That makes a Z80 an 8
bit core despite the limited double add, the 8086 a 16bit, and
a 68000 a 32bit processor.  That makes the PIC an 8bit core
without question...  Instruction size doesn't really matter.

BillW

2006\05\19@175700 by Spehro Pefhany

picon face
At 10:20 PM 5/19/2006 +0200, you wrote:

>True, but if you are comparing core (instruction) widths the 16F PICs
>are 14-bit cores, so the difference with a 16-bit core thumb-mode-ARM is
>vanishingly small.
>
>Wouter van Ooijen

Not instruction width, code density. How many K bytes does an entire
application take coded for core A vs. core M? That determines the area
of silicon required to store the program for a given technology.

There are many factors which affect this at the best of times, and it's
prone to marketing exaggerations such as the old Microchip ads which
misleadingly claimed a large savings of code space over Motorola (now
Freescale).

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffspam_OUTspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->>Test equipment, parts OLED displys http://search.ebay.com/_W0QQsassZspeff


2006\05\19@184737 by olin piclist

face picon face
William Chops Westfield wrote:
> For the sake of this discussion, let's define "core size"
> based on the registers and the add instruction.

Let's not since that's not what it means, and is certainly not how Microchip
uses the term.  The core size refers to the instruction processor, which is
why the PIC 16 is referred to as having a 14 bit core.  If you don't say
"core", it generally means the ALU width or the bit width of the most native
data word.  In that respect the PIC 16 is a "8 bit processor" since it has 8
bit data paths and ALU.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\05\19@190739 by Xiaofan Chen

face picon face
On 5/20/06, Wouter van Ooijen <RemoveMEwouterTakeThisOuTspamspamvoti.nl> wrote:
> > > OTOH (literally!) I don't see any real (readily available)
> > alternatives
> > > for the 10F's. Maybe Microchip should look down, not up.
> > >
> >
> > Microchip has already got the low end market right. They are
> > already the No 1 in the 8-bit market in terms of unit shipment.
> > So they have to look up.
>
> Not necesarily. Staying No1 in an expanding market is interesting too. I
> think the 8-bit market has still a big potential on the lower end.

But this is the intention of Microchip CEO and people inside Microchip.
They want to be successful in the 16-bit market where they will
have higher growth. For US company on stock market, growth is the
keyword. They say the 8-bit growth is already not fast for them.

> > If Microchip would license the ARM core, then maybe it is
> > a different story.
>
> now that would be interesting! will you convince them? :)
>
> I don't think James would object to an [ARM] tag?
>

I will try. ;-) Maybe I will try to use LPC21xx and not Microchip in
my next job.

Regards,
Xiaofan

2006\05\19@191510 by Xiaofan Chen

face picon face
On 5/20/06, Herbert Graf <EraseMEmailinglist2spamspamspamBeGonefarcite.net> wrote:
> >
> > If Microchip would license the ARM core, then maybe it is
> > a different story. I think Microchip will beat Atmel and
> > Philips pretty easily in the ARM clone market if they
> > want to.
>
> See, that's where I disagree.
>
> There seems to be a strong opinion that going 16bit/32bit means going
> with ARM. I've seem this opinion quite alot and just can't quite agree
> with it.
>
> My experience with the ARM architecture is that it is more focused on
> being a microprocessor instead of a microcontroller. This is an
> important distinction that has allowed MCHIP to capture the 8bit market,
> since the 8bit market no longer cares much about "processing" tasks and
> is more focused on "controlling" tasks.

There are new Microcontroller oriented ARM core like Cortex M3. If Microchip's
patent is invalidated, more lower end ARM based MCU will be out.

www.arm.com/products/CPUs/ARM_Cortex-M3.html
http://www.luminarymicro.com/index.php?option=com_content&task=view&id=65&Itemid=187

Microchip's patent will make companies to pay them to develop, for
example,6-pin 8-bit MCUs, 14pin 16-bit MCUs and 28pin/30pin 32-bit
MCUs.

Regards,
Xiaofan

2006\05\19@192713 by William Chops Westfield

face picon face

On May 19, 2006, at 3:47 PM, Olin Lathrop wrote:

>> For the sake of this discussion, let's define "core size"
>> based on the registers and the add instruction.
>
> Let's not since that's not what it means, and is certainly not
> how Microchip uses the term.  The core size refers to the
> instruction processor, which is why the PIC 16 is referred
> to as having a 14 bit core.

Microchip is the only one that uses it that way (arguably, they're
the only one that needs to.)  I use "core" to distinguish internal
register/alu size from external bus size (so that an 8088 and 8086
are both 16 bit cores.)

> If you don't say "core", it generally means the ALU width or the
> bit width of the most native data word.  In that respect the PIC
> 16 is a "8 bit processor" since it has 8 bit data paths and ALU.
>
Ok; I agree not to say "core."  This discussion isn't about
instruction size, it's about alu/register size.  When one says
that an ARM is a 16bit CPU and the PIC24 is a 16bit CPU, they're
not talking about instruction size.  And microchip would be a
laughing stock if they tried to claim to be the "16 bit leader"
based on the instruction size of PIC18...

BillW

2006\05\20@045339 by Wouter van Ooijen

face picon face
> When one says that an ARM is a 16bit CPU [snip], they're
> not talking about instruction size.

I would hope the are, because otherwise they are wrong. ARM is
32-bit-datapath and 32 (ARM) or 16 (thumb) bit-instruction.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\20@045340 by Wouter van Ooijen

face picon face
> For the sake of this discussion, let's define "core size"
> based on the registers and the add instruction.  If it has
> 16bit registers and a 16bit add instruction, it's a 16bit
> processor.  32bit registers and add makes it a 32bit processor,
> and only 8 bits makes it an 8bit core.  That makes a Z80 an 8
> bit core despite the limited double add, the 8086 a 16bit, and
> a 68000 a 32bit processor.  That makes the PIC an 8bit core
> without question...  Instruction size doesn't really matter.

In Microchip documentation the terems '12-bit core', '14-bit core', etc
are often used, so I would prefer to reserve that for the instruction
width. And I do think the instruction witdh does matter, if only for the
amount of code flash needed.

But OK, to avoid all confusion, let's talk about 'N-bit-datapath' and
'N-bit-instruction' chips.

I don't think there is much room for 16-bit-datapath chips, being
squeezed by well-established 8-bitters (PIC, 8051, AVR) and 32-bitters
like the ARM getting cheaper and available 'round the corner'.

The ARM in thumb-mode is a 16-bit-core, so I don't think its code size
will be much worse than a 14-bit-core PIC (16F's, some 12F's).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\20@052616 by Xiaofan Chen

face picon face
On 5/20/06, Spehro Pefhany <RemoveMEspeffKILLspamspaminterlog.com> wrote:

> Not instruction width, code density. How many K bytes does an entire
> application take coded for core A vs. core M? That determines the area
> of silicon required to store the program for a given technology.

The Arm Thumb and Thumb 2 are ARM's solution for higher code
density. In fact, the low end Cortex M3 MCU does not support
ARM instruction set, it only supports Thumb 2 instruction set.

www.arm.com/products/CPUs/archi-thumb2.html
http://www.arm.com/products/CPUs/ARM_Cortex-M3.html

Still the core does not really occupy the bulk of the MCU. The
memory and peripherals often occupy more space. Often
the peripherals decide the chip selection. For example, we
decided to use Silicon Labs C8051F MCU for an optic sensor
since it has a fast ADC and no PIC16F/18F have the
ADC performance we need.

www.atmel.com/dyn/resources/prod_documents/doc3323.pdf
is a nice white paper from Atmel. (But it is a pain that copy and
paste is not allowed!)

In the conclusion, the author tells us the real challenge:
"The migration from 8-bit to 32-bit microcontrollers is not just a question
of device cost. The integration level reached on 8-bit microcontrollers
during the last years must be matched."

For example, Atmel's ADC implementation in their AVR sucks since
it is very slow. Atmel's ARMs continue to use the slow ADC implementation.
This makes them useless for quite some applications even with a fast
and nice core.

Regards,
Xiaofan

2006\05\20@072236 by Herbert Graf
flavicon
face
On Sat, 2006-05-20 at 17:19 +0800, Xiaofan Chen wrote:
> Still the core does not really occupy the bulk of the MCU. The
> memory and peripherals often occupy more space. Often
> the peripherals decide the chip selection. For example, we
> decided to use Silicon Labs C8051F MCU for an optic sensor
> since it has a fast ADC and no PIC16F/18F have the
> ADC performance we need.

Yes, ADC performance has been a limitation with PICs, even their DSP
line often doesn't have "enough" ADC for me.

> www.atmel.com/dyn/resources/prod_documents/doc3323.pdf
> is a nice white paper from Atmel. (But it is a pain that copy and
> paste is not allowed!)

Ahh, Linux(or other alternate OSs) to the rescue. Flip one option in the
config of KPDF and you can copy to your hearts content!

TTYL

2006\05\20@081803 by Gerhard Fiedler

picon face
Peter wrote:

>> OTOH (literally!) I don't see any real (readily available) alternatives
>> for the 10F's. Maybe Microchip should look down, not up.
>
> But how low must one look before one starts having to use mask
> programmed parts simply for lack of pins ? The 10F programming algorythm
> is quite a piece as is.

I think the idea of using 10F parts as replacements for dedicated chips is
pretty attractive, but it hangs on two issues (and IMO none has to do with
programming the memory).

One is that there needs to be a variety of chips with the right on-board
peripherals for the job. To be cheap and small, they probably can't have
the whole selection of peripherals on-board, and so you need to be able to
get the one that you need.

The other is that developing custom firmware is expensive. This could be
addressed by providing working modules for common applications. Not
necessarily something they would have to provide, but something they could
provide the infrastructure for it. If you're talking about replacing simple
(but maybe more expensive or bigger) hardware solutions, this is an
important part. Unless you're only looking at products that sell in the
millions.

Gerhard

2006\05\20@085441 by Xiaofan Chen

face picon face
On 5/20/06, Gerhard Fiedler <listsSTOPspamspamspam_OUTconnectionbrazil.com> wrote:
> I think the idea of using 10F parts as replacements for dedicated chips is
> pretty attractive, but it hangs on two issues (and IMO none has to do with
> programming the memory).
>

I think one thing is that 10F is not really that cheap after all. It really
has something to do with memory programming which adds to the
process time and production cost. Of course the reason of on chip
peripherals and  the cost of firmware developing you mentioned are
also big reasons.

2006\05\20@090915 by Xiaofan Chen

face picon face
On 5/20/06, Herbert Graf <spamBeGonemailinglist2STOPspamspamEraseMEfarcite.net> wrote:
>
> > www.atmel.com/dyn/resources/prod_documents/doc3323.pdf
> > is a nice white paper from Atmel. (But it is a pain that copy and
> > paste is not allowed!)
>
> Ahh, Linux(or other alternate OSs) to the rescue. Flip one option in the
> config of KPDF and you can copy to your hearts content!
>

Thanks for the tip. I am using Gnome so the default application to
open pdf file is evince. Indeed KPDF has this option. To uncheck
"Obey DRM limitations" and I can then copy and paste from the
pdf file.

Regards,
Xiaofan

2006\05\20@095554 by Dave Lag

picon face
Xiaofan Chen wrote:
> On 5/20/06, Herbert Graf <KILLspammailinglist2spamBeGonespamfarcite.net> wrote:
>
>>>www.atmel.com/dyn/resources/prod_documents/doc3323.pdf
>>>is a nice white paper from Atmel. (But it is a pain that copy and
>>>paste is not allowed!)
>>
>>Ahh, Linux(or other alternate OSs) to the rescue. Flip one option in the
>>config of KPDF and you can copy to your hearts content!
>>
>
>
> Thanks for the tip. I am using Gnome so the default application to
> open pdf file is evince. Indeed KPDF has this option. To uncheck
> "Obey DRM limitations" and I can then copy and paste from the
> pdf file.
>
> Regards,
> Xiaofan
>
I don't suppose this is part of the knoppix CD?
That would be useful.
D

2006\05\20@102038 by Dave Lag

picon face
> The other is that developing custom firmware is expensive. This could be
> addressed by providing working modules for common applications. Not
> necessarily something they would have to provide, but something they could
> provide the infrastructure for it. If you're talking about replacing simple
> (but maybe more expensive or bigger) hardware solutions, this is an
> important part. Unless you're only looking at products that sell in the
> millions.
>
> Gerhard

Having software that could write the code as you drag your logic
blocks/gates to the screen? That would be great-might never use
TTL et al again.
(I presume this is what the software described in the FPGA thread does)
D


2006\05\20@152404 by Peter

picon face


On Sat, 20 May 2006, Xiaofan Chen wrote:

> But this is the intention of Microchip CEO and people inside Microchip.
> They want to be successful in the 16-bit market where they will
> have higher growth. For US company on stock market, growth is the
> keyword. They say the 8-bit growth is already not fast for them.

But in a limited market growth and long term stability do not go
together.

Peter

2006\05\20@153556 by Peter

picon face

On Sat, 20 May 2006, Gerhard Fiedler wrote:

> Peter wrote:
>
>>> OTOH (literally!) I don't see any real (readily available) alternatives
>>> for the 10F's. Maybe Microchip should look down, not up.
>>
>> But how low must one look before one starts having to use mask
>> programmed parts simply for lack of pins ? The 10F programming algorythm
>> is quite a piece as is.
>
> I think the idea of using 10F parts as replacements for dedicated chips is
> pretty attractive, but it hangs on two issues (and IMO none has to do with
> programming the memory).

The idea is that the next (?) generation of microcontrollers will likely
have programmable embedded analog functions in them. Like SOT23-6 10F???
with plain opamp inputs, adc, dsp, dac. With standard SOT23 opamp
pinout. Think 'mom, I shrunk the PsoC'. Now *how* do you program such a
thing ?

> One is that there needs to be a variety of chips with the right on-board
> peripherals for the job. To be cheap and small, they probably can't have
> the whole selection of peripherals on-board, and so you need to be able to
> get the one that you need.

At the current level of things, I think that the question is, which BGA
package will you use to implement everything you need using a single
chip (decouling caps not included).

> The other is that developing custom firmware is expensive. This could be
> addressed by providing working modules for common applications. Not
> necessarily something they would have to provide, but something they could
> provide the infrastructure for it. If you're talking about replacing simple
> (but maybe more expensive or bigger) hardware solutions, this is an
> important part. Unless you're only looking at products that sell in the
> millions.

I only deal in small numbers. But I think I can see what is coming. I
have been doing this for a while now. Firmware is always a problem and
it is a bug source. I think that chip makers will start offering
relatively complete code libraries soon. There is no other way to sell
complex chips like usb and ethernet.

I 'studied' the enc28j60 and i discovered it can do all sorts of
interesting things that only a high end machine will likely need.
Promiscuous mode ? Autonomous retransmit ? Multiple ip addresses ? Who
needs all this ? And who writes code to cover all the initialisations ?
(and where to store it) ?

Peter

2006\05\21@010845 by Peter Todd

picon face
On Sat, May 20, 2006 at 10:24:07PM +0300, Peter wrote:
>
>
> On Sat, 20 May 2006, Xiaofan Chen wrote:
>
> > But this is the intention of Microchip CEO and people inside Microchip.
> > They want to be successful in the 16-bit market where they will
> > have higher growth. For US company on stock market, growth is the
> > keyword. They say the 8-bit growth is already not fast for them.
>
> But in a limited market growth and long term stability do not go
> together.

Doesn't matter. The US market doesn't care. When Microchip has finished
all the fast, above market average, growth it can, the investors who
choose and influenced the board of directors of Microchip to pursue that
strategy will sell their investment and go somewhere else. (Or make
Microchip into a totally different company, same thing) Those buying the
investment may be suckers who think Microchip can go higher, maybe they
think Microchip is worth more sliced up and sold, maybe they want a low
risk, stable, investment. Who knows.

But long term never enters into it. Not even the stable investment
people, they'll sell the second bonds give a better return.

--
EraseMEpetespamEraseMEpetertodd.ca http://www.petertodd.ca

2006\05\21@104407 by Xiaofan Chen

face picon face
On 5/20/06, Dave Lag <@spam@davescomputer@spam@spamspam_OUTrogers.com> wrote:

> >>Ahh, Linux(or other alternate OSs) to the rescue. Flip one option in the
> >>config of KPDF and you can copy to your hearts content!
> >
> > Thanks for the tip. I am using Gnome so the default application to
> > open pdf file is evince. Indeed KPDF has this option. To uncheck
> > "Obey DRM limitations" and I can then copy and paste from the
> > pdf file.
>
> I don't suppose this is part of the knoppix CD?
> That would be useful.

I do not know about Knoppix. Are you using the Live CD? Live
CD is only good for testing and rescue purpose. It is never
good enough to use Live CD for Linux. But Knoppix can be
installed to harddisk as well.

Regards,
Xiaofan

2006\05\21@144442 by Peter

picon face

On Sun, 21 May 2006, Peter Todd wrote:

> But long term never enters into it. Not even the stable investment
> people, they'll sell the second bonds give a better return.

Long term enters it because it has been a stable source of chips for
*this* list. It would be nice to know if it is about to become another
Atmel slightly ahead of time, yes ?

Peter

2006\05\21@145713 by Peter

picon face


On Sun, 21 May 2006, Xiaofan Chen wrote:

{Quote hidden}

xpdf is on knoppix and you do not have to install it if you have
patience with the slow CDrom running ;-).

Peter

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...