Hi all, I’ve recently switched over to Linux Mint from Windows 10 and I’m having trouble installing a CH340 driver from Sparkfun. I’ve managed to unzip the contents and have it in this location: /home/user/Downloads/CH341SER_LINUX. I’ve tried running the files using the ./ command for both the ch34x.c and Makefile but ran into a bash issue which I’m stuck trying to figure out. Could someone please tell me how to make it work? I’ve already looked up a couple of different videos on Youtube but they kind of skip the explanation of how to install this driver on Linux in favor of Windows and MacOS.
Please see the attached image for the response I get in the terminal.
UPDATE: It turns out I had a bad micro USB cable. Most of the ones I was using to connect to an ESP32 board were charge only. Mint apparently had the driver for this all along. Thanks for the help everyone.
Why are you trying to install a driver for a CH340? The driver is already built into the kernel. Just plug it in and it will work.
This.
However sometimes the user can’t access the device. Depending on your system, I recommend adding your user to the dialout/serial group.
I.e. quick online search
Another issue is that brltty can take over the serial port. The easiest fix is to just uninstall it if you don’t use a braille display.
Like nearly all drivers lol
Drivers I needed to pay special attention to:
- NVidia (we all know the official stance on that topic)
- e1000e needs patching because my Laptops NIC somehow reports the wrong NVM checksum
- Some obscure chinese “USB to DVI-D” adapter
- The fingerprint sensor in my Laptop, as it’s still experimental
Whoa, you got the fingerprint sensor working? What laptop brand is it, and what distro are you using?
It’s a Dell Latitude 5420, with a Broadcom Corp. 58200. Per https://wiki.archlinux.org/title/Laptop/Dell#Latitude, the 5420 is supported with libfprint-2-tod1-broadcom. And of course, I use Arch btw.
Drawing tablet drivers!
To be fair, it actually does work out of the box, but shortcut mapping doesn’t really work well outside of the buttons on the pen itself and pressure curves isn’t customizable yet, at least on KDE.
Please dont follow windows workflows.
If you run a random script with or without sudo, you can easily get malware or break your system.
A .c file is also not ran, it is a C source file and needs to be compiled
i.e. you are doing something completely wrong and followed some strange advice.
Instead,
- Try if the USB cable is the only issue
- Drivers are in the kernel, so you cannot just install them
- Ask Linux Mint people how to do this, or Ubuntu or Debian people (the distros are related)
I agree with your sentiment. Just one small thing:
.c
files are usually C source code, and are meant to be compiled into binaries.It doesn’t change OP’s situation at all though.
The driver should already be installed but there seems to be an issue with
brltty
registering the corresponding USB ID when they shouldn’t. You can probably fix it by following this guide: https://koen.vervloesem.eu/blog/how-to-stop-brltty-from-claiming-your-usb-uart-interface-on-linux/ (or this one: https://unix.stackexchange.com/a/670637)Edit: Perhaps this has since been fixed in Mint 21 / Ubuntu 22.04.
Some time ago I wasted about 2 hours of time because of that damn brltty, wondering why the tf the arduino was not being detected until I followed dmesg. I was very upset at the time when I found out what brltty was. Like I get some people need that but if the user did not connect a braille display during install then the daemon should never be enabled or just uninstalls during os installation.
*.c files are C source files, you can’t run these directly. Run the makefile with
sudo make
orsudo make install
(assuming you havemake
installed) to build (or build and install) the driver.edit: Oops didn’t read far enough into your post, you’ve already tried
make
. What error does it give you?I get this as a result:
user@user-System-Product-Name:~/Downloads/CH341SER_LINUX$ sudo make Makefile
make: Nothing to be done for ‘Makefile’.
You don’t pass in
Makefile
tomake
as it will read that file automatically. Nor you needsudo
withmake
as compiling doesn’t need any special privileges.Step:
make
: compile the code to binarysudo make install
: install the binary to your system
Please dont just run whatever command with sudo.
Please read a bit of stuff before trying out crazy stuff.
Do you even need that driver?
can’t really tell much without knowing this package, but ./ is not what you’re looking for. try just “make” or “make clean”, as this is standard syntax for Makefiles. if you are wondering what happens, make looks for a file called “Makefile” in the current directory and executes whatever is inside. in your case it will most likely compile the .c file into an executable
I did what abominable_panda suggested and it returned a “wait_queue_t” and a couple of pointer type errors. I’m not sure if that’s something that could be fixed with installing something else, but I’m not at all familiar with troubleshooting on this OS yet. The troubleshooting part you mentioned is if it successfully installed but there are issues. It doesn’t quite explain the initial installation part.
As for cmnybo’s question, I’m trying to program a ESP32 module with the Arduino IDE. I’ve tried just plugging it in and hoping the driver would already be installed but lsusb doesn’t show it on the results.
If it’s not showing up in lsusb and there is no activity in syslog when connecting or disconnecting it, then the problem is not a driver. It’s likely a bad cable or you got a dead module.
You’re right about the bad cable. I have a collection of about 10 USB A to USB micro cables and only one of them showed up on lsusb! Thanks for the advice!
True, the device should absolutely be shown on lsusb
Have you setup a rules file for USB? You must have a udev rule setup that gives your user access to the hardware. It is trivial to create, but is one of those little headaches you learn as you go. Sparkfun and Adafruit should both have good tutorials if you search either of them for udev rules.
Mine for a ch340 is done like this:
$ cd /etc/udev/rules.d $ sudo nano 69-my-usb-serial-devices.rules # ch340 SUBSYSTEM="USB", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1a86", ATTR{idProduct}=="7523", MODE="0666"
I just told you to enter the terminal editor nano and enter a note that will help you remember that this is for the ch340
# ch340
followed by a line that sets the permissions for the device using a rule for which users have access to the device. I’m assigning the rule based on the vendor and product ID numbers. You can find these numbers by using the$ lsusb
command. FYI, the $ is standard shorthand for command line as your standard user. This is opposed to # which is short for the root user at the command line.Once you enter this line in nano, follow the instructions to save the file in nano
:qw
IIRC. The next time you plug in the device, the kernel should use this rule to set the permissions for the device to 0666 which means everyone can read write, but not execute stuff from the port; with execute would be 0777.When you are trying to find info about a USB device the following may be helpful:
$ sudo dmesg | grep -F "USB device number"
Note that the last line should be the most recently connected device.
$ dmesg
is the system-d boot log. Depending on how system-d is configured, you’ll probably see timestamps on the left. The initial bootup devices will show up with a tightly grouped time stamp, while later connections will show a much larger number.There have been some recent changes in Fedora that have broken a script I wrote to help me with all the various places where USB hardware is located and finding the right info. I’m trying to parse that script for the key elements. The first step is to find the location of the hardware. You are looking for something like
/dev/bus/usb/003/003
or wherever the new device got mounted. This is only the start, because different parts of the device may be mounted in different locations. I’m not just talking about the CH340, but like, if you are doing microcontrollers stuff that gets more complicated like forth, micropython and circuit python where there will be more going on than just the serial port, or you need to know low level stuff. Once you know the specific port, you can use$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/bus/usb/003/003) # enter the port for the device in question
.In the past, my script used
$ dmesg
to retrieve the device location, then used$ lsusb -D *device location*
to get the basic info. Then I went a layer deeper with the udevadm command to see everything related to the device. The command$ fdisk -l
might also help with some STM32 type stuff that has a dfu bootloader and identifies as a USB drive when plugged in… At least, I think that was the reason I kept that option in my script, it has been awhile since I used one of those.Edit: I can get the actual port location of a device now using
$ lsusb -t -vv
.Edit:
Scroll down about ¾ way down the sparkfun page that you linked, to the section that says “Linux” and follow those instructions
-
Read the readme file, either by opening in a text editor or typing “nano readme.txt” (then Ctrl+x to exit) -
Type “make” and see if that works. If it complains, install what its complaining about
-
Doesn’t look like the executable you are trying to run is with executable rights.
chmod +x ch34x.c
And retry.
(I don’t have any knowledge of this driver or installing it. Just wanted to give some directions.)
You don’t execute C source files. They have to be compiled.
First point as someone else commented, that driver is already present in any mainstream kernel. It’s very unlikely you have any need to build it.
But if you really want to build it the command will be
make
that will get instructions from Makefile on how to build the driver. But there will be other tools and libraries needed.No, the user is doing something very wrong here and this is way worse. Please dont give wrong advice.
Yeah, I know. It is a source code file…