On Wed, Dec 18, 2019 at 10:41:56AM -0600, Scott Cheloha wrote: > On Wed, Dec 18, 2019 at 09:54:43AM +0100, Alexandre Ratchov wrote: > > On Tue, Dec 17, 2019 at 07:09:02PM -0600, Scott Cheloha wrote: > > > The only conversion I'm having trouble with is the tsleep(). > > > The comment says "20ms", but then we use some arithmetic > > > to derive a count of ticks. > > > > > > Given > > > > > > hz * MIDI_MAXWRITE / MIDI_RATE > > > > > > You have hz ticks/second, and 32 bytes, and 3125 bytes/second, so you > > > have > > > > > > hz ticks 32 bytes 3125 bytes > > > -------- * -------- / ---------- > > > second 1 second > > > > > > = 32 * hz ticks > > > ------------- > > > 3125 > > > > > > = 1 ticks > > > > > > if hz = 100, with integer division. > > > > > > I'm not sure how to use the constants to produce a count of > > > milliseconds. Maybe I'm just having a slow day. > > > > The problem is that close() may reset the transmitter before the few > > bytes of its internal buffer is sent on the wire; there's no "wait for > > completion" feature in such simple hardware, so we just wait few > > milliseconds. > > > > The transmitter buffer size is around 16 bytes, the byte rate is 3125 > > bytes/second. So if we wait at least 16B / 3125B/s = 5.12ms, we're > > safe. Waiting 10ms-20ms is enough and is unnoticeable. > > Just to be sure we're all on the same page, the comment says 20ms is > 64 bytes' worth, and MIDI_MAXWRITE is 32 bytes, but you're saying the > buffer is around 16 bytes. Is any of this inconsistent?
Yeah, the comment doesn't match the code. 16B is what "typical" UARTs buffer. MIDI_MAXWRITE and 64 are both upper bounds of it. Waiting 20ms is safer. MIDI_MAXWRITE could be removed completely once your diff is in.
