I don't believe it exists. When I wrote a little Python P1-to-P2 helper program I looked for that in the Spin2 interpreter listing but couldn't find it, so my helper displays "N/A"
When the P1 was developed Chip probably thought he would be churning out Propeller variants in a timely manner. Given he's one person and takes input from the community, new Propeller development became a very slow process. If you need a unique ID, you can read the serial number from the flash of the P2 board.
BTW, thanks for all of the great P2 examples. I don't know what I would do without them. If I just could figure out the magic of smart pins..
It's my pleasure -- and I'm glad code I've written is useful for others. I'm about to embark on a big P1-to-P2 upgrade for a laser tag company I consult for. That's going to be fun. We've long run out of space for new features in the P1. I'm excited to have the speed and programming resources of the P2.
What do you want to pick off first with smart pins? Start a new thread -- I'd bet that one or more of us has working example code that would be helpful for what you want to achieve.
I was speaking with Chip about this because the P2 does identify itself to the IDE. What I was hoping was that there is a dedicated ROM location for the ID. There really isn't. The P2 returns the type in a string, which is based on a constant. Chip told me about a file called rombooter.spin2 which provides the response to the IDE.
What I ended up doing is creating a data dump to read the booter ROM which maps to $FC000 to $FFFFF. I ran the program using Propeller Tool 2.7.0 and found the version string, with the version character at address $FC26B. The result -- which is what I expected -- was "G" for the Rev B and Rev C boards I tested.
Things didn't go as well with my original Rev A Eval board. It identifies correctly:
...but I cannot download a program from Propeller Tool 2.7.0.
I opened the dump program in FlexProp and and made a couple adjustments for clean output. The B & C boards work there, but not the Rev A. The Propeller Tool says that Rev A has 48 smar pins, not 64 -- maybe the smart pin circuitry doesn't work on P62 & P63 which is used for the USB connection. Since most of our drivers use smart pin serial, this could be a problem. I suppose if one really wanted to know, one could write pure bit-bang serial like we had in the P1.
Here's the thing. There was only ever one P1. The P2 took 14 years to get to market -- it's not likely there will be another.
Doi! I can't believe I didn't think of dumping the ROM. Live & learn.
I have my firmware working now. It works well, but I could probably improve it with smart pins. I'll leave that for v2. The P2 is implementing some very esoteric stuff to talk to bespoke DOD hardware, otherwise I would post it.
I am very impressed with the P2. I used a P1 in several rugged applications in 2008, but the P2 is a real beast. It's been a life-saver, since the prototype of my hardware was based on STM32 parts which are pure unobtainium right now.
I will be looking forward to when the P2 documentation is mature.
kurth
Posts: 14
Comments
I don't believe it exists. When I wrote a little Python P1-to-P2 helper program I looked for that in the Spin2 interpreter listing but couldn't find it, so my helper displays "N/A"
p1p2_changes = { "**" : "sca/scas", "^^" : "sqrt", "||" : "abs", "~>" : "sar", "~~" : "signx (!)", "~" : "signx (!)", "?" : "?? (pre)", "|<" : "decod", ">|" : "encod (!)", "<-" : "rol", "->" : "ror", "><" : "rev (!)", "=>" : ">=", "=<" : "<=", "ina[" : "pinread", "outa" : "pinwrite", "dira" : "N/A (set by pin functions)", "ctra" : "Smart pin or code", "frqa" : "Smart pin or code", "phsa" : "Smart pin or code", "ctrb" : "Smart pin or code", "frqb" : "Smart pin or code", "phsb" : "Smart pin or code", "waitcnt" : "waitct", "cnt" : "getct()", "cognew" : "coginit/cogspin", "reboot" : "hubset($1000_0000)", "waitpeq" : "pinread + code", "waitpne" : "pinread + code", "waitvid" : "new code", "chipver" : "N/A", "constant" : "N/A", "string(" : "@ (optional)"Thanks, Jon. I can't believe that got left out.
BTW, thanks for all of the great P2 examples. I don't know what I would do without them. If I just could figure out the magic of smart pins..
When the P1 was developed Chip probably thought he would be churning out Propeller variants in a timely manner. Given he's one person and takes input from the community, new Propeller development became a very slow process. If you need a unique ID, you can read the serial number from the flash of the P2 board.
It's my pleasure -- and I'm glad code I've written is useful for others. I'm about to embark on a big P1-to-P2 upgrade for a laser tag company I consult for. That's going to be fun. We've long run out of space for new features in the P1. I'm excited to have the speed and programming resources of the P2.
What do you want to pick off first with smart pins? Start a new thread -- I'd bet that one or more of us has working example code that would be helpful for what you want to achieve.
I was speaking with Chip about this because the P2 does identify itself to the IDE. What I was hoping was that there is a dedicated ROM location for the ID. There really isn't. The P2 returns the type in a string, which is based on a constant. Chip told me about a file called rombooter.spin2 which provides the response to the IDE.
What I ended up doing is creating a data dump to read the booter ROM which maps to $FC000 to $FFFFF. I ran the program using Propeller Tool 2.7.0 and found the version string, with the version character at address $FC26B. The result -- which is what I expected -- was "G" for the Rev B and Rev C boards I tested.
Things didn't go as well with my original Rev A Eval board. It identifies correctly:
...but I cannot download a program from Propeller Tool 2.7.0.
I opened the dump program in FlexProp and and made a couple adjustments for clean output. The B & C boards work there, but not the Rev A. The Propeller Tool says that Rev A has 48 smar pins, not 64 -- maybe the smart pin circuitry doesn't work on P62 & P63 which is used for the USB connection. Since most of our drivers use smart pin serial, this could be a problem. I suppose if one really wanted to know, one could write pure bit-bang serial like we had in the P1.
Here's the thing. There was only ever one P1. The P2 took 14 years to get to market -- it's not likely there will be another.
Doi! I can't believe I didn't think of dumping the ROM. Live & learn.
I have my firmware working now. It works well, but I could probably improve it with smart pins. I'll leave that for v2. The P2 is implementing some very esoteric stuff to talk to bespoke DOD hardware, otherwise I would post it.
I am very impressed with the P2. I used a P1 in several rugged applications in 2008, but the P2 is a real beast. It's been a life-saver, since the prototype of my hardware was based on STM32 parts which are pure unobtainium right now.
I will be looking forward to when the P2 documentation is mature.
Thanks again Jon!
The P2 fabrication is done here in the US, so you can get them with no problem. Good luck with your project.