docs(inventory): document undecoded-laser + BAR: decoder-LDD model

This commit is contained in:
2026-07-06 18:13:57 +01:00
parent 5dce1ae794
commit 830225ecf5
+37 -31
View File
@@ -8,12 +8,12 @@ Written in PLIB C, built with the TopSpeed compiler (`tsc /m scan`).
## Phases
- **Phase 1 (this commit): scan and validate.** Reads barcodes from the scanner
and prints each one, flagging whether it is a valid UPC-A.
- **Phase 1 (current): scan and validate.** Read UPC barcodes from the integral
laser and display them.
Modules: `upc` (validation), `bcode` (scanner input), `scan` (the demo).
- **Phase 2 (next): inventory database.** A DBF file keyed on UPC holding a
quantity and a name. Scan to add stock (increment, or create on first sight),
scan to consume by a quantity unit. Built on the SIBO `Dbf*` API.
quantity and a name. Scan to add stock, scan to consume by a quantity unit.
Built on the SIBO `Dbf*` API (`p_dbf.h`).
## Build
@@ -21,37 +21,43 @@ Written in PLIB C, built with the TopSpeed compiler (`tsc /m scan`).
tsc /m scan
```
Produces `scan.img`. `scan.pr` compiles `upc.c`, `bcode.c` and `scan.c` and
links them.
Produces `scan.img`. `scan.pr` compiles `upc.c`, `bcode.c`, `scan.c` and links
`scan.img`.
## How the scanner is read
## How the scanner is read (important)
On the Workabout the barcode module decodes the label in hardware and sends the
result as an RS232 stream, so there is no special barcode driver call: the app
opens the serial port and reads it. The scanner is on the top internal slot,
which is port **D**, so the device is `TTY:D` (`bcode.c`).
The Workabout MX integral laser is an **undecoded (HHLC)** scanner: it emits a
raw bar/space signal, not decoded ASCII. The hardware serial decoder in the
RS232/Barcode module handles only wands and wand-emulation scanners — the HC
guide explicitly lists "Undecoded Laser Scanner (HHLC)" as **unsupported** there.
That is why reading `TTY:D` directly returned nothing even though the laser's
own good-read LED lit.
The scan loop is blocking: it reads the scanner and prints each barcode; you
exit via the System screen. (An asynchronous scan-or-Esc loop was tried but
panicked the Window Server: on SIBO the keyboard is event-driven through the
window server, not a raw `CON:` byte read, and a proper async loop needs the
Window Server event API, whose reference manual is not in this repo's `docs/`.)
The decode is done in **software** by a barcode decoder LDD. The SDK ships
several in `\SIBOSDK\LIB`; each registers the device `BAR:`:
This Phase 1 build also prints the byte length of each decoded barcode, so the
exact format the scanner emits for a UPC can be confirmed before Phase 2 uses
it as a database key.
| LDD | Symbology |
| --- | --- |
| `BAREAN.LDD` | EAN / **UPC** |
| `BARC39.LDD` | Code 39 |
| `BAR128.LDD` | Code 128 |
| `BARITF.LDD` | Interleaved 2 of 5 |
| `BARMPLES.LDD` | MSI Plessey |
| `BARRAW.LDD` | raw / undecoded |
## Things to confirm on the device
So the flow is: `p_loadldd("BAREAN")``p_open("BAR:")` → read decoded
barcodes. **`BAREAN.LDD` must be present on the device** for `p_loadldd` to find
it (copy it from `\SIBOSDK\LIB`, or load it via the system config).
Because this cannot be compiled or run off-device, these points are written to
the SDK docs but may need adjusting once you build and test:
The current build is a **diagnostic**: it dumps every byte of each read
(`n=<count>: <decimal bytes> "<printable>"`) so the exact decoded format — length,
any type/prefix byte, terminator — can be confirmed before the reader and the
Phase 2 database key are finalised.
- **Serial line settings.** `bcodeOpen` opens `TTY:D` with the default mode. If
the scanner needs a specific baud/parity/framing, configure the channel with
`p_iow(chan, P_FSET, &config)` (E_CONFIG, `p_config.h`) after opening.
- **Terminator.** `BCODE_TERM` in `bcode.h` is set to CR (`0x0D`), the common
case. Change it if your scanner suffixes LF or something else.
- **Raw scan format.** The build prints `len=NN [text]` per scan. Confirm
whether a UPC arrives as exactly 12 digits or with extra characters (a
leading zero / EAN-13, or a symbology prefix); Phase 2 normalises to the
database key based on this.
## The `BAR:` read protocol
The precise read semantics of `BAR:` (data format, any symbology configuration
via escape sequences) live in the I/O Devices Reference manual, which is not
among the committed docs. The diagnostic build exists to establish that format
empirically. Once a scan prints, the reader (terminator handling, UPC
validation via `upc.c`) and Phase 2 follow.