Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.forth > #23687

Re: OT (slightly) What is the "best" processor for a new project?

Show all headers | View raw

Hugh Aguilar wrote:

> On May 31, 1:01 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> Well, YMMV.  IMHO the 8051 works well if you have a small program which
>> doesn't even scratch all those memory boundaries.  If you really fill
>> 128k of combined code and data with an 8051 program, you very likely
>> should have selected a more powerful CPU.
>>
>> The programs I've written for my b16 are all in the range of 2k,
>> data+code combined.  Some slightly exceed the 2k, so make that 4k. 
>> That's about the right size of a project for an embedded controller
> 
> What is the point of having a custom processor that is used for such
> small projects? Writing a program that size is going to take 1 or 2
> weeks,

Er, the whole point of the project was to have a cheap, mass produced full-
custom *chip* doing that work, and a lot more, and the b16+memory embedded 
on silicon.  If you save 10 cents per unit, and sell 10 million units, 
that's a million dollars, if you save a dollar, that's 10 million dollars; 
if your customer doesn't want to pay a dollar, that means being in the 
business at all.  So if you pay a developer 200k bucks for developing that 
thing (algorithm+b16+stuff+research in battery chemistry which is necessary 
to make the algorithm really *work*), you still made a big profit.  And they 
did pay me that (in Euro, it's a bit less).  And they paid others money, 
too, because Apple wants more than 10 million units.

Apple told us that the cost adder they were willing to pay was 30 cents.  
This immediately ruled out the ARM+C approach, which higher management 
favored before, because even though ARM is well-known, and C is well-known, 
it would have cost a dollar or two per chip (with the outdated 0.25µ 
technology they used for their mostly analog chip - analog designers don't 
like to change technology that often).

> so it really doesn't matter whether it is written in Forth or
> 8051 assembly-language, or C or BASIC --- it is going to be pretty
> trivial in any case.

Sure.  But if you do it in 8051 assembler, you pay the price of using a 
bigger CPU (the 8051 I used when I started to develop the b16 was more than 
10 times bigger on silicon), and you probably also need bigger memory, 
because the 8051 is not doing that well on an algorithm that has to do 
mostly 16 bit computations, including multiplications and divisions.  And 
you pay the price of higher power consumption, which may not be acceptable - 
10 times bigger means 10 times more quiescent current, and for a program 
that is waiting most the time, that is the important metric.  You don't want 
the battery monitor drain your battery.

> We already have the 8051 family for this kind of
> project, and it is well known, so there is no training needed. I read
> your description of the B16, and it doesn't seem to offer any
> advantage over the 8051 family, and definitely not over the Dallas
> 80c320 --- but that is all 20 year old technology --- I suppose there
> is a gee-whiz aspect to it being Forth-based, but nobody pays for gee-
> whiz.

No, but they pay for saving millions in volume.  I know you don't understand 
how business works, which is why you are a taxi-driver.
 
> The MiniForth was far more powerful than your B16.

Sure, but power is not needed.  The reason why the b16 won against the other 
options was die area and power consumption (smaller is better).  That was 
the relevant metric for that project.  This is a program that runs about 
4000 cycles once or twice per second.  You don't need a very powerful CPU 
for this.

> If nobody cared
> about the MiniForth in 1995 when it was more powerful that the
> mainstream 80c320, why should anybody care about the B16 two decades
> later when it is less powerful than the 80c320, which is now obsolete.

Because it is a lot cheaper.  Business doesn't care about power, they care 
about price.  Adding any CPU to such a product which has more power than 
needed is a waste of money, because it's going to be more expensive.  I've 
not designed the b16 to be an uber-powerful CPU, I have designed it to be a 
very small, cost- and power-efficient deep embedded CPU for the typical "toy 
tasks" our customers were having.  I've never been paid for designing the 
b16 itself (which took only a few days, and if I had asked the minimum wages 
you took, it would probably have cost them 200 bucks), but I have been paid 
for developing solutions using it.

The market niche for the b16 is: if it's too complicated for a state 
machine, but still simple enough that the program fits in a few kilobytes of 
memory, *and* the program needs do to some 16 bit calculations, but not much 
bit operations.  Well, if the program would need more bit operations than 16 
bit calculations, I would just slightly modify the instruction set; that's 
what a coworker did for the valve controller.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-15 23:52 -0700
  Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-16 23:25 +0200
  Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-16 18:24 -0400

csiph-web