Fix a bug in writing SysEx messages.
At the start of a new USB packet (4 bytes), while in the middle of a SysEx, the code mistakenly
set the buffer length to 4, not the target length. As a consequence, the 3rd and 4th bytes from
the last packet were included, after every byte of the SysEx after the first packet of three.
The fix is simple, as it was just a typo, as can bee seen from the other branches in the same
section of if/else statements: At the start of a new packet, the code should set up the target
length... the buffer length should be left at 2 (as set on line 180).
- separate connect/disconnect handling
- hub work with full speed, but doesn't seem to work with Low speed
device (with mcb1800)
- need to update msc host after migrating from isr to xfer_cb (blocked
at inquiry)
define __USE_CMSIS instead of __USE_LPCOPEN will have startup enable FPU
on startup properly. Although it is only relevant to lpx43/40 series,
change all to __USE_CMSIS for consistency
This is helpful if you have already encoded audio data and want an
efficient way to send it. However, this approach is NOT THREADSAFE so
far and works realiably ONLY IF tud_audio_n_write_ep_in_buffer() is NOT
called form an interrupt!
b_bytes_copied was pointer with NULL value instead of
plain variable.
NULL pointer was passed to audio_tx_done_cb() and dereference
as well.
Now variable is not a pointer.
Buffer for TX and RX FIFO was not taking into account
size of element leading to out of bound access.
audio_tx_done_type_I_pcm_ff_cb() reported copied bytes was not returning
correct value number if channels was omitted in computation.
Transfer size calculation uses simpler arithmetic.
In several place p_desc_end calculation was not taking into account
that starting pointer (_audiod_itf[idxDriver].p_desc) was pointing
past interface association descriptor.
It would result in accessing random memory.
