This changes the internal buffering to the raw 4-byte messages. The
conversion of the messages to a byte-stream moved to the read/write
methods.
It adds a raw packet interface to send and retrieve the raw 4-byte
USB MIDI message:
static inline bool tud_midi_receive (uint8_t packet[4]);
static inline bool tud_midi_send (uint8_t const packet[4]);
MIDI USB packets carry virtual cable/wire/plug data in the packet header,
which cannot be exported in the byte-stream interface. The raw packet
interface allows to send and and receive the complete USB message.
This makes `rx_buffer` and `tx_buffer` *pointers*
volatile in order to avoid caching them in a register.
The original notation meant "a pointer to a volatile value"
(equivalent of `volatile uint8_t *`). This resulted in
`while(rx_buffer[ep_num] != NULL) ;` loop to get stuck
forever, even though the IRQ handler set the `rx_buffer[ep_num] = NULL`.
Since endpoint 0 is used for control requests, it doesn't have a class driver attached to it. As such, the corresponding `_usbd_dev.ep2drv` entry points to driver `0xFF`, which is invalid and this makes the `TU_ASSERT(drvid < USBD_CLASS_DRIVER_COUNT);` line fail, and eventually causes an endpoint stall. So as-is the stack cannot respond to any endpoint requests on endpoint 0.
However, standard requests on endpoint 0 do not need a class driver to produce a valid response. This commit changes the order of execution so that the assert is only checked if the endpoint is not 0.
Queue table has pointers instead of data os_event structs.
This resulted in crashes when elements were put to queue and
overwritten variables that were just after mpool desiged
for queue.
Due to an error, we were double-advancing the FIFO buffer. The end
result was that the second half of most reads were getting ignored.
This wasn't found during earlier testing because only 64-byte buffers
were tested.
This corrects this error by avoiding double-advancing the buffer.
Signed-off-by: Sean Cross <sean@xobs.io>
