On Oct 5, 1:26 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> 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.
>

16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku
and $0.23@100Ku.

Eeyore wrote:
> Jan Panteltje wrote:
>
>> On a sunny day (Sun, 5 Oct 2008 14:34:07 -0700 (PDT)) it happened
>> MooseFET <k...@rahul.net> wrote in
>> <7...@b38g2000prf.googlegroups.com>:
>>
>>> The strong type checking and the run time error checking means that
>>> an error in a Pascal program is just a little slip.  In C you end
>>> up with the MBR on the disk overwrittten.
>>
>> Hell I can do that from the command line:
>>
>> dd if=/dev/zero of=/dev/hda bs=512 count=1  (1)
>>
>> You mean Pascal is so limited you cannot even do anything with your
>> hd?
>>
>> GRIN
>>
>> (1) Warning: Do NOT run that line.
>
> Reminds me of formatting hard drives using debug. g = c8000 wasn't it
> ?

g=c800:5

linnix wrote:
> On Oct 5, 11:59 am, "RumpelStiltSkin" <fables...@abc.gov> wrote:
> 
>>"linnix" <m...@linnix.info-for.us> wrote in message
>>>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.
> 
> 
> I can't explain it.  But it happens to more than one of them.  They
> just stop working until I reprogram them.  Same board works fine
> indoor.

So this is a plastic packaged device, but exposed top-up to direct 
sunlight. What application operates like that ?
What temperatures do they reach ?

I recall intel threw a lot of R&D funds looking for a type of plastic
that would allow them to erase EPROMS, (save the expensive 
ceramic+window) - don't think they actually cracked it (or maybe flash
just took over anyway)

I do like the asian approach to legacy EPROM: - they use MTP flash,
EPROM pinout, plastic package, and a high Vpp to erase.
Flash flows, but 100% retrofit into a 27C512 design.


>>Please elaborate on the pitfalls of Flash. Everyone is abandoning OTP
>>and masked rom in favor of Flash.
> 
> 
> Costs, Costs and Costs.  Flash costs $1.  OTP costs $0.50 and ROM
> costs $0.25.  We might not go for ROM, but will go for OTP at least.

Which specific devices have that price footprint ? - none I am using
price like that. I HAVE had flash quotes down to 25c.

-jg

linnix wrote:

> On Oct 5, 1:26 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>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.
>>
> 
> 16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku
> and $0.23@100Ku.

That is cheap - that's just $8K order line!.
- was that your own device tho (so is really foundry costs)

On this type of device, ROM can also mean lower Vcc(min) and
lower operating Icc.

The 25c Flash I had, was a 1KF/128EE/32R device, targeting
remote controls (so nearly brain-dead)

-jg

On Oct 5, 5:08 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> linnix wrote:
> > On Oct 5, 1:26 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >>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.
>
> > 16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku
> > and $0.23@100Ku.
>
> That is cheap - that's just $8K order line!.
> - was that your own device tho (so is really foundry costs)

Factory outlet store.  No other markups.

>
> On this type of device, ROM can also mean lower Vcc(min) and
> lower operating Icc.

2.7V and 0.9mA operating.  0.08/0.003/0.0005mA standby.

>
> The 25c Flash I had, was a 1KF/128EE/32R device, targeting
> remote controls (so nearly brain-dead)

16K ROM and 192 SRAM,  40x4 or 40x8 LCD, 8 bits 6502 based.

I've been working on the compiler/simulator using the OTP version,
which is $0.50 each in hundreds.

Wilco Dijkstra wrote:
> "MooseFET" <k...@rahul.net> wrote in message
>> CBFalconer <cbfalco...@yahoo.com> wrote:
>>> larwe wrote:
>>>> Jim Granville <no.s...@designtools.maps.co.nz> wrote:
>>>
>>>>>> that uChip would phase out (read: burn at the stake) all parts
>>>>>> based on its frankly fucked-up legacy 8-ish-bit architectures.
>>>
>>>>> Why ? They ship in large volumes, and obviously do the task
>>>>> adequately. Elegence usually comes at a cost :)
>>>>
>>>> Ten million flies can't be wrong, eh?
>>>
>>> I am amazed at the things programmers carp at and distinguish.
>>> The C language is generally admired, yet it is one of the
>>> weirdest languages in existance. PIC assembly language is also
>>> weird (but works), and is generally poked fun at. Pascal (real,
>>> not Turbo) is almost the soundest language available to all,
>>> yet it is studiously ignored.
>>
>> Pascal's strict type enforcement means that most bugs are caught
>> before the program is even compiled.

First, please take more care with your quoting.  Your message
attributed quotes to the wrong people, by omitting some of the '>'
quote markers.  I think I fixed it.
> 
> That's a myth. Pascal's type checking is not stronger than C as
> long as you don't use explicit type casts.  Pascal is more
> restrictive so it's harder for a novice to create a program that
> compiles.

If you don't use the facilities of the language, you are using the
language incorrectly.  I greatly prefer a correct program to an
incorrect one that actually compiles.

> 
>> The run time type checking prevents big trouble on the few that
>> may slip by.
> 
> Again a myth. Automatic runtime checks don't significantly improve
> software reliability. Most bugs are due to incorrect specification
> or implementation, not due to accessing null pointers etc.

No myth.  Yes, such as failing to use the elaborate typeing
facilities of Pascal.  Note that your null (it's nil in Pascal)
access would be promptly pointed out by the system, and thus cannot
happen if the program has been exercized.

> 
>> This leads to its downfall.  If you think of programming as being
>> like mountain climbing, you will understand why.  The guy who
>> crawls up the side of a mountain gets a lot more respect than some
>> who takes a safe and comfortable helicopter ride there.

And the programmer who produces a working system, on schedule, and
with minimum bugs, is considered much superior to the one who
cannot so do.

> 
> A better comparison would be between a novice climber using safety
> ropes and an experienced climber without. The safety equiment
> doesn't stop the inexperienced climber from falling all the time
> or getting lost. The experienced climber knows to choose a safe
> route without risking a fall and so doesn't need the ropes that
> slow him down.
> 
> Experienced programmers don't need to be restricted by a language
> in order to write safe and reliable software.

Experienced programmers are more likely to know what language
features can trap them, and avoid those.  Should I gather that you
recommend releasing software with the maximum count of undisclosed
bugs present?


-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.

krw wrote:
> a...@TheWorld.com says...
>
... snip ...
> 
>> And there's a long history of succesful projects carried out by
>> crowds of expendable and interchangeable conscripts to prove it ;-)
> 
> Windows is pretty "successful".

Well, now we know your definition of 'successful'.  

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.

In comp.arch.embedded and sci.electronics.design,
On Sun, 5 Oct 2008 14:34:07 -0700 (PDT), MooseFET <k...@rahul.net>
wrote:

>On Oct 5, 8:27 am, "Wilco Dijkstra"
><Wilco.removethisDijks...@ntlworld.com> wrote:
>> "MooseFET" <kensm...@rahul.net> wrote in message
>>
>> news:7...@25g2000prz.googlegroups.com...
>> On Oct 3, 6:20 am, CBFalconer <cbfalco...@yahoo.com> wrote:
>>
>>
>>
>> > larwe wrote:
>> > > Jim Granville <no.s...@designtools.maps.co.nz> wrote:
>>
>> > >>> that uChip would phase out (read: burn at the stake) all parts
>> > >>> based on its frankly fucked-up legacy 8-ish-bit architectures.
>>
>> > >> Why ? They ship in large volumes, and obviously do the task
>> > >> adequately. Elegence usually comes at a cost :)
>>
>> > > Ten million flies can't be wrong, eh?
>>
>> > I am amazed at the things programmers carp at and distinguish. The
>> > C language is generally admired, yet it is one of the weirdest
>> > languages in existance. PIC assembly language is also weird (but
>> > works), and is generally poked fun at. Pascal (real, not Turbo) is
>> > almost the soundest language available to all, yet it is studiously
>> > ignored.
>> > Pascal's strict type enforcement means that most bugs are caught
>> > before the program is even compiled.
>>
>> That's a myth. Pascal's type checking is not stronger than C as long
>> as you don't use explicit type casts. Pascal is more restrictive so it's
>> harder for a novice to create a program that compiles.
>
>No it is not a myth. What is this restrictive that you speak of if it
>isn't the strong type checking?  It is easier to make a program that
>runs in Pascal than C.
>
>
>> > The run time type checking prevents big trouble on the few that may
>> > slip by.
>>
>> Again a myth. Automatic runtime checks don't significantly improve software
>> reliability. Most bugs are due to incorrect specification or implementation,
>> not due to accessing null pointers etc.
>
>Run time check prevent the software from continuing and creating the
>"big trouble" I referred to.  Running off the end of an array in C can
>result in a reformatted hard disk.  

   While that's definitely possible and "tragic," I don't think that's
quite the worst case. What more often happens is the stuff that "runs
off the end of an array" can be malacious executable code, thus making
an otherwise perfectly good program or operating system vulnerable to
trojan horses, viruses and such.

>In Pascal, the program just bombs
>leaving the hard disk as it was.

   I don't see this as an argument for Pascal NEARLY as much as an
argument for doing proper bounds checking (or asserts) in the code
BEFORE using the argument (in C, FORTRAN or other such language where
array bounds aren't normally checked) anywhere you're not ABSOLUTELY
SURE of the size of the input argument.
   This (buffer overflows that can turn program control over to "data"
that came from who-knows-where) appears to be cause of the vast
majority of vulnarbilities in all versions of MS Windows. 

   Actually, this makes a good argument AGAINST Pascal, and especially
letting its runtime code be the one to check bounds. If you rely on
the compiler/language's bounds checking, you lose control - when an
out-of-bounds access is attempted, the program stops with a run-time
error (is there . The user then becomes confused. 
   If you write the code to check before doing the access, you retain
control and can take appropriate steps and possibly display a message
appropriate to your program, and keep going. This is especially
important if the program is meant to be continuously running, as would
MANY of the embedded programs developed by those in these two
newsgroups.

   Many years ago I went from BASIC to Pascal (and not only survived
but quickly learned to like Pascal much better than BASIC - perhaps I
always smelled the inherent evil in "goto"), went from UCSD on the
Apple II to Turbo on the PC with no problem...
   Then I started to learn C. I became frustrated over various points,
for various reasons, partly because of some misleading "how to program
in C" textbook statements, and partly "just because." It was a bit
tough, but I eventually learned that (among other things) Pascal was
doing for me what I should have been be doing for myself, taking
responsibility for things such as proper array bounds checking.

"CBFalconer" <c...@yahoo.com> wrote in message news:4...@yahoo.com...
> Wilco Dijkstra wrote:
>> "MooseFET" <k...@rahul.net> wrote in message
>>> CBFalconer <cbfalco...@yahoo.com> wrote:
>>>> larwe wrote:
>>>>> Jim Granville <no.s...@designtools.maps.co.nz> wrote:
>>>>
>>>>>>> that uChip would phase out (read: burn at the stake) all parts
>>>>>>> based on its frankly fucked-up legacy 8-ish-bit architectures.
>>>>
>>>>>> Why ? They ship in large volumes, and obviously do the task
>>>>>> adequately. Elegence usually comes at a cost :)
>>>>>
>>>>> Ten million flies can't be wrong, eh?
>>>>
>>>> I am amazed at the things programmers carp at and distinguish.
>>>> The C language is generally admired, yet it is one of the
>>>> weirdest languages in existance. PIC assembly language is also
>>>> weird (but works), and is generally poked fun at. Pascal (real,
>>>> not Turbo) is almost the soundest language available to all,
>>>> yet it is studiously ignored.
>>>
>>> Pascal's strict type enforcement means that most bugs are caught
>>> before the program is even compiled.
>
> First, please take more care with your quoting.  Your message
> attributed quotes to the wrong people, by omitting some of the '>'
> quote markers.  I think I fixed it.

I added them by hand as the original post didn't quote correctly.

>> That's a myth. Pascal's type checking is not stronger than C as
>> long as you don't use explicit type casts.  Pascal is more
>> restrictive so it's harder for a novice to create a program that
>> compiles.
>
> If you don't use the facilities of the language, you are using the
> language incorrectly.  I greatly prefer a correct program to an
> incorrect one that actually compiles.

I greatly prefer to be able to write a program the way I want to rather
than being forced to write it the way the language designer thought
I should write it. C/C++ allows one to implement a problem in the most
obvious way.

>>> The run time type checking prevents big trouble on the few that
>>> may slip by.
>>
>> Again a myth. Automatic runtime checks don't significantly improve
>> software reliability. Most bugs are due to incorrect specification
>> or implementation, not due to accessing null pointers etc.
>
> No myth.  Yes, such as failing to use the elaborate typeing
> facilities of Pascal.  Note that your null (it's nil in Pascal)
> access would be promptly pointed out by the system, and thus cannot
> happen if the program has been exercized.

So we agree automatic null-pointer checking adds absolutely nothing.
Automatic runtime checks only give the illusion of safety, but they only point out
the most stupid mistakes. Checking the specification at runtime using explicit
assertions is far more useful. This also allows you to take appropriate action.

>> Experienced programmers don't need to be restricted by a language
>> in order to write safe and reliable software.
>
> Experienced programmers are more likely to know what language
> features can trap them, and avoid those.  Should I gather that you
> recommend releasing software with the maximum count of undisclosed
> bugs present?

Avoiding language features is not a solution, except perhaps when you first
start programming and learn the features one at a time. Despite all the myths,
one can learn how to write safe and reliable software using pointers, including
pointer arithmetic, pointer casts etc. As I said the most common bugs are logic
and specification bugs.

Wilco

"MooseFET" <k...@rahul.net> wrote in message 
news:7...@b38g2000prf.googlegroups.com...
On Oct 5, 8:27 am, "Wilco Dijkstra"
<Wilco.removethisDijks...@ntlworld.com> wrote:
> "MooseFET" <kensm...@rahul.net> wrote in message
>
> news:7...@25g2000prz.googlegroups.com...
> On Oct 3, 6:20 am, CBFalconer <cbfalco...@yahoo.com> wrote:
>
>
>
> > larwe wrote:
> > > Jim Granville <no.s...@designtools.maps.co.nz> wrote:
>
> > >>> that uChip would phase out (read: burn at the stake) all parts
> > >>> based on its frankly fucked-up legacy 8-ish-bit architectures.
>
> > >> Why ? They ship in large volumes, and obviously do the task
> > >> adequately. Elegence usually comes at a cost :)
>
> > > Ten million flies can't be wrong, eh?
>
> > I am amazed at the things programmers carp at and distinguish. The
> > C language is generally admired, yet it is one of the weirdest
> > languages in existance. PIC assembly language is also weird (but
> > works), and is generally poked fun at. Pascal (real, not Turbo) is
> > almost the soundest language available to all, yet it is studiously
> > ignored.
> > Pascal's strict type enforcement means that most bugs are caught
> > before the program is even compiled.
>
> That's a myth. Pascal's type checking is not stronger than C as long
> as you don't use explicit type casts. Pascal is more restrictive so it's
> harder for a novice to create a program that compiles.

Btw There is something wrong with your settings, automatic quoting
doesn't work.

> No it is not a myth. What is this restrictive that you speak of if it
> isn't the strong type checking?  It is easier to make a program that
> runs in Pascal than C.

Where to begin? Everything is more restrictive in Pascal, from the syntax,
semantics to the programming constructs. So it's significantly more work to
write a Pascal program, even for simple problems. And many problems
cannot even be expressed in Pascal. Try writing memcpy in ISO Pascal
for example...

> > The run time type checking prevents big trouble on the few that may
> > slip by.
>
> Again a myth. Automatic runtime checks don't significantly improve software
> reliability. Most bugs are due to incorrect specification or implementation,
> not due to accessing null pointers etc.

> Run time check prevent the software from continuing and creating the
> "big trouble" I referred to.  Running off the end of an array in C can
> result in a reformatted hard disk.  In Pascal, the program just bombs
> leaving the hard disk as it was.

No it can't format the hard disk. It will likely crash the program, allowing
the programmer to fix the problem. An inexperienced programmer will
quickly learn never to make that mistake again. Problem solved.

> > This leads to its
> > downfall. If you think of programming as being like mountain
> > climbing, you will understand why. The guy who crawls up the side of
> > a mountain gets a lot more respect than some who takes a safe and
> > comfortable helicopter ride there.
>
> A better comparison would be between a novice climber using safety ropes
> and an experienced climber without.

> Again you are wrong.  The helicopter is a far better comparison.

No it's not. Automatc runtime checks don't give you an easy ride. They don't
find any bugs in the logic or specification. At best they flag up the most stupid
bugs. But they do nothing to prevent them in the first place or allow one to take
appropriate action (such as a controlled shutdown that doesn't lose your work).
So if you want to compare it with a helicopter ride, it would be one that ended
with a crash.

> The safety equiment doesn't stop the
> inexperienced climber from falling all the time or getting lost.

> The strong type checking and the run time error checking means that an
> error in a Pascal program is just a little slip.  In C you end up with
> the MBR on the disk overwrittten.

That's pretty much impossible. Can you give a link that proves this ever happened?

> The experienced
> climber knows to choose a safe route without risking a fall and so doesn't >need
> the ropes that slow him down.

> Idiots go without ropes.  Experienced climbers use ropes.

Ropes don't stop you from killing yourself. It's all down to you.

Wilco