* More board definition modules other than Nano and Uno. Need hardware to
  test.

* The Nano board definition has not been tested on actual hardware,
  and we wonder if eg pin10 can really handle PWM. Some documentation seems
  to say not. It would be good to check it's basically working.

* Serial input/output can support types other than the current Int8.
  For example, here's an implementation for Word8:
  https://github.com/tom-hoffman/copilot-looper/blob/main/Word8IO.hs

* analogReference()
  Takes one of a set of defines, which vary depending on board,
  so how to pass that through Copilot? Could write a C
  switch statement, on an int, and have the board modules define
  effectively enums.

* ADC is a raw ADC value; add a stream function to convert that
  to a floating point actual voltage, given also a stream that contains
  the reference voltage.

* advanced IO (pulses, tones, and shiftin, shiftout)

* Wire library

* EEPROMex supports writing individial bits of a byte, but the haskell
  library does not expose it. What would be a good haskell interface to
  that, a Stream (Array 8 Bool)?

* Factor out Range from EEPROMex, and use it to also implement RAM ranges.
  Maybe redundant with Copilot's support for Array, but Copilot's
  facilities for operating on Array are limited so it could be useful to
  have a Range interface too.

* A single Sketch that has two writes to the same pin currently results
  in C code that indeed writes twice per loop. This is somewhat surprising,
  undocumented, and perhaps breaks the FRP-like behavior. It would be possible
  to prevent multiple writes to the same pin in a Sketch (already done for
  dissimilar uses of the same pin), but that is complicated by combining
  two Sketches with if/then/else or whenB or similar, that both write to
  the same pin, but not actually at the same time.
  	whenB foo (led =: false) >> whenB bar (led =: true)
  Which should be legal at least when foo /= bar.

* The way serial output works is somewhat unsatisfying, because
  it does not take a Stream FormatOutput. So the Copilot DSL can't be used
  to adjust the output format as the arduino runs; it's fixed at compile
  time. While Serial.byte does operate on a Stream, it would be hard to do
  eg, an interactive program using it.

  It might be possible, using Copilot's support for C structs, to allow
  Stream FormatOutput to be accepted by Copilot. However, this issue
  seems like it would probably get in the way of actually constructing such
  a stream: https://github.com/Copilot-Language/copilot/issues/36

  The workaround, for now, is to use ifM_ etc to switch between different
  sketches for the different output formats.