OK - be creative. End the flames, throw some ideas. Here goes another summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be "censored" in the distributions.
1. Any kind of network protocol that would talk to "driver". PRO - Possibilities to use JTAGs over internet to debug remotely, possibility to use closed-source drivers (for me that's a pro [; ) CONS - latency of the medium, need to run another program on one's PC, someone has to create the program and that has to be more complicated than the one from option 2. 2. Modular OpenOCD which would allow binary "drivers" to be used (just as the drivers are used in Linux kernel) PRO - possibility to use closed-source drivers (same as above), no need for running additional software other than OpenOCD, no speed penalty of the medium CONS - someone would have to create the "driver" (this would be much easier than in option 1) 3. Creating a libftdi replacement dll that would mimic libftdi API but use ftd2xx.dll (propsed by Magnus Lundin in a separate thread) PRO - probably easiest of solutions, no speed penalty, no need for additional software CONS - user has to KNOW about that to use the replacement, APIs of ftd2xx.dll and libftdi.dll are probably not 100% compatible (?) (the PRO and CONS are not complete of course, just as there maybe more solutions). Personally I think that options 1 and 2 should be introduced anyway, because they are good (especially option 1 is very interesting!). For the short term solution I think option 3 would be quite OK, we can all agree to kill that once a better solutions exist. I'm willing to help with any of those, but - as I'm not a hard-core PC programmer, that help would probably by minor compared to others. Please - don't throw any suggestions like "I'll do it for $$$" here. 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
