avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] General programming question/GPS parsing


From: Curtis Maloney
Subject: Re: [avr-gcc-list] General programming question/GPS parsing
Date: Wed, 02 Mar 2005 15:27:59 +1100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

wbounce wrote:
I am think of trying to parse a GPS feed which is transmitted at 4800
baud. It can send 7 "sentences" of a max of 80 bytes to a potential of
560 bytes every second. Then I need to parse the data. I am concerned
about how much time and ram it will take to do all of this. With only 4K
of ram space how would you handle this. I was think of using a round
robin buffer approach but then that complicates the parsing with having
to worry about wrapping. Or should the program be fast enough to process
the 1st 80 bytes by the time the 2nd sentences is done coming in? I am
running a ATMega 128  16MHZ. Using WinAvr C and was think of using the
AVRlib  standard strcmp,strsep,strtok_r etc.

Well, let's look at the real world timings, here. At 4800bps, you have just over 2ms to parse each BYTE of incoming data. In that time, a 16MHz AVR will process something approaching 3,333 instructions.

That's PER BYTE. Now, I'm not sure how much work you need to do on these "sentences", but I'm betting you could get a lot of it done well before the next byte is due.

I agree that double-buffers of 80bytes each is a good idea. And in the time it takes you to receive 80bytes, you have well over a quarter of a million instructions to get things done with.

Has anyone done this and kept control of a robot at the same time?

Maybe somebody has. How much trouble you may run into depends on a lot of things, such as complexity of parsing the GPS data, complexity of "controlling" your robot, and how you schedule tasks.

Are there timing values for the library routines?

That is a very excellent question. I'm willing to bet a good deal of effort has been made to make these routines size and speed efficient. Perhaps you'd like to try some elemental timings?

--
Curtis Maloney
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]