General Question about the Propeller
ThomasB
Posts: 7
I have some general questions about the Propeller. Despite my lurking and searching, I have some nagging questions that continue to haunt me. In no particular order ...
1. I am curious about the use of SPIN tokens. What was the reason for this, versus a compiled run-time language?
2.·Are there any docs that list the execution times for all the SPIN instructions?
3. For debugging, I am accustomed to a full IDE with breakpoints and watches. Are there any plans to incorporate hardware debugging on future Propeller chips?
4. I understand that tokenized instructions remain in main memory and do not occupy the local COG ram. Does that mean that each COG runs its own token "engine"?·Can the COG run assy programs larger than its local·2K space?
5. I have an existing design based on a PIC18F that is busting at the seems with its 32K code space. The Propeller would easily improve its performance, but I am not sure if it will offer all the program space I need to add more features. Has anyone posted their experience with code space efficiency on a Propeller based design that was ported over from a common micro like a PIC or AVR? It would be motivating to see some practical examples of how the code size went from this BIG to this Big. [noparse]:)[/noparse]
6. I will need to be able to distribute secure software updates to users. Is there a standalone Propeller reflashing program that will accept hex-like files that automates code updates. Is there any way to encrypt the "compiled" code (or embed it in the PC reflashing program) to prevent disassembly and thievery?
7. I'm using Prop Clip. However, can a program be easily reflashed using a common 3-wire RS-232 interface?
Thanks in advance for any advice!
·
1. I am curious about the use of SPIN tokens. What was the reason for this, versus a compiled run-time language?
2.·Are there any docs that list the execution times for all the SPIN instructions?
3. For debugging, I am accustomed to a full IDE with breakpoints and watches. Are there any plans to incorporate hardware debugging on future Propeller chips?
4. I understand that tokenized instructions remain in main memory and do not occupy the local COG ram. Does that mean that each COG runs its own token "engine"?·Can the COG run assy programs larger than its local·2K space?
5. I have an existing design based on a PIC18F that is busting at the seems with its 32K code space. The Propeller would easily improve its performance, but I am not sure if it will offer all the program space I need to add more features. Has anyone posted their experience with code space efficiency on a Propeller based design that was ported over from a common micro like a PIC or AVR? It would be motivating to see some practical examples of how the code size went from this BIG to this Big. [noparse]:)[/noparse]
6. I will need to be able to distribute secure software updates to users. Is there a standalone Propeller reflashing program that will accept hex-like files that automates code updates. Is there any way to encrypt the "compiled" code (or embed it in the PC reflashing program) to prevent disassembly and thievery?
7. I'm using Prop Clip. However, can a program be easily reflashed using a common 3-wire RS-232 interface?
Thanks in advance for any advice!
·
Comments
2. not really. start a clock, execute what you will, stop clock, make a list.
3. maybe, but short hand is busy
4. yes, on engine. yes, with large memory model programming techniques. In other words, assembly can do what you want it to, if you know how.
5. none obviously; but if you stay away from floating point and math in general, things get done quickly in a prop.
6. there is a copy of the loader running about, in two presentations (languages) I think. Encrypt: generally not. My thought: use a dip chip with a smpt eeprom below. Put a big dummy eeprom out in plain view. Fill with bugs. Pot it all with epoxy and poisons.
7. If you satisfy the eeprom's needs and keep the prop otherwise out of the way, yes. My guess the prop wouldn't give a damn about you do with the eeprom once it has booted. Or use the prop to talk to rs232 and eeprom. Then on reset (including a soft one) the eeprom will reload prop with new program.
Now for some real answers, read on:
Post Edited (Fred Hawkins) : 11/19/2007 9:25:27 PM GMT
The answers to most of your questions should be obvious, or obviously "no"
>1. I am curious about the use of SPIN tokens. What was the reason for this, versus a compiled run-time language?
The structure of COG/HUB and memory size. Wait for the emerging C-Compiler, how much faster it will be than SPIN and how much larger its generated code. This is still a "secret", though the ImageCraft people should know it in the meantime... Reference was PBASIC and SPIN (@80MHz) is significantly faster...
>2. Are there any docs that list the execution times for all the SPIN instructions?
No. Around 500 ticks according to my observations..
>3. For debugging, I am accustomed to a full IDE with breakpoints and watches. Are there any plans to incorporate hardware debugging on future Propeller chips?
As I understand: Not by Parallax.
> 4. I understand that tokenized instructions remain in main memory and do not occupy the local COG ram. Does that mean that each COG runs its own token "engine"?
Yes
>Can the COG run assy programs larger than its local 2K space?
No; except is "reloads", which has to be done manually..
> 5. I have an existing design based on a PIC18F that is busting at the seems with its 32K code space. The Propeller would easily improve its performance, but I am not sure if it will offer all the program space I need to add more features. Has anyone posted their experience with code space efficiency on a Propeller based design that was ported over from a common micro like a PIC or AVR? It would be motivating to see some practical examples of how the code size went from this BIG to this Big. [noparse]:)[/noparse]
I know of no comparison. You most likely have to split it into ASM and SPIN. Most likely it will become much shorter due to the compact size of SPIN bytecode, when generated by a compiler before. But there can be adversary effects when using 32-bit data rather than PIC bytes...
> 6. I will need to be able to distribute secure software updates to users. Is there a standalone Propeller reflashing program that will accept hex-like files that automates code updates. Is there any way to encrypt the "compiled" code (or embed it in the PC reflashing program) to prevent disassembly and thievery?
There are many possibilities. For one, you can exchange the complete socketed external EEPROM ($1.50)
But you also have to keep it encrypted inside the EEPROM
> 7. I'm using Prop Clip. However, can a program be easily reflashed using a common 3-wire RS-232 interface?
Yes. Have look at the PArallay schematics (transistors, or MAX 232) - you have to invert the level and differenciate the DTR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
1. I am curious about the use of SPIN tokens. What was the reason for this, versus a compiled run-time language?
Probably better code density. Assembler code takes four bytes per instruction and does only one thing. Spin instructions can be as small as a byte and do more things. The maximum number of Assembler instructions the 32KB memory can hold is 8K.
2. Are there any docs that list the execution times for all the SPIN instructions?
No. If there are, they are locked in a cupboard a Parallax HQ and not in the public domain.
3. For debugging, I am accustomed to a full IDE with breakpoints and watches. Are there any plans to incorporate hardware debugging on future Propeller chips?
No idea on that I'm afraid. It would be handy.
4. I understand that tokenized instructions remain in main memory and do not occupy the local COG ram. Does that mean that each COG runs its own token "engine"?
That's correct. Each Cog runs the "Spin interpreter" or a user-defined Assembler program.
Can the COG run assy programs larger than its local 2K space?
Yes. The Cog would have to overlay in sections of code from Hub and then execute them, or pull instructions in one at a time and execute them that way. Check the forum for "Long Memory Model".
5. I have an existing design based on a PIC18F that is busting at the seems with its 32K code space. The Propeller would easily improve its performance, but I am not sure if it will offer all the program space I need to add more features.
Hard to answer as it depends upon exactly what you need. Spin is quite compact but slow, Assembler is fast but Cogs are limited to 496 instructions before getting into Large Memory model techniques. Some code may take less space to implement on a Cog than a PICmicro, in other cases it may take more.
6. I will need to be able to distribute secure software updates to users. Is there a standalone Propeller reflashing program that will accept hex-like files that automates code updates.
Not from Parallax AFAIK but a number of command line / GUI interfaces have been written by third parties to do that. The download protocol has been revealed by Parallax.
Is there any way to encrypt the "compiled" code (or embed it in the PC reflashing program) to prevent disassembly and thievery?
You can encrypt the .binary/.eeprom files and/or embed them in a standalone downloader / reflasher, but ultimately the code will placed in the external Eeprom where it will be in plain form and thus can be copied and disassembled from there.
You could potentially encrypt the code in Eeprom but you'd need the decryption routines in there as well ( as plain form ) and it could get complex.
7. I'm using Prop Clip. However, can a program be easily reflashed using a common 3-wire RS-232 interface?
Reset needs to be asserted to initiate the download process. It may be possible to do that by Reset button push and use three wires but it would be easier with four; TX, RX, DTR and 0V.
You could build a small three-wire serial to Propeller four wire interface with a PICmicro/AVR and use 'break' to initiate the Reset. using just a serial resistor you could avoid needing a MAX232 meaning just the PICmicro/AVR.
>3: For Assembly programs there is PASD with Source code debugging, Breakpoints and SingleStep (single cog only).
>5: The Propeller has 48kByte RAM ! 32kByte MainMemory and 8*2kByte CogRAM. With clever programming you can reuse a portion of the MainRAM after transfer Assembly programs to the cog, or program a cog to be a little data RAM (~1.5kB).
>6: Look at PropTerminal. It is a little stand alone application that can automatically upload binary and eeprom files at startup. The started (Spin-) application can then ask for a password and encrypt some portions of the EEPROM for example. But the security is not very high, because it is always possible to sniff the I2C transfer between the Propeller and the EEPROM.
>7: The standard boot process needs 4 wire: GND, RX, TX, DTR.
Andy
In regards to·protecting the code, it looks like that will difficult, especially given the ease of reading the external eprom. It's·certainly not going to be as easy as setting a code protect bit during flashing. To those of you that have incorporated the Propeller in your commercial project -- how do you protect your IP?
Edit: I'm still a bit shaky on the video features. I've done a good bit of prototyping with the·composite·video examples found in the library and those shared on Hitt's site. At this point I am ready to increase the number of·text lines (for both PAL & NTSC) and change the scaling so that I get exactly 32 text chars on a full line of text (full screen). For those of us with simple video goals,·is there a well documented source of online information·that gets into·these details?
Post Edited (ThomasB) : 11/20/2007 4:50:34 AM GMT
So in summary, scratch the ID off the chip, then bury your whole design in a thick layer of opaque epoxy.
·
All needed information is hidden in this forum - or course.
My plans for describing it as a tutorial had to be postponed upto the Christmas holidays...
My plans for describing it as a tutorial had to be postponed up to the Christmas holidays...
I was hoping the info was already prepared in a nice tidy tutorial. Until yours is available, I will dig into the hardware and software examples and learn it the old fashion way. [noparse]:)[/noparse]
Thanks to all for the advice and comments.
If you have enough Flash in a micro and don't mind a perhaps prolonged boot-up time, you can download and store encrypted code in the micro and then download that into Propeller Ram at power-up, no Propeller external Eeprom needed.
True, the TX line can be sniffed but that's harder than pulling an Eeprom and deciphering it. You can also vary the bit timing to create an extra pain to decode. Plus downloading a deciphering program which runs in a Cog then reads an encrypted download over the lines. That could be another deciphering program adding an extra layer. There's always going to be a weak point, but you can make it as narrow as possible and a lot of work to unravel.
I am always interested whenever people talk about "protecting IP", as in "To those of you that have incorporated the Propeller in your commercial project -- how do you protect your IP?".
Personally, I think that protecting IP is a waste of time and resources, unless you are Microsoft and can completely dominate a market. I have been in the embedded business for many years and I find that nobody will bother to copy your IP for any small-volume hardware apps, even if you give away the source. I have been involved in several large contracts for custom IP where open source was a contract requirement that helped us get the jobs. Your mileage may vary. And if you are talking about huge volumes, than you had better protect your IP by using custom hardware, not off-the-shelf programmable chips. And in spite of that, just look at how quickly the iPhone was cloned in spite of Apple's lawyers and paranoia! Best wishes.
I'd never buy such a product.
It's like selling a car where you can't open the hood.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
> and can completely dominate a market.
I have to agree, but only if the protection scheme requires extraordinary measures. Frankly, I'm used to just setting a MCU's code protect bit, which is sufficiently effective. I·realize that the common MCU code protection schemes are not the holy grail, but·they present enough of hurdle to provide practical protection at zero cost. I can afford that on the BOM. [noparse]:)[/noparse]
I don't care about protecting the hardware design (doing that is often too destructive and is rarely effective at low cost). Hiding the code is enough·for our needs. FWIW, I have been involved with part number grinding, potting, and other nasty solutions, and it is a horrible thing for the production folks.
Long story short, I just had to ask the IP protection question. With the hopes that someone has done something marvelously simple that I never considered because I can't think outside the·Prop Box.··Frankly, there are a lot of commercial applications that·might like to·use a Propeller, but will never choose·it·due to the lack of code protection. For sure, code protection has always been a requirement every commercialized project I have worked on. This one is no different, so I am looking for a painless silver bullet. Some interesting ideas have been suggested here, but none have made it to the top of my list yet. [noparse]:)[/noparse]
·
If someone is going to go to the trouble of decompiling and disassembling your code, then learning what it does (because there are no labels or names and no comments) and doing the work to make it recompilable, they must want it pretty badly and it would not be that hard to break an MCU protection scheme if it were available.
The "protected"·micro had a command which could set some port bits, so you started by
grabbing a copy of the program and then modifying it from the location of the reset vector - one executable byte at a time.·The first command required to decode was the one to output bits to the output port. The second command required was a NOP.·By modifying the port bits you found the encryption for the next byte in memory, and continued iteratively (skipping the known bytes using NOPs) until you had enough program space available to write a little program to dump the contents of the micro over the output port. In practice·you only actually had to decode·a dozen bytes or so.
Encryption algorithms/systems have probably improved since then, but if someone is dedicated enough . . .
---
These days, a number of serial numbers are generally available on the hardware platform, and one of them could be used to protect the code in some way. Examples are:
1) 1-Wire Dallas temperature and ID chips have a unique ID.
2) SD cards have a unique ID.
3) If you're doing Ethernet, then MAC / IP address could be used for protection.
The biggest catch is that you'll probably have to write your own programming tool to get the encrypted code into the EEPROM in the first place - but that shouldn't be a major·problem if your code protection is that important.
---
The biggest problem is that thieves aren't honest, and they don't play fair. Or as my first employer used to say - Locks on the door only keep the honest people out.
·
In regards to the system timer, I have searched through the docs and cannot find any details about the circumstances of a timer wrap around. In all the propeller timer examples I have come across, I didn't see any user code to handle this exception. Within relative time calculations, does the chip's architecture transparently account for this so that we don't have to worry·about it?
Post Edited (ThomasB) : 11/23/2007 4:43:28 PM GMT
To wait for 10 milliseconds do: waitcnt( clkfreq / 100 + cnt )
To check for a 20 millisecond timeout do:
startTime := cnt repeat if (cnt - startTime) > clkfreq / 50 quit ' ... try to do somethingSee if you can get a definition of what sort of theft you're trying to protect against. If you are trying to protect against someone who might probe the circuit board to read the contents of the EEPROM using internal wiring of the board (rather than stuff brought out to connectors or headers), you won't be able to reasonably do it. If you're primarily concerned about distributed software updates being sent around in unencrypted form, there are a variety of solutions.
There are download programs written both in Python and Spin that mimic the Propeller Tool's download process. Using either as a model, you could write your own in some compiled language that would take an encrypted update file (or embedded and encrypted file), decrypt it on the fly, and download it "in the clear" to the Propeller. The download protocol is not plain 8-bit data. The downloaded program is actually transferred 3 bits per byte and this would be pretty impenetrable to someone not very familiar with the Propeller and willing to put a bit of work into decoding it.
That part I fully understand. In a traditional MCU, when the timer is allowed to wrap around, the code must accommodate the wrap·condition if it is measuring relative time with a free running timer. I haven't seen any such user coding effort with the Propeller. At this point I must assume that Spin and the assy instructions are devised to handle this for me. But, I hate to assume anything.
·
There's no special coding to handle the wrap condition other than what I've shown you in the two examples. Neither Spin nor the assembler do anything special for the system clock register. Since all arithmetic is 32 bit and the add and subtract instructions make no distinction between signed and unsigned arithmetic, there's nothing special to do. In subtracting two time counts from each other, as long as the difference is less than 31 bits (about 2,000,000,000 or roughly 25 seconds at 80MHz), comparisons will work as expected.
Regarding the protection thing ...
The program in the boot EEPROM could have two parts ... a "loader" that includes a "hidden" key distributed throughout the loader in such a way that the thief would have to decompile / disassemble the program and figure it out to find the pieces of the key and the algorithm being used ... and the rest of the program would be encrypted as a block and included in the loader as a hunk of data. The "loader" would include an assembly language decryptor that would run in a cog, decrypt the data, and copy it into position to be executed, then start up the Propeller with the "new" program.
This would at least make it hard for the thief to be successful. Parallax people have pointed out that the MCU protect bits are not very effective for a professional thief with the proper equipment and that the decision to not include IP protection hardware was based on real experience, not lack of interest.
Beyond that, the required·protection disarming skills becomes grand enough that such talent could just be redirected into producing independent code that does the same thing. Basically, the gene pool is limited, so you just need to set the bar high enough to·limit the access·to a level that suits·the value of the code. Adding BOM costs to do that is never attractive, but fortunately the typical cost-free MCU fuse feature is sufficient for many designs. Of course this is just my opinion, warts and all.
I think all my nagging questions have·been beaten to death. I appreciate all the sage advice. So, next on the list is to get·the existing hardware (+ new features) translated into a Propeller based monster. After that, the code writing will begin. May the cog gods have mercy on my soul. [noparse]:)[/noparse]