5

I'm trying to get 9bit serial working for communication with a device that requires the 9th bit set high in order to receive (yea, I know...).

I'm using a pretty standard USB-RS232 dongle with an FTDI chip in it and it appears to be using the FTDI drivers on the system.

I've been using this guide for MARK/SPACE parity which my research suggests is the only way to go (?) and basing my code off of this which I've been lead to believe is terrible but, hey, that's never stopped me before.

I'm pretty sure at this point that the Linux FTDI drivers completely ignore CMSPAR but if anyone knows otherwise, your input would be greatly appreciated. I do know for a fact that the FTDI dongle I have can, in a limited capacity, support 9bit serial as I have the dongle working fine on a windows machine.

Assuming nobody has a magical answer to all of this, the main question I'm asking becomes, how difficult it would be to "fix" the FTDI driver, if necessary, to work? Additionally, where would be a good place to start for someone with limited experience with linux device drivers? Assuming all goes well, it seems I'm not the only person with this problem so it would be great to contribute something, however small, to the community.

Community
  • 1
  • 1
pdel
  • 685
  • 12
  • 23
  • If the feature works on Windows, then it would presumably be supported in the firmware and you might be able to figure out how to activate it by packet sniffing the windows driver. I think from windows 7 on there is actually a stock USB sniffer available from Microsoft as an ad-on tools download. Running windows in a VM and sniffing on the hosting operating system might be another option. – Chris Stratton Mar 31 '15 at 19:03
  • Another thing to look into is how hard it would be to push 9-bit data through the Serial API. If that seems like it is going to be hard, you also have the option of not running a kernel(module) USB-Serial driver but rather talking to the raw USB device from userspace using either Linux USB APIs or something like libusb wrapping them. – Chris Stratton Mar 31 '15 at 19:07
  • 1
    The driver itself should be OK provided your kernel isn't older than [this commit](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/ftdi_sio.c?id=38fcb8309964b94d0c0499982583d7f30b40abec) - unfortunately I don't know enough about the bit in between to be helpful. As for general driver reference, [LDD3](http://lwn.net/Kernel/LDD3/) is always a good start. – Notlikethat Mar 31 '15 at 19:24
  • IMO the fundamental problem of using an 8-bit UART/USART for 9-bit data is that you cannot simultaneously transmit and receive (because the setting of parity is common to Rx and Tx in HW & SW). That may not be an issue if you have a master/slave configuration. – sawdust Mar 31 '15 at 23:15
  • @ChrisStratton thanks for the info. That's an interesting approach I hadn't considered. – pdel Apr 01 '15 at 00:58
  • @Notlikethat I'll have to double check the kernel but I assume its newer. I'll have to dig a bit and figure out how this affects things. Thanks for the LDD3 link, that's super helpful. – pdel Apr 01 '15 at 00:59
  • @sawdust valid point and while I can't say a ton about the protocol here, its very much a master/slave setup with the linux system pinging other devices and waiting for a reply. Shouldn't be an issue since the devices are way too dumb to handle any sort of full duplex. – pdel Apr 01 '15 at 00:59

1 Answers1

0

If the ninth bit should always be high, just use 8 data bits and one more stop bit than you would normally be using.

To gain more control, use the D2XX Direct Drivers that provide a relatively simple C API.

Tom
  • 3,281
  • 26
  • 33