| View previous topic :: View next topic |
| Author |
Message |
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
| Internal serial number |
 Posted: Fri May 21, 2021 6:31 am |
 |
|
Hi.
I would like to know if the pic´s have any internal serial number that I can extract (one number for each manufactured pic)
I'm using a 10F222 pic and I need a different number for each recorded pic (as if it were a unique ID for each one).
Whenever the pic turns on, it takes the unique number to use.
In pics that have eeprom I have it randomly generate and write to eeprom, so at each start it reads the memory and uses that number, but as this pic does not have eeprom, I thought that if it has a unique internal number I could use it it.
Note: I cannot change the pic model for cost reasons. In the last case, I have the solution with the 10F322 and HEF.
thanks |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Fri May 21, 2021 7:01 am |
|
|
No. PIC's do not have a unique serial.
Microchip do offer a number of add on chips that offer such a number.
You could write a serial number into the code of the PIC. Look at the
CCS function #SERIALIZE. If you are programming with a supported
programmer this can add a 'variable' into your code, that is assigned
a new number each time a chip is programmed. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Fri May 21, 2021 7:35 am |
|
|
Yes, but using this function #SERIALIZE still I would have to have a way to store the value generated by the function and in pic 10F222 I have nowhere to store it.
It will be complicated to keep changing the code every time you program the pic.
When I say serial, I mean, if I could get any number that was the same in every uC start.
Anyway, thank you very much for your answer and tip. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Fri May 21, 2021 10:02 am |
|
|
No. The #SERIALIZE puts the value into the code. It creates a const
variable, which can be read by your code (stored as part of the program),
that is changed each time you program a chip.
You don't need any extra storage. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Fri May 21, 2021 1:06 pm |
|
|
| Ttelmah wrote: | No. The #SERIALIZE puts the value into the code. It creates a const
variable, which can be read by your code (stored as part of the program),
that is changed each time you program a chip.
You don't need any extra storage. |
Very interesting.
You would have a simple example for me, please, I looked at the example of CCS but I didn't understand it very well.
edit:
As I understand it, does this have to do with the programmer that will be used to burn the pic?
I use a pic kit3 I don't know if it would work. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Sat May 22, 2021 12:37 am |
|
|
As far as I know, this is only supported using one of CCS's own programmers.
So I don't think it'll work with the PicKit.
Use is simple:
| Code: |
#include <10F322.h>
#device ADC=8
#use delay(internal=4000000)
const int16 serialnum=0;
#SERIALIZE(id=serialnum, next="0001")
void main()
{
int16 val;
val=serialnum; //will get 1, then 2 etc...
while(TRUE)
{
}
}
|
For more complex sequences, you can define a file from which the numbers
will be read. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Mon May 24, 2021 6:37 am |
|
|
OK thank you.
Well, if it only works with a CCS programmer, I don't have much to do.
Let's say I do the following:
| Code: |
int value = get_timer0 ();
|
with this command every time the pic starts up, it will get a count value of timer0 right? My question is, do you think that in every startup the value will be the same, or with minimal variations in voltage this value can change? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Mon May 24, 2021 7:22 am |
|
|
The default value in the OPTION register means the timer will clock on
the T0CKI pin. So it's value will depend on any noise on this pin.
Prescaler will be assigned to the watchdog by default.
The value in the timer register itself is specified as 'unknown'.
It is not going to be a reliable value, and may well be the same for
different chips. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Mon May 24, 2021 7:27 am |
|
|
| Thank you so much !! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Mon May 24, 2021 7:48 am |
|
|
Seriously, just write yourself a little script to generate a serial number
into the hex file. Just store a serial as perhaps the last couple of bytes
in the ROM. Have this used as a value in your code, then have a script
that modifies this line in the hex file (including obviously generating the
correct checksum for the line). Each time you program a chip run the
file to update the number. |
|
|
smee
Joined: 16 Jan 2014
Posts: 24
|
|
| Posted: Tue May 25, 2021 4:10 am |
|
|
| or if you have a spare i/o line, put a dallas semi ds2401 on it. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Tue May 25, 2021 4:41 am |
|
|
possible method, haven't tried but it 'looks good in my memory'.....
That PIC has a 'User ID Memory' and you can use the PK3 to program a 'serial number' in there (0x0000 to 0xFFFF).
You'd have to enter the serial number, burn the PIC (ONLY the ID#), get another PIC, change serial number, burn that PIC, repeat for the entire batch of PICs. Should be able to do 40-50 in an hour.
Now you just grab a 'prenumbered' PIC, burn the PROGRAM only into it. Be sure to unselect the 'ID Memory' from being burned first.
Since 99% of my products these days have to read the temperature, I use a DStemp sensor. They all have unique IDs. I understand your product is very cost 'sensitive' but when you add the true cost of R&D time to get ID number in PICs into the overall costing, it might be better to have a bigger PIC or a peripheral with ID in it.
There may be other solutions but qty of PICs is important, 10, 100, 10,000 ??? |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Tue May 25, 2021 6:25 am |
|
|
| Ttelmah wrote: | Seriously, just write yourself a little script to generate a serial number
into the hex file. Just store a serial as perhaps the last couple of bytes
in the ROM. Have this used as a value in your code, then have a script
that modifies this line in the hex file (including obviously generating the
correct checksum for the line). Each time you program a chip run the
file to update the number. |
Sorry, I have no idea how to do this, but I appreciate the tip. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Tue May 25, 2021 6:26 am |
|
|
| smee wrote: | | or if you have a spare i/o line, put a dallas semi ds2401 on it. |
I cannot add extra cost to the product, as it is very cheap.
but thanks for the tip. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Tue May 25, 2021 6:32 am |
|
|
| temtronic wrote: | possible method, haven't tried but it 'looks good in my memory'.....
That PIC has a 'User ID Memory' and you can use the PK3 to program a 'serial number' in there (0x0000 to 0xFFFF).
You'ld have to enter the serial number, burn the PIC( ONLY the ID#), get another PIC, change serial number, burn that PIC, repeat for the entire batch of PICs. Should be able to do 40-50 in an hour.
Now you just grab a 'prenumbered' PIC, burn the PROGRAM only into it. Be sure to unselect the 'ID Memeory' from being burned first.
Since 99% of my products these days have to read the temperature, I use a DStemp sensor. They alll have unique IDs. I understand your product is very cost 'sensitive' but when you add the true cost of R&D time to get ID number in PICs into the overall costing, it might be better to have a bigger PIC or a peripheral with ID in it.
There may be other solutions but qty of PICs is important, 10, 100, 10,000 ??? |
Even the 10F222 pic has this ID memory ??
From what I read, this pic has no place where I can write and read an ID,
So to proceed with 10F222, I'm going to change the Id directly in the code, and go recording and do this for everyone.
The alternative I found is to use 10F322, which has HEF memory, so I use the rand () function to generate 3 random bytes and record in the HEF, and record another control byte, saying that the ID has already been generated and recorded, so when the program starts I read this control bit, the code sees that it has already done so, then goes to the else and reads the ID and proceeds to the main loop.
Here in Brazil there is a significant difference in the value of 10F222 to 10F322, but when I buy directly from Mouser, I saw that there is no difference, so I will choose this option. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
