On Windows (either native or running on a virtual machine from a Linux host), I can open a serial port in 8N1 mode and my desired speed of 921600 bps, and an incoming test string arrives fine from an external hardware device: HELLO WORLD.
On Linux, however, with same serial configuration I can only get slightly garbled text: H�LLO �OR�D.
However, lower baudrates (such as 460800 bps) work fine in both Windows and Linux. So by using 921600 bps I'm clearly hitting a speed maximum, imposed by some component of Linux.
Why does this happen? Does Linux have a default limit on serial baudrate? Is there anything I should configure to enable baudrates higher than 460800 bps?
Some more details:
The external device's serial output is connected to the computer via a CH340G-type serial-to-USB converter.
Tested software is TeraTerm and PuTTY on Windows, picocom, minicom, and screen on Linux.
Tested O.S. versions are Windows 7, Ubuntu Linux 16.04, and Ubuntu 20.04.
As mentioned (but it's worth repeating it), the text can be read fine if opening the serial port on Windows running from a VirtualBox virtual machine, from the same Linux host that is not able to cope itself with the mentioned baudrate! I guess this works because VirtualBox simply does a USB device passthrough, so whatever limits Linux has, they don't apply to the virtualized Windows.
In theory, my Linux seems to support the requested speed: the file /usr/include/asm-generic/termbits.h contains the definition for B921600 (together with lower ones such as B460800, and lots of other higher ones that go up to B4000000).
There is/was a bug on the CH340 driver.
Apparently, the baud rate error for 921600 bps was more than 7%. I guess that's what you might be experiencing.
I don't have any such devices so I did not research this further and I'm not sure if the patch or patches written to fix this issue ended up on the mainline kernel.
You will have to go here and find out yourself.
Related
I have a virtual machine with Linux (Lubuntu) on a Windows 10 Host. From my virtual machine i wanna connect with python to an external device via a serial port and read 1000 bytes. Therefore i am using the pyserial library.
On the Windows 10 host i just can use
if(serialHandler.isOpen()):
serialHandler.read(1000)
and everything works perfect.
In the linux virtual machine this the same code gives me only 512 Bytes. So i tried to put the read call into a while loop. It Looks like
if(serialHandler.isOpen()):
while serialHandler.inWaiting():
serialHandler.read(1)
Anyways it gives me only 512 Bytes back. I tried several things without any success. I tried to delay the thread (sleep) to give the external device further time to process my read request. I tried to different codes with timeouts etc.
All gives me only 512 Bytes exactly. My assumption is that the root of this issue has to do with the serial buffer in Linux but i cannot resolve it. How can i get the second half of the 1000 bytes i need? Has it to do with the port mapping from the Linux virtual machine to the windows host? Any hints to solve the problem?
UPDATE:
LUBUNTU Linux System: Release 14.04, Ubuntu 14.04.3 LTS
In serial settings of the virtual machine i tried already "Host-Pipe" and "Host-Device" for configuring the COM Port on the Linux VM System. Both doesn`t make a change.
I am working with a SOM mounted on a carrier board running Ubuntu 14.04 with the generic 3.13 kernel.
While testing out the peripherals, I hit a problem with serial communication.
Basically, I can transmit data from the custom platform to an external Linux machine, but I can not properly receive data from the external Linux machine to the custom platform.
Through my research I have messed with all sorts of BIOS settings, baud rates, hardware flow control, parity, etc. Nothing has worked. Most info I have found online just says "Make sure your baud rates and other settings match", and they do. It is not my first time working with Linux serial ports. But it is my first time encountering a problem like this.
Does anyone have any suggestions, recommendations, or has anyone ever seen an issue like this before?
More info: We are running a quad-core Intel Atom micro with a custom serial breakout interface. The serial port is at /dev/ttyS0.
EDIT (clarification):
If I set up a session in Picocom or Minicom, I can send characters from our custom platform (running Ubuntu 14.04) to another Linux PC (also running Ubuntu 14.04). However, if I try to send characters from the Linux PC to our custom board, I sometimes get nothing, and other times get unrecognized characters (they show up as bubbles with question marks in them).
I can also simply echo a string to /dev/ttyS0 on the custom platform and receive it on the Linux PC. I just can't get it to work the other way around.
Simple question - how to map serial port (serial2USB as /dev/ttyUSB0) to XenApp with Citrix receiver 13 on Linux (Ubuntu 13)?
With Citrix receiver 12, I can run connection manager (wfcmgr) and map desired port in preferences, but CR13 dont have this manager. I tried to manually edit wfclient.ini and put there these lines (copied from wfclient.ini used by CR12):
LastComPortNum=1
ComPort1=/dev/ttyUSB0
But nothing happened. In addition, I found this link so maybe I should ask: How to redirect USB devices? (and throw away this COM antique)
So, lines in wfclient.ini are correct but I was operating with incorrect information that unix kernel v.2.4.20 (and higher) contains drivers for TFDI devices. Truth is that these drivers are in kernel v.2.6.31 (and higher). I should have to check dmesg... sigh
I'm trying to write a linux driver to a device that i have the windows driver of (Similar to the case described Here, but a different device)
I'm using Libusb for the communication on the linux side, and SourceUSB as my USB sniffer (on the windows machine). Now I think I've replicated the controls and bulks properly, but I can't really test the linux log against the windows one. I'm running Ubuntu 12.04 on a VM.
So my questions are:
Is there a multiplatform logger? That could really simplify the log compare process.
When I attach the USB device to the VM - I get the VM driver in Windows. Sniffing this device gives me exactly what the device sees, right? I mean - Is this where I want to sniff?
EDIT:
I've compiled my application on windows (libusb is cross platform - A big thanks to libusb developers who did such a good job) and my application worked properly.
When sniffing the VM driver while running my application on linux, I see the requests to the USB as VENDOR_DEVICE instead of CONTROL_TRANSFER and BULK_OR_INTERRUPT. This seems to be the problem if I understand correctly, since this is what the device "sees".
So I guess my problem now is why does Linux sends my requests as vendor.
ANOTHER EDIT: Problem solved:
Listening to the VM driver gave me the wrong requests (I was listening to the VM driver traffic, not, as i wanted, the traffic of the my USB linux driver
Libusb is perfectly multiplatform. It took me a few minutes to get my code to compile under windows, and from there it was pretty easy to debug and compare logs
You can use Wireshark to capture USB traffic. This page explain how to do it for Linux and Windows : CaptureSetup/USB
and I want to know if my chipset is capable off doing those things
My chipset is a intel centrino advanced 6200-n on a sony vayo laptop running on windows 7.
Now, I know that windows is only capable off listening, so I boot backtrack 4
from a usb stick.
I also want to know if a live distribution can work flawlessly with the wificard even if it does not support formentioned things, because I try'd to use wget to download something
and it says it ca not resolve the address?
thanks, Richard
Intel centrino advanced 6200-n does support both monitor mode and frame injection with iwlwifi driver. There are some intricacies involved on driver side though so it is best to use very recent kernel to make it work reliably. The patches which make this work well are expected to be part of Linux kernel version 3.5, until it's released you can build kernel yourself from iwlwifi.git tree:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi.git
Instructions on building kernel from a git tree:
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
It should also work with older kernels.
As for the fact that you couldn't wget something - have you connected to wireless network at all? Standard client mode in iwlwifi works very well even with old kernels.