Size of received MIDI data from USB

[stever]

Hi Thorsten (and anyone else watching!),

I'm making some progress with my MIDI device but have a question regarding the data coming via the USB port to the PIC18F2550. I've been examining the MIDINator code to get an understanding of how the data arrives - nice and easy as it can send the MIDI data to the serial port.

As I mentioned in my first thread, the GetEP1 handler is interpreting the whole 64 byte buffer when there is only one valid USB-MIDI packet in the buffer. The debug code prints all 16 packets out, but (by luck or design?) only the valid packet is passed to a real MIDI device (basically because a first byte of 00 is invalid for USB-MIDI packets).

I've got the MIDINator code compiling under C18 and compatible with the bootloader, so it's easy to try things out. By capturing the byte count, it seems that the Endpoint is actually receiving all 64 bytes. As it is based on your own code, I thought you may have an insight into what is going on.

I was expecting a byte count of 4 for a single packet - or does the USB engine always get a buffer full of data, padding with zeros as necessary? This seems unlikely as there was no mention of it in the MIDINator article.... although I believe I saw the same behaviour in the original MIDINator firmware.

Any comments welcomed, Steve.

[TK.]

Hi Steve,

I can confirm this - the byte count always corresponds with the "bytes per packet" definition, which has been made in the OUT endpoint descriptor. I guess that the actual package size is full under control of the USB host, so it might be a windows specific issue. I believe that the unused buffer area will always be patted with 0x00, because I never noticed something else (e.g. artefacts from previous transfers)

In my own class driver, zero packages will be simply ignored:

; --------------------------------------------------------------------------
; IN:  expecting pointer to Tx packet in FSR2
; OUT: request retry if ZERO flag set!
USBCLS_MIDISend
        movf    INDF2, W                ; ignore zero packages
        andlw   0x0f
        bnz     USBCLS_MIDISend_Ok
[/code]
However, I see the point, that it makes CIN=0 packages useless for future extensions.
Best Regards, Thorsten.

[stever]

I can confirm this

...

<snip!>

...

However, I see the point, that it makes CIN=0 packages useless for future extensions.

Wow!... I wasn't expecting that, although I couldn't understand what I was seeing unless this was the case. As you say, CIN=0 becomes useless.... I wonder if anyone has tried this under Linux? I'll see if I can find a system to try, though I've never played with MIDI on Linux before.

Thanks for the response, Thorsten.

Regards, Steve.

[stever]

I can confirm this - the byte count always corresponds with the "bytes per packet" definition, which has been made in the OUT endpoint descriptor. I guess that the actual package size is full under control of the USB host, so it might be a windows specific issue. I believe that the unused buffer area will always be patted with 0x00, because I never noticed something else (e.g. artefacts from previous transfers)

Just thought of something else.... good to hear that you haven't seen any "old" data - that makes things a little simpler. But have you ever seen more than one packet arrive in a single IN transfer? If not, is there a problem with making the input buffer just 4 bytes? Even if you have seen more than one packet in a transfer, would a four byte buffer be a problem?

Steve.

[TK.]

Just thought of something else.... good to hear that you haven't seen any "old" data - that makes things a little simpler. But have you ever seen more than one packet arrive in a single IN transfer? If not, is there a problem with making the input buffer just 4 bytes? Even if you have seen more than one packet in a transfer, would a four byte buffer be a problem?

I tried different buffer sizes, but finally I decided to use 64 bytes because of following reasons:

- in chapter 5.8.3 of USB2 spec it's stated, that "The USB defines the allowable maximum bulk data payload sizes to be only 8, 16, 32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints"

This is a weak requirement, as they don't specify the minimum package size, but to be at the secure side, at least 8 bytes should be prefered as maximum size

. 64 bytes are used in the the USB midi spec descriptor example, and it cannot be excluded that any OS gets use of this possibility in order to gain bandwith.

So, why reducing the USB slave capabilities?

- it cannot be excluded, that the legacy driver wants to send more than one MIDI event package, if it is directed to multiple "midi cables" (= MIDI Out Ports), or if MIDI events are sent to more than one "cable" concurrently for best synchronous timing (e.g. MIDI Clock distributed to multiple devices).

Same question: why reducing the USB slave capabilities?

Since the transmission of 64 bytes doesn't really hurt (in distance: it could improve performance), I don't see a reason for reducing the EP buffer size

Best Regards, Thorsten.

[stever]

It was late last night... I'd seen that statement on buffer sizes but forgotten it. It's a bit weak, as you say. I also answered my own question this morning... a sysex message appears as multiple packets in a single transfer.

So it comes down to, in Windows at least, that the 00 CIN is not usable with the standard drivers.

Thanks once again for your assistance, Thorsten.