[sdiy] Techniques for Multiplying MIDI Clock frequency?

[mskala at northcoastsynthesis.com]

On Fri, 24 Dec 2021, Brian Willoughby wrote:
> On Dec 24, 2021, at 08:40, mskala at northcoastsynthesis.com wrote:
> > That was my own PIC24 host code, with no operating system as such.  The
> > device on the other end of the connection was an Akai "MPK mini" USB-MIDI
> > keyboard.
>
> Ah. I see. So, when you talk about throttling the rate you're talking
> about Host code, which is totally within the USB spec, I suppose (unless
> they require lots of polling somehow).

Sure - I don't think the host is ever *required* to poll a bulk endpoint,
let alone more than once per frame.

> Maybe not. The PIC18 that I worked with is limited to Device only. It
> cannot be a Host. The electronics would be vastly different. I suppose
> it's possible that the PIC24 peripheral register set could be a strict
> superset, but I assume they're very different peripherals due to the
> additional capabilities of the PIC24.

Interesting.  I several times found answers to questions in the PIC18
discussion forums that seemed applicable to the PIC24 also, but I guess
that could simply be because of similar design philosophy, and
similarities in the driver software at the higher level.

> One mystery I've never dug in to is this: What happens when a USB Host
> schedules a packet for a USB Device and that device responds really
> slowly (due to poor firmware optimization)? I know that if the delay is

I think this is in section 7.1.18 of the USB 2.0 standard.  The device is
expected to reply pretty much immediately, if it's going to reply at all.
For low and full speed, the maximum allowed is either 6.5 or 7.5 bit times
depending on whether the device has a detachable cable.  Many more bit
times, but still a small amount of real time, for high speed.  If the
device takes longer than allowed, it runs the risk of colliding with the
host's next packet, and would be better off to keep silent (which *will*
be an error).

> The answer is partly made evident because most USB Device firmware
> stacks require the code to set up the complete data for a packet in
> advance, so that the hardware interrupt can immediately enable DMA to
> transfer the data faster than the processor could handle in code alone.

Bearing in mind that the signalling is synchronous, there can't be a delay
in the middle of a packet without corruption.  It's not like a UART
connection that resynchronizes on every byte and could potentially have
arbitrary pauses between bytes.  Once the device starts sending a packet,
then whatever voltages exist on the bus over the next however many
microseconds *are* the contents of the packet whether the device was
driving those voltages or not.  And if it doesn't start sending the packet
at all when the host was expecting it to, I guess that depends on the host
but it seems like a standards-compliant host should have given up almost
immediately.  The whole bus can't wait for one device.  Devices that
cannot send data on schedule are supposed to send NAKs on schedule, not
send nothing or break the schedule.

> However, Control endpoints have Host query commands that switch between
> OUT and IN during a transaction, and I've wondered what would happen if
> firmware grabs a piece of data for the Control endpoint from a slow
> peripheral, and thus delays the Control endpoint timing.

That seems like it should be a delay at a different level.  The control
in transfer looks something like this:

host        device

SETUP
DATA
            ACK
IN
            DATA
ACK
OUT
DATA (0 length)
            ACK

If the device needs more time to prepare the data for the IN, it is
allowed to send NAK to indicate it's not ready, but the NAKs themselves
have to be sent promptly:

host        device

SETUP
DATA
            ACK
IN
            NAK
IN
            NAK
IN
            DATA
ACK
OUT
DATA (0 length)
            ACK

I would expect most devices nowadays to handle this with hardware
that will automatically send the NAK if the firmware has not yet
instructed it to give a different response.  7.5 bit times at full speed
is not a lot of time for a microcontroller to handle an interrupt and
decide whether to start sending data.

At the higher level, I think the number of NAKs allowed may be unlimited.
The standard says this phase of the control transaction is handled like a
bulk transfer, in which NAKs would be unlimited.

> I've had clients who designed their own USB Device prototypes that were
> so messed up that they took out my client's laptop - or at least took
> out the USB ports. This had more to do with external supplies for the

A straightforward power short on the USB port will often shut down a
laptop.  Usually, they can boot up again afterward.

-- 
Matthew Skala
North Coast Synthesis Ltd.