>
> I am trying to do both MIDI recieving and sending on a PIC. At the moment I
> am considering the use of external UARTs. One problem is MIDI System
> messages. MIDI system messages are used to transmit such info as MIDI timing
> and other messages that need to be transmitted quickly. The MIDI spec allows
> System realtime messages to be inserted in the middle of other messages to
> avoid delays.
>
> As I am intending to use multiple external UARTs I would really like to take
> advantage of their FIFO's to allow for longer gaps in polling. The UART I am
> currently looking at is the National Semiconductors Dual UART as I would
> need less pins (or less multiplexers). This unit is equipped with 16 byte
> FIFOs on both inputs and outputs. The problem is if I have 16 bytes in the
> FIFO and recieve a System message the only thing I can do is stick it on the
> end of the FIFO. This means at 31250 baud it could take up to 0.005 seconds.
> While this delay shouldn't matter for normal messages it could easily be a
> problem for System messages which carry such info as timing messages (1
> timing message sent every 1/16th of a note) and Start\Stop messages.
>
> I could not use the FIFO but this means much more polling. Ideally I would
> like to be able to constantly keep the FIFO's full so I can ignore a chip
> for a fair amount of time with no consequences. What I would really like is
> a UART where the FIFO is software accessible. Thus if a system message
> arrived I could read out the FIFO, put the system data in first and refill
> the FIFO. It would also be fine If I could simply shove a byte on the front
> of the queue.
>
> The only way I can see to achieve anything like this on the NS DUART is to
> keep a copy of the FIFO in the MCU's memory. Thus, I could reset the FIFO,
> and reload it from my copy. This would mean monitoring the UART, triggering
> an interrupt on send/recieve and updating my FIFO copies on the interrupt.
> This is something I really don't want to attempt even if it is possible (and
> I'm not so sure it is).
>
> Before I start figuring out the resource usage of doing software FIFOs for
> sending, can anyone suggest a better way of doing it.

Hi Thomas,

Are you getting my messages on this subject? I've posted a couple but no
responses.

Just another reason to look into programming a PIC to be a smart UART. It has
the memory for a FIFO. It has the smarts to be programmed to do part of the
MIDI routing by changing the channel on the UART. Now it can pic (pun intended)
out System Messages and route them before regular message simply by having
another small queue for its messages.

So in short, get a 12C508 and wire it up as such:

Power, Ground, 4 Mhz crystal takes 4 pins.
MIDI in, out takes two pins.
I2C type clock and data takes 2 pins.

All 8 pins of the part are used and by using a modified I2C protocol (or the
actual protocol in fact) the master controller can communicate with all the
uarts.

I'll post more on the subject later, but the bottom line is that the tasks
you want to do require more smarts than dumb UARTS (even with FIFO's) can
handle. Since you're going to have to have some smarts in front of the UARTS
anyway, why not simply make the UART smart by doing it in software.

BAJ