Hello Maciej, Maciej Grela napsal(a): > A friend of mine pointed me to the threads concerning > GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an > idea came to my head - what if we implement our own GPL/LGPL version > of libd2xx.dll ?
This is also an option, but there are problems mainly in maintainance of compatibility - these days there is more than just a single version of the chip while FTDI keeps compatible API - I am not sure whether the compatibility is maintained in the driver or the DLL but I experienced a situation after driver update that different versions of driver and DLL are not necessarily compatible. > From my investigation it seems, that the driver does all the hard > work, the DLL itself just calls some ioctls. However, this is completely undocumented. > Also, the driver is the > only thing, that needs to be signed if I understand correctly. Yes, you are right. > Obviously, GPL code can communicate with drivers using system calls so > I don't suspect any traps. Correct, despite (as stated in my previous post) I really do not like the qualification of communication to "GPL allowed" and "GPL prohibited", GPL speaks so. > Also, Freddie, can I ask for more details about your performance > comparisons ? You've said, that libd2xx performs better than libftdi > but is this only under windows ? What is the speed difference between > libftdi + libusb under linux, libftdi + libusb under windows and > libd2xx + native windows driver ? I'm trying to figure out if the > windows driver does some magic to speed up the transfers or does > libusb suckiness on win32 cause it's inferior performance. The problem with libftdi used to be that it was not able to do async I/O operations, which meant that data was not read from the chip during writing larger block to it - this might cause buffer overflow. Because of that there had to be quick write/read turnarounds with small block sizes - what fits into the on-chip buffer. However when I looked into recent libftdi sources I assume this is no longer true, so the performance difference shall not be that significant these days - in theory. Best regards, Pavel _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
