Use a Scenix!!!

They can run at 50 MIPS, you can do multiple UARTS in software,
and thus configure your UARTS to behave however you like!!! And they're
dirt-cheap. No external hardware!

Cheers,
Ben

Byron A Jeff wrote:
>
> >
> > 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