Since you're most likely to use this around a computer anyway then you
might consider simply using a computer with two serial ports and one of
the many available progams for it.  This is what I've done (with a
simple VB program) to decipher some communications between a computer
and the TI-LINK for graphing calculators.

The second easiest method, I suspect, is to simply tap the lines in a
straight through cable.  You'll then have two TX lines, and a bunch of
signal lines from each.  Use a PIC to read the signals and send them off
to the computer - no need to use any uarts.  You don't get the ability
to change bytes in the stream on the fly though.

But if you want to do this on a PIC and have the ability to change bytes
on the fly, I'd suggest you use an 18f device running with a 9.216MHz
crystal (quadrupled) which would give you 80 instructions for each bit
at 115.2kbps.  This frequency is divisible by 5 (three times) and by 3
(twice) so you can create any common bps rate exactly.  I doubt you'll
come across many devices that'll need the full 115.2k, but when you do
you'll need to ransfer data out of the pic twice as fast, or assume that
neither device is using the full bandwidth and buffer it in the PIC.

Good luck!

-Adam

Michael Milner wrote:

>I've gotten a couple good ideas here.  I'll let you know what I'm actually
>trying to do and maybe you'll be able to help me come up with something
>better.
>
>In my job, I often have to debug serial communication lines and reverse
>engineer the protocols.  I'm trying to build a generic device that can be
>used to connect to devices, sort of like a "man-in-the-middle" concept.
>
>The first device connects to UART_1, the second device connects to UART_2.
>When device_1 sends a byte, UART_1 receives it, then, as fast as possible,
>UART_2 sends it to device_2; and similarly in the opposite direction.  I
>want to make this as fast as possible so that the delay won't interfere with
>the device's communications.
>
>Using this setup, I will be able to log every byte transmitted, and also
>know which device sent it.  Depending on the baud rate of the devices, this
>may even be fast enough to change the data as it passes through.
>
>The original reason for two UARTs was because I'd worked with the 16550
>before, and I though it would be faster than a dual UART.  I also want the
>PIC to be able to determine the baud rate of the target device automatically
>(although it would probably lose a byte or two in the process)
>
>So, any suggestions on the best method to do this??  If I used two cheap
>PICs instead of UARTs, would I have the same range of supported BAUD rates?
>These target devices may use irregular baud rates.
>
>Thanks for all your help!
>
>Mike
>
>--
>http://www.piclist.com hint: PICList Posts must start with ONE topic:
>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
>
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads