The handling of the device configuration is subtile. On one side new attached devices shall be recognized automatically in case that they are FTDI devices. On the other side you may want to have great flexibilty in assigning special names and starting automatically applications related to one or more certain devices.
So the FTDI driver implements both requirements in the following way. To allow maximum flexibility it supports Castles USB Alias matching with some extensions.
The FTDI driver only handles a devices if you are telling it to so by using the command
FTDIDriver_Claim USB_DeviceNo [-P Pendant_Extension] [-C Own_Config_Extension]
If FTDIDriver_Claim is executed for a certain USB device it will determine the USB VendorID and ProductID of the device and it will add the pendant extension if given to it. Then it will evaluate the according setting file inside the "Devices" directory and create a copy of it inside Choices:FTDI.Devices directory if this is not already available. If given the copy will get a given own config extension at its end. This content of the configuration file inside Choices:FTDI.Devices directory will be used to setup the device.
Important note: FTDIDriver_Claim is perfomed as callback by the FTDI driver due to certain USB problems which has the consequence that you won't get errors even FTDIDriver_Claim generates them properly.
For the driver it is not possible to recognize which pendant of a certain identification is attached. It is also impossible for the driver to distinguish how to setup several identical devices with the same identification. You must help it by providing the pendant and/or config extension in such cases. But the driver can recognize whether it is able to support a certain device type in general. The driver can support a FTDI device in the case that a corresponding device configuration file is provided inside its "Devices" directory.
If the FTDI driver starts it will evaluate the "SetAlias" file inside the Choices:FTDI directory. If this file does not exists it will created it without any Alias settings. After the "SetAlias" file has been executed a small program "NewDevs" will be executed which will look for attached USB devices which might be handled by the FDTI driver and register them into the "SetAlias" file as if they had been just attached.
If an USB device is attached the FTDI driver examines whether there is an Alias setting for the hexadecimal USB VendorID and ProductID. If this exists no further action will be taken by the driver. It will just wait until this Alias setting is evaluated and will execute a FTDIDriver_Claim. If the setting does not execute such a command it is ok and the driver won't take control over the device.
However if no such Alias setting is available the FTDI driver will look inside its "Devices" directory for a matching device configuration file (but not for pendant files!). If it finds such a file it will generate an according Alias setting leading to an according FTDIDriver_Claim, will add it to the "SetAlias" file inside the Choices:FTDI directory and will claim the device. This must be done because inside the USB driver the alias matchings are calculated and queued before the USB device attach service call is done. Which in our case leads to the situation that there are no accordings alias settings.
For coping with device pendants and several identical devices you have to edit the "SetAlias" file inside the Choices:FTDI directory because it is as mentioned above impossible for the driver to distinguish the devices automatically. Note that the changes inside the file will only have effects after the FDTI driver is restarted.
The FDTI driver uses Aliases of the format
Alias$@USBDevice____VVVV_PPPP____
to handle its devices. Where VVVV is the hexadecimal USB vendor ID and PPPP is the hexadecimal USB product ID. These Aliases are added to end of the "SetAlias" file every time when a new FTDI device is recognized. The Alias entry is followed by a line which causes the FTDI driver to claim the according already attached devices after the driver has been startet.
A pendant is a device which uses a certain USB vendor/product id combination which is assigned to another USB device. Usually this doesn't happen for USB devices but with the FTDI driver chips there is a special situation. FTDI has claimed vendor/product id for their chips and the chip is that what USB sees. So all FTDI based devices would look identical to USB even they are entirely different (emulating serial or parallel ports and so on). So FTDI chips provide the possibility to setup an own vendor/product combination for every product. However unfortunately not all manufacturers of devices containing FTDI chips are making usage of this. So you have to extend the according FTDIDriver_Claim commands by the pendant parameter.
Some remarks on the USB Alias concept must be made here to avoid trouble. As mentioned above the according Alias commands for a device are determined as it is attached. They are queued internally and yes launched from a callback procedure asynchronously. This might lead to race between the device attach service call and the execution of the alias commands which is handled properly by the FTDI driver concept. More important are the limitations resulting from command execution out of callback. It seems that the USB driver doesn't like it to get an opening of a stream inside callback mode. Therefore FTDIDriver_Claim is executed also as callback by the FTDI driver. The actions you can perform inside the Alias command line are limited to commands. Eg you can't start a small BASIC program to perfom more complex things for you or an application directly. But it is possible to execute several commands. Starting applications belonging to a certain device is such a thing. StartDesktopTask would allow this but the FTDI driver might be started before the WIMP has been started and so the application won't execute.
Difficult is also the handling of several devices of the same type. Each device might be configured in a different way (eg in baud rate). Note that the configuration also includes the device name which can be used only once. To handle different configuration files you have to add the own config extension parameter to FDTIDriver_Claim. However the standard USB Alias concept doesn't allow to distinguish between the devices of the same type. The only possibility to distinguish them is the usage of the position inside the USB bus topology or the device serial number. The USB device number can't be used for the addition of a single device or an USBReset will change it. To simplify this problem for you the FTDI driver provides the command
FTDIDriver_DeviceAlias USB_DeviceNo [Default_Command]
When this command is executed. The FTDI driver determines the Vendor- and Product-ID of the given device and searches for Aliases of the following scheme in the given order:
Where VVVV is the hexadecimal USB vendor ID and PPPP is the hexadecimal USB product ID. BBUUUUUUUUUU represents hexadecimal bus position as returned by DeviceFS_CallDevice for USB 1<<31 + 4. You can obtain this number by looking into !USBinfo topology window. The USB device serial no is text as reported by USBDevinfo. If an Alias is found it is executed by appending the device number as parameter at its end. If no Alias is found the optional given default command is executed also with appending the device number at its end.
You can edit the Choices:FTDI.Devices files according to your preferences. Especally the device name and baud rate might be of interest especally in conjunction with subsequently started applications.