# Can I generate random numbers on PIC from INTOSC vs crystal?

Generating truly random numbers on a microcontroller is a known difficult task.

One way is to run two different clocks, and measure the clock drift between them.

The PIC16F1783 which I'm using does have two clocks. One using an external crystal and the LFINTOSC which powers the watchdog.

Is there any way to get at the LFINTOSC, while running from the external crystal clock?

One idea I had was to let the watchdog expire, and check the value of TMR2, but it doesn't work because TMR2 is reset by watchdog resets.

One could write a counter to EEPROM in a tight loop and let the watchdog expire, and then inspect the contents of EEPROM, but this seems very inelegant. Edit: It's much better to write to RAM, as suggested in one of the comments.

Is there a better way? Without using external circuitry, and without relying on ADC-noise (which might not always be present)?

Edit: I want the random number to generate a GUID to be able to tell apart multiple devices sharing the same RS485 bus. My idea is to use something similar to 1-wire device discovery. But to do this I need to have different GUID on different devices, and I'd like to avoid the hassle of having to program them with unique ID:s.

• +1 no answer but nice question. A useful aim if achievable. A noise diode MAY be easier albeit needing hardware and a pin. . – Russell McMahon Jun 14 '15 at 19:56
• Make use of the "Temperature Indicator Module" that is present. – JonRB Jun 14 '15 at 20:14
• The temperature itself does not really matter; you are interested in the noise generated during the ADC operation (you could use any other source for the ADC, but the temperature sensor does not need external hardware). – CL. Jun 14 '15 at 20:21
• Why would you write to EEPROM, instead of RAM? – Nick Johnson Jun 14 '15 at 20:23
• Microchip cannot break the laws of nature. But in practice, you have to measure how much of a difference you get when the temperature stays mostly constant. (And break all of Microchip's recommendations of how to reduce noise, i.e., use shorter sample times.) – CL. Jun 15 '15 at 8:57

Okay, I've found a way to do exactly what I asked in the question, without involving the WDT.

It's a bit of a hack, to say the least, and sacrifices two pins (EDIT: only one pin is sacrificed) (but requires no external components, so if you have two unused pins it will be "for free").

The idea is to use the PSMC (Programmable Switch Mode Control) of the PIC16F1783.

This can be clocked from the INTOSC, by way of connecting the HFINTOSC to the 4x PLL, yielding a 64MHz frequency to clock the PWM output.

The PWM output can then be routed to another pin on the PCB.

Now, using the external crystal to clock the CPU, the PWM signal can be read in a tight loop. Since the two clocks are not synchronized, there should jitter between the two clocks, and the PWM input should contain some unpredictable jitter.

On way to use this jitter to build random values could be to have a 16 byte checksum array. The TMR1 could then be configured to run as fast as possible, and every time the PWM signal changes, the TMR1 value could be written to the start of the array. Then the MD5 sum of of the array could be taken, and written back to the same array.

By iterating this procedure a few thousand times, a 16 byte MD5 hash could be built, which should be entirely random.

However, a MD5 checksumming algorithm barely fits on the PIC16F1783, so this is more of use on slightly more powerful chips. The same idea could be used though, by simply incrementing a byte by the TMR1 value, and let it wrap around a few thousand times before considering it "random enough".

The only way this could fail is if the internal 500kHz source would somehow sync up to the crystal oscillator. I have no idea if that is possible.

Update:

The following code seems to work in practice in my lab:

#define RAND_SIZE 255
unsigned char random_data[RAND_SIZE];
void make_random_data()
{
//Used output pin: RC3. Make sure it is unconnected!
PSMC1PRH=0x0; //choose a very short period period
PSMC1PRL=0x3;

PSMC1DCH=0x00; //set 50% duty
PSMC1DCL=0x2;

PSMC1PHH=0;
PSMC1PHL=0;

PSMC1CONbits.PSMC1EN=1;

PSMC1CLK=1; //64mhz
PSMC1STR0bits.P1STRD=1;
PSMC1OENbits.P1OED=1;
PSMC1PRSbits.P1PRST=1;
PSMC1PHSbits.P1PHST=1;
PSMC1DCSbits.P1DCST=1;

// Zero the id, to make sure any previous value does not influence result.
for(int i=0;i<RAND_SIZE;++i)
random_data[i]=0;

// Generate the new random id:
for(int pass=0;pass<1000;++pass)
{
for(int j=0;j<RAND_SIZE;++j)
{
for(signed char bitnum=7;bitnum>=0;--bitnum)
{
if (PORTCbits.RC3)
}
}
}
}


Update 2:

Only one pin is sacrificed, since it is possible to read the output PWM pin, you don't need to route it to an input and read that.

• Certain types of clocks will tend to sync themselves to other clocks, so this concern may be valid. Not all types do that, so a bit of research would be in order. – AaronD Jun 15 '15 at 17:08
• Hmm. Maybe the temp sensor idea is better in practice then. – avl_sweden Jun 15 '15 at 17:37
• I'd be interested in seeing some test of randomness applied to the output (but not interested enough to do it myself!). Is this something you could do conveniently? – Scott Seidman Jun 15 '15 at 21:20
• I've tested both the PSMC clock jitter and temperature sensor approach. Both work, and both can generate a 16 byte serial number in a few seconds on a PIC16F1783. – avl_sweden Jun 15 '15 at 21:38