Recommendations for a serial port card you can actually BUY?

[Andrew Gordon]

On Thu, 5 Oct 2006, Karl Denninger wrote:
> On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote:
> > I have used USB-to-serial converters with no problem. All the control
> > signals (at least the ones my applications need) seem to work
> > correctly. I don't remember any brands or models off hand, I bought
> > what was cheap as I needed them and they all worked. "Cheap" means
> > under $20 delivered (for one port).
>
> Interesting.
>
> Now, what happens when you reboot?  Do they come back in random order?
> That won't work!  I need to know that port 2 will BE Port 2 the next time
> the machine comes up....

Competent USB devices have serial numbers in them, although the current
FreeBSD USB system doesn't provide easy access to the data (the
kernel collects it as part of the device discovery, but AFAIR doesn't do
anything with it).  I solved my problems in a different way (below).

As already mentioned in this thread, USB serial adapters fall into the
'too cheap' category (the purchase cost isn't worth mentioning, but you
have no idea what will arrive when you order one).  IMO, it's worth
standardising on one adapter type (hence one device driver) and spending a
bit more time/money on the purchasing.   I standardized on adapters
using the FTDI chips  (www.ftdichip.com, they sell their own adapters but
these chips are widely used and I've usually bought mine elsewhere).
FTDI have been through about 3 generations of these chips while remaining
driver compatible.

When I started (several years ago), the uftdi driver wasn't up to the job
for the sort of reasons you mention (control of handshakes, real-time
control), but for my applications it was convenient to avoid using uftdi
and simply address the devices with the ugen driver - giving me direct
control over the handshakes, the FIFO timeout behaviour etc.   I believe
that uftdi has since improved and may now be the right way to go if your
applications want a tty-style interface (I don't use it much, having as
above written all my serious applications another way).

The FTDI devices keep the device descriptors etc. in an EEPROM, so my
approach to the 'which port is which' problem was to change the textual
part of the descriptor - "usbdevs -d" then immediately tells you what is
going on.  The EEPROM is writable over the USB connection - I have a
program to do so if anybody wants it.