Default state: Decoding requests

What’s with that `request` variable, how do we define that? The
structure is described in the USB 2.0 spec, Table 9-2. It’s quite
simple.

We are assuming here that the compiler will treat this structure as
packed, and that the `enum`s will be byte-sized. But that’s a sensible
assumption for an 8-bit controller and enum values less than 256.

You could stop now and ask if we really had to type out that request
structure and the enums. Surely there are already several places where
USB requests are already implemented, could we just grab a header from
them?

* The Linux kernel has a `<linux/usb/ch9.h>` header, named after the USB
  specification chapter 9. It is licensed under GPLv2 _only_, and that
  would be an unfortunate limitation for us if we want GPLv3.
* The `libusb` library has `<libusb.h>`, and it is licensed under
  LGPLv2.1 or later. But that file includes several others and declares
  libusb’s functions as well. A bit too heavy for us.
* There is, theoretically, also the Windows DDK. I don’t even want to
  consider making it a compile dependency for the firmware.

So, let’s for now just define all we need ourselves.

And that `utohs` function? Well, the USB specification dictates that all
multibyte values are sent in little-endian order. Our compiler, SDCC,
happens to use little-endian order as well, but not all 8051 compilers
are like that. The one that compiled the original TECK firmware, for
example, was a big-endian one. Better be explicit and define a couple of
macros to convert USB to native order and vice-versa. (They are named
analogously to `htons` and `ntohs`, Host to Network / Network to Host,
but using `u` for USB in place of `n` for Network.)
Default state: Handling requests, top-level

The usb_request function will ultimately need to dispatch on the
`bmRequestType` and `bRequest` fields and handle the request. We do each
level of dispatch in a separate function. First, see if the request is
directed at the Device, one of its Interfaces, or any of their
Endpoints.

In the Default state, we only handle Device requests; will add more
recipients later.
Default state: Handling device requests

For a Device request, we see whether it is a Standard or Class-specific
request. (Also Vendor-specific when we get to that.)

Again, we only handle a couple of Standard requests.
Default state: Handling Standard device requests

In the Default state, we only handle a couple of Standard requests.
These are `GET_DESCRIPTOR` and `SET_ADDRESS`.

The latter has one quirk. In response to it, we must take the address
assigned to us and assign it to the `UADDR` register. But we must not do
that until after the whole control transfer is over. So we just stash
the new address into a variable, to be dealt with later, and send a
zero-length status response.
Default state: Handling `GET_DESCRIPTOR`

For `GET_DESCRIPTOR`, we just continue the pattern of dispatching. The
first descriptor that we get asked for is the device descriptor.
Default state: Sending request responses

The usb_transmit_descriptor function accepts a block of data and its
size and arranges for it to be transmitted to the host. It also checks
how much of the descriptor the host asked for, because it’s common for
the host to first ask only 8 bytes of the device descriptor.

Actual transmission might have to be done in several chunks if any of
our transfers exceed 64 bytes. So let’s set up two global variables that
track where we are transferring from and how much is remaining.

Each time the transmit FIFO is ready, we send as much as we can, but not
more than the maximum size of 64 bytes, and update the globals. If the
chunk is incomplete, we’re done. (From this it follows that if the data
is evenly divisible by the max chunk size, there will be one zero-sized
chunk at the end.)

When each chunk is transmitted, we get a USB interrupt with `UTXD0` set.
That’s a signal for us to send the next one (if any).

We call the `usb_transmit_done` function when all chunks are sent.
Default state: Handling `SET_ADDRESS`

The `usb_transmit_done` function that we call when all chunks are sent
is in fact a good place to finish the handling of `SET_ADDRESS`.

And since the “transmit done” interrupt handler looks at the
`usb_transmit_ptr` variable to decide if there’s another chunk, the
`SET_ADDRESS` initial handler has to set it to `NULL`. I factored that
out into a separate `usb_transmit_dynamic` function. We will call it
when our response can be queued immediately. (This means it must fit in
less than 64 bytes.)
Default state: Handling `GET_DESCRIPTOR` (cont)

What’s left is the `device_descriptor` constant. For now, let’s use
this. We’ll flesh it out some time later.

(I’m using a different Product ID so as not to interfere with my main
keyboard, which is, of course, another Truly Ergonomic. 030C is the
Product ID in production mode; when in ISP DFU mode, the device
identifies itself as 030B.)