I can't think of anything more boring than playing a game of Simon Says that repeats the same pattern over and over again. Baseball might be a close second (sorry, baseball fans).

Typically, in order to implement randomness into a game's pattern, I would do something like this in C++:

1. Import a standard library

2. Slap rand() into my code with a range of 0–2

3. Assign 0, 1, and 2 to specific colors in my game

4. Call it a day

However, because we're dealing with embedded systems, I needed to think at a deeper level. How would I achieve this if I had limited heap space and had to deal with the typical constraints that embedded software engineers face?

This led me to research how random numbers are generated by computers. Typically, something called a seed value is used. This is a seemingly random number sourced from some external or unpredictable input. A deterministic algorithm (meaning 100% predictable given the same input) then uses this seed to produce a seemingly random value. I say "seemingly random" because, unless the source of the seed is truly random (see Cloudflare's wall of lava lamps), we can only say the result is pseudo-random.

We're building a game of Simon Says — not encryption for the NSA!

Awesome — so conceptually, all I had to do was find a seed value! After working my way through this problem, a quick internet search revealed that I could actually pull electrical noise from an uninitialized pin and generate a seed value that way!

How this works is as follows:

1. I identify a pin on my board that is uninitialized — meaning the pin is left floating with no circuit actively driving it.

2. I use analogRead() in my loop to read the electrical noise from the uninitialized pin. This serves as a sufficiently random seed value. Then, the value modulo 3 is used to output values between 0–2 (perfect for assigning three colors). It looks something like this:

randomInt = analogRead(A0) % 3;

With that, I now have a PRNG (pseudo-random number generator) without the use of any libraries! To be fair, I did use analogRead(). However, now that I have a proof of concept, I might be interested in exploring reading from a pin without the use of the analogRead() method.

Until next time!

- Eric Byrd