RE: Looking for basic documentation on Cygwin and Serial Ports

["Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>]

> > Dave Korn wrote:
> > 
> >>   AAAARGH[*]!  FTDIchip are the bane of my life at the 
> moment.  Buggy 
> >> drivers. I hate them so much <spit>.
> >> 
> >> [*] - I just got back from rebooting a testrig that locked 
> up due to 
> >> buggy ftdichip drivers at about the twentytwo-hour point into a 
> >> twentyseven-hour testrun.  I am not happy.
> > 
> > Wow. I've been using them too, but have had no problems at all
> > (WinXPsp2) from native consoles (no cygwin involved, if 
> that matters).
> > Then again, I wasn't trying to run 27 hour tests.
> 
>   The unplug-while-you-still-have-a-handle-open thing is 
> fairly reproducible.
> Device stays busy and can't recover; the COM port can't be 
> opened again until you reboot.
> 
>   As to the lock up crash, I think that it's just a 
> rare-enough race condition that you wouldn't expect to see it 
> except once in (quite a lot of traffic) times.  It's a bad 
> one, though: the screen goes black and the PC stops 
> responding, as if it had dropped into a standby or hibernate 
> state.  Except that it doesn't respond to anything you do to 
> try and wake it, including hitting the soft power button, 
> pressing keys or moving the mouse, and plugging or unplugging 
> USB devices (which sometimes helps flush through the system 
> when its gone wrong by triggering interrupts and other IO activity).
>

There's a new federal law that makes it illegal to blame anybody other than
Microsoft for bad drivers.  The one exception is if you've ever done Windows
driver development yourself, in which case the law doesn't need to apply -
you'll already know why Windows drivers that work are rare and Windows
drivers that work well are essentially non-existent.  I'm not the "M$" hater
that most everybody else in the world is, but their treatment (read:
complete ignoring when not deliberately impeding) of driver developers is
criminal.
 
>   Another issue is that there are an awful lot of devices 
> such as bus analyzers and fpga programmers and so on that all 
> use FTDIchip devices internally, and all the manufacturers 
> ship their own lightly-customised variants of the FTDIchip 
> drivers, many of which are out-dated or immature versions, 
> and the different drivers all stomp on each other trying to 
> claim the same VID/PID combinations.
> 

This is the Windows kernel version of the "don't have multiple Cygwin DLLs
in the same room at the same time" and "installation as an afterthought"
issues.  The key differences being:

- This completely unnecessary problem destabilizes the kernel.
- Windows driver installation isn't an afterthought, it's a
never-even-considered-it-thought.  Only in the last ~year has Microsoft
given so much as lip service to providing any sort of not-a-complete-hack
ability for driver developers to install their drivers.
- The organization responsible for this travesty is run by the richest men
in the world.  Must be good to be king.

In this particular case, the situation is even more pathetic, were that
possible.  There would be no need for FTDI to be developing any drivers at
all if Microsoft would simply support the USB-IF-defined bog-standard
Communications Device Class[1] (which BTW has been around forever), instead
of actively fighting its very existence.

-- 
Gary R. Van Sickle
[1] Of course, it'd help everybody if they'd *properly* support the Device
Classes that they *do* deign to support, but I guess that's asking too much
of the richest SOB in the world.