Home |
Search |
Today's Posts |
#11
![]() |
|||
|
|||
![]()
"pilot" wrote in message
oups.com... Thank you Meindert, it clarifies the hardware part. Now, for the software : can a normal computer (800 Mhz) handle serial data coming at 488 bauds from a gps, and an other one, coming at 38400 bauds, from an AIS port, at the "same time " ? Easily!! Example: our multiplexers handle 6 channels at the same time, 4 at 4800 baud, 2 at 38400 and 57600 respectively. And all on an 8MHz processor. I have run 486/66 computers with serial ports at 375,000 baud without a problem. Since I will probably take only the lat & long, HDOP and number of sat's from the GPS, I will leave all satellites related sentences (GPGSV) aside. Do you think I will be better to do some timesharing between the ports, or let them fire the comm events whenever they happen, no matter where they are from, I mean from one port or the other ? I have never tried anything of this nature. That's why I ask. There's no such thing as timesharing between com ports. You open two comports and you either run a task/thread per com port or you run a fast loop that periodically calls readfile() to get any buffered characters. The com port drivers in Windows (do you run windows ?) buffer a few kb of data. But the best way is to run a thread per com port and let each thread assemble characters into a complete sentence and then create a message that passes a pointer to the sentence, which is handled by the main task of your program. To play it safe, you can implement a sentence queue but you'll find this queue get's hardly filled up unless the main part of your software is terribly slow at updating charts, for instance. Meindert |
Reply |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Bluetooth depth finder? | General | |||
NMEA - Bluetooth | Electronics | |||
Bluetooth comunications in a boat | Electronics | |||
Bluetooth GPS | Electronics | |||
AD: Bluetooth enabled NMEA multiplexers | Electronics |