FW: Looking for basic documentation on Cygwin and Serial Ports

FW: Looking for basic documentation on Cygwin and Serial Ports

[Dave Korn]

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

Re: FW: Looking for basic documentation on Cygwin and Serial Ports

[Charles Wilson]

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

RE: Looking for basic documentation on Cygwin and Serial Ports

[Gary R. Van Sickle]

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

RE: Looking for basic documentation on Cygwin and Serial Ports

[Dave Korn]

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