>$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. 

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