I have a situation where I am using two FT4232H devices for serial communication via ftdi_sio, and a third device which I wish to use in bit bang mode to set up some control lines in the UARTS which are downstream from
the first two FT4232Hs. These UARTS can be configured as RS232/422/485, etc. Of course, I do not wish to disturb the first two FT4232H devices wrt to their connection to ftdi_sio. However, I must discover all these devices to decide which one I should use
with libftdi. But first, I check how things come up before attempting anything:
dmesg | grep 'ftdi_sio\|ttyUSB'
[ 5.271673] usbcore: registered new interface driver ftdi_sio
[ 5.272285] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 5.288663] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 5.288950] ftdi_sio 1-1.2:1.1: FTDI USB Serial Device converter detected
[ 5.292972] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB1
[ 5.293284] ftdi_sio 1-1.2:1.2: FTDI USB Serial Device converter detected
[ 5.298149] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB2
[ 5.298421] ftdi_sio 1-1.2:1.3: FTDI USB Serial Device converter detected
[ 5.299454] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB3
[ 5.299714] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[ 5.306961] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB4
[ 5.307430] ftdi_sio 1-1.3:1.1: FTDI USB Serial Device converter detected
[ 5.309766] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB5
[ 5.310170] ftdi_sio 1-1.3:1.2: FTDI USB Serial Device converter detected
[ 5.312157] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB6
[ 5.312604] ftdi_sio 1-1.3:1.3: FTDI USB Serial Device converter detected
[ 5.313939] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB7
[ 5.314401] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
[ 5.315814] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB8
[ 5.316152] ftdi_sio 1-1.4:1.1: FTDI USB Serial Device converter detected
[ 5.317715] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB9
[ 5.318218] ftdi_sio 1-1.4:1.2: FTDI USB Serial Device converter detected
[ 5.325421] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB10
[ 5.325745] ftdi_sio 1-1.4:1.3: FTDI USB Serial Device converter detected
[ 5.327572] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB11
As you can see, all the devices are captured by ftdi_sio. Usb 1-1.4 is the device which I would like to use for bit banging.
NOTE: on the Raspberry Pi, running Raspbian jessie, when the bit-banging FT4232 is plugged into the usb hub after the serial comm devices, it always shows up last. Not the best way to choose, but good enough for proof
of concept work.
So, I use FTDI::List::find_all() w/the correct vid and pid. I get this back:
Found the following FTDI devices
================================
FTDI (0x12ea6f0): FTDI, FT4232H MiniModule, FT2B9PTB
FTDI (0x12fb218): FTDI, le,
FTDI (0x12fb230): FTDI, le, `
The garbage returned is a bit unsettling. I know now, from other experiments, that these are the devices which are to be used as the serial communication devices. The program which is driving them, is not running.
Now dmesg shows this situation:
[ 91.700214] ftdi_sio ttyUSB4: FTDI USB Serial Device converter now disconnected from ttyUSB4
[ 91.700314] ftdi_sio 1-1.3:1.0: device disconnected
[ 91.703325] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 91.703456] ftdi_sio 1-1.2:1.0: device disconnected
This indicates that just listing devices disconnects two of the channels from two of the devices which should be actively engaged in serial I/O. I traced the code into libusb and I can't see what is causing this to happen. The fact that it's only the first
channel of each device is explained, perhaps by the fact that the interface is set to INTERFACE_ANY in ftdi_init(). But it doesn't explain why the devices are being detached.
I have tried to use the detach mode setting, setting it to DONT_DETACH_SIO_MODE, but this apparently is used only in the ftdi_usb_open_dev() call.
When I open the device associated with usb 1-1.4 on channel A, dmesg gives me this:
[ 69.506524] ftdi_sio ttyUSB4: FTDI USB Serial Device converter now disconnected from ttyUSB4
[ 69.506629] ftdi_sio 1-1.3:1.0: device disconnected
[ 69.509338] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 69.509428] ftdi_sio 1-1.2:1.0: device disconnected
[ 69.518141] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[ 69.518229] ftdi_sio 1-1.4:1.0: device disconnected
(Yes, these are from different runs, after rebooting, hence the time differences)
For some reason, find_all() traverses the enumerated devices in reverse order. I know this because the last device disconnected above is the first device in the FTDI::List object. Or perhaps it's a function of how things are pushed into FTDI::List.
I'm running out of ideas. I'd appreciate some pointers. Here's the relevant code snippet.
Thanks,
Paul
====================================================================
// Find all available FT4243H devices
int vid =
0x0403, pid = 0x6011;
Ftdi::Context context;
// context.context()->module_detach_mode = DONT_DETACH_SIO_MODULE;
Ftdi::List* list = Ftdi::List::find_all(context, vid, pid);
if (!list->empty())
{
std::cout << std::endl << "Found the following FTDI devices" << std::endl <<
"================================" << std::endl;
for (Ftdi::List::iterator it = list->begin(); it != list->end(); it++)
{
std::cout << "FTDI (" << &*it <<
"): "
<< it->vendor() <<
", "
<< it->description() <<
", "
<< it->serial();
// // Open test
// if(it->open() == 0)
// std::cout << " (Open OK)";
// else
// std::cout << " (Open FAILED)";
// it->close();
std::cout << std::endl;
}
// Apparently, libftdipp traverses the USB enumeration last to first.
// Ftdi::List::iterator portController = list->begin();
// portController->set_detach_mode(AUTO_DETACH_SIO_MODULE);
// std::cout << std::endl << "Choosing first FTDI device discoverd on USB Bus:\n\t "
// << portController->vendor() << ", "
// << portController->description() << ", "
// << portController->serial() << std::endl;
// // Now initialize the chosen device for bit-bang mode, all outputs
// // need to select the interface based on the specified port
// // at present, assume 2 bits per port definition
// enum ftdi_interface iface = INTERFACE_ANY;
// switch ( port ) {
// case PORT0:
// case PORT1:
// case PORT2:
// case PORT3:
// iface = INTERFACE_A;
// break;
// case PORT4:
// case PORT5:
// case PORT6:
// case PORT7:
// iface = INTERFACE_B;
// break;
// default:
// break;
// }
// portController->set_interface(iface);
// portController->set_bitmode(0xFF, BITMODE_BITBANG);
// portController->set_baud_rate(9600);
// portController->open();
// // get the current port definitions
// portController->read_pins(&portTypeDefs);
// std::cout << std::endl << "Initial Port Definitions" << std::endl << "========================" << std::endl;
// printPortDefs(iface);
// // Set the port type for the desired port
// setPortType(port, portType);
// // Call FTDI API to set the desired port types
// portController->write(&portTypeDefs, 1);
// // print out the new port configurations
// std::cout << std::endl << "New Port Definitions" << std::endl << "====================" << std::endl;
// printPortDefs(iface);
// portController->close();
// pause();
delete list;
}
else
{
std::cout << "No FTDI devices found!!" << std::endl;
return -3;
}
