NMEA parsing - baud rate and instruction time

[Guest]

Hi,

I know this topic has been done to death, but hopefully this will be a quickie.
I'm new to CCS, although I have used PICBasic and C in general before.

A common method for parsing NMEA sentances seems to be to receive the first byte, check it, receive the second, check it, and so on, until you are sure you have the correct sentance. You can then either discard and start looking for another sentance, or keep on reading in the data.

My question concerns how processing of incoming data you can do without missing subseqent serial data. For instance, if running at 9600 baud, you receive a byte and check if it is '$'. If it is, you have found the start of a sentance, and want the next character - but by the time you have made this comparison, is there still time to receive it?

[SherpaDoug]

The math is easy. If you are running at a 4MHz cyrystal speed you get 1 instruction every 4 cycles, so 1 MIPS or 1us per instruction.
If you use the CCS software UART it returns a byte at the start of the STOP bit. So you have the length of the STOP bit to do processing. 9600 baud means each bit is 1/9600 seconds long or 104us or 104 instructions. That is plenty to see if a byte is "$" and either put it in a buffer or punt to the seeking-start-of-message state.
If you have the luxury of a hardware UART it probably has a 2 character buffer. That gives you 104us per bit x 2 characters x 10 bits per character = 1667 instructions! That is enough time to tie your shoes, write a sonata, and maybe even do a floating point calculation.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

Depends totally on the speed of the chip.
You have just fractionally under two character times available in the hardware buffer, and for safety, say one. At 9600bps, this gives you just over 1mSec. On a chip at even 4Mhz, this is 1000 instruction times, while on one at 40MHz, it is 10000 instruction times. Even written carelessly, such a test, should be doable in under 100 instructions. Even better though, use the serial interrupt, and buffer the data, and if one test takes longer (perhaps actually decoding the numeric value), this won't matter.

Best Wishes

[newguy]

What I do (I also parse NMEA gps data) is to receive one full NMEA sentence before I do any examination or manipulation of the data itself. Basically if I receive a '$' I know that an NMEA sentence is starting (so I reset the receive buffer to fill from the beginning), and if I receive a CR LF, I know I have a complete sentence in my receive buffer. It is then 'safe' to examine it.

I have a GPS receiver that can be configured to output as many or as little NMEA sentences as you wish. I have it configured to output only one. If your receiver can't be configured to only output one sentence, then the PIC is probably more than fast enough to do the processing you require on the fly, as SherpaDoug and TTelmah have already suggested.

[Guest]

Thanks - You are right it is a simple calculation, it was the "1 instruction every 4 cycles" part that I was unsure about. Presumably some commands take more clock cycles to complete than others?

Cheers,

Ben

[Guest]

Using the hardware USART ...

If I use the software USART, as long as I am ready to receive again by the end of the stop bit I am ok, giving me 104uS @ 9600 baud.

As far as I can see, the code written remains the same - the compiler generates hardware USART code if #use rs232... specifies the hardware pins, or implements a software solution if not.

Does it also set the RX buffer up as a circular buffer, so it contains the last 2 bytes to arrive constantly? I know previously using ASM and basic I have had to clear the buffer manually, or risk the PIC reseting...

[SherpaDoug]