FW: Looking for basic documentation on Cygwin and Serial Ports

Charles Wilson wrote on 25 April 2008 18:16:

[ Thread duely TITTTL'd ]

> 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).

  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.

  Oh, and they appear to be none too reliable downstream of
hubs either.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Dave Korn wrote:
>   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).

Okay, I lied. That /did/ happen to me once -- but I didn't
blame the 
FTDI driver.   I blamed my five year old laptop that had
never been 
defragged or had its OS refreshed. <g>

I had to remove the battery, and then deliberately unplug
the PS. 
Laptops don't really have anything other than a soft reset
button which 
they call a "power" button.  But it takes software
somewhere to 
recognize "Oh, he held the 'power' button down for five
seconds -- that 
means actually shut off now"

Unless your power management settings say that it means
hibernate, 
instead. Like mine did. yeesh.

>   Oh, and they appear to be none too reliable
downstream of hubs either.

That was my configuration when the above occurred.

--
Chuck

> > 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.

Gary R. Van Sickle wrote on 26 April 2008 20:26:

> 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, 

  <puts hand up>

> in which case the law doesn't need to apply 

  Hah, they'd never take me alive anyway!

> [ ... ]  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.

  ISTM these days that there's actually plenty of info out
there.  It's
actually been several years now since they /started/ taking
seriously the
notion of documenting the ddk apis properly, and there's
also always been a
lot of good books and folks like OSR and sysinternals.  If
you understand all
the principles of device driver coding from other
environments (resource
management, synchronisation and hardware programming issues,
for the most
part) then I figure a copy of the Dekker/Newcomer driver
book and the Nebbett
Native API book should be all you need to be capable of
writing and debugging
a decent quality windows device driver.

>>   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:

  Hmm, I think I'd point a fair amount of the blame at
FTDIchip and their
partner companies in this case, for poor co-ordination.  In
fact FTDI do run a
subregistry with their PID block and offer to issue ranges
to their customers,
but somehow the damn things still end up clashing. 

> - The organization responsible for this travesty is run
by the richest men
> in the world.  Must be good to be king.

> [ ... ] the situation is even more pathetic, were that
> possible.  [ ... ] if Microsoft would simply [ ... ]
> instead of actively fighting its very existence.

> but I guess that's asking too much of the richest SOB
in the world.

  Heh, we'll make a M$-hater of you yet.  You're half the
way there already,
and for all the right reasons.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....