Hi Michael,

Thanks for your reply.
I have been looking at the 16F628 and seems to be a good the candidat...
yes, I would be interested in the code.
Could you send it to my email address thomas@anza.is  ?

Thanks,
Thomas

-----Original Message-----
From: michael brown [mailto:spam-me@HOUSTON.RR.COM]
Sent: 4. febr=FAar 2003 15:46
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: 9600 baud to 7200 baud converter


On Monday 03 February 2003 04:31 pm, you 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).=20

I think this would be a good idea, may I recommend the 16F628 (about=20
US$3.50 single quantity)  I just started working with them in the last=20
week (previously 16F84).

>2. Data will only be send one way (from the GPS module) in a
> periodic one second intervall in the following format(example):=20
> $GPRMC,224009,A,6407.9020,N,02151.0298,W,001.6,152.5,080201,018.9,W*7
>E This is the standard NMEA string.Optionally, the GPS module can
> output the data also binary encoded.

70 bytes takes approx. 70mS to receive at 9600 baud and around 100mS to=20
transmit at 7200 baud.  If you try to buffer the whole packet before=20
sending, you may have to split the packet across more than one bank of=20
ram.  That shouldn't be that difficult, but it lacks a certain finesse.  =

;-) =20

Since I have more experience bit-banging received data, I would probably =

bit-bang the input, sticking the data into a queue.  Then at main=20
level, I would just pull the data and transmit it with the hardware=20
USART and no interrupts, just polling the status bit(s).  This would=20
require less than half the RAM requirement.  I would imagine 32 bytes=20
(powers of two are easier ;-) would be enough. =20

If you are interested, I have some (working) code that receives bytes=20
and then sticks them into a circular queue using TMR0 interrupts.  Then=20
the main level code liesurely pulls data from the queue and displays it=20
to an LCD.  The queue automatically uses all available ram (that is=20
contiguous and in one bank).  It's not very pretty, but it works well.=20
;-)
  =20
> I need to stick with the rs232 specs, so I will use a MAX232 or
> similar.

That sounds like the safe thing to do.  ;-)

> 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 ?

Since I would need to learn how to use the built in hardware USART,=20
maybe a day or so.  Of course I may need an extra week or two to=20
resolve some obsession that I developed, after observing some=20
"interesting" behavior.  ;-)

michael brown - IANAEE, but I've written a bunch of code in my life.

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

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