# driver for rs232 to usb



## blind0ne (Oct 29, 2021)

Recently I've bought rs232 to usb serial cable to connect through serial cable to switch. On windows I've installed CH340SER.EXE driver and it works. But on freebsd it's not working or eat chars or give broken input. Witch programs and manuals could you advice to resolve this problem. 

Please give me a direction to move along. Maybe it's something wrong with setting for console programm I'm connecting through? Couse on Windows i've used Putty and it works fine, no bad input at all. 

on freebsd i've used:

screen /dev/cuaU0 38400

The output weird or not present at all, 

it just kicks me off for now. 

Whitch handbook pages should I read for finding right recepies?


----------



## mer (Oct 29, 2021)

Assuming the driver exists (it likely does), I've had better luck using the command tip 

Example:
I have a cable like that for the console of a pfSense device, and as *root* I use the command:
tip ucom1 -115200

So, run as root, make sure you specify the correct "system name" for tip (that's the ucom1)  tip looks up in /etc/remote.

I'd also double check what device gets created by doing "ls -ltr /dev" before and after plugging the cable in.
Double check the expected baud rate;  most things seem to default to 9600 or 115200.


----------



## jbo (Oct 29, 2021)

blind0ne said:


> Witch programs and manuals could you advice to resolve this problem.


Whenever I want to talk to a device over serial on FreeBSD, I use comms/minicom. It never let me down so far.

As for the driver: uchcom(4) should do the job. Given that you get "weird output" I assume that the driver is loaded & working tho.
Therefore, just make sure that your settings are correct as mentioned by mer.


----------



## mer (Oct 29, 2021)

Minicom works well too.  Good old standby.  
Weird output is typically baud rate mismatch. But don't forget about num data bits, num stop bits, parity, hw flow control;  all those make a difference.


----------



## SirDice (Oct 29, 2021)

blind0ne said:


> screen /dev/cuaU0 38400


While screen(1) might work you're better off using an actual comms application like cu(1).

Definitely like comms/minicom too, brings back lots of fond memories from the good old MS-DOS Telix application.


----------



## blind0ne (Oct 29, 2021)

SirDice said:


> While screen(1) might work you're better off using an actual comms application like cu(1).
> 
> Definitely like comms/minicom too, brings back lots of fond memories from the good old MS-DOS Telix application.


cu with right bit rate (i hope i can say so) is also also generates same results. I think the others along with minicom and tip would behave in this way. When I've just changed the cable adapter and use the same screen or cu wiht right bound rate - everything is fine. So I can be sure that the problem not in the screen command, but somewhere deeper. Or I need to use different setting on different cabels? In Windows with putty it's not the case.


----------



## mer (Oct 29, 2021)

If you have a working config in putty with respect to num bits, baud rate, etc, those same values should work on whatever you use on FreeBSD.  You may need to specify more than just a different baud rate, and you may need to run as root in order to open the device up.
As root (su or sudo) in either the console or a term window try:
tip ucom1 -38400

ucom1 for tip translates to /dev/cuaU0, defaults to "8N1 no flow control"


----------



## blind0ne (Oct 29, 2021)

mer said:


> If you have a working config in putty with respect to num bits, baud rate, etc, those same values should work on whatever you use on FreeBSD.  You may need to specify more than just a different baud rate, and you may need to run as root in order to open the device up.
> As root (su or sudo) in either the console or a term window try:
> tip ucom1 -38400
> 
> ucom1 for tip translates to /dev/cuaU0, defaults to "8N1 no flow control"


But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another


----------



## jbo (Oct 29, 2021)

blind0ne said:


> But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another


The settings have nothing to do with "the cable" (i.e. the RS232-to-USB adapter) but rather the device itself.
If you have a working serial connection you can use whatever adapter you want as long as you have a working driver for it.


----------



## mer (Oct 29, 2021)

blind0ne said:


> But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another


Ahh, I didn't understand you have 2 different cables. But as jbodenmann says "The cable shouldn't matter", but if you can swap them to the working Putty, that would let you verify it.

With a USB to serial converter, sometimes the cable isn't just wires.  The device itself is the one presenting the physical interface, so maybe the 2 cables aren't exactly the same.


----------



## SirDice (Oct 29, 2021)

mer said:


> With a USB to serial converter, sometimes the cable isn't just wires. The device itself is the one presenting the physical interface, so maybe the 2 cables aren't exactly the same.


Yeah, keep in mind those USB-to-Serial adapters can have different chipsets, it's never just some wires. FTDI is a common USB serial chip, but there are others. Even if you buy two USB-to-Serial cables from the same vendor you can get different chipsets in them. I have a bunch of those cheap Sweex USB-to-Serial converters and they all use different chips. Super annoying. 









						FTDI - Wikipedia
					






					en.wikipedia.org


----------



## blind0ne (Oct 29, 2021)

SirDice said:


> Yeah, keep in mind those USB-to-Serial adapters can have different chipsets, it's never just some wires. FTDI is a common USB serial chip, but there are others. Even if you buy two USB-to-Serial cables from the same vendor you can get different chipsets in them. I have a bunch of those cheap Sweex USB-to-Serial converters and they all use different chips. Super annoying.
> 
> 
> 
> ...


On windwos i've installed driver called 'ch340ser-wimdows.zip', and Yes I didnot miss spelled it. So on my current machine it works perfectly, I would like to make it work on freebsd as good as on windows.


----------



## jbo (Oct 29, 2021)

blind0ne said:


> On windwos i've installed driver called 'ch340ser-wimdows.zip', and Yes I didnot miss spelled it. So on my current machine it works perfectly, I would like to make it work on freebsd as good as on windows.


As mentioned in my first post, the uchcom(4) driver implements support for the CH340 chipset and worked the well last time I used it.
But given that in your post you mentioned that you do see characters showing up (just "garbage") I would assume that you already figured that out and that the driver is working.


----------



## SirDice (Oct 29, 2021)

Looks helpful: https://wiki.freebsd.org/USB/Peripherals/Serial



> You might also want to avoid WinChipHead CH340/CH341 given the comments in the driver https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c#n63




```
/*
 * Driver for WinChipHead CH341/340, the worst USB-serial chip in the
 * world.
 */
```


----------



## blind0ne (Oct 29, 2021)

jbodenmann said:


> As mentioned in my first post, the uchcom(4) driver implements support for the CH340 chipset and worked the well last time I used it.
> But given that in your post you mentioned that you do see characters showing up (just "garbage") I would assume that you already figured that out and that the driver is working.



It's just gives me canot open /dev/cuaU0, on minicom -b 38400 -D /dev/cuaU0. The driver is loaded already.


----------



## jbo (Oct 29, 2021)

Is the user you're using allowed to access this device?
If in doubt, you can always do a quick test as root.

In any case: It's usually helpful if you can show the *exact* error message that you're getting (copy-paste into a [code][/code] block).


----------



## blind0ne (Nov 1, 2021)

jbodenmann said:


> Is the user you're using allowed to access this device?
> If in doubt, you can always do a quick test as root.
> 
> In any case: It's usually helpful if you can show the *exact* error message that you're getting (copy-paste into a [code][/code] block).


Yep I'm trying from root, but still no errors, just empty tty.


----------



## diizzy (Nov 1, 2021)

You probably have a wiring issue and/or dead controller.

I'd also chime in and recommend tio (comms/tio) over minicom but I guess that boils down to preference, for quick hacks cu is more than sufficient.

SirDice
Tried to condense the wiki page as much as possible without excluding "known" information


----------



## mark_j (Nov 1, 2021)

What's in your /boot/loader.conf? You need umodem and it wouldn't hurt to set the hw.usb.template to 3 just in case.
Uchcom would also be required.
What's the output of usbconfig anyway?


----------



## blind0ne (Nov 1, 2021)

mark_j said:


> What's in your /boot/loader.conf? You need umodem and it wouldn't hurt to set the hw.usb.template to 3 just in case.
> Uchcom would also be required.
> What's the output of usbconfig anyway?


ugen5.2: <vendor 0x1a86 USB2.0-Ser> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)


----------



## blind0ne (Nov 1, 2021)

mark_j said:


> What's in your /boot/loader.conf? You need umodem and it wouldn't hurt to set the hw.usb.template to 3 just in case.
> Uchcom would also be required.
> What's the output of usbconfig anyway?


# cat /boot/loader.conf
uchcom_load="YES"


----------



## blind0ne (Nov 1, 2021)

With this one everything is fine - ugen5.2: <FTDI USB Serial Converter> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (44mA)
but one mentioned as USB2.0-Ser also works great under windows, but on freebsd is useless.


----------



## SirDice (Nov 1, 2021)

That FTDI USB Serial converter is a much better chipset. If the remarks in the driver of uchcom(4) are to be believed those chips are really badly implemented. The windows driver may have all sorts of quirks to circumvent those issues.


----------



## blind0ne (Nov 1, 2021)

SirDice said:


> That FTDI USB Serial converter is a much better chipset. If the remarks in the driver of uchcom(4) are to be believed those chips are really badly implemented. The windows driver may have all sorts of quirks to circumvent those issues.


So i'm locked in windows with this chip? Is it theoreticly possible to fix this issues on freebsd?


----------



## SirDice (Nov 1, 2021)

blind0ne said:


> Is it theoreticly possible to fix this issues on freebsd?


Sure, if you can report the issue (PR) then the developer may be able to add some of the quirks to get your cable working. That's assuming the developer is able to find what the cause of the issue is. There's nothing worse than a bug that happens intermittently and is difficult to reproduce.


----------



## blind0ne (Nov 1, 2021)

SirDice said:


> Sure, if you can report the issue (PR) then the developer may be able to add some of the quirks to get your cable working. That's assuming the developer is able to find what the cause of the issue is. There's nothing worse than a bug that happens intermittently and is difficult to reproduce.


is there some manual on how can I drive the solution trough all steps to resolving. I guess I need more then just usb devices dump.


----------



## SirDice (Nov 1, 2021)

Just try to report the issue you're seeing. Similar to how you reported it here. If I load this, then this happens. Don't put your life story in there, just state the facts. Hopefully the developers are able to reproduce the issue, but they may ask for some more specific information.


----------



## blind0ne (Nov 2, 2021)

SirDice said:


> Just try to report the issue you're seeing. Similar to how you reported it here. If I load this, then this happens. Don't put your life story in there, just state the facts. Hopefully the developers are able to reproduce the issue, but they may ask for some more specific information.


Where should I post it?


----------



## SirDice (Nov 2, 2021)

blind0ne said:


> Where should I post it?








						FreeBSD Bugzilla Main Page
					






					bugs.freebsd.org


----------

