Like in Linux you have to add/register the DeviceID so the OS will use the CDC driver.
I'm not sure what you mean.
I have used a lot of random USB/Serial dongles over the years and never had to do anything to have them working.
Presumably the udev rules in Linux already know how to recognize most common chips out there.
But anyway, it makes no sense to me to have to use vendor and product IDs to determine what a device is. As long as it does the job who cares who made it and what they call it? The device should announce that it is a serial adapter and that is it. I thought that was what "plug'n'play" as supposed to be all about.
Everybody here is claiming that there is no CDC driver in Windows. This is not true at all.
There is no CDC driver in Windows XP. That is true. But all Windows Versions since XP (Vista, W7, W8, W2003 - W2012 Server) do have a CDC driver.
With that list, it suggests it should be possible to install a CDC driver for Win XP ? Does that exist ?
I see FTDI have CDC libraries for VNC2, perhaps they will also release CDC & HID for their new FT51 ?
( http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT51.pdf)
With that list, it suggests it should be possible to install a CDC driver for Win XP ? Does that exist ?
I see FTDI have CDC libraries for VNC2, perhaps they will also release CDC & HID for their new FT51 ?
( http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT51.pdf)
Well, it is for sure possible to write a CDC driver for XP. Just Microsoft will not do that. They stopped support for (XP, W98, W95, W3.12, etc.)
Chris, I would never suggest that Parallax or any other company immediately cancel all products that require FTDI devices / drivers and redesign everything to avoid them. That is clearly an expensive road to chaos and ruin. What I find appalling is that a company like Parallax needs to supply a driver for a serial port. Using an external device that requires a humble serial connection should not dictate messing with the guts of the users operating system, installing executable code of untraceable provenance into the the very kernel of the OS. Equally appalling is that Microsoft has to ship a driver from a hardware manufacture for such a simple thing as a serial port. How come this is not a standards compliant part of the OS provided by MS already? Serial devices are part of the USB specifications along with mice and keyboards etc. That's before we get to talking about how the hell it happened that some little company managed to slip malware through Microsoft's update system that can cause users systems to fail. The whole regime is suspect. What should one do? Pretend nothing has happened and continue as usual? Or start to think about a way out of this mess?
I understand your concerns and I don't have an answer for those last questions, which is why I left my answer specific to our immediate future actions. There's no telling what the future holds, however I don't see any reason why this current situation should cause an immediate change on our part. I really do hope that some day hardware like this is simply supported by the O/S, but that would require a level of cooperation between the manufacturers and O/S developers that would probably be impossible. But we can hope.
.. I really do hope that some day hardware like this is simply supported by the O/S, but that would require a level of cooperation between the manufacturers and O/S developers that would probably be impossible. But we can hope.
See #151 - however, when you dig deeper, you find that CDC is only a (strange) subset of a serial port, if fails to be able to read CTS. Some designs use CTS for other than flow control, and that use fails.
You really wonder who compiles these 'standards' sometimes.
["If you want to use CTS in an unconventional way, such as having a host application read a switch state on a device, you’re out of luck with the CDC driver unless you can define a vendor-specific command that travels on the same bulk pipes that carry application data."]
Comments
I have used a lot of random USB/Serial dongles over the years and never had to do anything to have them working.
Presumably the udev rules in Linux already know how to recognize most common chips out there.
But anyway, it makes no sense to me to have to use vendor and product IDs to determine what a device is. As long as it does the job who cares who made it and what they call it? The device should announce that it is a serial adapter and that is it. I thought that was what "plug'n'play" as supposed to be all about.
With that list, it suggests it should be possible to install a CDC driver for Win XP ? Does that exist ?
I see FTDI have CDC libraries for VNC2, perhaps they will also release CDC & HID for their new FT51 ?
( http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT51.pdf)
Well, it is for sure possible to write a CDC driver for XP. Just Microsoft will not do that. They stopped support for (XP, W98, W95, W3.12, etc.)
Enjoy!
Mike
I understand your concerns and I don't have an answer for those last questions, which is why I left my answer specific to our immediate future actions. There's no telling what the future holds, however I don't see any reason why this current situation should cause an immediate change on our part. I really do hope that some day hardware like this is simply supported by the O/S, but that would require a level of cooperation between the manufacturers and O/S developers that would probably be impossible. But we can hope.
See #151 - however, when you dig deeper, you find that CDC is only a (strange) subset of a serial port, if fails to be able to read CTS. Some designs use CTS for other than flow control, and that use fails.
You really wonder who compiles these 'standards' sometimes.
See http://janaxelson.com/usb_virtual_com_port.htm
["If you want to use CTS in an unconventional way, such as having a host application read a switch state on a device, you’re out of luck with the CDC driver unless you can define a vendor-specific command that travels on the same bulk pipes that carry application data."]