on valid pages were being updated in a dictionary entry as
it is updated; actually, entries that are invalid should also
be zeroized, otheriwse they "Stick around" as valid entries.
the new offset address was being used for copying data, instead
of the old offset, which was causing key data to refer to
an incorrect entry after deletion
Rather than hardcoding numbers, use an enum with the constant values.
This will make it easier to reason about what the constants mean.
Signed-off-by: Sean Cross <sean@xobs.io>
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.
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.
