usb3sun 2.0: faster starts, slower mice, better menus
i’ve been working on a new firmware for usb3sun for almost a year, and it’s finally done! the release notes are loooong, but here are the highlights:
- it supports the upcoming pcb rev B0, which i’m hopefully shipping next week
- you can now set the mouse baud rate to 4800, 2400, or 1200, for operating systems that don’t support 9600 baud, like NeXTSTEP and plan 9
- it starts faster and enumerates your usb devices faster
- it has a completely overhauled menu ui — settings are only saved when you close the menu, and you can reboot the adapter after saving by holding Shift
- it finally has automated tests and an AddressSanitizer build
how did you make usb devices enumerate faster?
i upgraded the usb stack, which i was previously unable to do due to a regression that made newer versions of the host stack completely unusable. many thanks to Jonathan Haylett for getting to the bottom of that one. see these issues for more details about the regressions i ran into, and how i fixed them.
apropos of nothing, it turns out Pico PIO USB has its own minimal host stack, which we may be able to use instead of tinyusb. maybe someday we’ll use that, because as much as tinyusb is mature and feature-packed, it’s also a complex beast with a lot of moving parts.
isn’t this embedded code? how did you do automated tests, let alone AddressSanitizer?
i did it by making the code… uhh… not embedded. by moving all of the i/o to a hardware abstraction layer, we can now build the firmware as a normal program for linux, which made automated testing and dynamic analysis much easier.
this took a fair bit of work, because there’s no easy way to keep the arduino api when we build for linux, so we lose all of our arduino-based dependencies, including the graphics library, which i ended up having to reimplement myself. also you can’t build tinyusb for linux, like at all, not even the platform-independent parts. so even pure functions like parsing a hid report descriptor become hal operations, and we end up having to duplicate a bunch of defines and structs.
but having a hal means all of the i/o can now be emulated, recorded, mocked, or stubbed out, and we use all four of these techniques when building it as a normal program. as a result, we can test a wide range of behaviour like:
- when the firmware starts, we touch the correct gpios in the correct order
- when we receive 01h from the workstation, we reply with FFh 04h 7Fh
- when you close the menu, we only show you the confirmation screen if you changed anything, and only save your settings if you say yes
- ok the code for this one is goofy, but when you choose “Reprogram idprom”, we send that exact sequence of 1202 bytes (~400 keystrokes), containing your chosen hostid
by the way, those changes i had to make for automated testing? they also mean we can do fun things like emulating the ui in a terminal, which made it so much easier to develop new ui features and take the pretty screenshots you saw above:
▶
anyway… enjoy! if you’re one of the early adopters that bought a rev A1 from me, email me and i’ll send you a jig to update your firmware, free of charge.