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;
}
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [email protected]
