Building Gecko.NET from source

[Nuke]

Thanks for clearing that up. So far I have not run into any problems but I have only made a test application with it (part of the sdk which I plan to release with SE) and it hasn't crashed. Bushing did tell me long before I started using Mac hardware that the drivers were not very good and I trust him when it comes to anything related to Mac stuff.

I shall set up libftdi and give it a try.

btw isn't VCP only USB 1.1 spec, i.e can't handle a 64K down packet?

Well, I am not sure if d2xx is supported correctly. Basically I do not have a Mac personally, I was talking to 2 Team Twiizers back then and they literally complained about the official ftdi driver for being hardly supported, slow and unreliable (meaning it sometimes crashes). The major downside of it: rather than supporting to be a Virtual COM Port or a D2XX library at once you can choose one of both - D2XX outrules the COM port and vice versa.

As far as I can see libftdi is its own implementation: so libftdi is not 100% D2XX compliant and not 100% COM Port either. Internally libftdi uses libusb and directly communicated via USB.

@giantpune: your code seems interesting!

[Link]

btw isn't VCP only USB 1.1 spec, i.e can't handle a 64K down packet?

I do not know for sure, but I also did hear something like that!

[dcx2]

USB 2.0 doesn't handle 64k packets.  The max packet size for a single Hi-Speed USB transfer is usually 512 bytes (for Full-Speed devices, it's 64 bytes).  It is the responsibility of the driver to split a larger packet up into smaller packets.

I checked Jan Axelson's website - http://www.lvr.com/usb_virtual_com_port.htm - and I couldn't find anything that restricts the max packet size to that of Full-Speed devices.  Perhaps the restriction you refer to is a result of FTDI's driver, and not the USB spec?