Week 12: Interface and Application Programming

This week

We OneRNG now.

Assignment: interface with an input or output device we built

A random-number generator is a kind of output device, yes?

After the strangeness that was Week 11 I reassembled my project board. I made the following changes:

  • Moved the I2C header further down to avoid physical collision with the display module.
  • Added 10k pull-up resistors to SCL and SDA.
  • Added 10-pin breakouts for Port A and Port C in case they end up being useful.
    • It’s possible I can use these to straight-up sense 16 buttons. This is a less shiny solution than afforded by the Trellis and is incredibly wasteful of pins but lets us easily remove dependency on one more store-bought item. Also, our choice of MCU means we have no shortage of spare pins.

The AT90USB1286 and the level shifters were salvaged directly from the previous board, as they are the most expensive items (and the ones we have the fewest of). As always, the display remains a plug-in module.

I modified the system software to implement a simple serial interface for receiving random data:

R pulls the entire RNG state:
returning the ASCII-encoded number of RNG bytes,
followed by the raw bytes,
followed by a newline \n.

On the computer side, I created a simple Python script using pyserial that continuously requests entropy and dumps it to standard output.

The result is some pretty random data:

Each of the 8 images above represents 128x128 (16384) random 8-bit integers. There seems to be generally a lack of obvious repeating patterns meaning that our onboard hardware RNG is not terrible.

Unfortunately, it takes a long time to gather enough data for rigorous statistical tests, so I don’t have results (yet) from anything like dieharder.

This new board has a bug where it likes to soft-reset itself sometimes. I suspect it is a cable issue actually.