serial port, tasks, GPS , and average processing power

[spamiam]

THis is the continuation of a thread under a new more specific heading.

[pdubinsky]

[spamiam]

Well, Com1 is the hardware port, and is interrupt driven, but the interrupt ONLY puts the data in the queue. The task I am suggesting is more complex than that. It will read the queue and break out the data into its component ASCII parts, and make it ready to be translated/processed by a separate task.

The second task running concurrently does the translation/processing.

As far as Com1 baud rate. Running at a high baud rate is fine but your problem is that you can not process the data as fast as it comes in. Making it come in faster aggravates the problem and requires a larger queue because the overflow is worse. If you are old enough, you may have seen reruns of the old Lucy show where she is working on a candy assembly line. It runs faster and faster and she can not keep up. All sorts of highjinks ensue. That is what is happening to you.

By slowing down the baud rate so that you JUST finish reading and processing the last piece of data as the nest set begins will give you the most time to perform all your operations.

In the dual task model I suggest, you may be able to keep up pretty well with the 38000 baud data flow. By dumping it in FAST, it will allow the greatest separation (i.e. minimal task activity overlap) between the tasks.

I am not surprised that you have not improved much on the ZX general support routines. I think they are more thoroughly optimized than the stuff on the BX. It almost seems as if the BX compiler development was abandoned in mid-stream, and it is a work-in progress, without any more progress. I did check on the stack requirements for my special data conversion modules, but maybe I did it on the BX where we have a couple of programs to measure that stuff. I am pretty sure I also used some of the reporting functions of ZBasic to compute the likely stack demands.

So, in summary, I think that 38000 baud may stress your system worse, rather than less. At the very least it requires that you have as large a receive queue as the data you will receive over the full 1 second since there is no way you will be processing as it comes in.

At a lower baud rate, you might need a smaller queue because you can come closer to keeping up!

I still think that the 2 task technique is interesting, but maybe needlessly complex.

-Tony

[pdubinsky]

[cloxwerx]

Paul,

If you would like to see some code I wrote for the BX-24 that has been cranking for over a year reading GPS sentences at 4800 baud (COM3) I'd be glad to post or email it for you. It's part of an amateur radio APRS (Automatic Position Reporting System) project I built.

I'm going to enhance the program using ZBasic since there is more RAM and 2x speed available.

Dennis
W7KMV
Tucson

[cloxwerx]

Paul,

Well, I forgot I sent you a link to the code on a previous message. Hope you get a solution running.

Dennis

[pdubinsky]

Yes, Dennis, you did and it was a great help getting started. I have worked with streaming serial devices before and your code and my code were functionally equivalent though your's was a lot cleaner and better organized than mine. (I'm a "get working - we'll clean it up later" type coder.)

The real help I got from your code was how to work with the SiRF commands. Initially, I had trouble finding any useable documentation for the SiRF binary protocol so I was stuck on determining checksums (it was a while before I found that NMEA checksums and SiRF checksums were calculated differently), etc. When I finally got the necessary docs and understood them, the project moved right along.

The version of my program as of last night first initializes the GPS by turning off all the NMEA msgs. (This receiver sends all six standard NMEA sentences every second continuously at 4800 baud as the startup default.) Then I change the GPS serial baudrate to 38,400, change the comm1 baudrate to 38,400, and start a do loop polling for the GPS for the GGA sentence (to get altitude) and then polling for the RMC sentence (for Lat, Long, Speed, Track, Time and Date.) By polling and using the increased RAM of the ZX-24 (boy, do I like the increased RAM!), I don't have any possiblity of buffer overruns.

I'll drop you a zip file of the code when I've got it tidied up. I'm also planning on posting a code snippet showing how to use polling rather than streaming with the GPS receiver. I can't be the only person who has had this problem. And, using polling, the code should work on a BX-24 after the RAM usage is pared back down to fit the limited RAM of the BX-24.

Thanks, again, for the help,
Paul

[cloxwerx]

Paul,

Thanks for the kind words about the code I sent to you. I'm glad it was of some use. I had used the MicroBlox test program that was available to exercise the GPS device I had and it generated all the hex commands that I copied out. It made it a lot simpler than calculating the checksums and parameters. I also didn't have to generate SIRF commands on the fly, so there was no need for calculation once I figured out what to do.

Good luck on your project.

Dennis