This is an attempt to make the least shit code that operates the ch341a/ch347 as possible. There seem to be tons of different attempts at this buried within different tools for doing things with i2c or spi devices but none of them seem to very good.

To avoid yet another hacked up copy of someone else's ch341a code in yet another project lets make a reusable library.

This will use my libusrio shim thingy to make the API look like the Linux i2c/spi userspace APIs because that's cool.

https://github.com/fifteenhex/libusrio

• There seems to be no way to get the current output state of pins? So setting one pin can change the state of the others if they are not known.

Included are a set of hacky sample programs. Most of the are re-implementations of tools you'd normally use with an in-kernel driver:

• ch341a_probe - Probe for supported device, print info
• ch341a_i2cdetect - Like i2cdetect from i2c-utils
• ch341a_i2cget - Like i2cget from i2c-utils
• ch341a_i2cset - Like i2cset from i2c-utils
• ch341a_gpioinfo - Like gpioinfo from gpiod
• ch341a_gpioget - Like gpioget from gpiod
• ch341a_gpioset - Like gpioset from gpiod
• ch341a_spipipe - Like spi-pipe from spi-tools
• spiepaper - Demo of using SPI + GPIOs to drive an SPI epaper.

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

The ch347 seems to be basically the same idea as the ch341a except: Has JTAG, better SPI implementation, some differences with how NAKs are handled, bigger USB endpoints, no usable GPIO?

http://www.wch-ic.com/products/CH347.html

• Implement SPI
• Work out if it's possible to get any gpio support For mode 3 at least GPIO seems to be a hacked on by messing with the i2c bus?