This makes it more forgiving of constant acceleration mid-movement, if
the beginning of the movement looks random. Handy for mice that for some
reason generate bot-like constant velocities.
- Implement advanced LED flash support
- Tweak HAL_SPI_TransmitReceive to tolerate a longer SysTick interrupt
- Tune KEYBOARD_BOTDETECT parameters
- L-shift and R-shift are now high-speed alphanumeric keys
(Upstream). Also implemented read-only mass storage mode.
Todo:
- Test. Everything!!!
- Report write protect flag in SCSI "mode parameter header" (whatever
that is)
So it turns out the SCSI ReadCapacity10 command does not return the
device capacity. It returns the address of the last block, which is
(capacity - 1).
Also fixed Upstream's end-of-device sanity check.
Previously we wrote 4 x 64 byte transactions to the downstream device.
This is fast, but very occasionally the USB host silicon would bug out.
Reverting to single 64 byte write transactions increases reliability at
the expense of some write speed.
Upstream's edge-detect interrupt that starts SPI transmission was not
firing. Sometimes. On some boards only. The cause was Downstream not
allowing enough time between edges for Upstream to catch the signal.
Also misc code tidyups.
It turns out that suspend support on the STM32 USB core is buggy as
heck. Host mode cannot resume after suspend, and device mode cannot
receive resume or send wakeup signalling.
I managed to fake resume support by keeping Downstream and our connected
device running at full power, and simulating a wakeup event to the host
by disconnecting/reconnecting Upstream from the host.
It will sometimes NAK part-way through a multi-packet OUT URB. And what
it wants is for the host to resend beginning from the last even-numbered
packet. NOT the last packet it received, and NOT the beginning of that
URB.
Robert Fisk