This tests the firmware with a busy USB stack, and measures how busy we're keeping it. By virtue of this being a stupid blocking USB client it won't actually be that busy, but this is a baseline at least.

This is way too verbose

I originally had this in here as a workaround because sometimes fcserver would fill up its USB queue, but this increases lag a lot. Much better without, and if fcserver acts up again I should just fix it :P

Configuration is now no longer mandatory.

This makes it easier to move around for future optimizations, and it already gains us a few FPS by allowing the compiler to optimize a little better

This actually works fine, we just weren't initializing it to zero, which borked a bunch of assumptions of course.

This is hella verbose, quit it.

It's causing USB problems (reading the string descriptors) and it doesn't help now that I've determined that executing from RAM doesn't significantly speed up the updatePixel loop.

This causes false negatives sometimes, boo.

The new 16-bit residual code is a little bit slower, and it shows. I hope I can get this back up soon...

This gives one combined image that is convenient to load either with the test jig or with the Teensy Loader

This fixes some bug that I don't have time to investigate right now. Annoying! I suspect an assumption in usb_mem that I'm forgetting about.