Since the data is only going in one direction the code is vastly simpler.

If you haven't done bit-banging UART stuff before it will probably take
you many hours to put out the first one.  When I was doing bit banging
serial stuff ( http://www.ubasics.com/spic/ ) I started with code from
"Serial Pic'n", which has quite a few routines (full duplex, half
duplex, interrupt, auto baud, etc) and modified it for my own use.  In
order to make the code easier to understand I used excel to create
simplified program execution flow charts (with full code) since the code
had to be counted to the cycle.  The excel sheets, code, and preliminary
datasheet for my device are on the above web page.

The program you need to make is simpler in many ways, I suspect you
could even get away with a 3.6864MHz crystal without too much work.  Put
it, the max232, and the caps & crystal in SMT on two sides of a pcb and
you could fit it into a db-9 shell.

-Adam


Thomas Fleckenstein wrote:

>Hi Adam,
>
>Thanks to you and the others who provided feedback on that topic.
>
>1. I would like to go for the smaller/less expensive/more elegant solution but as usual, there is not much time left
>   for showing a prototype. I probably will use a chip with a built-in USART to simplify things (this is probably
>   a much more expensive solution compared to the solution you mentioned which uses a Pic12cxxx device).
>2. Data will only be send one way (from the GPS module) in a periodic one second intervall
>   in the following format(example):  $GPRMC,224009,A,6407.9020,N,02151.0298,W,001.6,152.5,080201,018.9,W*7E
>   This is the standard NMEA string.Optionally, the GPS module can output the data also binary encoded.
>
>I need to stick with the rs232 specs, so I will use a MAX232 or similar.
>
>As I already mentioned, i like your idea with the PIC12cxxx devices a lot. How much time do you think
>it would take to develop a stable firmware ?
>
>
>Thanks again for your great feedback.
>
>Regards,
>Thomas
>
>
>-----Original Message-----
>From: M. Adam Davis [mailto:adampic@UBASICS.COM]
>Sent: 3. febrzar 2003 15:20
>To: PICLIST@MITVMA.MIT.EDU
>Subject: Re: 9600 baud to 7200 baud converter
>
>
>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.
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.
>
>
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body