I have only a few suggestions: First, decide which is more important, short project development time (and possibly larger/more expensive solution), or smaller/less expensive/more elegant solution (and much longer product development time). Second, define your specification more fully. Do you need to be able to send data the other way as well (from the 7200bps device to the 9600 gps), or is the GPS transmission automatic and periodic. If it's periodic, then how many bytes does it send before it takes a break (and thus determine how much you have to buffer on chip as you send it at a slower rate) Are there any design shortcuts you can take? If the data is ascii text, you could receive 8 bits and send at 7 bits, which would reduce (but not eliminate) the need to buffer data. You could employ further data compression on chip (convert ascii to binary, ignore data you don't need, etc). Or decide that there's enough space on the chip to buffer the little data that is needed to be stored. The minimum solution would involve a 12cxxx chip, with a nice 11.2896MHz (possibly slower depending on the program) crystal on two pins, and rs-232 i/o on the other four pins (two in, two out), a max232 and its capacitors and a regulator. You could get rid of the max if your design didn't require the full rs-232 specification. You would need to employ at least one ring buffer, and some miscellaneous single character send/receive buffers, and 4 counters (one for each receiver and transmitter). The 11.2896MHz crystal would give you 294 cycles for every 9600bps bit you needed to send and receive. That gives you 49 instruction cycles to implement your loop. Use counters to determine whether you need to check for a new bit on either channel, or send a new bit on either channel, then branch to the specific routines that read bits or write bits. On those instances where you need to do two things at once, err on the side of sending on time and reading a loop late. If you must write two bits at once or read two bits at once, always read or write the 9600 line first, then the 7200. When a confluence occurs and you must read from both and write to both at the same time, well, I'll leave this as an excercise for the reader. :) I will say that the 7200 port will require some attention every 8 loops at minimum (more frequently when it's waiting for a new start bit) and the 9600 port will require some attention every 6 loops (again, more frequently when waiting for a new start bit). The development time for this solution would be very large in the planning stages - you wouldn't be able to sit down, write code, test, tweak, write, test, tweak, etc. But in general that isn't a good way to attack a problem anyway. Were I in your shoes, I'd probably use a chip with a built in UART for the 9600 section, and a 3.6864MHz crystal. It would give me 128 cycles per bit for the 7200 transmit/receive, which should be enough time to implement a simple ring buffer and bit-bang uart. The development time would be much less, even if you do the write, test, tweak, rinse, repeat method of development. -Adam Thomas Fleckenstein wrote: >Hi, > >I need to design a simple circuit with 2 serial ports. One port is used to read gps data @ 9600 baud. The other port is used to output these gps data @ 7200 baud. I am planning to use the PIC16F84 with two Maxim RS232 chips. I appreciate any help. > >Regards, >Thomas > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.