Your drawing shows the signal being sent to /INT0. I wasn't sure if you intended to use it to generate interrupts, or as timer 0 gate control.

If it is used as interrupt, you can read out the timer but depending on timer speed, you may get one or two bits for each interrupt, since the high-order bits of the counter value suffers from aliasing relative to the previous read-out.


The reason I did mention 1ms was because of this:

I used 1ms as an example to show that the theoretical amount of random data available is greatly affected by the timer speed in relation to the bandwidth of the noise data. That was also why I noted that a program that needs a lot of random data would need to use the hw-generated noise as internal state for a PRNG.

With a 1MHz timer speed, a user may get n*1000 bits/s, where n will depend a bit on required quality of the bits. If a low quality is accepted, then each read of the timer can make use of several bits. For maximum quality, only the least significant bit may be accepted. Having a faster timer in relation to the bandwidth limit of the noise will obviously affect the number of bits/read that has a minimum quality.


Meaning now clarified.


That was the reason why I wrote "Either a few of the least significant bits may be picked up and used, or a good one-way hash should be used."

For many problems, the distribution can't be averaged out. Using all bits from the timer every time may get a good distribution of numbers, but it would not get a good distribution of the difference between consecutive random values. Quite a lot of timer-based implementations are "validated" by computing the average of all values, and the total count of all values, but forgets to look at the distribution of the difference. 1 million throws of a 6-sided dice may produce very similar counts for 1 to 6, but knowing that the last throw was a 6, the probability that the next throw is a 6 too may be way off from 1/6.


A sw package would then have to either make use of a PRNG driven by the hw noise, or have a function read_random_bits(count,timeout) or a function get_current_entrophy(). The first alternative gives the user access to infinite amounts of pseudo-random numbers with random seed. The second two alternatives give the user a way to pace the consumption of randomnes.


The circuit alone has a number of limitations, but combined with an entrophy pool it can produce very good results. Combined with a PRNG and some post-processing, the capacity can also be scaled quite well.