-
Notifications
You must be signed in to change notification settings - Fork 47
SerialPortHandler
The simplest way to add support for a new device to the Hardware Driver is via a driver module. A driver module is a class in the SPH namespace that inherits from SerialPortHandler. A driver module is the bridge between a particular device and the POS interface. It must read information from the hardware device and forward appropriate messages to POS as well as accept POS messages and write appropriate info to the hardware device. The name is a bit of an anachronism. There's no requirement that the device specifically be connected to a serial port.
The driver module class must implement two functions:
- void Read()
- This method is responsible for reading from the device. It's running in its own thread and in most cases never exits.
- void HandleMsg(string msg)
- This method is called when POS passes a message (msg) to the hardware driver. The parent thread will call HandleMsg on all loaded driver modules for every message received. A driver module may ignore any messages not relevant to its particular device.
When the driver needs to send a message to POS, it should call:
- parent.PushOutput(string msg)
- The parent thread is responsible for maintaining a communication channel back POS.
POS currently sends the following messages to the driver.
- goodBeep requests a single beep. This is traditionally a scanner-scale function.
- beepTwice requests two beeps. This is traditionally a scanner-scale function.
- errorBeep requests three beeps. This is traditionally a scanner-scale function.
- twoPairs requests two beeps, a pause, and two more beeps. This is traditionally a scanner-scale function.
- rePoll requests the scale's current status.
- termReset requests a soft reset from the card terminal.
- termReboot requests a full restart from the card terminal.
- termManual requests manual card entry mode on the card terminal.
- termApproved requests the terminal display an approval message.
- termSig requests the terminal collect a digital signature. Additional characters may be appended after the "g" for a message to display while the customer signs.
- termGetType requests the terminal display a credit/debit/etc selection screen without an EBT option.
- termGetTypeWithFS requests the terminal display a credit/debit/etc selection screen that includes an EBT option.
- termCashBack requests the terminal display a cashback selection screen.
- termGetPin requests the terminal go into PIN input mode
- termWait requests the terminal show a message indicating its waiting for additional information from POS.
POS currently understands the following messages from the hardware driver.
- Any string of strictly digits will be interpreted as a UPC.
- S11WWWW where WWWW is weight in hundreths of a pound (e.g., 1234 = 12.34 lb.)
- S144WWWW where WWWW is weight in hundreths of a pound. The duplicate command is an artifact of Datalogic's protocol.
- S140 scale is not ready
- S141 scale weight is not stable
- S142 scale weight exceeds maximum capcity
- S145 scale weight is less than zero
- TERMAUTODISABLE and TERMAUTOENABLE. This indicates whether the card terminal driver is in auto mode. In auto mode, the driver advances from one step to the next on its own. When auto mode is disabled, the driver only advances to the next step after receiving a message from POS (see above). Non-auto effectively creates a handshake and is generally more reliable.
- TERMCLEARALL drop all card information collected thusfar and start over
- TERM:Credit chosen card type is credit
- TERM:Debit chosen card type is debit
- TERM:Gift chosen card type is gift
- TERM:EbtFood chosen card type is EBT, food side
- TERM:EbtCash chosen card type is EBT, cash side
- TERMCB:X set cashback amount to X. X is denominated in cents (e.g., 100 = $1).
- PINCACHE:DATA where DATA is an encrypted PIN block. This needs to be forwarded by POS to the card processor.
- PANCACHE:DATA where DATA is an encrypted card data block. This needs to be forwarded by POS to the card processor.
Additional messages may be added in either direction (POS => hardware driver or hardware driver => POS) but corresponding functionality needs to be added to POS.