Have a look at 'BT747cmd.java' which implements the CLI and which does most of the top level operations in a single file.
BT747 is multi-platform. As the serial connection depends on the platform, the class really handling the connection is set in the main class like this:
The connection is started by calling 'connectGps' of the controller ( c.connectGPS(); ). The controller will get the parameters (port, speed) form the options.
In GpsController.java there is a function called 'run' which is called on regular intervals - it is not really a thread, but almost (the SuperWaba platform does not allow threads - 'run' can not hava an indefinite loop).
This loop calls 'handler.getResponse()' which returns a "packet" from the link. That packet is then analysed for its semantics. The packet itself is built based on protocol syntax by the decoders.
GpsRxTx does the decoding, and how it does the decoding depends on the 'state' of GpsRxTx . There is for instance gps.connection.NMEADecoderState. 'state.getResponse()' is called in GpsRxTx's getResponse().
The DecoderStateFactory returns an instance of the requested decoder state which is called from GPSrxtx (newState). The default state is defined there (NMEA_STATE) and is changed when the device is put into binary mode for instance (as in MtkBinWriter in setMtkBinMode or doSetNmeaMode, depending on whether the device is supposed to enter or exit binary mode).
To be perfect, more stuff should be refactored (class names, organisation), but it is as it is.
Hi Have a look at
Hi
Have a look at 'BT747cmd.java' which implements the CLI and which does most of the top level operations in a single file.
BT747 is multi-platform. As the serial connection depends on the platform, the class really handling the connection is set in the main class like this:
if (!GPSrxtx.hasDefaultPortInstance()) {
GPSrxtx.setDefaultGpsPortInstance(new gps.connection.GPSRxTxPort());
}
The connection is started by calling 'connectGps' of the controller ( c.connectGPS(); ). The controller will get the parameters (port, speed) form the options.
In GpsController.java there is a function called 'run' which is called on regular intervals - it is not really a thread, but almost (the SuperWaba platform does not allow threads - 'run' can not hava an indefinite loop).
This loop calls 'handler.getResponse()' which returns a "packet" from the link. That packet is then analysed for its semantics. The packet itself is built based on protocol syntax by the decoders.
GpsRxTx does the decoding, and how it does the decoding depends on the 'state' of GpsRxTx . There is for instance gps.connection.NMEADecoderState. 'state.getResponse()' is called in GpsRxTx's getResponse().
The DecoderStateFactory returns an instance of the requested decoder state which is called from GPSrxtx (newState). The default state is defined there (NMEA_STATE) and is changed when the device is put into binary mode for instance (as in MtkBinWriter in setMtkBinMode or doSetNmeaMode, depending on whether the device is supposed to enter or exit binary mode).
To be perfect, more stuff should be refactored (class names, organisation), but it is as it is.