Skip to content

Hardware Driver

Andy Theuninck edited this page Aug 26, 2015 · 3 revisions

The hardware layer is theoretically swappable but in practice everyone is using the NewMagellan driver. This page discusses its structure.

The driver is written in C#. The main driver application loads one or more modules of class SerialPortHandler. Each modules is responsible for managing actual communication with a hardware device. Which modules should be loaded and which device files (e.g., COM1, /dev/ttyS0, etc) they should attach to is configured in ports.conf.

Communication between POS and hardware devices all flows through the main driver application. Messages traveling from POS to a hardware device are submitted directly to the driver via UDP. The main driver application then forwards the message to every SerialPortHandler module. The individual modules can then do something to the actual hardware device (or simply ignore the message if it's not relevant to that piece of hardware).

Communication from hardware devices to POS takes a different path. Unlike the driver process which is always running and hence always listening for messages over the network, the POS process only runs long enough to draw the page then exits. When a SerialPortHandler wants to send a message from (or about) a hardware device to POS, it passes the message to the main driver application. The main driver application then creates a new file in the ss-output directory containing the message. POS constantly runs AJAX requests in the background that check for new files in ss-output and read their contents. POS deletes these files after reading and receiving their messages.

The Datacap SerialPortHandler modules use a different communication path. Their interactions are much less complex. Communication is always initiated by POS. This eliminates problems related to whether or not POS' process is actually running. A message will never originate from the hardware end when POS' state is unknown. Additionally, each message from POS will receive exactly one message back in response. To facilitate this, those SerialPortHandlers listen for HTTP requests on port 8999 (note: this means you cannot run more than one of these modules concurrently without some adjustments). AJAX POSTs directly to the SerialPortHandler are the easiest way to send messages and receive back the related responses. The HTTP implementation is extremely basic: all headers are ignored, things like x-form-urlencoded don't work, etc. The body of the request is all that matters.

Clone this wiki locally
You can’t perform that action at this time.