The CH341 is declined in several flavors, and may support one or more of UART, SPI, I2C and GPIO, but not always simultaneously:

- CH341 A/B/F: UART, Printer, SPI, I2C and GPIO
- CH341 C/T: UART and I2C
- CH341 H: SPI

They work in 3 different modes, with only one being presented depending on the USB PID:

- 0x5523: UART mode, covered by the USB `ch341` serial driver
- 0x5512: SPI/I2C/GPIO mode, covered by this set of drivers
- 0x5584: Parallel printer mode, covered by the USB `usblp` driver

From linux kernel 5.10 to 5.16, the 0x5512 PID was unfortunately also claimed by the driver for the UART part, and will conflict with these drivers. Blacklisting that module or deleting it will solve that problem. In /etc/modprobe.d/blacklist.conf, add the following line to prevent loading of the serial driver:

blacklist ch341

Mode selection is done at the hardware level by tying some pins. Breakout boards with one of the CH341 chip usually have one or more jumpers to select which mode they work on. At least one model (CJMCU-341) appears to need bridging some solder pads to select a different default. Breakout boards also don't usually offer an option to configure the chip into printer mode; for that case, connect the SCL and SDA lines directly together.

The various CH341 appear to be indistinguishable from the software. For instance the gpio-ch341 driver will present a GPIO interface for the CH341T although physical pins are not present, and the device will accept GPIO commands.

Some breakout boards work in 3.3V and 5V depending on some jumpers.

The black chip programmer with a ZIF socket will power the CH341 at 3.3V if a jumper is set, but will only output 5V to the chips to be programmed, which is not always desirable. A hardware hack to use 3.3V everywhere, involving some soldering, is available there:

https://eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/

These drivers have been tested with a CH341A, CH341B and CH341T.

Some sample code for the CH341 is available at the manufacturer website:

http://wch-ic.com/products/CH341.html

The following repository contains a lot of information on these chips, including datasheets.

https://github.com/boseji/CH341-Store.git

This set of drivers is based on, merges, and expands the following pre-existing works:

https://github.com/gschorcht/spi-ch341-usb.git
https://github.com/gschorcht/i2c-ch341-usb.git

Warning: try not to yank the USB device out if it's being used. The linux subsystems gpio and spi may crash or leak resources. This is not a problem with the drivers, but the subsystems themselves.

The drivers will build for the active kernel:

$ make

This will create four drivers: ch341-core.ko, gpio-ch341.ko, i2c-ch341.ko and spi-ch341.ko which can then be insmod'ed, in that order.

This driver used to be in a single piece, called ch341-buses.ko. However since the goal is to upstream it, it was not possible to keep it as is.

It is possibly to override the target kernel by setting the KDIR variable in the working environment, to point to a built kernel tree.

These drivers have been tested with a linux kernel 6.2, and should still build for older kernels.

Although it's possible to access everything as root, or even to give a user some rights to access the i2c/spi/gpio subsystem, some of these resources are critical to the system, and reading or writing to them might make a system unstable.

WARNING! Accidentally accessing a motherboard or graphic card I2C or SPI device may render the former unoperable. Double check that the correct device is accessed.

The following is more safe. As root, create a group, add the user to the group and create a udev rule for that group that will bind to the devices recognized by the core driver:

$ groupadd ch341
$ adduser "$USER" ch341
$ echo 'SUBSYSTEMS=="usb" ATTRS{idProduct}=="5512" ATTRS{idVendor}=="1a86" GROUP="ch341" MODE="0660"' > /etc/udev/rules.d/99-ch341.rules

After plugging in the USB device, the various /dev entries will be accessible to the ch341 group:

$ ls -l /dev/* | grep ch341
crw-rw----   1 root ch341   254,   2 Sep 20 01:12 /dev/gpiochip2
crw-rw----   1 root ch341    89,  11 Sep 20 01:12 /dev/i2c-11
crw-rw----   1 root ch341   153,   0 Sep 20 01:12 /dev/spidev0.0

The ch341 supports 4 different speeds: 20kHz, 100kHz, 400kHz and 750kHz. The driver only supports 100kHz by default, and that currently cannot be dynamically changed. It is possible to change it in the ch341_i2c_init() function. A future patch should address that issue.

I2cdetect requires the i2c-dev module to be loaded. You can load it once:

$ modprobe i2c-dev

Or add it to /etc/modules-load.d/ to autoload the module at boot time:

$ echo 'i2c-dev' > /etc/modules-load.d/i2c-dev.conf
$ systemctl restart systemd-modules-load.service

To find the device number:

$ i2cdetect -l
...
i2c-11        unknown           CH341 I2C USB bus 003 device 005        N/A

Adding support for a device supported by Linux is easy. For instance:

modprobe bmi160_i2c
echo "bmi160 0x68" > /sys/bus/i2c/devices/i2c-$DEV/new_device

or:

modprobe tcs3472
echo "tcs3472 0x29" > /sys/bus/i2c/devices/i2c-$DEV/new_device

Files from these drivers will be created somewhere in /sys/bus/i2c/devices/i2c-$DEV/

The ch341 doesn't work with a Wii nunchuk, possibly because the pull-up value is too low (1500 ohms).

16 GPIOs are available on the CH341 A/B/F. The first 6 are input/output, and the last 10 are input only.

Pinout and their names as they appear on some breakout boards:

CH341A/B/F     GPIO  Names                    Mode
  pin          line

 15             0     D0, CS0                  input/output
 16             1     D1, CS1                  input/output
 17             2     D2, CS2                  input/output
 18             3     D3, SCK, DCK             input/output
 19             4     D4, DOUT2, CS3           input/output
 20             5     D5, MOSI, DOUT, SDO      input/output
 21             6     D6, DIN2                 input
 22             7     D7, MISO, DIN            input
  5             8     ERR                      input
  6             9     PEMP                     input
  7            10     INT                      input
  8            11     SLCT (SELECT)            input
  ?            12     ?                        input
 27            13     WT (WAIT)                input
  4            14     DS (Data Select?)        input
  3            15     AS (Address Select?)     input

They can be used with the standard linux GPIO interface. Note that MOSI/MISO/SCK may be used by SPI, when SPI is enabled.

To drive the GPIOs, one can use the regular linux tools. gpiodetect will report the device number to use for the other tools (run as root):

$ gpiodetect
...
gpiochip2 [ch341] (16 lines)

$ gpioinfo gpiochip2
gpiochip2 - 16 lines:
        line   0:      unnamed       unused   input  active-high
        line   1:      unnamed       unused   input  active-high
        line   2:      unnamed       unused   input  active-high
        line   3:      unnamed       unused   input  active-high
        line   4:      unnamed       unused   input  active-high
        line   5:      unnamed       unused   input  active-high
        line   6:      unnamed       unused   input  active-high
        line   7:      unnamed       unused   input  active-high
    [......]
        line  15:      unnamed       unused   input  active-high

$ gpioset gpiochip2 0=0 1=1 2=0
$ gpioget gpiochip2 5

If the SPI mode is enabled, the MOSI, MISO and SCK, and possible one or more of CS0/1/2, won't be available.

On Ubuntu 21.04, the libgpio is too old and will return an error when accessing the device. Use a more recent library. The master branch from the git tree works well:

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

The INT pin, corresponding to GPIO 10 is an input pin that can trigger an interrupt on a rising edge. Only that pin is able to generate an interrupt, and only on a rising edge. Trying to monitor events on another GPIO, or that GPIO on something other than a rising edge, will be rejected.

As an example, physically connect the INT pin to CS2. Start the monitoring of the INT pin:

$ gpiomon -r gpiochip2 10

The INT will be triggered by setting CS2 low then high:

$ gpioset gpiochip2 2=0 && gpioset gpiochip2 2=1

gpiomon will report rising events like this:

event: RISING EDGE offset: 10 timestamp: [ 191.539358302] ...

See above for how SPI and GPIO exclusively share some pins.

Only SPI mode 0 (CPOL=0, CPHA=0) appears to be supported by the ch341.

As long as no SPI device has been instantiated, all the GPIOs are available for general use. When the first device is instantiated, the driver will try to claim the SPI lines, plus one of the chip select.

To instantiate a device, echo a command string to the device's sysfs 'new_device' file. The command is the driver to use followed by the CS number. For instance, the following declares a user device (spidev) at CS 0, and a flash memory at CS 1:

$ echo "spidev 0" > /sys/class/spi_master/spi0/new_device
$ echo "spi-nor 1" > /sys/class/spi_master/spi0/new_device

Starting with the Linux kernel 5.15 or 5.16, the following steps are also needed for each added device for the /dev/spidevX entries to appear:

echo spidev > /sys/bus/spi/devices/spi0.0/driver_override
echo spi0.0 > /sys/bus/spi/drivers/spidev/bind

Change spi0 and spi0.0 as appropriate.

After these command, the GPIO lines will report:

$ gpioinfo gpiochip2
gpiochip2 - 16 lines:
        line   0:      unnamed        "CS0"  output  active-high [used]
        line   1:      unnamed        "CS1"  output  active-high [used]
        line   2:      unnamed       unused   input  active-high
        line   3:      unnamed        "SCK"  output  active-high [used]
        line   4:      unnamed       unused   input  active-high
        line   5:      unnamed       "MOSI"  output  active-high [used]
        line   6:      unnamed       unused   input  active-high
        line   7:      unnamed       "MISO"   input  active-high [used]
        line   8:      unnamed       unused   input  active-high
        ...
        line  15:      unnamed       unused   input  active-high

To remove a device, echo its CS to 'delete_device'. The following will remove the spidev device created on CS 1 above:

$ echo "1" > /sys/class/spi_master/spi0/delete_device

If all the devices are deleted, the SPI driver will release the SPI lines, which become available again for GPIO operations.

This driver (and other USB drivers) can easily be developed and tested in a VM, using QEMU and virtme-ng (available in some distributions or at https://github.com/arighi/virtme-ng). The older virtme (at https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/) will not work with compressed modules.

The following command will boot a VM under 10 seconds with any CH341 in I2C mode passed through:

vng --run --force-9p --qemu-opts="-smp 2 -usb -device usb-host,vendorid=0x1a86,productid=0x5512"

or with the original virtme:

virtme-run --pwd --installed-kernel --qemu-opts -usb -device usb-host,vendorid=0x1a86,productid=0x5512

Build the module on the host, but test it in the VM. Add the --rwdir option to be able to write files to the host. Type ctrl-a x to exit the VM.

The amount of loaded drivers is going to be minimal. More modules may need to be loaded, such as i2c-dev, spi-nor or mtd, depending on usage.