Skip to content
Search

Universal Serial Bus

lastmod 2026-10-02created 2014-04-2823 edits

USB (Universal Serial Bus; Korean: beomyong jingnyeol beoseu, Hanja: 汎用直列 - ; North Korean standard language (Munhwaeo): beomyong jingnyeol moseon, ilban jingnyeol moseon) is one of the input/output standards used to connect computers and peripheral devices. Major versions include USB 1.0, 1.1, 2.0, 3.0, and 3.1.

USB was created to replace a variety of existing serial and parallel connections. It is used to connect a wide range of devices such as keyboards, mice, gamepads, joysticks, scanners, digital cameras, printers, PDAs, and storage devices. Most of these device connections are made using the standard connection method. USB was developed for the PC, but it is now also adopted in PDAs, game consoles, and so on, and its power supply capability is widely used for charging as well. In 2008 there are about 2 billion USB devices worldwide.

The USB standard is decided by the USB Implementers Forum. As of March 2010, the forum chair is Jeff Ravencraft of Intel. Because Intel's share of I/O chips in the computer motherboard market is overwhelming (62.1% according to Merrill Lynch's Q3 2004 report), the standard is being driven by Intel, which holds the largest demand in the consumer market and has the greatest influence within the forum.

IEEE 1394, often mentioned as a competing standard, is mainly built into camcorders and used for the DV format, whereas USB is adopted in a large number of low-cost devices.

Categories

Types

Connector types

USB Type A

Usb_type_a.png

USB Type B

Usb_type_b.png

USB Type C

Usb_type_c.jpg

Cable length limits

Passive (plain copper) cables do not support 5m. If you need 5m or more, you must use an active cable or an active optical cable (AOC).

Limits of passive cables

USB 3.2 Gen 2 (10Gbps) has a high signal frequency, so attenuation in copper wire is large. Under USB-IF criteria, USB-C to C passive cables are certified only up to about 1m for Gen 2. For reference, Gen 1 (5Gbps) is about 2m. Legacy Type-A/B connectors have no length stated in the spec and are instead defined by an electrical loss budget (insertion loss), but in practice the stable length for Gen 2 is about 1~2m. With a passive cable longer than this, the link often drops to Gen 1 or USB 2.0 speed, or disconnects.

How to go beyond 5m

  • Active copper cable: has a redriver/retimer chip inside the cable. For Gen 2 these typically reach about 3~5m.
  • Active optical cable (AOC): 10m, 15m, 30m, or longer is possible. Most have limited or no VBUS power delivery, so if you use bus-powered devices, check whether it is a hybrid AOC with power wires included. Many products are also directional (separate Host/Device ends).
  • Connect a self-powered hub or repeater in between: the USB topology allows up to 5 tiers of hubs, so you can extend in segments. However, the hubs must support Gen 2.
  • USB over Fiber/Ethernet extender: commonly used for long distances or at industrial sites.

When connecting industrial cameras

USB3 Vision cameras stream at high bandwidth for long periods, so they are prone to "it connects, but frames occasionally drop" problems. It is safest to use an active cable or AOC certified by the camera manufacturer. If the distance is fairly long, it is also worth considering GigE/10GigE Vision from the start.

How to mount in the Linux

On Linux, most USB devices use device names such as /dev/sda or /dev/sdb, and any device name not currently in use on the Linux server can be used as the USB device name. To check which device name it was assigned, use the fdisk -l command. 

$ fdisk -l
## ...
## 이후 아래와 같이 마운트 한다.
$ mount -t vfat /dev/sdb1 /mnt/usb

How to identify USB devices

You can list USB devices with lsusb: 

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 04f2:b67a Chicony Electronics Co., Ltd LG HD WebCam
Bus 003 Device 004: ID 046d:c539 Logitech, Inc. USB Receiver
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0029 Intel Corp.
Bus 001 Device 019: ID 0bda:c811 Realtek Semiconductor Corp.
Bus 001 Device 015: ID 0853:0146 Topre Corporation USB2.0 Hub
Bus 001 Device 011: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 009: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 010: ID 2109:8888 VIA Labs, Inc.
Bus 001 Device 008: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Look at Realtek Semiconductor Corp on line 9.

In the middle there is a ... ID 0bda:c811 ... part; the first half is the Vender ID and the second half is the Product ID.

If you are not comfortable with the terminal, check with sysinfo or hardinfo.

Hardinfo_sample_screenshot.png

Based on this information, check the kernel messages with the dmesg utility: 

$ sudo dmesg -H -w
...
[  +2.019060] usb 1-2.4.4: new high-speed USB device number 26 using xhci_hcd
[  +0.122475] usb 1-2.4.4: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[  +0.000010] usb 1-2.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 1-2.4.4: Product: 802.11ac NIC
[  +0.000003] usb 1-2.4.4: Manufacturer: Realtek
[  +0.000002] usb 1-2.4.4: SerialNumber: 123456
...
[ +33.686931] usb 1-2.4.4: USB disconnect, device number 26
...

(For reference, the -H option means Human Readable and the -w option means Follow)

When you connect a new USB device, output like the above appears with a prefix such as usb 1-2.4.4. Check that the Vender ID and Product ID on line 4 match.

Following the usb 1-2.4.4 prefix gives you the kernel messages for the same device.

Of these, check Product: 802.11ac NIC on line 6. So this device turns out to be a "wireless wifi dongle".

Common fixes when USB boot fails

These are the most common causes of boot failure:

  • Disable Secure Boot — turn off Secure Boot in the BIOS and try again
  • Check Boot Mode — if it is set to UEFI Only, enable Legacy/CSM as well
  • Boot Order — check that USB is near the top of the boot order
  • Disable Fast Boot — with Fast Boot on, the USB may not be detected

GPT/MBR partition table issues

Some older BIOSes do not recognize GPT. To make a bootable USB manually: 

# USB 초기화 후 수동 구성
sudo wipefs -a /dev/sdb

# MBR 파티션 테이블로 생성 (Legacy BIOS 호환)
sudo parted /dev/sdb --script mklabel msdos
sudo parted /dev/sdb --script mkpart primary fat32 1MiB 100%
sudo parted /dev/sdb --script set 1 boot on

# FAT32 포맷
sudo mkfs.vfat -F 32 /dev/sdb1

# ISO 마운트 후 파일 복사
sudo mkdir -p /mnt/{iso,usb}
sudo mount -o loop ubuntu-24.04-desktop-amd64.iso /mnt/iso
sudo mount /dev/sdb1 /mnt/usb
sudo cp -a /mnt/iso/. /mnt/usb/
sudo sync

# UEFI 부팅을 위한 부트로더 설치
sudo grub-install --target=i386-pc --boot-directory=/mnt/usb/boot /dev/sdb

sudo umount /mnt/{iso,usb}

Introduction to writing user-space USB drivers

  • USB driver development is considered kernel-level work, but in practice it can be implemented in user space at a difficulty similar to socket programming
  • With libusb, you can do device enumeration, control transfers, and data transmission/reception without writing any kernel code
  • USB communication consists of four transfer types (Control, Bulk, Interrupt, Isochronous) and IN/OUT directions, and each endpoint acts as a one-way channel
  • Using the Fastboot protocol of Android devices as an example, demonstrates in code how commands and responses are exchanged over Bulk endpoints
  • A complete USB driver can be implemented in user space, and all USB protocols share the same basic structure

Introduction

  • Drivers for USB devices feel hard because of the perception that they require dealing with kernel code, but in reality their complexity is at the level of an application that uses sockets
  • Even developers without much hardware experience can learn how to handle USB in user space
  • Materials covering the detailed workings of USB exist, but they are hard for beginners to approach
  • Using USB does not require embedded-systems-level knowledge; it can be approached like network sockets

USB devices

  • Uses an Android smartphone in bootloader mode as the example
    • Easy to obtain, has a simple protocol, and the OS has no built-in driver for it, making it suitable for experiments
  • How to enter bootloader mode differs by device, usually via a combination of the power and volume buttons

Enumerating the device manually

  • Enumeration is the process in which the host requests device information to identify the device, performed automatically when the device is connected
  • Standard devices have drivers loaded automatically based on their USB class, while vendor-specific devices use the VID (Vendor ID) and PID (Product ID)
  • On Linux, device information can be checked with the lsusb command
    • Example: ID 18d1:4ee0 Google Inc. Nexus/Pixel Device (fastboot)
    • 18d1 is Google's VID, 4ee0 is the PID of the Nexus/Pixel bootloader
  • The lsusb -t command shows the class and driver status
    • Shown as Class=Vendor Specific Class, Driver=[none], meaning the OS did not load a driver
  • On Windows, the same information can be checked with Device Manager or USB Device Tree Viewer

Enumerating devices with libusb

  • The libusb library lets you communicate with USB devices from user space without writing kernel code
  • libusb_hotplug_register_callback() sets up a callback to run when a device with a specific VID:PID combination is connected
  • After starting the program, connecting the device prints the "Device plugged in!" message
  • Works out of the box on Linux; if needed, the kernel driver can be detached with libusb_detach_kernel_driver()
  • On Windows, the Winusb.sys driver is required; if it is missing, it can be swapped in manually with the Zadig tool

Communicating with the device

  • The first communication with a USB device goes through the Control endpoint (address 0x00)
  • libusb_control_transfer() sends a standard request (GET_STATUS) to read the device status
    • Example response: 01 00 → the first byte means Self-Powered, the second means Remote Wakeup is not supported
  • A GET_DESCRIPTOR request can then fetch the device descriptor
    • The returned data includes device information such as idVendor, idProduct, and bDeviceClass
  • The lsusb -v command shows all descriptors (device, configuration, interface, endpoint, etc.) in detail
    • Example: the Android Fastboot interface has Bulk IN (0x81) and Bulk OUT (0x02) endpoints

Endpoints

  • An endpoint is a concept similar to a network port: a channel through which the device sends and receives data
  • The type and direction of each endpoint are defined in the descriptor
  • Control transfer type
    • Every device has one, and its address is always 0x00
    • Used for initial setup and device information requests
    • Does not belong to an interface; exists as part of the device itself
  • Bulk transfer type
    • Used for large, non-real-time data transfers
    • e.g. Mass Storage, CDC-ACM (serial), RNDIS (Ethernet)
    • High bandwidth but low priority
  • Interrupt transfer type
    • Used for small, low-latency data transfers
    • Quickly polls button input on keyboards, mice, etc.
    • Not an actual hardware interrupt; the host requests periodically
  • Isochronous transfer type
    • Used for time-sensitive, large data (audio, video streaming)
    • Any delay immediately shows up as degraded quality
    • Handled asynchronously in libusb
  • IN / OUT direction
    • USB is host-centric: a device does not send data until it receives a request
    • IN: the direction in which the host receives data
    • OUT: the direction in which the host sends data
    • If the most significant bit (MSB) of the endpoint address is 1, it is IN; if 0, it is OUT
    • Up to 127 user-defined endpoints can be used (0x00 is reserved for Control)
    • Endpoints are unidirectional and come in IN/OUT pairs, as in the Fastboot interface

Fastboot protocol

  • Fastboot is the Android bootloader communication protocol: you send a command string and receive a 4-byte status code and data
    • Examples:
      • Host: "getvar:version" → Client: "OKAY0.4"
      • Host: "getvar:nonexistant" → Client: "OKAY"
  • Example code that sends Fastboot commands using libusb
    • Claim interface 0 with libusb_claim_interface()
    • Send the "getvar:version" command to the Bulk OUT (0x02) endpoint
    • Receive the response on the Bulk IN (0x81) endpoint
    • OKAY is the success status, 0.4 is the Fastboot version

Conclusion

  • A complete USB driver can be implemented in user space without writing kernel code
  • All USB drivers follow the same basic principles; only the protocols differ
  • Even complex protocols (such as MTP) have the same basic structure and can be approached with concepts similar to socket communication

Libraries

Bootable USB

Troubleshooting

/dev/ttyUSB0 disconnecting by itself on Ubuntu

Checking the log with sudo dmesg -w: 

[  208.805626] usb 1-1.2.3: new full-speed USB device number 8 using xhci_hcd
[  208.909682] usb 1-1.2.3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[  208.909696] usb 1-1.2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  208.909700] usb 1-1.2.3: Product: USB Serial
[  208.946567] ch341 1-1.2.3:1.0: ch341-uart converter detected
[  208.960853] usb 1-1.2.3: ch341-uart converter now attached to ttyUSB0
[  209.540161] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input42
[  209.780667] usb 1-1.2.3: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[  209.783648] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[  209.783689] ch341 1-1.2.3:1.0: device disconnected

The important lines, in plain words:

  • [208.960853] usb 1-1.2.3: the ch341-uart converter is now attached to ttyUSB0
  • [209.540161] input: BRLTTY 6.4 Linux screen driver keyboard /devices/virtual/input/input42
  • [209.780667] usb 1-1.2.3: usbfs: interface 0 is claimed by ch341, and 'brltty' sets configuration #1
  • [209.783648] ch341-uart ttyUSB0: the ch341-uart converter is now disconnected from ttyUSB0
  • [209.783689] ch341 1-1.2.3:1.0: device disconnected

In short, remove brltty. 

sudo apt purge brltty

When brltty runs, it tries to take over USB interface 0. This results in the disconnection.

See also

Favorite site

References

  1. USB-Device-Tracking-Artifacts.pdf ↩

author Zer0 sitemap