Alan B. Pearce wrote:
>> $GPRMC,"time"(6bytes),A,"long"(8bytes),N,"lat"(9bytes),E,005.1.2.......
>> $GPRMB,A,......"speed"(6bytes)V*71
>> what i'm thinking of doing is the check for the C character (ASCII)
>>     
>
> Personally I would search for the "$GPRM" and then save from the next 
> character to the carriage return, this way you get the full length of both 
> lines.
>
>   
>> then read 86 bytes after the C character (from the first ,
>> till the 1 in 71)
>>     
>
> No, I would save them as two separate lines by looking for the beginning of 
> a line (as above) and then saving all characters up to and including the 
> carriage return line terminator. When reading back you can then use the CR 
> character as the end of message block terminator identification. If you need 
> to send the string out to a device that understands an NMEA string, then you 
> just precede it with "$GPRM" and then the stored string. After a CR send 
> another "$GPRM" and the next string.
>
>   
>> save them then sort them in some sort of table or buffer where
>> i take only the bytes of the time, long, lat and speed before
>> transmitting them to the ram(24LC64) via the I2C bus.
>>     
>
> Umm, be careful, the 24LC64 is not a RAM, it is an EEPROM, and has a 
> significant write time which you need to wait before sending the next 
> message. Also I think you need to have the message set as a multiple of a 
> fixed number of bytes, possibly 8, maybe more, as it does block writes. It 
> may take you several blocks to write one line of the GPS message. Note that 
> you will end up loosing a percentage of the EEPROM capacity because of the 
> block structure of the writing algorithm unless you do some sneaky 
> bookkeeping of the address pointers when writing. There is no problem when 
> reading.
>
> One way to get around the problem of block write times is to use a FIFO 
> buffer between the serial receive routine and the EEPROM write routine. With 
> the serial data coming about once per second there should be enough time to 
> write all the data to the EEPROM when using a properly constructed write 
> routine that takes account of the delays. The FIFO can also be used to 
> buffer the correct number of bytes for a block write to the EEPROM so you do 
> not loose some of the capacity.
>
> Another way is to use two (or more) EEPROM devices, and write the first 
> block to the first device, the next block to the same address in the second 
> device and then the third block to the next address block in the first 
> device, and so on. This requires some bookkeeping in the micro. The write 
> routine still needs to take account of the delay times for the EEPROM, but 
> interleaving devices like this can give significant speed improvements (as 
> well as extra capacity if needed) where this is needed.
>
> There other devices which do not have the write time constraints of an 
> EEPROM, called FRAM devices, but I don't have the info or links on them 
> handy. 
>
>   
The other devices are made by RAMTRON. Indeed, there are NO write delays 
whatever. These
parts are available now from Mouser Electronics (Ft Worth, TX).

--Bob
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist