Describe this project

server: Replay log

server: Denormalized Message

Oh, wow, implementing deserialization in serde by hand is painful.
This hurts less.

server: Hand-implement Serialize

Mostly for symmetry with Deserialize, for which the lack of #[serde(flatten)]
support hurts much wors.

server: SystemTime → u64 of seconds since UNIX_EPOCH

server: Extract merge_message()

server: Bind port before messing with log files as a lock

Rather than messing with flock, fnctl-F_SETLK, etc., just bind the port
before touching the log file & let the failure to bind the port keep
two instances of the server from stepping on each others' log i/o.

server: extract open_log_for_writing()

server: Only write CSV headers when initially creating the log file

server: Log file name constant

server: Write CSV to log file

server: Write reports as CSV

server: Drop `ago` field

server: Merge keystroke time ranges

server: Combine ago & clock to get original event time

server: Parse messages

client: New epoch if seq wraps

housing: Clarify license

server: Clarify license

server: Receive packets

server: Start

client: Change wire format!: Add epoch

This helps the server de-dupe: Records with the same sequence number but
different epochs do not describe the same event.

client: Change wire format!: Expand `ago` field: 16 bits → 32 bits

16-bit values of seconds only go up to 18 hours, and sometimes a little
more than that would be nice.

32 is overkill.  24 would have been fine, but would have been slightly
annoying to encode and parse.

client: Bump default config_resend_count 5 → 16

client: Explain the exponential re-send delay

client: Specify license

client: lint nits

client: const config

client: Make the queue size bounds configurable

client: Hold presses in queues, one queue per send_count

This lets us efficiently hold many more presses with pending resends
and eliminates the failure mode in which young presses could be dropped
because the sleeps_heap was full of old presses.

Instead of storing each press in the sleeps_heap, we now only store up
to config_resend_count entries in the sleeps_heap.

Old presses now only compete with similarly-old presses for retention
space.

client: xcalloc

client: get_press_due_for_resend()

This removes the last references to pp's internals outside press.c.

client: create_press() → add_press()

client: Bundle press_t[] & pheap_t* together as press_pile_t

client: Rename sends.c → press.c

client: Rename: send → press

client: Rename: set_send_alarm → set_resend_alarm

client: Rename the event enum values

client: Rename: send_report -> send_report_packet

client: Extract set_send_alarm()

client: next_scheduled_send()

client: create_send()

client: Start moving pending-sends logic out to sends.c

client: Exponential backoff resend intervals

client: Stop sleeping separately for each re-send

Instead, determine when the next send, in the whole pile of sends,
needs to happen and sleep until then.

This is the first functionality in this project that is more than simple
glue code.  This is the first non-trivial functionality that has some
internal logic to it.

I'd really like to write a test for it.

This environment (C, CMake, pico-sdk) makes testing hard!  :(

I'd like to build the test as a host/native executable and run it on the
build machine at build time, even though the primary/production use of
the code under test would be on the pico, cross-compiled.

I know testing this way is imperfect: It would fail to catch the entire
class of bugs that are caused by the code under test making architecture
assumptions that are valid on the build host but invalid on the cross
target.  But it would still be very useful for all other classes of bugs!

This usage is very much not supported:

1. CMake doesn't support it at all: One toolchain per language:
   https://discourse.cmake.org/t/compile-unit-test-natively-and-cross-compile-code-for-embedded-target/3607
   https://discourse.cmake.org/t/using-multiple-toolchains-in-the-same-project/1505

2. Even if I'm confident in my ability to write portable C that runs
   correctly on both build-host and cross-target architectures, I can't
   rely on pico-sdk's pheap library to be portable in this way.  It is
   super-not-portable-at-all; it will never run on the build host.

3. If I use a different, portable heap library, I'm duplicating code
   already in the pico-sdk standard library.  The pico is small enough
   already.  I'd rather not deploy two heap libraries.

4. I could define an interface to a heap library & use the pico's heap
   library when deploying to the pico & some other heap library when testing
   on the native machine, but

   a. My interface-to-pico's-heap-library code goes untested.
   b. The interface-to-a-heap-library code would likely add overhead.
   c. That's a bunch of extra code to write.  :(

5. Even if I worked through the interfacing-with-pico's-heap library issue
   and made this a separate, independent, portable library, I'd still
   be left with the problem of composing the two pieces.  Do I build
   a library .so separately, spinning up a separate Debian VM for that?
   Does pico-sdk even support building libraries?  Or do I copy the source
   of the library into the executable's source tree & make building the
   library part of the executable's build process?  Ick.  :(

6. Other option: Build a test intended to run on the pico.  It's nuts
   that this is the least-nuts option.  :(

I am very discouraged.  :(

I don't even bother to keep this functionality separate with a clean
interface for the test harness.  :(

So, no tests.  :~(

For now.

Advice welcome.

client: Extract pending-send object as send_t

client: Move queue servicing to service_queue()

client: Interleave accepting new button presses & re-sends

client: queue_try_add_ignoring_errors()

client: Set up for multiple types of events to go into the queue

client: Prefix all the config settings with "config_"

client: Calculate 'ago' with a clock

client: Work in 1-second granularity

client: Send each report multiple times

UDP is unreliable.

It would be better to re-send over a much longer interval, interleaving
re-sends from different presses.  Do this simple re-sending for now.

client: Less chatty with the LED

client: debounce

client: Initial wifi connection time: 10s → 90s

No reason to give up so aggressively.

Be robust against the AP restarting, which takes ~1 minute.

client: Don't sleep in interrupt context

client: Respond to button press

client: Explain config settings

client: net: Fix port byte order

Docs ( https://www.nongnu.org/lwip/2_0_x/group__udp__raw.html ) say
"ipaddr & port are expected to be in the same byte order as in the pcb,"
which apparently means _don't_ run it through htons().

client: Send UDP packets

client: Move config to config.c

housing: Extra length for cord grip

housing: Grip board tighter

housing: Flatten

housing: Adjust board fit

housing: Basic shape

Not solved yet: Cord grip/anchor

housing: Start

client: Move blink stuff to separate file

client: Connect to wifi

client: Fancier blinking

client: Build wifi deps

client: Get lwipopts.h from pico-examples

client: Build in a Debian VM

This finally makes it work.  Hurray!

Other things I tried that didn't help:
  * Other versions of cross gcc (8, 9, 10, 11 12)
  * Other versions of host gcc (10)
  * Other versions of pico-sdk (1.3.1, 1.4.0)

arm-none-eabi-gcc as packaged in Debian works.
arm-none-eabi-gcc as packaged in Nix doesn't.
I haven't yet looked further into why.

client: Use standard <nixpkgs>

Do the "fetchSubmodules = true;" override here

client: Install the .uf2

client: Switch to pico_w blink example

client: Start with the 'blink' example