feat(inventory): Phase 1 - scan and validate UPC barcodes #1
@@ -150,15 +150,34 @@ So **decoded output is terminated by CR LF** (`0x0D 0x0A`), and Code type `0x3F`
|
|||||||
enables all symbologies (UPC included). A reader should assemble bytes until
|
enables all symbologies (UPC included). A reader should assemble bytes until
|
||||||
CR/LF and strip the preamble/postamble.
|
CR/LF and strip the preamble/postamble.
|
||||||
|
|
||||||
### Still to confirm on-device
|
### Confirmed on-device
|
||||||
|
|
||||||
The `int 0xCF` calls pass their argument by value in `DX`; replicating this from
|
- `p_open(&h, "WL2:D", -1)` returns `0`.
|
||||||
C requires that `p_iow(chan, func, arg)` land `arg` in `DX` (or inline asm). The
|
- Issuing control ops **6 then 7** on the channel (`p_iow(h, 6)`, `p_iow(h, 7)`)
|
||||||
exact ordering of the config-byte writes and the two enable ops, and two helper
|
**triggers a scan**: the laser fires and decodes (green good-read LED). This is
|
||||||
subroutines (`0xD6DC4`, `0xD8DCB`), still need tracing and — crucially —
|
reproducible. The trigger is one-shot — it must be re-issued for each scan.
|
||||||
**validation on the device**, since none of this can be tested off-hardware. The
|
|
||||||
clean alternative remains the **Workabout MX C SDK** `SCANNER.DYL` header, which
|
### NOT yet solved: retrieving the decoded data
|
||||||
`SCANAPP` was built against.
|
|
||||||
|
After a confirmed good read, the decoded barcode could **not** be retrieved from
|
||||||
|
the `WL2:D` channel by any tried method:
|
||||||
|
|
||||||
|
- `p_iow(h, P_FREAD, buf)` (count-in-`buf[0]` style) — no data.
|
||||||
|
- `p_read(h, buf, len)` (synchronous, with length) — no data.
|
||||||
|
- `p_ioc(h, P_FREAD, &stat, buf, &len)` + trigger + `p_iowait()` (async) — no data.
|
||||||
|
|
||||||
|
The retrieval logic in `SCANNER.DYL`/`SCANAPP` uses relocatable code that does not
|
||||||
|
disassemble cleanly without the EPOC16 executable segment map, builds decoder
|
||||||
|
command frames (`0xff 0xee …` at `channel+4+0x13`), and performs read/write on a
|
||||||
|
**separate handle** (a driver global), suggesting the decoded result is delivered
|
||||||
|
by a mechanism other than a plain `P_FREAD` on `WL2:D` (e.g. an auxiliary channel
|
||||||
|
or an installed callback / active object). Extracting it reliably needs either:
|
||||||
|
|
||||||
|
1. The **Workabout MX C SDK** `SCANNER.DYL` header/category (what `SCANAPP` was
|
||||||
|
built against) — the clean answer; or
|
||||||
|
2. A full RE effort: parse the SIBO ROM/executable format, load `SCANNER.DYL` at
|
||||||
|
its correct segment base, and trace the retrieval path — large, and every
|
||||||
|
hypothesis costs an on-device build/test cycle.
|
||||||
|
|
||||||
## Error codes seen (from `epocdefs.h`)
|
## Error codes seen (from `epocdefs.h`)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user