Wilco Dijkstra wrote:
>>On Sun, 05 Oct 2008 10:40:45 -0500, Vladimir Vassilevsky
>><a...@hotmail.com> wrote:
>>>Wilco Dijkstra wrote:
>>>
>>>>Experienced programmers don't need to be restricted by a language in order
>>>>to write safe and reliable software.
>>>
>>>Yes, of course. But the real problem is where to get many experienced
>>>programmers for cheap.
> 
> 
> Indeed. But would you rather use several inexperienced programmers rather than
> a few more experienced ones? In the long term the experienced ones are likely less
> expensive.

This is a classic question of few knights vs many conscripts. It turns 
out that big practical tasks are better handled by the crowds of 
expendable and interchangeable conscripts. There are the tasks for 
professionals, too; however the main stream (where the money goes) is 
handled by the hordes. So the goal of a modern programming language is 
making the programming a blue collar job; the less is the possibility to 
screw the things up, the better.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>>>>Yes, of course. But the real problem is where to get many experienced
>>>>programmers for cheap.

>This is a classic question of few knights vs many conscripts. It turns 
>out that big practical tasks are better handled by the crowds of 
>expendable and interchangeable conscripts.

And there's a long history of succesful projects carried out by crowds of
expendable and interchangeable conscripts to prove it ;-)

 
-- 
	mac the naïf

"Anthony Fremont" <n...@noplace.net> wrote:

>Uniden wrote:
>> In article <0b4a9ce0-c18f-44ab-b418-3c9f169519c1
>> @m45g2000hsb.googlegroups.com>, z...@gmail.com says...
>>>  A rabid
>>> wombat in a bell jar full of crack smoke could not have designed a
>>> less-pleasant ISA than PIC.
>>
>> Funniest thing I've read in a long time. And laser accurate. :-P
>
>I really don't get all the PIC hatred.  I've played around with quite a few 
>different micros starting with the 1802.  Every micro that I've used has its 
>own set of crappy handicaps; PICs by no means have the market cornered on 
>this.  By far the best design I've ever worked with is the ARM. 

The problem with PIC is that people who know PIC don't (want to) know
anything else. If you only have a hammer, then everything looks like a
nail. If someone suggests to use more than 1 PIC in a design instead
of a real microcontroller get rid of him/her. That's the first sign of
trouble!

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

On Oct 3, 3:30 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
> "Jim Granville" <no.s...@designtools.maps.co.nz> skrev i
meddelandetnews:48e68e7c$1...@clear.net.nz...
>
> > linnix wrote:
> >> On Oct 3, 2:15 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >>>Most designers choose the cheapest device that will get the job done.
> >>>A toothpaste timer does not really need
> >>>memory-agnostc function pointer support  ;)
>
> >> And we don't need flash uC for productions.  Most other uCs offer ROM/
> >> OTP version. ROM/OTP AVRs should be much cheaper to make.
>
> As technology move forward, you will see that ROM is no good.
>
> With 6 inch wafers and 10 mm2 which might be more standard today
> you have ~1500 dies/wafer and  36000 per lot.
>
> Assume 8 inch wafer and 5 mm2 die in the future.
> Each wafer is 32428 mm2 so you would get ~6000dies per wafer.
> One lot of 24 wafers will give you 24 * 6000 dies = 144000 dies.
>
> So that would be your minimum order...

The 16K ROM uC we are considering is 25,000 minimum order.  The cost
is low enough that even if we throw away half of them, it is still
cheaper than OTP and much cheaper than flash.

"linnix" <m...@linnix.info-for.us> wrote in message 
news:3...@r15g2000prh.googlegroups.com...
> Didn't see my earlier post.  Perhaps memory erased.
>
> On Oct 3, 3:29 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>> linnix wrote:
>> > On Oct 3, 2:15 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>> >>Most designers choose the cheapest device that will get the job done.
>> >>A toothpaste timer does not really need
>> >>memory-agnostc function pointer support  ;)
>>
>> > And we don't need flash uC for productions.  Most other uCs offer ROM/
>> > OTP version. ROM/OTP AVRs should be much cheaper to make.
>
> Flash is too expensive, period.  Furthermore, try running a flash uC
> under direct sun-light.   They sometimes lose their memories.

Please explain. Makes no sense. Flash has no "erase" window.

>> This is an interesting area.
>> Many say flash is the only path, but others offer Flash and 'ROM/OTP'.
>
> We need migration path for: low quantity Flash, mid quantity OTP and
> large quantity ROM.  They should be C source and register level
> compatible, for minimum porting issues.
>
>> Atmel had some OTP AVR's but they phased them out.
>
> That's why our customers are phasing out Atmel for productions.  I
> love AVR. I spent lots of time prototyping with AVR.  I am strongly
> against using Flash AVR in our productions.

Please elaborate on the pitfalls of Flash. Everyone is abandoning OTP
and masked rom in favor of Flash.

"Anthony Fremont" <n...@noplace.net> wrote in message 
news:f...@supernews.com...
> Uniden wrote:
>> In article <0b4a9ce0-c18f-44ab-b418-3c9f169519c1
>> @m45g2000hsb.googlegroups.com>, z...@gmail.com says...
>>>  A rabid
>>> wombat in a bell jar full of crack smoke could not have designed a
>>> less-pleasant ISA than PIC.
>>
>> Funniest thing I've read in a long time. And laser accurate. :-P
>
> I really don't get all the PIC hatred.  I've played around with quite a 
> few different micros starting with the 1802.  Every micro that I've used 
> has its own set of crappy handicaps; PICs by no means have the market 
> cornered on this.  By far the best design I've ever worked with is the 
> ARM.

I hate PICs, but one thing you got to admit is that they have
much better support than any other micro. That is why they are successful.

On Oct 3, 6:29=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:

> Many say flash is the only path, but others offer Flash and 'ROM/OTP'.

At some point, it doesn't make any sense to optimize any more.

For example, I had a design containing a very expensive,
"ROM" (actually vendor-programmed OTP EPROM, I believe) micro, and I
had to cost it down. Let's say the old micro costs $3. I look at all
the preferred vendors and I get the following absolute best prices.
Either of these parts will fit the bill as far as the other
peripherals go:

- For an 8K ROM part with 512b RAM and no EEPROM, $0.84 + $7500 NRE.
Leadtime on first piece sample 8 weeks, leadtime on a code change once
production ramps up is 24 weeks. I can't qualify the RF performance of
my app on real silicon. If I need to change something (e.g. I find a
weird harmonic and need to change the base clock frequency, thereby
requiring code changes), I need to wait another 8 weeks to know if it
works.

- For a 16K FLASH part with 2K RAM and 1K EEPROM, $0.85 + no NRE.
Leadtime on first piece samples is 24 hours. Leadtime on 100Ku
production quantity is 6 weeks. Leadtime on code changes is 0 because
we can IAP new code. Plus I can develop and qualify with the
production part; I can shift those frequency spurs around however I
need to avoid the carrier and IF danger zones in my circuit.

Why would I buy into all this risk and problem quicksand for a penny a
unit, even at 250K units/year? And in this specific example, the ROM
part has gone up to $0.90 while the flash part has fallen to $0.83.

On Oct 3, 7:16=A0am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:

> Small PICs, like the 8 bit, are ment to be programmed is asm.
> Sure, many grab, for reasons unknown to me, but

If you're talking one of the truly miniscule devices like the 8-pin 1K
parts used for PlayStation modchips and so forth - yes, an asm
program, get in quickly, get out quickly.

But the braindead PIC architectural features are alive and well in
devices up to 64K or even more. For my money, code volumes in excess
of a few kilobytes are much easier to maintain, outsource and
technology-transfer if they're in an HLL.

Once you get up to dsPIC, then yes you have a reasonable architecture.
But dsPIC is not PIC.

ANY architecture with banked memory is simply not meant to be
programmed in any language. There is absolutely no reason for it in
this day and age.

larwe wrote:
> On Oct 3, 6:29 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
> 
>>Many say flash is the only path, but others offer Flash and 'ROM/OTP'.
> 
> 
> At some point, it doesn't make any sense to optimize any more.
> 
> For example, I had a design containing a very expensive,
> "ROM" (actually vendor-programmed OTP EPROM, I believe) micro, and I
> had to cost it down. Let's say the old micro costs $3. I look at all
> the preferred vendors and I get the following absolute best prices.
> Either of these parts will fit the bill as far as the other
> peripherals go:
> 
> - For an 8K ROM part with 512b RAM and no EEPROM, $0.84 + $7500 NRE.
> Leadtime on first piece sample 8 weeks, leadtime on a code change once
> production ramps up is 24 weeks. I can't qualify the RF performance of
> my app on real silicon. If I need to change something (e.g. I find a
> weird harmonic and need to change the base clock frequency, thereby
> requiring code changes), I need to wait another 8 weeks to know if it
> works.
> 
> - For a 16K FLASH part with 2K RAM and 1K EEPROM, $0.85 + no NRE.
> Leadtime on first piece samples is 24 hours. Leadtime on 100Ku
> production quantity is 6 weeks. Leadtime on code changes is 0 because
> we can IAP new code. Plus I can develop and qualify with the
> production part; I can shift those frequency spurs around however I
> need to avoid the carrier and IF danger zones in my circuit.
> 
> Why would I buy into all this risk and problem quicksand for a penny a
> unit, even at 250K units/year? And in this specific example, the ROM
> part has gone up to $0.90 while the flash part has fallen to $0.83.

Yes, clearly in your example Flash is the correct choice.
linnix must be working in a different number space, which is why I asked
for some examples.

Some companies are still releasing what they call ROM parts, along with
flash.

An example, from Korea : Wide family of nice 80C51's with first 
OTP/'ROM', and now Flash/'ROM'
http://www.coreriver.co.kr/product-lines/top_corerivermcu.html

I suspect they are not classic ROM (ie not actually two metal custom 
mask) for the reasons you mention above, but they may be 'Flow optimised 
flash', with an Erase-kill fuse.

That approach does make sense.

-jg

Jim Granville wrote:

> This is an interesting area.
> Many say flash is the only path, but others offer Flash and 'ROM/OTP'.

I think one reason is that ROM is more reliable. Lifetime of Flash is much
smaller, if working at high temperature. And for high radiation
environments and where you can't replace chips, like in space, the lifetime
is important. A nice alternative solution is MRAM, if the price is not so
important:

http://www.nsti.org/press/PRshow.html?id=2964

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de