From: Peter Stuge <peter@stuge.se>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] OT: HiTech-C question
Date: Mon, 15 Nov 2010 19:53:07 +0100 [thread overview]
Message-ID: <20101115185307.4013.qmail@stuge.se> (raw)
In-Reply-To: <4CE17835.7080301@tampabay.rr.com>
wireless wrote:
> > It's not a realistic spec for any microcontroller. Please try again,
> > with more care. You can get most of what you want in a single package
> > but not all of it. Unless of course you make your own.. Take an Actel
> > M1A3P250 with an ARM Cortex-M1 hardcore, then you could easily fit
> > all those peripherals in one package.
>
> Oh sure it is, but not in the 32 bit world.
You can get one, but will end up with a much larger chip, in order to
find one which has all the things you needed, and it'll also have a
ton of other stuff that you don't need.
To a degree I think this goes for all processor makers, but granted,
Microchip really have very many parts with only small peripheral
differences. :)
> > M1A3P250 starts at $11.99 at Future Electronics. (MOQ=180, was 90 before)
> > But maybe you'll be able to put something else on the board into the
> > FPGA to balance that extra cost.
>
> yes, 32 bit and dsp processors have come way down on price.
The M1A3P250 is not a processor, it's a processor and FPGA combined.
> But, when you look at building a complete embedded system,
> those high end processors eat you alive on external
> component count and manufacturing costs.
The point that this thread tries to make is that all 32-bit
processors are not "high end" as you might be used to.
In particular the Cortex-M products are quite fuss free. A handful of
caps is really all you need. That goes for the M1-enabled FPGA too.
> That board I just spec'd cost less that $30 to manufacture, with a
> PIC and every thing else that I did not require, like molex
> connectors and such.
I think the cost would not be significantly higher if using something
more powerful than a PIC, and the other point this thread tries to
make is that the development work would be significantly easier,
netting a total reduced cost.
> > As you see, part cost is no problem for ARM, but you'll need more
> > than one component for your project however you do it.
>
> PRECISELY!; a 32 bit part can never compete with a micro if
> specs are tight and cost/power requirements are astringent,
> which most are. Certainly anything that is manufacutured in
> lots of 10 or more, every penny counts and cost reduction
> rules the decision process, never what some employee or
> consult "likes". They (32+) only compete when you actually
> need all those mips and mops, which is rare for the vast
> majority of uP based products.
I think you would benefit from re-evaluating this position, quickly.
And of course it is simply folly to save on production cost in a
small (1k, 10k) run if there is a noticeable tradeoff to be made with
software/firmware development effort.
For lots of 10, 100, 1000 and even 10000, pennies in production are
irrelevant, they translate to just a few hours worth of development
time.
I haven't looked closely at the power numbers for M0, so for power,
physical size and mass production I agree that it remains very
important to choose parts very carefully.
But ARM cores have quite significant benefits in development, and
especially with Cortex-M0 they are eating up big parts of what used
to be an 8- or 16-bit only market.
> Don't believe me, just do a little research into the numbers,
This is my point too.
> Fairchild and such won't even talk to you about
> anything less than 1M in qty per quarter.
That's certainly not my experience from (in particular) Fairchild.
> For large companies, those (8/16)uP are sub $1, for qty 10k or
> more....... Some companies sell uP for pennies, just
> to get the supply contract for the passives and such
> on really large deals.
Of course it may be significant to save $1 (vs. the $1.46 ARM in
100qty, assuming you can get down to $0.46 for something else) for a
10k run, but certainly not for a 100qty run. It buys just one hour of
development time.
> 8/16 STILL rules the world and dominates the economics of embedded.
The state today is mostly uninteresting IMO, I find what happens
tomorrow all the more interesting. ARM is quickly taking a big part
of the market.
> Granted 32 bit cores that run linux are very cool and preferred by
> most embedded folks, but, that's a very small number of design wins
> with big quantity (cell phones for example), compared to their
> mature brethren (8/16).
That's comparing apples and oranges. I think you should really take
a look at the smallest ARM cores.
> and yes, I like ARM very much, particularly in areas of
> low power design, relative to intel or amd.
While more on-topic for gentoo-embedded that is only the Cortex-A
parts, which is on the opposite end of ARM's line card. Look into
the Cortex-Ms.
//Peter
next prev parent reply other threads:[~2010-11-15 19:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 2:10 [gentoo-embedded] OT: HiTech-C question David Relson
2010-11-15 3:37 ` Peter Stuge
2010-11-15 7:44 ` Mike Frysinger
2010-11-15 11:22 ` wireless
2010-11-15 12:25 ` Arkadi Shishlov
2010-11-15 14:45 ` wireless
2010-11-15 16:05 ` Peter Stuge
2010-11-15 18:13 ` wireless
2010-11-15 18:53 ` Peter Stuge [this message]
2010-11-15 19:28 ` Arkadi Shishlov
2010-11-15 14:53 ` Peter Stuge
2010-11-15 12:37 ` David Relson
2010-11-15 14:25 ` wireless
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101115185307.4013.qmail@stuge.se \
--to=peter@stuge.se \
--cc=gentoo-embedded@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox