Random number xc8 before programming
im producing 100 remote controls with pic16f1823 and i need a unique id for each remote but it needs to be constant over time so i think it better generate a random value before programming in the mplab compiler and then compile those 100 remotes I want not to change remote_id manually
#include "mcc_generated_files/mcc.h"
#define remote_id 33800
char col;
uint24_t data_out;
void Reset_state(void);
int Key(void);
int Key_prime(void);
void main(void)
{...
please help me with this problem
source to share
It should be possible to use SQTP mode with IPE as described here.
http://microchipdeveloper.com/ipe:serial-quick-turn-programming-sqtp-settings
source to share
Can you have a script at work that modifies the ihex file to make your serial number look different on the EEPROM (EE), since most of the pictures have 1KB of internal EE for data storage? The remote will then read its unique serial number from the EE locations. This would be a simple job for "gawk", say ...
source to share
Use the SQTP functionality in MPLAB IPE. You need to enter "advanced mode" and first enter the IPE.
On the SQTP tab, set it to store the values in the EEPROM as "Raw Data" at memory address 0x00. Click "Create" and it will write the sqtp file for you.
Select the SQTP file in the "operate" tab under the field where you select your .hex file.
Each time you update a new mcu, the IPE will grow to the next value in the SQTP file and even track between sessions.
You can use this in your code to get data:
unsigned char EEPROM_ReadByte(unsigned char eepromAddress)
{
while(RD || WR); // check the WR&RD bit to see if a RD/WR is in progress
EEADR=eepromAddress; // Write the address to EEADR.
RD = 1; // Set the RD bit to trigger the eeprom read operation.
return(EEDATA); // Return the data read form eeprom.
}
Call EEPROM_ReadByte passing 0x00 and it will return one character from your data. Increase eepromAddress and it will return the second character, etc.
Please note that your data will be in reverse order, I'm not sure why, maybe it has to do with how the SQTP files are encoded.
source to share