 |
 |
| View previous topic :: View next topic |
| Author |
Message |
temtronic
Joined: 01 Jul 2010
Posts: 9135
Location: Greensville,Ontario
|
|
 Posted: Tue May 25, 2021 10:52 am |
 |
|
It's in the 10f222 datasheet,section 8.11 , 'special features' of the CPU....
8.11 ID Locations
Four memory locations are designated as ID locations
where the user can store checksum or other code
identification numbers. These locations are not
accessible during normal execution, but are readable
and writable during program/verify.
Use only the lower 4 bits of the ID locations and always
program the upper 8 bits as ‘1’s.
I had to check the datasheet as I originally looked in MPLAB for the PK3 programming information.... |
|
 |
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Tue May 25, 2021 12:34 pm |
|
|
| temtronic wrote: | It's in the 10f222 datasheet,section 8.11 , 'special features' of the CPU....
8.11 ID Locations
Four memory locations are designated as ID locations
where the user can store checksum or other code
identification numbers. These locations are not
accessible during normal execution, but are readable
and writable during program/verify.
Use only the lower 4 bits of the ID locations and always
program the upper 8 bits as ‘1’s.
I had to check the datasheet as I originally looked in MPLAB for the PK3 programming information.... |
Yes, but if they are not accessible during the execution of the program, how would I use something programmed there?
In addition to having to change this value in every recording, it would be easier to use as it is currently used, where I use a simple 8-bit variable with the value I need. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9135
Location: Greensville,Ontario
|
|
| Posted: Tue May 25, 2021 1:48 pm |
|
|
They should be readable....though I've never used that chip(have samples though...).
The memory map will show where they are located. Unless you 'write protect' memory, ALL locations are available to be read.
You only need to program them ONCE.
If using MPLAB and a PICKIT3....
you run MPLAB, select 'configure', then 'ID memory',fill in 'User ID' as your unique serial number', then ONLY program that into the PIC. ( Do NOT program in your compiled code 'program' ).
Now you'll have a 'blank' ( no program ) PIC with a 'serial number'.
When you want to program your compiled code into the PIC, be sure to deselect 'ID memory' in the 'erase/burn' options !! Otherwise, the PK3 WILL erase the serial number located in the ID memory locations.
It's probably a good idea to do say a batch of 20 PICs at a time with a 'cheat sheet' to check off used serial numbers. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue May 25, 2021 5:34 pm |
|
|
temtronic, your quote says:
| Quote: | 8.11 ID Locations
These locations are not accessible during normal execution,
but are readable and writable during program/verify.
|
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9135
Location: Greensville,Ontario
|
|
| Posted: Tue May 25, 2021 6:21 pm |
|
|
hmm, that's disappointing, as I KNOW they're available on the 46K22...I assumed the same for all the PICs, well as least 'newer' ones.
Seems silly not to have a feature like that on all PICs |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19264
|
|
| Posted: Tue May 25, 2021 11:43 pm |
|
|
Yes, it is a thing that is quite annoying.
These very basic chips don't support reading the config bits from code.
Silly....
As I said already, the way to do this, is to simply write a little program
script that edits the hex file, and updates the checksum to match.
You can have it increment a value stored in the ROM each time it is called.
Just have a const variable stored at a fixed location, and update this.
You'll have to be aware that such a variable is stored as RETLW instructions
on these chips.
This is probably just about the hardest PIC to do such a thing with, of all
the chips in existence.
It may be cheap, but with that cheapness, comes a marked 'lack of features'.
The 10F322 by comparison, does allow the code to read these locations.
Suddenly the whole thing becomes a lot easier. The price is basically the
same for these. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Wed May 26, 2021 1:33 pm |
|
|
| Ttelmah wrote: |
The 10F322 by comparison, does allow the code to read these locations.
Suddenly the whole thing becomes a lot easier. The price is basically the
same for these. |
Yes, as I mentioned earlier, I already developed something that works for 10F322, as I said, here in Brazil the value varies a lot from 222 to 322, but when I buy a larger quantity, it will certainly be at the mouser and I saw that the price is practically the same.
But this topic was good, to know that it is not possible to extract a unique number from each mcu.
I appreciate the responses. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Thu May 27, 2021 8:09 am |
|
|
Another doubt that is pertinent to what I am programming:
We know that the rand () function can determine a certain rand_max, a maximum limit that it will randomize a number, but I have a doubt, how to determine a minimum limit? From 100 for example, is it possible or should I deal with software? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19264
|
|
| Posted: Thu May 27, 2021 11:00 am |
|
|
First, remember rand, has nothing to do with 'random'. It generates a
pseudo random sequence that is dependant on the seed number it is fed
with. If left unseeded, or the seed is the same, it will always develop the
same number sequence. To give anything approaching a random sequence
it needs a truly hard to predict seed. A clock from an RTC, or a voltage
from a floating pin, are typical seed values.
Then rand simply gives an integer from 0 to RAND_MAX. If you want a
sequence starting at 100 and going to 200, then you set RAND_MAX to
100, and add 100 to the value returned by rand. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Thu May 27, 2021 11:58 am |
|
|
| Ttelmah wrote: | First, remember rand, has nothing to do with 'random'. It generates a
pseudo random sequence that is dependant on the seed number it is fed
with. If left unseeded, or the seed is the same, it will always develop the
same number sequence. To give anything approaching a random sequence
it needs a truly hard to predict seed. A clock from an RTC, or a voltage
from a floating pin, are typical seed values.
Then rand simply gives an integer from 0 to RAND_MAX. If you want a
sequence starting at 100 and going to 200, then you set RAND_MAX to
100, and add 100 to the value returned by rand. |
I program and executed the same pic a few times and in all of them the numbers obtained from rand () were different .. anyway ..
About your idea, yes very creative, I ended up doing something similar, where I compare if the number obtained is less than 100, I add 100 to it. it worked pretty much the same as your suggestion. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9135
Location: Greensville,Ontario
|
|
| Posted: Thu May 27, 2021 3:15 pm |
|
|
I've been thinkig about this on and off today.... 'random' will eventually give you the same number and I think you want 'unique' numbers for each PIC.
One possible way, is to code a 'ROM constant' as the serial number. If you have more than 255 devices, you'll need a 16 bit variable.
While 'clumsy', you code the 'serial_number' variable with '1', compile, burn PIC #1. next PIC, you edit program, change 'serial_number' to '2', compile, burn PIC #2, repeat as needed....
Each PIC would have a unique serial number, works for any PIC, provided you have 2 bytes of space.
There may be something wrong but doing it in my memory it 'looks OK'....
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19264
|
|
| Posted: Thu May 27, 2021 11:37 pm |
|
|
| rodrigo_cirilo wrote: | | Ttelmah wrote: | First, remember rand, has nothing to do with 'random'. It generates a
pseudo random sequence that is dependant on the seed number it is fed
with. If left unseeded, or the seed is the same, it will always develop the
same number sequence. To give anything approaching a random sequence
it needs a truly hard to predict seed. A clock from an RTC, or a voltage
from a floating pin, are typical seed values.
Then rand simply gives an integer from 0 to RAND_MAX. If you want a
sequence starting at 100 and going to 200, then you set RAND_MAX to
100, and add 100 to the value returned by rand. |
I program and executed the same pic a few times and in all of them the numbers obtained from rand () were different .. anyway ..
About your idea, yes very creative, I ended up doing something similar, where I compare if the number obtained is less than 100, I add 100 to it. it worked pretty much the same as your suggestion. |
That should not be the case. What are you putting into srand?.
Rand, should _always_ give exactly the same sequence when called, unless
srand has been used to start a new sequence.
The manual specifically says that unless you are using srand, rand will
give the sequence corresponding to an srand of 1. The actual code itself
says:
| Quote: |
Calling rand before any call to srand generates the same
sequence as calling srand with seed passed as 1.
Usually, you need to pass a time here from outer source
so that the numbers will be different every time you run.
|
You should not be seeing 'different' sequences, unless you are using
srand to seed the sequence to a different start. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Fri May 28, 2021 6:10 am |
|
|
| temtronic wrote: | I've been thinkig about this on and off today.... 'random' will eventually give you the same number and I think you want 'unique' numbers for each PIC.
One possible way, is to code a 'ROM constant' as the serial number. If you have more than 255 devices, you'll need a 16 bit variable.
While 'clumsy', you code the 'serial_number' variable with '1', compile, burn PIC #1. next PIC, you edit program, change 'serial_number' to '2', compile, burn PIC #2, repeat as needed....
Each PIC would have a unique serial number, works for any PIC, provided you have 2 bytes of space.
There may be something wrong but doing it in my memory it 'looks OK'....
Jay |
DOing this is the same as changing a variable int ID for example every time you write the code, it is much simpler than writing and reading in ROM. |
|
|
rodrigo_cirilo
Joined: 31 Mar 2019
Posts: 43
Location: Sao paulo/Brazil
|
|
| Posted: Fri May 28, 2021 6:16 am |
|
|
| Quote: |
You should not be seeing 'different' sequences, unless you are using
srand to seed the sequence to a different start. |
Well, I can see what was generated by rand () and recorded in the flash through pickit3, and each time there were different numbers.
in the protheus simulator the numbers are always the same, but in real life they are different.
see how I use the function:
| Code: |
#include <10F322.h>
//#include <12f675.h>
#FUSES NOWDT //Watch Dog Timer
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOPROTECT //Code not protected from reading
#FUSES INTRC
#FUSES NOWRT
#use delay(clock=4000000)//,RESTART_WDT)
#ORG 0x1E0, 0x1E3 {}
#define RAND_MAX 255
#INCLUDE <STDLIB.H>
#define HEF 0x1E0
void(main)
{
buffer[2]=rand();
buffer[4]=rand();
buffer[6]=rand();
if(buffer[2] < 100)
{
buffer[2] = buffer[2] + 100;
}
if(buffer[4] < 100)
{
buffer[4] = buffer[4] + 100;
}
if(buffer[6] < 100)
{
buffer[6] = buffer[6] + 100;
}
my_write_program_memory(HEF, buffer, 8);
}
|
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9135
Location: Greensville,Ontario
|
|
| Posted: Fri May 28, 2021 6:36 am |
|
|
re: in the protheus simulator the numbers are always the same, but in real life they are different
please read PIC101, Proteus is NOT a good 'simulator'...... you can have 100% proper code but as the simulator doesn't work right, you get bad numbers...or 'stuff doesn't work right'....
re: 'serial number'. I was under the impression you wanted each PIC to have a unique 'serial number', hard coded into the PIC. I think what you're now trying to do is generate a 'serial number' within the final PIC program and it'd be in RAM ?
AT 68 + 3 days, it's easy for me to get confused....... maybe restate what you really need. Also what quantity of PICs are needed?
What many never consider is the actual cost of R&D time.
Say you charge $50/hr and are making 50 units. Say it takes you 2 hours to 'cut WORKING code'. That's $100. If the DS device is $1, x 50 units = $50 cost for parts. So, at the end of the day you've SAVE $50 and each PIC WILL have a unique ID number. The cost per unit will be lower, the more you make.
Most never even count the time they spend on this forum as R&D time, but every 1/2 hr is costing you $25 at $50/hr......
Jay |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
