Menu
▾
▴
1 Attachments
#184 Add ftdix driver
ftdi: Add ftdix driver
Mode2 transmitter using the bitbang mode of an FTDI USB-to-serial chip such as
the FT230X. The standard FTDI driver with the FT232R is unreliable having a
IR transmit failure rate of ~2%. The FT232R also becomes unusable if you set
the tx_baud_rate to values other than 65536.
This driver works differently modifying its tx_baud_rate according to the
carrier frequency set. This is ok because the FT230X does not have the timing
bugs present in the FT232R. This allows much lower data rates over USB and
so improves reliablity, particularly if other devices are connect to the same
USB port.
Receive is not included to significantly simplify design of this driver.
Having this driver in the same file as the ftdi driver makes sharing code
easier and avoids confusing plugins/make-pluginlist.sh which is called during
autogen.
I've tested this device/driver with the roku 2 with over 300000 keypresses and have seen no missed keypresses.
See also this discussion here: http://thread.gmane.org/gmane.comp.hardware.lirc/13294/focus=13307
As for the driver file it looks OK at a glance. However, we need some documentation. Could you add a simple file doc/plugindocs/ftdix.html, using doc/plugindocs/ftdi.html as template? Also, update doc/Makefile.am and add a reference to ftdix in the ftdi html page.
If you have time, adding device enumeration would be great for this driver. There is example code in the atilibusb.c driver (look for drvcrtland list_devices).
Last edit: Alec Leamas 2016-04-27
Patch with documentation attached.
In theory enumeration should already be implemented by the ftdi driver. This bit is shared between the two drivers.
Fixed in [3d2bde] and [06f6cc] (master) and [27bd62] (release-0_9_4).
The patches needed some overhaul, visible in the second master commit. If you make new patches, please install the git commit hook as described in CONTRIBUTE.md to automate formatting checks.
The release branch is handled without touching ftdi.c to not break any eggs at this late point.
Related
Commit: [06f6cc]
Commit: [27bd62]
Commit: [3d2bde]
Thanks
Ping? One missing piece is the device enumeration. I can write it, but need help with testing (no hardware). Can you possibly help with some tests if I come up with that code?
EDIT: Yes, it's there, but needs to be rewritten.
Last edit: Alec Leamas 2016-04-29
Ok, what's the issue with it in its current form?
The basic issue is that there is to little information for users to identify each device. While there is more info available in the ...get_strings library call I think it also would make sense to use udev to enumerate them -it's a more general interface used in some other plugins. See e. g., devinput.c.