PDA

View Full Version : 24LC1025 Cost and Propeller II



Luis Digital
01-21-2009, 09:54 AM
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 (http://www.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMuVhdAcoizlRSetfYkA y0SVKEWa0LNBP4g%3d) with another Flash (http://www.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMtI%252bQ06EiAoG11m ZA9uhtKT0nQcqKSXRFI%3d) 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 http://forums.parallax.com/images/smilies/smile.gif

Thank you.

Kye
01-21-2009, 11:36 AM
The propeller 2 will not support anything other internally than rom and ram. No flash, no eeprom due to the manufacturing process.

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,

Cluso99
01-21-2009, 11:52 AM
I understand there will probably be a few bytes/longs of flash for user serial no. or other code protection methods.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

william chan
01-21-2009, 12:11 PM
Propeller II should be made flexible to allow the use of smaller EEPROMs like the 24LC256 or the bigger 24LC1024, whatever that is required by any application.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Luis Digital
01-21-2009, 12:29 PM
Kye said...
The propeller 2 will not support anything other internally than rom and ram. No flash, no eeprom due to the manufacturing process.

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...


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. http://forums.parallax.com/images/smilies/sad.gif

Mike Green
01-21-2009, 01:59 PM
Cluso99, What was discussed for the Prop II was not flash, but fusible ROM that can be written once-only. As mentioned, the manufacturing process cannot provide flash memory of any kind.

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).

Jo„o Geada
01-21-2009, 11:48 PM
Out of curiosity, why is Parallax sticking to that manufacturing process? Seems awfully limiting
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„o

Leon
01-22-2009, 12:17 AM
Someone asked the same question at an XMOS seminar I attended a few months ago. They use the TSMC 90 nm process and the only way they could put flash on the same chip would be to use an older, slower process.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

potatohead
01-22-2009, 12:47 AM
Wasn't there some IP discussion as well? The current Propeller is 100 percent custom silicon. Every polygon is a Parallax polygon. I think sticking to that inhibits the use of flash memories, if I'm remembering that thread right. That's one of the core value propositions in the Propeller. All custom, all debugged, no licensed stuff, and full control over it lies with Parallax.

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! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Ariba
01-22-2009, 02:18 AM
I hope the Prop II will have an option to boot from an SD card. I do this mostly also with Prop 1, with a Bootloader in EEPROM which loads a specific file from the SD card (if one inserted).
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

Sleazy - G
01-22-2009, 05:11 AM
potatohead said...

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?


∑∑∑ There are reverse engineering houses all over China that just "de-cap" chips, microscopically analyze the silicon, then make their own copy.∑ Bootleggers, pirates if you will, of silicon design.

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..

Jo„o Geada
01-22-2009, 07:13 AM
One way I've heard of is to encapsulate the chip in a stressed ceramic substrate containing random oriented metal strands. Effectively opaque to
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„o

Paul Baker
01-22-2009, 09:14 AM
Chip has looked into the SPI flash memories that are commonly availible in high densities for a fraction of the cost of I2C eeprom (plus it's faster). But the last time I talked with him about it (half a year ago) he hadn't decided whether to use it.

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 (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/22/2009 1:37:11 AM GMT

Luis Digital
01-22-2009, 09:40 AM
Nobody of Parallax has spoken, seems that already is very late. Perhaps in another version Propeller II or Propeller III.

Paul, is happy me to see it around here always, always I remember the photo of the full box of Propellers protoboard. http://forums.parallax.com/images/smilies/smile.gif

Paul Baker
01-22-2009, 09:44 AM
Luis Digital said...

Paul,∑ I remember the photo of the full box of Propellers protoboard. http://forums.parallax.com/images/smilies/smile.gif
Yeah that was a happy time, the first product I worked on that became commerically availible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

Cluso99
01-22-2009, 10:12 AM
I must say, being able to boot from SPI Flash or an SD card makes a lot of sense.

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 http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)

My cruising website is ∑www.bluemagic.biz (http://www.bluemagic.biz)

awesomeduck
01-22-2009, 10:14 AM
I'm really surprised to see flash/EPROM viewed as the problem. Does anyone else think that 32KB of RAM is the bottleneck in designing? I fin the Propeller to be highly innovative, very cool, slick and fun. But RAM seems to be the bottleneck for any video oriented projects. Looking at the instruction set architecture though, it would be a huge re-design to use an address bigger than 16 bits.

Paul Baker
01-22-2009, 10:16 AM
The next chip's SRAM will indeed be larger (this conversation is about the chip currently in the works), it will be at least 4x larger.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

Cluso99
01-22-2009, 01:27 PM
@awesomeduck: The cog will remain at 512 longs (9 bits) - this is "chipped" (pardon the pun) in stone. The hub is a different story as the addresses are actually 32 bits and chip has indicated the hub ram will likely be 256KB (18 bits).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)

My cruising website is ∑www.bluemagic.biz (http://www.bluemagic.biz)

mctrivia
01-22-2009, 02:36 PM
just imagine we could squeeze 4GB of ram in to the hub to take advantage of the entire 32bit addressing.

Andrew E Mileski
01-23-2009, 06:40 AM
It is fairly trivial to add a parallel bus to a Propeller given all the I/O lines.

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.