24LC1025 Cost and Propeller II
Luis Digital
Posts: 371
Hello all,
It is not official, but the new propeller will use a memory of 128 KB, and I see that the cost is over some microcontrollers ($4.59).
Comparing a memory EEPROM with another Flash the cost is a lot smaller and with more capacity.
We are to time to take a change in the design or is too late?
Or important reasons exist to continue using traditional EEPROM?
Maybe in Propeller III
Thank you.
It is not official, but the new propeller will use a memory of 128 KB, and I see that the cost is over some microcontrollers ($4.59).
Comparing a memory EEPROM with another Flash the cost is a lot smaller and with more capacity.
We are to time to take a change in the design or is too late?
Or important reasons exist to continue using traditional EEPROM?
Maybe in Propeller III
Thank you.
Comments
Additionally, comparing the propellers cost to other microcontrollers makes no sense unless you mulitply it by 8 as the propeller is really 8 in 1. Memory may be a different matter but the benefit of multiple processors outweights vast memory storage. As seens by not neededing complex interrupt rountines to save state, etc, etc.
As for external memory... you can change that yourself in your design. However, the boot loader may be a problem...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Kye,
I am not comparing the Propeller with other microcontroller. It was speaking on the external memory for the program that will cost more than a microcontroller.
Luis Digital, There has not been any discussion yet of how the Prop II will handle the initial download from EEPROM. I don't know for sure, but I suspect one of two things will happen. 1) The bootloader will still work with 32K no matter how much memory is provided. 2) The bootloader will load a Spin program using a length stored in the program (as exists currently, but isn't used by the bootloader).
and puts the Propeller at a disadvantage both in features and BOM cost compared to other microcontrollers.
There is currently (and it has been this way for a number of months) a worldwide glut of fab
capacity across all manufacturing nodes and processes. Most fabs are currently running at
under 50% capacity and all are desperate for more volume. So it ought to be possible to find
a process compatible with Flash/EEPROM and meeting the other technical requirements both at
reasonable price and the lowish volume that Parallax will need.
And it is not as if the Propeller II pushes the boundaries at any of the likely nodes
(on my day job I deal with million+ gates chips running at GHz clock speeds at 45nm and smaller nodes)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Also, with regard to feature / BOM cost disadvantage, I think that's questionable. It's likely a Propeller will provide functions in software that normally would be addressed with other dedicated function glue type chips. If that's true, for a given project, then the cost perception must be weighed in that light, or it's just not a valid comparison. Also, being able to do this is a feature, and likely one worth the trade-off for on chip FLASH / EEPROM.
If there is some provision for an encryption key to be stored on chip, then the external program source can be reasonably protected. There are no absolutes on that, so it comes down to risk / reward and or sheer cost.
Basic security is evaluated in terms of risk / reward. An example being your home. If you have a dog, lights, and a low key perception of the value contained in your home, risk runs fairly high compared to the perception of the reward, thus the home is deemed "secure". Such a home would be "more" secure than the one that is poorly lit, nobody home, high value perception, etc...
Now, if people know you've got a million in cash sitting in the living room, the reward is very high, thus the home is deemed "not secure". You could have all those things, plus locks, security guard, etc... and still be somewhat insecure! It's all about how that ratio boils down. It's either favorable or it's not. And security is either there or not, with the judgment being both in the eyes of the person wanting to protect something, and those willing and able to violate said protection.
Cost is a secondary factor, where the reward is known and risks are very low. IP works this way more often than not, because there are always places in the world friendly to those kinds of things. (and that's good, frankly -->think about that a little)
In that case, cost then in the form of decryption is an effective deterrent. There are only deterrents, no absolutes. How much of a target the IP is and what kind of cost will be required to capture the IP in a re-purposable form, are the primary factors surrounding a "secure" judgment.
If the Propeller can contain some key, then there are a lot of software options that can be costly to deal with, and that then would be "secure"
I'm hoping such an encryption scheme will still permit plain old Propeller code to run, just so that Propellers already encoded can still be re-purposed down the line for hobby reasons. Nobody likes throw away tech. It's a waste really.
On chip isn't proving to be the security it's cracked up to be either. For a few hundred dollars, one can get a chip "de-capped" and photos of the silicon inside! This is being done on a hobby (?!?) basis to capture and preserve arcade games right now. Those guys are just looking at the silicon and decoding things that way. Interesting no?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Prop II can have such a function in ROM and then no additional EEPROM is needed.
An alternative would be to use an Atmel Dataflash with SPI interface. This devices have some Megabits capacity and cost only 1..2 $.
Andy
If you can remember, HIPPY had cracked Chip's encryption scheme, on a·challenge. He was able to post source code.
I think the real way to protect chips is to put a thin layer of some sort of radioactive isotope just above the die, so when its "de-capped", everything in the lab gets irradiated.· Or you could just use LSD...Even better.· That'll show em..
x-rays and if you attempt to "take the top off" it fractures into lots of tiny little pieces (just like tempered glass)
But it is an expensive way to do things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
If Parallax implements an encryption algorithm on the chip itself (which is only availible to the system upon start up before control is passed to user code), it would be very difficult to make any copies.
But if all thats provided is the fuses, the next chip will sadly be no more secure because the fuse value would be accessible run time and it would be possible to decrypt the encrypted information (key +·decryption alorithm + encrypted data = unencrypted data) this would be like leaving an outline of your deadbolt key engraved on·your front door, but it would be about as secure as on board EEPROM·microcontrollers·(ie not secure at all). So you might be able to convince the big wigs to use it in a commerical product by stating the program is encrypted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/22/2009 1:37:11 AM GMT
Paul, is happy me to see it around here always, always I remember the photo of the full box of Propellers protoboard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
A SPI and SD interface would be a great addition to the ROM and could be used like the boot rom does now, look for the various parts on the same pins. Alternately, sacrifice 2 pins (not i/o pins, because the package will hance more pins anyway) to select the option in rom. this can be hardwires by the pcb or soft by links.
I am sure Chip will make the right decision anyway
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
My cruising website is ·www.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
My cruising website is ·www.bluemagic.biz
Add a couple of latches, and a multiplexed bus can be made. Slower, but less I/O costly.
One can even do it serially if I/O lines are scarce, at the cost of speed of course.
To boot from SD: get the smallest PIC with an I2C and SPI interface, and program the PIC to act as a I2C slave at the EEPROM address. The PIC can handle the SD master stuff. Use a real SD controller, and get max performance (up to 12.5 MBytes/sec). Easier to update a PIC or controller when the SD spec changes than re-do silicon.