Hi
Backing off a bit to uBlox decoding:
The streams all start and end with certain characters. The easy thing to catch is the cr/lf at the end.
There is absolutely no guarantee that one string will stop, time will pass, and another one will start. It is far more likely that they all will come out in a giant blob of characters. Depending on what you have turned on, that maybe several thousand characters.
By far the best way to do this is to use a buffer. One routine shoves characters into the buffer as fast at they come in (>=115.2K baud is a really good idea ...). That's all that routine does. It is small and fast. It likely runs off of an interrupt.
Next up is a simple routine that pulls characters out of the buffer. That does not sound to complex, but it has to keep all the counts correct. It is not as easy as it sounds (don't ask how I know this ...).
Normally, you have some sort of timer that runs the higher level code. It could be as simple as a loop. It could be part of an RTOS. The net effect is the same. Code pops up, looks to see if there is anything in the buffer. If not, it goes back to sleep. If there are enough characters in the buffer that it might be interesting, it gets the buffer contents. Next check is for a full line. No full line? back to sleep.
At this point, you get into a structural decision. You can parse the line in the same code as you check it, you can pass it on down the line to something else. There are a lot of reasons for going each way. Either way, you need to parse the line.
The uBlox data is coma separated ASCII text. Each coma you find in the line equals another data field. It becomes a "next coma" / "get data" / "case statement" ... on and on sort of process.
If you are sending data to the device while you are receiving strings from it, there is the added complexity of the ACK and NACK on the string you send. How you work that into your parser is another whole set of decisions.
So, have I gone to crazy to fast?
Bob