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=.)
meddelandetnews:48e68e7c$ snipped-for-privacy@clear.net.nz...
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.
Please explain. Makes no sense. Flash has no "erase" window.
Please elaborate on the pitfalls of Flash. Everyone is abandoning OTP and masked rom in favor of Flash.
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.
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.
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.
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'
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
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:
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Atmel has a well known history of "Announce early, deliver late"...
-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
ADA is 3 of everyones favorite languages.
On a sunny day (Sun, 5 Oct 2008 14:34:07 -0700 (PDT)) it happened MooseFET wrote in :
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.
On a sunny day (Sun, 5 Oct 2008 14:37:50 -0700 (PDT)) it happened MooseFET wrote in :
I have a 20 year old boook about ADA, wanna buy it?
20 years onward I still have no use for it.
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.
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.
Once anyways
16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku and $0.23@100Ku.
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.
Which specific devices have that price footprint ? - none I am using price like that. I HAVE had flash quotes down to 25c.
-jg
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
Factory outlet store. No other markups.
2.7V and 0.9mA operating. 0.08/0.003/0.0005mA standby.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.
[....]
I agree. The trashing of your hard disk is the default behavior of a C program with a bug in it. People can write C programs that do far worse things.
Yes, this is a very big problem. Doubly so on OSes where large sections of the code run with all permissions. Modern CPUs can make things a little safer by protecting sections of the system from the buggy C code.
Pascals checking, assuming a correct compiler, does the check correctly. When the programmer has to code it, you are allowing the same mistake to be made in two places near each other to cause troubles. Having the range checking built into the language means that someone else has done the check on a different day.
Yes, this shows the danger of allowing any important program to be written in C.
The checking does not prevent you from checking your inputs. It protects the machine against trouble on the things that the programmer missed.
It is better that the user become confused than having their machine taken over or vital data going missing.
Again there is nothing preventing a programmer from checking things in Pascal.
BTW: I code imbedded stuff in ASM.
I program in C a fair amount too. I also have to root out the drains here at home sometimes too.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.