USB host OTG barcode scanner on an embedded controller

Your embedded controller has one micro-USB port, your barcode scanner has a USB cable, and you want the decoded code to arrive in your own program instead of in a text box on a PC. That works, with two conditions: the port must run in USB host role through an OTG adapter, and the scanner must power itself, because a port like this carries no 5 V on VBUS. This guide gives you the wiring order, the power check that predicts whether a given scanner will enumerate, an enumeration test that does not rely on the misleading status LED, and the quickest path to reading the decode with a USB host library's keyboard example.

Host role, device role and what OTG changes

A USB port has exactly two roles. The host controls the bus: it polls devices, schedules traffic and, on a PC, supplies 5 V on VBUS. The device, your scanner, answers. Most controller boards wire their micro-USB port for the device role by default, because that is how firmware gets flashed from a PC.

USB On-the-Go (OTG) lets a dual-role port switch sides. The OTG adapter is not just a shape changer: its micro-USB plug carries the ID pin grounded, and that grounded pin is what tells the controller to come up in host role. The differences between host and device operation on industrial ports, and the workarounds for fixed-role hardware, are laid out in host mode versus device mode on industrial USB ports.

If the controller only ever attaches scanners and never presents itself as a device on that link, it acts as an embedded host: same wiring, no role switching to manage in code.

What you need

• A controller whose micro-USB port supports host operation through OTG.
• A micro-USB male to USB-A female OTG adapter with the ID pin grounded in its plug. A plain extension cable leaves the port in device role, so the adapter is the first thing to check.
• A barcode scanner with a USB device port and its own power: an internal battery or an external power input.
• The scanner's cable. In the setup followed here that is a USB Type A male to Type B male cable, with the B end into the scanner.
• A serial console on the controller, so USB attach and detach messages are visible.
• A USB host library with a keyboard example. The USB_Host_Library_SAMD package and its KeyboardController.h class are the usual starting point on these boards, and they ship examples for other device classes too.

Still choosing the controller side? A comparison of USB host hardware options for embedded controllers covers add-on host shields and boards with native host ports.

Where the OTG adapter goes

The chain, scanner to controller: the Type B end of the scanner cable into the scanner's device port; the Type A end into the adapter's USB-A socket; the adapter's micro-USB plug into the controller's receptacle.

The adapter belongs at the controller end. The grounded ID pin lives in the adapter's plug, and only the controller's dual-role receptacle reads it. An adapter placed at the peripheral end selects nothing, so the port never enters host role.

A battery-powered phone is the classic test device. If a phone enumerates on the same adapter while the scanner stays silent, the wiring and role selection are proven, and the scanner is waiting for power that the port does not supply. That failure mode is the subject of the next two sections.

The power rule: why the port supplies nothing

On the controller class discussed here, the micro-USB host port carries no 5 V on VBUS, whatever powers the board itself. The data lines still work, so signalling is unaffected by the missing power pin; a device that needs bus power simply never gets any.

USB 2.0 allows a peripheral to draw up to 100 mA before it is configured and up to 500 mA afterwards, at 5 V nominal (4.75-5.25 V at the device). A bus-powered scanner plugs in, waits for power that never arrives and never enumerates. A scanner with an internal battery or an external power input runs its scan engine from its own supply and needs nothing from the port except data.

Two consequences follow. The scanner's battery will not charge over this link, so it charges from its own charger or any powered USB port. And if you later move to a host port that does source VBUS, a bus-powered scanner within those current limits attaches normally. For adapters and cables that do carry power, the common traps are collected in power and interface checks for USB adapters.

Worked example: battery scanner versus bus-powered scanner on a no-VBUS port

Inputs, with their sources: available host-port current is 0 mA, because the port supplies no 5 V on VBUS (stated by the board vendor for this controller class and visible in the dead power pin); bus-powered peripheral demand is up to 100 mA before configuration and up to 500 mA after, at 5 V nominal (USB 2.0 baseline); scanner demand is 0 mA, because the scanner in this setup runs on its internal battery.

Rule, in words: an attachment succeeds only if the peripheral's VBUS demand never exceeds what the port can source, at enumeration and afterwards.

Arithmetic:

• Bus-powered scanner: shortfall at enumeration = 100 mA - 0 mA = 100 mA. The power that cannot be delivered is 5 V × 0.100 A = 0.5 W, rising to 5 V × 0.500 A = 2.5 W once configured. With 0 mA on offer, the scanner sits unenumerated.
• Battery scanner: shortfall = 0 mA - 0 mA = 0 mA. Nothing is missing, so attachment depends only on the data lines, which the port does carry.

Decision: on this port the threshold is 0 mA. Any scanner that draws anything from VBUS fails, so it must run from a battery or an external input. Move to a host port that sources the full 500 mA allowance and a bus-powered scanner inside those limits attaches normally, with up to 5 V × 0.5 A = 2.5 W of bus power instead of none.

Wire it and prove enumeration, step by step

1. Power the controller from its normal supply, terminal block or DIN-rail power module, and open the serial console you use for printing.
2. Plug the OTG adapter into the controller's micro-USB receptacle.
3. Connect the scanner's cable: Type A end into the adapter's USB-A socket, Type B end into the scanner's device port.
4. Power the scanner. Switch its battery on or feed its external input; a battery scanner with a flat battery fails here exactly like a bus-powered one.
5. Replug the cable at the adapter once or twice. Each cycle should print attach and detach messages in the console. That is enumeration, observed directly.
6. Ignore the status LED. On many boards it lights only for device-role connections, such as plugging the controller into a PC, and stays dark for host attachments that are working perfectly.
7. Load the USB host library's keyboard example, the one built on KeyboardController.h, and run it.
8. Scan any code. The decoded characters appear in the console as typed keystrokes.

Steps 5 and 8 are the verification: attach and detach messages prove the port sees the device; characters on a scan prove the whole decode path, from scan engine to your console.

When nothing enumerates, work down this list

• No battery and no external input on the scanner. It needs VBUS, and this port has none. The phone test above separates power problems from wiring problems in a minute.
• The adapter is an extension cable, not an OTG adapter. Without the grounded ID pin the port never enters host role. Swap the adapter before touching code.
• Attach and detach messages churn on their own. Suspect the cable and the seating before the scanner: flaky connections on these ports show up as signal errors, the same physics covered in diagnosing USB signal errors on OTG ports.
• Profile mismatch. The scanner is set to serial emulation while you run the keyboard example. Set the scanner's USB profile to keyboard emulation first, then match the example to the profile.
• The controller shares a marginal supply. Commission the link with the controller on its rated supply, not a bench supply sized for something else.

Read the decode into your program

Keyboard emulation is the default choice: the decode arrives as ordinary characters, so the console test is already most of the application. Give records a terminator by setting a CR or LF suffix at the scanner; prefix and suffix framing for scanner input shows how records stay separated at the receiving end.

Serial emulation sends bytes over a CDC port instead, and then framing and pacing are yours to handle. The capture patterns in USB barcode scanner data capture in your application map onto that directly.

The scanner side, USB profile, prefix, suffix and trigger behaviour, lives in the reader's own configuration. Configuring a USB barcode scanner on an industrial controller port walks those settings from end to end.

If the controller cannot do host role at all, the fallbacks are the older paths: RS-232 into a PLC or a fixed reader with Ethernet, compared in barcode scanner input methods to a PLC.

Choosing the scanner side

Whatever reader you pair with this wiring, the requirements are the three above: a USB device interface, a keyboard emulation profile, and power that does not come from the port, meaning internal battery or an external input. On a host port that does source VBUS, a bus-powered reader inside the 100 mA and 500 mA limits is fine as well.

The data sheet for the LS-HCR-0001 lists a 1.0 MP sensor, a global shutter and a USB 2.0 wired interface:

Among the wired handheld code readers with USB interfaces in the catalog, these two models cover the compact and general-purpose ends of the range:

Browse the handheld code readers category, filter by interface and connection in the code reader finder, or contact the team when you want a second opinion on matching a reader to your controller. More integration guides sit under code reading.