@xobs found a scheduler bug that would trigger a runnable process
search every time a scalar message returned. This fixes the problem,
causing the quantum to go back to the caller as intended.
Improves performance on the syscall by about 40%.
The original implementation didn't keep around some key data,
so we had to read the old version of the record and update parameters
assuming that the USB descriptors didn't change too much.
Unfortunately with the mass storage option, the description can
change quite a bit, so we have to reconsitute it from scratch.
Basically, we re-do the `alloc()` call in the reset routine,
playing it reverse so that we setup all the higher-number
endpoints before doing ep0 last.
This hopefully fixes a stability issue for usb hid mode when
mass storage is enabled as a build option.
- use new SpinalUsbDevice::new() interface instead of cloning
- put the blank "key-up" event on keyboard events after the
core is switched to, instead of at boot.
- add some more appropriate debug statements to help track
view switching in debug logs
Instead of making it once and then cloning it (which is a bit
unclear what's going on), make it so that the shared memory
ranges are allocated in the caller's scope, and then create
the structure "clean".
Also add a static AtomicBool to track interrupt init state,
since that can be only called once.
For some unknown reason, just adding a second bulk endpoint descriptor makes enumeration
fail on essentially all operating systems.
Adding three endpoints is no issue though, but since we want to avoid wasting resources around
here, writing 0x42 at the end of the last bulk endpoint... fixes everything.
Tested under Linux, Windows, OpenBSD, FreeBSD.
bulk endpoints have a different behavior now than interrupt
endpoints; bulk endpoints have chained descriptors so that the
hardware automatically responds to multiple USB packets quickly.
interrupt endpoints also have subtly different way of handling
data readiness, which is incompatible with the block device layer
as implemented.
since we don't have a clear use case for this yet and it's just
for testing on bleeding-edge, make a very small disk just so it's
easier for people to do testing, but not so big that it's a burden
on the system.
later on we can make this dynamically sizeable/allocateable only
e.g., only when the disk is required
before we were looking at the amount of data transferred and
seeing if it matches the expected amount
I just realized that we can just look at the descriptor pointer in
the status region; if it is non-zero, then the descriptor set
is "live" and needs to be filled.
if it's zero, then a packet came in.
use this to fix the wait conditions for accepting new commands.
IN descriptors now chain up to 512 bytes long
OUT descriptors still need to be worked up
However, there is an issue where the system is injecting the
ZLP/CSW immediately after the bulk response is queued up, and this
is getting sent before the bulk data is issued. Need to figure out
this race condition.
