driver for rs232 to usb

blind0ne

blind0ne

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?
 
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.
 
blind0ne said:
Witch programs and manuals could you advice to resolve this problem.
Click to expand...
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.
 
  • Thanks
Reactions: a6h
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 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.
Click to expand...
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.
 
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"
 
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"
Click to expand...
But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another
 
blind0ne said:
But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another
Click to expand...
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.
 
blind0ne said:
But could this setting be defferent for 2 console cabels? Why it works on one cable but dont want on another
Click to expand...
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.
 
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.
Click to expand...
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.

en.wikipedia.org

FTDI - Wikipedia

en.wikipedia.org en.wikipedia.org
 
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.

en.wikipedia.org

FTDI - Wikipedia

en.wikipedia.org en.wikipedia.org
Click to expand...
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.
 
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.
Click to expand...
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.
 
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.
Click to expand...

It's just gives me canot open /dev/cuaU0, on minicom -b 38400 -D /dev/cuaU0. The driver is loaded already.
 
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).
 
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).
Click to expand...
Yep I'm trying from root, but still no errors, just empty tty.
 
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 :)
 
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?
 
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?
Click to expand...
ugen5.2: <vendor 0x1a86 USB2.0-Ser> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA)
 
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?
Click to expand...
# cat /boot/loader.conf
uchcom_load="YES"
 
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.
 
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.
 
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.
Click to expand...
So i'm locked in windows with this chip? Is it theoreticly possible to fix this issues on freebsd?
 
blind0ne said:
Is it theoreticly possible to fix this issues on freebsd?
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top