Shop OBEX P1 Docs P2 Docs Learn Events
Unique ID — Parallax Forums

Unique ID

HumanoidoHumanoido Posts: 5,770
edited 2010-01-03 06:57 in Propeller 1
Using SPIN, it is possible to to CHIPVER to get the Propeller's version number.

V := chipver


However, is there a unique ID from chip to chip, and a method for recall?
(like a serial number)
«1

Comments

  • James LongJames Long Posts: 1,181
    edited 2009-12-29 03:58
    Hey,

    That is a useful question........I too would like to know this.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-29 04:15
    To my knowledge, there's nothing in the chip that's designed for that purpose. But you might be able to take advantage of process variations (e.g. the internal RC oscillator frequency) to concoct something. But, even then, neither uniqueness nor repeatability would be guaranteed. A more reliable approach at the system level would be to program a serial number into the EEPROM or to include a one-wire silicon serial number from Maxim.

    -Phil
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-29 04:16
    No, the Prop uses a mask rom which means it's exactly the same for every prop and you can't change it plus a unique ID would complicate the process and add real costs to the price of the chip. Very very few chips have unique IDs embedded in them at the factory.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • James LongJames Long Posts: 1,181
    edited 2009-12-29 04:28
    Well it was a great idea......

    I can't have everything in a Propeller that I want, but it definitely has enough..

    I guess I'll serialize the EEprom.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-29 06:53
    There is no eeprom connected to this circuit and I don't want to add any more components. However, I like the idea of programming a serial number into the prop chip. Is there a way to burn in the number, and keep the number stored inside when the power is removed?

    Now I wish the Prop chip had a tiny flash memory inside somewhere... Just think of the possibilities!

    Post Edited (humanoido) : 12/29/2009 7:01:45 AM GMT
  • James LongJames Long Posts: 1,181
    edited 2009-12-29 06:58
    humanoido said...
    There is no eeprom connected to this circuit and I don't want to add any more components. However, I like the idea of programming a serial number into the prop chip. Is there a way to burn in the number, and keep the number stored inside when the power is removed?

    Nope,

    The propeller memory (volatile) is emptied when powered off. You would need to have the ID stored in the propeller eeprom itself. The problem with that, is the normal security issue. It could be read with a savvy person with a I2C logging system.

    If your not using an eeprom, how is the propeller loaded for operation?

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-29 07:05
    James Long said...
    The propeller memory (volatile) is emptied when powered off. You would need to have the ID stored in the propeller eeprom itself. The problem with that, is the normal security issue. It could be read with a savvy person with a I2C logging system.
    The circuit has no eeprom external to the prop chip. Security is not an issue. It's ok if anyone reads the unique ID. The goal is to establish a unique ID, with repeatability, without adding any external parts.
  • James LongJames Long Posts: 1,181
    edited 2009-12-29 07:38
    humanoido said...
    James Long said...
    The propeller memory (volatile) is emptied when powered off. You would need to have the ID stored in the propeller eeprom itself. The problem with that, is the normal security issue. It could be read with a savvy person with a I2C logging system.
    The circuit has no eeprom external to the prop chip. Security is not an issue. It's ok if anyone reads the unique ID. The goal is to establish a unique ID, with repeatability, without adding any external parts.

    I see....this prop must be being feed it's program from another prop (you being the super computer type of guy).

    I'm not sure how you could do that, unless you use some of the I/O to give it an ID like an eeprom would (or something else on an I2C bus).

    Would that work? Like using P0-P3 to address the propellers? Then the program could let each chip decide where it is in the matrix.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!

    Post Edited (James Long) : 12/29/2009 7:44:23 AM GMT
  • RaymanRayman Posts: 14,876
    edited 2009-12-29 13:50
    The FTDI chip has a unique number, if you want USB too...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • LeonLeon Posts: 7,620
    edited 2009-12-29 13:57
    Dallas Semi/Maxim have a 1-Wire ID chip.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-29 16:11
    James Long said...
    If your not using an eeprom, how is the propeller loaded for operation?
    It loads the program directly from the prop tool into RAM using the RAM option on the software tool.

    Ok, so far we have some basic ideas.

    * load a unique ID into EEPROM
    * Use prop pins to read an external device
    * Wire an external serial ID chip to the circuit
    * Read a unique USB circuit for each chip

    * Another idea, a self incrementing serializing code that changes each time it loads into a chip on the array. The loading sequence maintains the chip position in the array while the increment determines the serial number ID.

    So... we think there is absolutely nothing inside the propeller chip that can be prodded to become unique and serve as a serializing derived number with repeatability...
  • James LongJames Long Posts: 1,181
    edited 2009-12-29 17:35
    humanoido said...
    James Long said...
    If your not using an eeprom, how is the propeller loaded for operation?
    It loads the program directly from the prop tool into RAM using the RAM option on the software tool.

    Ok, so far we have some basic ideas.

    * load a unique ID into EEPROM
    * Use prop pins to read an external device
    * Wire an external serial ID chip to the circuit
    * Read a unique USB circuit for each chip

    * Another idea, a self incrementing serializing code that changes each time it loads into a chip on the array. The loading sequence maintains the chip position in the array while the increment determines the serial number ID.

    So... we think there is absolutely nothing inside the propeller chip that can be prodded to become unique and serve as a serializing derived number with repeatability...

    And *take 4 pins with resistors to provide a 4 bit address for the propeller using I/O.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-30 04:08
    Thanks James. Updating the Unique ID list.

    Ways to Develop a Unique ID for the Propeller Chip
    * take 4 pins with resistors to provide a 4 bit address for the propeller using I/O
    * load a unique ID into EEPROM
    * Use prop pins to read an external device
    * Wire an external serial ID chip to the circuit
    * Read a unique USB circuit for each chip
    * Self incrementing serializing code that changes each time it loads into a chip on the array. The loading sequence maintains the chip position in the array while the increment determines the serial number ID.

    So... we think there is absolutely nothing inside the propeller chip that can be prodded to become unique and serve as a serializing derived number with repeatability...??????????
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-30 04:22
    humanoido said...
    So... we think there is absolutely nothing inside the propeller chip that can be prodded to become unique and serve as a serializing derived number with repeatability...??????????
    That's been answered conclusively here more than once. Wishing it otherwise isn't going to change anything.

    -Phil
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-30 04:48
    @ Phil:

    I still have hope that there remains some method to access an internal feature towards the goal of uniqueness. I still think there is some process inside the Propeller chip that has some degree of uniqueness, even if it's a randomness, signal orientation, rc uniqueness, or a result from a variation in substrate.

    There are always variations in manufacturing processes. If not, then there would be no need to test chips. Even the internal RC circuit should vary. If it did not, then Parallax would not post a range of possible clock frequencies when engaging the internal circuit.

    I think this may be one key to solving this chip's "internal" challenge. It's internal and it can vary from chip to chip based on the resistor capacitance combination. I think this is covered in the two Propeller books as I recall. I am sure this effect can be measured from chip to chip.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-30 05:09
    I had already raised the "process variation" approach above but discredited it in the same post it since "neither uniqueness nor repeatability would be guaranteed." Nothing has changed since I made that assertion.

    -Phil
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-30 05:15
    h, this is not a "challenge", it's just a load of *&^%!

    Thinking something is fine but it is of no use unless it is based upon something factual and can be applied. Thinking that there is some process inside the Prop is quite different from knowing if there might be but variations in tolerances is hardly a way of trying to classify a degree of uniqueness. The RC oscillator is never a measure of "uniqueness", it's just something that varies with temperature, voltage, and process but is never constant. There is no unique process, it is just a sliver of silicon, that's all and silicon can have unique IDs embedded in them but this is usually a special (expensive) process. Sure, pay Parallax enough (I don't mind if you do) and they will even embed Flash in there for you too. I love reading Sci-Fi novels where they can wish and want and somehow come up with something impossible but unfortunately we have to live and breathe in the real world where things don't happen that way.

    For networks I have software that generate a random number on each node during the enumeration process (a bit like a MAC address) and the "master" successively approximates addresses until it gets a single response after which it assigns a sequential ID (bit like a IP address). As there is always a remote chance that two or more devices have the same random address there is also a resolution process where those conflicting nodes generate new random addresses. I have also used DALLAS single-wire ID chips as well and even used a similar approach to assigning local addresses with them. Failing that there is always the DIP switch approach, sure n certain.

    So, please separate fact from fairy-tale and research it yourself so that you have some basis for your "beliefs".

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • Nick McClickNick McClick Posts: 1,003
    edited 2009-12-30 06:20
    You could also do an R/C decay - different cap values would change the decay time. It wouldn't be secure and the address space would be somewhat limited (maybe 50 different address?), but it would only take one pin.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Forums RSS Feed!

    Gadget Gangster - Share your Electronic Projects
  • HumanoidoHumanoido Posts: 5,770
    edited 2009-12-30 06:25
    Peter Jakacki said...
    The RC oscillator is never a measure of "uniqueness", it's just something that varies with temperature, voltage, and process but is never constant.
    What values did you see returned from the internal oscillator in your circuit, and holding temperature and voltage as constants, what was the median error in repeatability?
  • James LongJames Long Posts: 1,181
    edited 2009-12-30 06:33
    Nick McClick said...
    You could also do an R/C decay - different cap values would change the decay time. It wouldn't be secure and the address space would be somewhat limited (maybe 50 different address?), but it would only take one pin.

    Nick,

    That is a great idea.......didn't think of that one. Saves 3 pins from my scenario.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • heaterheater Posts: 3,370
    edited 2009-12-30 07:29
    How about using positional information to generate a unique ID at start up?

    Consider a linear array of Props linked via some serial connection, Prop to Prop to Prop...horizontally.

    1) Each Prop sends a "who am I" ID request to the neighbour on its right and then waits for a reply.
    2) Each Prop gets a reply from its right hand neighbour which it uses as its own ID in future communications.
    3) Each Prop increments it's own ID number and uses the result to return as an ID in reply to the "who am I" request from it's left neighbour.
    4) The most right hand Prop has no neighbour to the right. So it times out the "who am I" request and uses zero as it's own ID.

    This can be extended to a 2 dimensional grid easily. Three dimensions and hyper cubes get progressively more tricky.

    Problem comes with rings, spheres, toroids etc where there are no "edges" and everyone has neighbours in all directions. Looks like you have to create some artificial "edges" as reference, points, lines, planes etc in that case.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • James LongJames Long Posts: 1,181
    edited 2009-12-30 07:39
    heater said...
    How about using positional information to generate a unique ID at start up?

    Consider a linear array of Props linked via some serial connection, Prop to Prop to Prop...horizontally.

    1) Each Prop sends a "who am I" ID request to the neighbour on its right and then waits for a reply.
    2) Each Prop gets a reply from its right hand neighbour which it uses as its own ID in future communications.
    3) Each Prop increments it's own ID number and uses the result to return as an ID in reply to the "who am I" request from it's left neighbour.
    4) The most right hand Prop has no neighbour to the right. So it times out the "who am I" request and uses zero as it's own ID.

    This can be extended to a 2 dimensional grid easily. Three dimensions and hyper cubes get progressively more tricky.

    Problem comes with rings, spheres, toroids etc where there are no "edges" and everyone has neighbours in all directions. Looks like you have to create some artificial "edges" as reference, points, lines, planes etc in that case.

    Well....I would say the first prop with a program would constitute an edge. So all edges would align there. Considering one of the props has to start the cascade.

    I have a problem with some of this. How are the props going to power up. Since they must receive a program from somewhere.......where will they receive it?

    You can not use one eeprom.......too many talking at once (no program internally to tell them not too). They can't ask their neighbor.....it may not have a program yet.

    I would think this will need a cascade power up sequence as well. Each prop would turn on it's neighbor then give him/her the program.

    I come up with the worst problems.......... I wouldn't want to have to manually power up the system every time it was shut down, or needed a new program.

    (sorry....didn't mean to ask an slightly off topic question.......but I would like to know).

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • heaterheater Posts: 3,370
    edited 2009-12-30 07:53
    I'm not really sure where all this is going James but there have been discussions here about booting up arrays of Props. Generally I think this comes down to having:
    1) A master Prop that can reset and program all the others or
    2) Chaining Props so they can reset and program their neighbours.

    Given the chain loading it would be possible to put a unique ID into the binary images prior to booting your neighbour with it. Sort of combine the ID generation process with the booting.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • James LongJames Long Posts: 1,181
    edited 2009-12-30 08:06
    heater said...
    I'm not really sure where all this is going James but there have been discussions here about booting up arrays of Props. Generally I think this comes down to having:
    1) A master Prop that can reset and program all the others or
    2) Chaining Props so they can reset and program their neighbours.

    Given the chain loading it would be possible to put a unique ID into the binary images prior to booting your neighbour with it. Sort of combine the ID generation process with the booting.

    That is what I was getting at.

    If it is a cascade power up (which I think would be needed), each Propeller could be programmed with a unique ID. I wouldn't think you could program all of them at once from one. This is due to the capacitance of the traces(single bus...all RESn tied together). The closest will ack before the others do (if they ack...I really don't know....never read into it).

    I guess you could have a master tied to each other prop reset using an I/O pin for each one (RESn), but that would use a bunch of I/O. I would think the chain would be better to prevent a lot of I/O wasted.

    Just rambling on the whole idea.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-30 08:08
    humanoido said...
    Peter Jakacki said...
    The RC oscillator is never a measure of "uniqueness", it's just something that varies with temperature, voltage, and process but is never constant.
    What values did you see returned from the internal oscillator in your circuit, and holding temperature and voltage as constants, what was the median error in repeatability?

    Research this yourself if you want to know. I don't care about this particular RC oscillator's characteristics, it's an RC oscillator, the datasheet says what it says.

    @Nick: For a smaller number of nodes it is possible to use an RC network (yes, I've done that too). But caps vary widely with temperature and age so you need a good margin and different values of resistors, not a good thing for production though. There is even the I2C SAA1064 which using one address pin selects 4 devices.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-30 08:14
    James Long said...
    heater said...
    I'm not really sure where all this is going James but there have been discussions here about booting up arrays of Props. Generally I think this comes down to having:
    1) A master Prop that can reset and program all the others or
    2) Chaining Props so they can reset and program their neighbours.

    Given the chain loading it would be possible to put a unique ID into the binary images prior to booting your neighbour with it. Sort of combine the ID generation process with the booting.

    That is what I was getting at.

    If it is a cascade power up (which I think would be needed), each Propeller could be programmed with a unique ID. I wouldn't think you could program all of them at once from one. This is due to the capacitance of the traces(single bus...all RESn tied together). The closest will ack before the others do (if they ack...I really don't know....never read into it).

    I guess you could have a master tied to each other prop reset using an I/O pin for each one (RESn), but that would use a bunch of I/O. I would think the chain would be better to prevent a lot of I/O wasted.

    Just rambling on the whole idea.

    James L

    Way way back I posted an idea for a chain loader that as each Prop loaded up it would use a location in eeprom for it's address and then increment that for the next prop. The last prop on the line would have a pullup resistor on it's control line and know to zero that location instead of incrementing it. Each control normally has a pulldown on it to prevent the next prop from booting until enabled. The prop's all share the same eeprom.

    RESET IN
    >[noparse][[/noparse]reset PROP #1 control]
    >[noparse][[/noparse]reset PROP #2 control]
    >[noparse][[/noparse]reset PROP #3 control]
    >[noparse][[/noparse]reset PROP #4 control]
    pullup resistor

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • James LongJames Long Posts: 1,181
    edited 2009-12-30 08:22
    Peter Jakacki said...

    Way way back I posted an idea for a chain loader that as each Prop loaded up it would use a location in eeprom for it's address and then increment that for the next prop. The last prop on the line would have a pullup resistor on it's control line and know to zero that location instead of incrementing it. Each control normally has a pulldown on it to prevent the next prop from booting until enabled. The prop's all share the same eeprom.

    RESET IN
    >[noparse][[/noparse]reset PROP #1 control]
    >[noparse][[/noparse]reset PROP #2 control]
    >[noparse][[/noparse]reset PROP #3 control]
    >[noparse][[/noparse]reset PROP #4 control]
    pullup resistor

    Basically what I said, just a different way to implement it. All the props couldn't load at the same time.

    You could basically do the same thing prop to prop, but would take more code.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • hippyhippy Posts: 1,981
    edited 2009-12-30 13:13
    If there were hooks in the PropTool you could run a plug-in to place an incrementing 32-bit ID / timecode into the Eeprom image and that could be poked at ( or moved to ) a convenient location to form a return value for myId := GetMyId(). The number would change on every download but would be permanent if burnt to Eeprom.

    The PropTool doesn't provide such hooks, but you can jump through hoops to achieve it, or maybe use one of the third-party compilers and loaders and insert a step in the middle.

    Ask nicely and one of the third-party developers may include a named 'constant' which gives a different value every time it runs.

    Post Edited (hippy) : 12/30/2009 1:18:29 PM GMT
  • CannibalRoboticsCannibalRobotics Posts: 535
    edited 2009-12-30 15:02
    I'd be really happy with a versioning capability within the PropTool that would deploy a single revision number accross all code files as a comment and·available in the code as a prop CONstant.
    It would automatically increment·all files·for each save or archive.

    ·yeah.gif


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Signature space for rent!
    Send $1 to CannibalRobotics.com.
  • mctriviamctrivia Posts: 3,772
    edited 2009-12-31 05:07
    you can always use the id object in the obex: obex.parallax.com/objects/410/

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
Sign In or Register to comment.