How to develop a random number generation device

[John Larkin]

It's often more than just a couple of the taps and, with a little
ingenuity, the "lockup" state can be included in the sequence.

If the feedback is pure xor, and it's a maximal length sequence, then
exactly one state is the lockup, and that's either all 1's or all 0's
in the register.

John

 

[John Larkin]

If the feedback is pure xor, and it's a maximal length sequence, then
exactly one state is the lockup, and that's either all 1's or all 0's
in the register.

John

Hmmm, seems like all 0's must be the lockup for an all XOR feedback.

Sorry.

John

 

[Fred Bartoli]

Le Thu, 06 Sep 2007 08:54:17 -0400, Spehro Pefhany a écrit:

Maybe you should research how to generate random numbers.

Displaying a number is not very complex, maybe as simple as:
"printf("%d", x);"


Best regards,
Spehro Pefhany

Does printf work on 7 segments led displays? ;-)

 

[John Devereux]

Le Thu, 06 Sep 2007 08:54:17 -0400, Spehro Pefhany a écrit:



Does printf work on 7 segments led displays? ;-)

Well it's a bit limited.... it works on a 8x1 character LCD module
though!

 

[John B]

These things come up from time to time - does anyone know if there's
an algorithm for selecting taps for the maximum-length sequence, or
is it just by-guess-and-by-gosh?

Don L? Any ideas here?

Thanks,
Rich

There's a full list of Modulo 2 Primitive Polynomials (up to 100 bits)
in Chapter 7 of "Numerical Recipes in C". Unfortunately this book is
now out of print but the college library will certainly have it. My
edition is dated 1988.

 

[tomcee]

Hi,

I'm a researcher. As a part of my project work I want to desing a
random number generated and displayed on a LCD/ LED module. Can
anybody help me out in this.

Thiagu

I would recommend searching through the Microchip website.
There you will find articles on Random Number Generators, and details
on specific devices that can drive display modules directly.
TomCee

 

[John B]

Le Thu, 06 Sep 2007 08:54:17 -0400, Spehro Pefhany a écrit:



Does printf work on 7 segments led displays? ;-)

Why wouldn't it? Any printf() requires a putchar() function underneath
it. You just need to write one that interfaces to a 7 segment display.

 

[MK]

These things come up from time to time - does anyone know if there's an
algorithm for selecting taps for the maximum-length sequence, or is it
just by-guess-and-by-gosh?

Don L? Any ideas here?

Thanks,
Rich

My favourite source for this is:

www.xilinx.com/bvdocs/appnotes/xapp052.pdf

Hope it works for you.

Michael Kellett

www.mkesc.co.uk

 

[Spehro Pefhany]

Why wouldn't it? Any printf() requires a putchar() function underneath
it. You just need to write one that interfaces to a 7 segment display.

Yes, I've done that.

Since he mentions a "module", the chances are that it speaks ASCII
anyway. If it's a raw display, he'd need drivers, a little
interrupt-driven scan routine that uses a chunk of ram, and putchar
modified.

There is one interesting issue with using a 7-segment display with
ASCII-oriented routines.. the latter assume that a "."
is a seperate character, but they are interstitial on a 7-segment
display, which causes a certain amount of hilarity to ensue when
dealing with leading zero blanking and such like. The issue does not
arise with character-mode LCD displays.

Best regards,
Spehro Pefhany

 

[MooseFET]

On Sep 7, 5:43 am, Spehro Pefhany <[email protected]>
wrote:
[... Random number gen ....]

Since he mentions a "module", the chances are that it speaks ASCII
anyway. If it's a raw display, he'd need drivers, a little
interrupt-driven scan routine that uses a chunk of ram, and putchar
modified.

No interrupts really are needed. If all this thing does is display a
random number, the main loop can look like this:

while Power Is On
if The Button is pressed
call MakeRandom
call NumberTo7Seg
end if

for I = 1 to NumberOfDigits
DisplayDigit(I);
Delay 10mS
next I
ClearDisplayPorts
end while

The fact that the display ports get cleared each time around (ie the
LCD or LED gets no voltage) won't matter because the test of the
button being pressed is very quick.

The fact that the display is blanked while the button is held down,
could be sold as a feature.

 

[MooseFET]

Hmmm, seems like all 0's must be the lockup for an all XOR feedback.

Sorry.

XNOR is the all 1s case. That is likely what you thought about.

BTW: If you are making the shift register for such a thing in a
micro, it is usually faster to arrange the bits like this:

Byte0: Has bits 0, 4, 8, ...
Byte1: Has bits 1, 5, 9, ...
Byte2: Has bits 2, 6, 10, ...
Byte3: Has bits 3, 7, 11, ...

This way most of the shifting of the bits is done by moving whole
bytes. Only the shift into Byte0 needs an actual shift instuction.

 

[Spehro Pefhany]

On Sep 7, 5:43 am, Spehro Pefhany <[email protected]>
wrote:
[... Random number gen ....]

Since he mentions a "module", the chances are that it speaks ASCII
anyway. If it's a raw display, he'd need drivers, a little
interrupt-driven scan routine that uses a chunk of ram, and putchar
modified.

No interrupts really are needed. If all this thing does is display a
random number, the main loop can look like this:

while Power Is On
if The Button is pressed
call MakeRandom
call NumberTo7Seg
end if

for I = 1 to NumberOfDigits

Normally we blank the display (turn off at least one set of drivers)
before updating, otherwise you'll get visible ghosting since updating
the digit and segment drivers is usually not an atomic operation on an
8-bit micro.

DisplayDigit(I);
Delay 10mS
next I
ClearDisplayPorts
end while

The fact that the display ports get cleared each time around (ie the
LCD or LED gets no voltage) won't matter because the test of the
button being pressed is very quick.

The fact that the display is blanked while the button is held down,
could be sold as a feature.

Yes, you could do it that way, but using interrupts is a "set and
forget" type of operation, and I would recommend he uses it. If he
wants to blank the display between presses, that's easy too.

Best regards,
Spehro Pefhany

 

[John Fields]

Hmmm, seems like all 0's must be the lockup for an all XOR feedback.

Sorry.

 

[John Larkin]

I don't follow that. One state, all 0's usually, is the lockup. How do
you force that to be part of the sequence?

You can add a lockup state detector, a big OR gate or something, and
jam in a "1" if the whole register ever gets to the all-0's state, but
then the all-0's state is not part of the sequence, because it never
happens again.

A maximal-length pr sequence has one sequence of (2^n)-1 states, and
another sequence of a single hangup state.

John

 

[Vladimir Vassilevsky]

I don't follow that. One state, all 0's usually, is the lockup. How do
you force that to be part of the sequence?

You can add a lockup state detector, a big OR gate or something, and
jam in a "1" if the whole register ever gets to the all-0's state, but
then the all-0's state is not part of the sequence, because it never
happens again.

It can happen at the startup though. You have to ensure the nonzero
initial state.

VLV

 

[John Fields]

I don't follow that. One state, all 0's usually, is the lockup. How do
you force that to be part of the sequence?

You can add a lockup state detector, a big OR gate or something, and
jam in a "1" if the whole register ever gets to the all-0's state, but
then the all-0's state is not part of the sequence, because it never
happens again.

---
You detect the state just before lockup, EXOR that with the output
from the taps and feed that signal to the input of the shift
register. That'll force a zero into the input and, after the next
clock, will cause the outputs of the shift register to be all zeros.

Now, though, the input to the shift register will be a one so, after
the next clock, the sequence will begin anew.
---

A maximal-length pr sequence has one sequence of (2^n)-1 states, and
another sequence of a single hangup state.

---
Done as above, the number of states will be 2^n.

I'll post a .exe simulation (8bit, 256 states) to abse and the
QBASIC source code for it in a little while so you can see how it
works.

 

[Rich Grise]

My favourite source for this is:

www.xilinx.com/bvdocs/appnotes/xapp052.pdf

Hope it works for you.

Cool! Thanks!

Cheers!
Rich

 

[John Larkin]

But the state just before lockup *is* the lockup state. And the state
just after lockup is the same. Either the register is all 0's, and
it's locked forever, or it's some other code, in which case it hopping
through the 2^n-1 states, none of which are zero.

That'll force a zero into the input and, after the next
clock, will cause the outputs of the shift register to be all zeros.

Now, though, the input to the shift register will be a one so, after
the next clock, the sequence will begin anew.

XNOR feedback?

So you're just detecting some arbitrary state, and forcing the next
state to be zero. Then detecting the zero state 0 and restarting the
sequence. Why bother?

I'll post a .exe simulation (8bit, 256 states) to abse and the
QBASIC source code for it in a little while so you can see how it
works.

John

 

[Rich Grise]

XNOR feedback?


So you're just detecting some arbitrary state, and forcing the next
state to be zero. Then detecting the zero state 0 and restarting the
sequence. Why bother?

This app note has an awesome description of just that. It was
posted by "MK" without the "http://" part, so probably wasn't
clickable:
http://www.xilinx.com/bvdocs/appnotes/xapp052.pdf

Hope This Helps!
Rich

 

[Spehro Pefhany]

It can happen at the startup though. You have to ensure the nonzero
initial state.

VLV

If you care about fault tolerance you will ensure recovery from a zero
state which occurs at any time.

Best regards,
Spehro Pefhany