Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sun, 2009-06-28 at 12:50 +0200, Freddie Chopin wrote: > Dominic pisze: > > It isn't possible with the current ft2232.c code because it uses > > conditional compilation to compile either with libftdi or FTD2XX. While > > offering basically the same functionality there are not only syntactical > > but also semantical differences. If ft2232.c was to support both > > libraries in one binary there would be some rework required. I'm not > > sure if that effort is worth it since ftd2xx might eventually go away in > > the not too distant future. > > I never said that supporting both "drivers" at once is just a matter of > removing these: > > #if (BUILD_FT2232_FTD2XX == 1 && BUILD_FT2232_LIBFTDI == 1) > #error "BUILD_FT2232_FTD2XX && BUILD_FT2232_LIBFTDI are mutually exclusive" > #elif (BUILD_FT2232_FTD2XX != 1 && BUILD_FT2232_LIBFTDI != 1) > #error "BUILD_FT2232_FTD2XX || BUILD_FT2232_LIBFTDI must be chosen" > #endif > > I know that the code would need reworking, but if the maintainers of the > project don't want such changes that's fine for me. Maybe I didn't dig > into the code enough, but I think that such reworking is not impossible, > and not extremely hard. Building both is actually a build system problem. I believe the automake documentation shows how to build a single source file using different configuration options So, symbols similar to those you show above would be defined as extra -D in the automake rules for the targets. I really think that this kind of rework should be fairly easy, if time consuming to get exactly right. Modular driver support _has_ been discussed in the past, to the extent that it was put on the TODO list long ago. :) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 12:54:26 Freddie Chopin wrote: > Everything would be easier if libftdi would be a dll <: Now I'd have to > change and recompile libftdi <: Heh, that's exactly where I was heading with my questions ;). Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Dominic pisze: > How is libftdi, and more specifically OpenOCD with libftdi support build > on Windows? > > OpenOCD ft2232.o references symbols from libftdi which references > symbols from libusb0. On Linux, libftdi and libusb are shared objects > that get dynamically linked. > > You say libftdi isn't a dll? Is it a static library (.a) that gets > statically linked to the OpenOCD? Exactly. only libusb0.dll is a dynamic library. > You further say libftdi's code _statically_ links to libusb0.dll - do > you mean it dynamically links it (since it's a dll I assume that), but > doesn't dynamically load it at runtime (via LoadLibrary)? I'm not a pro, so I used wrong words - again that's exactly what you say. An executable compiled only for ft2232 with libftdi fails to start when there is no libusb0.dll somewhere in the system. Everything would be easier if libftdi would be a dll <: Now I'd have to change and recompile libftdi <: 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Dominic pisze: > It isn't possible with the current ft2232.c code because it uses > conditional compilation to compile either with libftdi or FTD2XX. While > offering basically the same functionality there are not only syntactical > but also semantical differences. If ft2232.c was to support both > libraries in one binary there would be some rework required. I'm not > sure if that effort is worth it since ftd2xx might eventually go away in > the not too distant future. I never said that supporting both "drivers" at once is just a matter of removing these: #if (BUILD_FT2232_FTD2XX == 1 && BUILD_FT2232_LIBFTDI == 1) #error "BUILD_FT2232_FTD2XX && BUILD_FT2232_LIBFTDI are mutually exclusive" #elif (BUILD_FT2232_FTD2XX != 1 && BUILD_FT2232_LIBFTDI != 1) #error "BUILD_FT2232_FTD2XX || BUILD_FT2232_LIBFTDI must be chosen" #endif I know that the code would need reworking, but if the maintainers of the project don't want such changes that's fine for me. Maybe I didn't dig into the code enough, but I think that such reworking is not impossible, and not extremely hard. > Building is always going to require the library headers to be present. > If all interface drivers were to be built unconditionally you'd have to > have all headers present on the build system, which isn't good imho. > Hence the off-by-default convention. But you'd only need headers for libusb, ftd2xx and libftdi - that's not hard to get... > Exactly - but that's not related to the configure options. Being able to > produce a OpenOCD binary that _could_ use all possible JTAG interfaces, > but doesn't require installation of all prerequisite libraries would be > nice. As I said (three times [; ) - that's the main idea. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 11:07:56 Freddie Chopin wrote: > Martin Panter pisze: > > So why loading libusb rather than libftdi? Is it because libftdi is > > only built (or linked to) as a static library on Windows but still > > needs the libusb DLL? > > libftdi is not a .dll, but it's code statically links to libusb0.dll, so > I guess I'd have to modify libusb sources... Don't know whether that > would work, but it should. How is libftdi, and more specifically OpenOCD with libftdi support build on Windows? OpenOCD ft2232.o references symbols from libftdi which references symbols from libusb0. On Linux, libftdi and libusb are shared objects that get dynamically linked. You say libftdi isn't a dll? Is it a static library (.a) that gets statically linked to the OpenOCD? You further say libftdi's code _statically_ links to libusb0.dll - do you mean it dynamically links it (since it's a dll I assume that), but doesn't dynamically load it at runtime (via LoadLibrary)? Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sunday 28 June 2009 11:06:27 Freddie Chopin wrote: > Zach Welch pisze: > > You cannot have both libftdi and FTD2XX support in > > the same FT2232 driver binary, so this patch not even allowing testing > > them both using the same openocd binary (presumably by adding/removing > > the OS drivers between tests). > > Why is that so impossible? init() will try to load one of the libraries, > and in case of failure will try using libftdi. The order is just because > ftd2xx.dll is available as library, whereas libftdi is not. Yesterday > I've thought about that issue a bit and come to conclusion, that I'd > have to modify libftdi code so that it would load libusb0.dll dynamically. It isn't possible with the current ft2232.c code because it uses conditional compilation to compile either with libftdi or FTD2XX. While offering basically the same functionality there are not only syntactical but also semantical differences. If ft2232.c was to support both libraries in one binary there would be some rework required. I'm not sure if that effort is worth it since ftd2xx might eventually go away in the not too distant future. > > Personally, I think that I have failed to see the value of this patch, > > but maybe I have missed something. In contrast to the strategic > > solution, what problems does this current patch solve for OpenOCD users, > > today? Without a clear answer to this, I am not sure why we want it. > > To compile openocd you need to specify dozens of options for configure, > because some of them are exclusive (like support for libftdi and > ftd2xx). I think that it would be possible to modify the code in a way > that ALL possible interfaces would be enabled. It's easier to compile > with "bootstrap, configure, make" than browsing through docs to find all > required configure options... Of course I cannot do that alone, as I'm > not a skilled and experienced developer. A user who compiles the OpenOCD for his personal use is normally going to use only one or maybe two different JTAG interfaces. The available options can be looked up with ./configure --help. Packagers building OpenOCD for a Linux distribution, Windows, or some other software platform (as opposed to packagers building for a particular JTAG interface) are a different story. I suppose they're interested in being able to build for the widest variety of interfaces. Building is always going to require the library headers to be present. If all interface drivers were to be built unconditionally you'd have to have all headers present on the build system, which isn't good imho. Hence the off-by- default convention. > When there would be a binary release it could have just the executable, > without any libraries attached. Now when you do a binary release with > maximum number of interfaces enabled you need to attach some libraries > to it. For example compiling support for rlink makes libusb0.dll > required, even if the end-user uses Wiggler. He doesn't need the library > for use, but OpenOCD won't start without it. Exactly - but that's not related to the configure options. Being able to produce a OpenOCD binary that _could_ use all possible JTAG interfaces, but doesn't require installation of all prerequisite libraries would be nice. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Freddie Chopin pisze: > libftdi is not a .dll, but it's code statically links to libusb0.dll, so > I guess I'd have to modify libusb sources... Don't know whether that > would work, but it should. I meant "libftdi sources" [; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Martin Panter pisze: > So why loading libusb rather than libftdi? Is it because libftdi is > only built (or linked to) as a static library on Windows but still > needs the libusb DLL? libftdi is not a .dll, but it's code statically links to libusb0.dll, so I guess I'd have to modify libusb sources... Don't know whether that would work, but it should. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Zach Welch pisze: > You cannot have both libftdi and FTD2XX support in > the same FT2232 driver binary, so this patch not even allowing testing > them both using the same openocd binary (presumably by adding/removing > the OS drivers between tests). Why is that so impossible? init() will try to load one of the libraries, and in case of failure will try using libftdi. The order is just because ftd2xx.dll is available as library, whereas libftdi is not. Yesterday I've thought about that issue a bit and come to conclusion, that I'd have to modify libftdi code so that it would load libusb0.dll dynamically. > Personally, I think that I have failed to see the value of this patch, > but maybe I have missed something. In contrast to the strategic > solution, what problems does this current patch solve for OpenOCD users, > today? Without a clear answer to this, I am not sure why we want it. To compile openocd you need to specify dozens of options for configure, because some of them are exclusive (like support for libftdi and ftd2xx). I think that it would be possible to modify the code in a way that ALL possible interfaces would be enabled. It's easier to compile with "bootstrap, configure, make" than browsing through docs to find all required configure options... Of course I cannot do that alone, as I'm not a skilled and experienced developer. When there would be a binary release it could have just the executable, without any libraries attached. Now when you do a binary release with maximum number of interfaces enabled you need to attach some libraries to it. For example compiling support for rlink makes libusb0.dll required, even if the end-user uses Wiggler. He doesn't need the library for use, but OpenOCD won't start without it. Moreover - I haven't noticed any thread where anyone would plan on adding "driver modules" in some form to OpenOCD. Actually I remember you and few other maintainers opposing the "driver modules" solution, as a door for closed-source drivers. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sun, 2009-06-28 at 01:23 +, Martin Panter wrote: > On 27/06/2009, Freddie Chopin wrote: > > 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c > > 2. enable dynamic loading of libusb0.dll in ft2232.c > > So why loading libusb rather than libftdi? Is it because libftdi is > only built (or linked to) as a static library on Windows but still > needs the libusb DLL? > > > 3. make it possible to have support for both libftdi and ftd2xx at the same > > time in ft2232.c > > > > n. enable dynamic loading for some other modules - jlink, rlink, presto > > > > n+1. make it possible to have support for both libftdi and ftd2xx at the > > same time in presto.c > > > > I can do the same for linux, but as I have no means for testing I'd rather > > pass that to someone else. With help in testing I can try to do that myself. > > Maybe it's worth trying something like GNU Libtool's libltdl which is > a wrapper around dlopen (Linux), LoadLibrary (Windows) and apparently > stranger things on other platforms as well. I guess you'd still have > to hard code platform specific file names (ftd2xx.dll vs libftd2xx.so > or similar) but it would get rid of most of the platform specific > code. A disadvantage is the added complexity of yet another library to > link to. I would also suggest using libltdl for these tasks; however, that should be a fairly easy change, after eliminating the existing redundancy. After thinking about this patch some more today, I have become confused about its motives. If the binary cannot be distributed with the FTD2XX driver in it, this patch does not help folks that must compile the code themselves anyway. You cannot have both libftdi and FTD2XX support in the same FT2232 driver binary, so this patch not even allowing testing them both using the same openocd binary (presumably by adding/removing the OS drivers between tests). The later suggestion shows that there could be some value of allowing dynamic loading like this, if you provided a second patch to fix the build system to produce both drivers. However, I think that such a patch will only be possible after adding more full dynamic loading for the JTAG interface drivers. Specifically, the proper place to use dynamic module loading will be to discover the jtag_interface structure from each OpenOCD driver module, adding the structure from each successfully loaded module to populate the interface list. With that, you no longer need this patch either, because the module will fail to load if its required libraries are missing. Personally, I think that I have failed to see the value of this patch, but maybe I have missed something. In contrast to the strategic solution, what problems does this current patch solve for OpenOCD users, today? Without a clear answer to this, I am not sure why we want it. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On 27/06/2009, Freddie Chopin wrote: > 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c > 2. enable dynamic loading of libusb0.dll in ft2232.c So why loading libusb rather than libftdi? Is it because libftdi is only built (or linked to) as a static library on Windows but still needs the libusb DLL? > 3. make it possible to have support for both libftdi and ftd2xx at the same > time in ft2232.c > > n. enable dynamic loading for some other modules - jlink, rlink, presto > > n+1. make it possible to have support for both libftdi and ftd2xx at the > same time in presto.c > > I can do the same for linux, but as I have no means for testing I'd rather > pass that to someone else. With help in testing I can try to do that myself. Maybe it's worth trying something like GNU Libtool's libltdl which is a wrapper around dlopen (Linux), LoadLibrary (Windows) and apparently stranger things on other platforms as well. I guess you'd still have to hard code platform specific file names (ftd2xx.dll vs libftd2xx.so or similar) but it would get rid of most of the platform specific code. A disadvantage is the added complexity of yet another library to link to. There's a precompiled Windows libltdl3.dll, static library, ltdl.h etc available from gnu win32: http://gnuwin32.sourceforge.net/packages/libtool.htm ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sat, 2009-06-27 at 20:50 +0200, Freddie Chopin wrote:
> Second version of previous patch improved with suggestions from Ronald.
>
> Pls try (; Works for me <:
This patch now looks 1000 times better with the changes from Ronald.
Thanks to both of you for producing and refining it.
My only remaining suggestion would be to add a macro that eliminates the
duplicate calls the GetProcAddress. From what I can see, each of those
5 line blocks can be reduced into a single macro call with the proper
symbol name as the only argument. The magic that I used to implement
the parse_type helpers in command.c will be helpful to see how to do it,
but you might also need to look up how to "stringify" too.
Thanks for making these improvements.
--Z
> plain text document attachment (win32_ft2232_ftd2xx_dynamic_v2.patch)
> Index: ft2232.c
> ===
> --- ft2232.c (revision 2405)
> +++ ft2232.c (working copy)
> @@ -63,6 +63,51 @@
> #include
> #endif
>
> +/* Dynamic loading of libraries at runtime - only for Win32 and ftd2xx.dll
> currently */
> +
> +#if defined(_WIN32) && BUILD_FT2232_FTD2XX == 1
> +#define FTD2XX_DYNAMIC 1
> +#else
> +#define FTD2XX_DYNAMIC 0
> +#endif
> +
> +#if FTD2XX_DYNAMIC == 1
> +
> +// typedefs for all used functions from ftd2xx.dll library
> +typedef FT_STATUS (WINAPI *FT_Write_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
> DWORD dwBytesToWrite, LPDWORD lpBytesWritten);
> +typedef FT_STATUS (WINAPI *FT_Read_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
> DWORD dwBytesToRead, LPDWORD lpBytesReturned);
> +typedef FT_STATUS (WINAPI *FT_OpenEx_t)(PVOID pArg1, DWORD Flags, FT_HANDLE
> *pHandle);
> +typedef FT_STATUS (WINAPI *FT_ListDevices_t)(PVOID pArg1, PVOID pArg2, DWORD
> Flags);
> +typedef FT_STATUS (WINAPI *FT_SetLatencyTimer_t)(FT_HANDLE ftHandle, UCHAR
> ucLatency);
> +typedef FT_STATUS (WINAPI *FT_GetLatencyTimer_t)(FT_HANDLE ftHandle, PUCHAR
> pucLatency);
> +typedef FT_STATUS (WINAPI *FT_SetTimeouts_t)(FT_HANDLE ftHandle, ULONG
> ReadTimeout, ULONG WriteTimeout);
> +typedef FT_STATUS (WINAPI *FT_SetBitMode_t)(FT_HANDLE ftHandle, UCHAR
> ucMask, UCHAR ucEnable);
> +typedef FT_STATUS (WINAPI *FT_GetDeviceInfo_t)(FT_HANDLE ftHandle, FT_DEVICE
> *lpftDevice, LPDWORD lpdwID, PCHAR SerialNumber, PCHAR Description, LPVOID
> Dummy);
> +typedef FT_STATUS (WINAPI *FT_Purge_t)(FT_HANDLE ftHandle, ULONG Mask);
> +typedef FT_STATUS (WINAPI *FT_Close_t)(FT_HANDLE ftHandle);
> +
> +// library handle
> +static HINSTANCE dynamic_library;
> +
> +// global pointers for read and write functions
> +static FT_Write_t FT_Write_ptr;
> +static FT_Read_t FT_Read_ptr;
> +
> +// replacements for original functions
> +#define FT_Write (*FT_Write_ptr)
> +#define FT_Read (*FT_Read_ptr)
> +#define FT_OpenEx(*FT_OpenEx_ptr)
> +#define FT_ListDevices (*FT_ListDevices_ptr)
> +#define FT_SetLatencyTimer (*FT_SetLatencyTimer_ptr)
> +#define FT_GetLatencyTimer (*FT_GetLatencyTimer_ptr)
> +#define FT_SetTimeouts (*FT_SetTimeouts_ptr)
> +#define FT_SetBitMode(*FT_SetBitMode_ptr)
> +#define FT_GetDeviceInfo (*FT_GetDeviceInfo_ptr)
> +#define FT_Purge (*FT_Purge_ptr)
> +#define FT_Close (*FT_Close_ptr)
> +
> +#endif
> +
> /* max TCK for the high speed devices 3 kHz */
> #define FTDI_2232H_4232H_MAX_TCK3
>
> @@ -1803,6 +1848,78 @@
>
> LOG_DEBUG("'ft2232' interface using FTD2XX with '%s' layout
> (%4.4x:%4.4x)", ft2232_layout, vid, pid);
>
> +#if FTD2XX_DYNAMIC == 1
> +
> + FT_OpenEx_t FT_OpenEx_ptr;
> + FT_ListDevices_t FT_ListDevices_ptr;
> + FT_SetLatencyTimer_t FT_SetLatencyTimer_ptr;
> + FT_GetLatencyTimer_t FT_GetLatencyTimer_ptr;
> + FT_SetTimeouts_t FT_SetTimeouts_ptr;
> + FT_SetBitMode_t FT_SetBitMode_ptr;
> + FT_GetDeviceInfo_t FT_GetDeviceInfo_ptr;
> +
> + dynamic_library = LoadLibrary("ftd2xx.dll");
> +
> + if(dynamic_library == NULL)
> + {
> + LOG_ERROR("Can't open ftd2xx.dll");
> + return ERROR_JTAG_INIT_FAILED;
> + }
> + else
> + {
> + BOOL fail = FALSE;
> +
> + if((FT_Write_ptr = (FT_Write_t)GetProcAddress(dynamic_library,
> "FT_Write")) == NULL)
> + {
> + LOG_ERROR("Can't get FT_Write() function");
> + fail = TRUE;
> + }
> + if((FT_Read_ptr = (FT_Read_t)GetProcAddress(dynamic_library,
> "FT_Read")) == NULL)
> + {
> + LOG_ERROR("Can't get FT_Read() function");
> + fail = TRUE;
> + }
> + if((FT_OpenEx_ptr =
> (FT_OpenEx_t)GetProcAddress(dynamic_library, "FT_OpenEx")) == NULL)
> + {
> + LOG_ERROR("Can't get FT_OpenEx() function");
> + fail = TRU
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Second version of previous patch improved with suggestions from Ronald.
Pls try (; Works for me <:
4\/3!!
Index: ft2232.c
===
--- ft2232.c(revision 2405)
+++ ft2232.c(working copy)
@@ -63,6 +63,51 @@
#include
#endif
+/* Dynamic loading of libraries at runtime - only for Win32 and ftd2xx.dll
currently */
+
+#if defined(_WIN32) && BUILD_FT2232_FTD2XX == 1
+#define FTD2XX_DYNAMIC 1
+#else
+#define FTD2XX_DYNAMIC 0
+#endif
+
+#if FTD2XX_DYNAMIC == 1
+
+// typedefs for all used functions from ftd2xx.dll library
+typedef FT_STATUS (WINAPI *FT_Write_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToWrite, LPDWORD lpBytesWritten);
+typedef FT_STATUS (WINAPI *FT_Read_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToRead, LPDWORD lpBytesReturned);
+typedef FT_STATUS (WINAPI *FT_OpenEx_t)(PVOID pArg1, DWORD Flags, FT_HANDLE
*pHandle);
+typedef FT_STATUS (WINAPI *FT_ListDevices_t)(PVOID pArg1, PVOID pArg2, DWORD
Flags);
+typedef FT_STATUS (WINAPI *FT_SetLatencyTimer_t)(FT_HANDLE ftHandle, UCHAR
ucLatency);
+typedef FT_STATUS (WINAPI *FT_GetLatencyTimer_t)(FT_HANDLE ftHandle, PUCHAR
pucLatency);
+typedef FT_STATUS (WINAPI *FT_SetTimeouts_t)(FT_HANDLE ftHandle, ULONG
ReadTimeout, ULONG WriteTimeout);
+typedef FT_STATUS (WINAPI *FT_SetBitMode_t)(FT_HANDLE ftHandle, UCHAR ucMask,
UCHAR ucEnable);
+typedef FT_STATUS (WINAPI *FT_GetDeviceInfo_t)(FT_HANDLE ftHandle, FT_DEVICE
*lpftDevice, LPDWORD lpdwID, PCHAR SerialNumber, PCHAR Description, LPVOID
Dummy);
+typedef FT_STATUS (WINAPI *FT_Purge_t)(FT_HANDLE ftHandle, ULONG Mask);
+typedef FT_STATUS (WINAPI *FT_Close_t)(FT_HANDLE ftHandle);
+
+// library handle
+static HINSTANCE dynamic_library;
+
+// global pointers for read and write functions
+static FT_Write_t FT_Write_ptr;
+static FT_Read_t FT_Read_ptr;
+
+// replacements for original functions
+#define FT_Write (*FT_Write_ptr)
+#define FT_Read(*FT_Read_ptr)
+#define FT_OpenEx (*FT_OpenEx_ptr)
+#define FT_ListDevices (*FT_ListDevices_ptr)
+#define FT_SetLatencyTimer (*FT_SetLatencyTimer_ptr)
+#define FT_GetLatencyTimer (*FT_GetLatencyTimer_ptr)
+#define FT_SetTimeouts (*FT_SetTimeouts_ptr)
+#define FT_SetBitMode (*FT_SetBitMode_ptr)
+#define FT_GetDeviceInfo (*FT_GetDeviceInfo_ptr)
+#define FT_Purge (*FT_Purge_ptr)
+#define FT_Close (*FT_Close_ptr)
+
+#endif
+
/* max TCK for the high speed devices 3 kHz */
#defineFTDI_2232H_4232H_MAX_TCK3
@@ -1803,6 +1848,78 @@
LOG_DEBUG("'ft2232' interface using FTD2XX with '%s' layout
(%4.4x:%4.4x)", ft2232_layout, vid, pid);
+#if FTD2XX_DYNAMIC == 1
+
+ FT_OpenEx_t FT_OpenEx_ptr;
+ FT_ListDevices_t FT_ListDevices_ptr;
+ FT_SetLatencyTimer_t FT_SetLatencyTimer_ptr;
+ FT_GetLatencyTimer_t FT_GetLatencyTimer_ptr;
+ FT_SetTimeouts_t FT_SetTimeouts_ptr;
+ FT_SetBitMode_t FT_SetBitMode_ptr;
+ FT_GetDeviceInfo_t FT_GetDeviceInfo_ptr;
+
+ dynamic_library = LoadLibrary("ftd2xx.dll");
+
+ if(dynamic_library == NULL)
+ {
+ LOG_ERROR("Can't open ftd2xx.dll");
+ return ERROR_JTAG_INIT_FAILED;
+ }
+ else
+ {
+ BOOL fail = FALSE;
+
+ if((FT_Write_ptr = (FT_Write_t)GetProcAddress(dynamic_library,
"FT_Write")) == NULL)
+ {
+ LOG_ERROR("Can't get FT_Write() function");
+ fail = TRUE;
+ }
+ if((FT_Read_ptr = (FT_Read_t)GetProcAddress(dynamic_library,
"FT_Read")) == NULL)
+ {
+ LOG_ERROR("Can't get FT_Read() function");
+ fail = TRUE;
+ }
+ if((FT_OpenEx_ptr =
(FT_OpenEx_t)GetProcAddress(dynamic_library, "FT_OpenEx")) == NULL)
+ {
+ LOG_ERROR("Can't get FT_OpenEx() function");
+ fail = TRUE;
+ }
+ if((FT_ListDevices_ptr =
(FT_ListDevices_t)GetProcAddress(dynamic_library, "FT_ListDevices")) == NULL)
+ {
+ LOG_ERROR("Can't get FT_ListDevices() function");
+ fail = TRUE;
+ }
+ if((FT_SetLatencyTimer_ptr =
(FT_SetLatencyTimer_t)GetProcAddress(dynamic_library, "FT_SetLatencyTimer")) ==
NULL)
+ {
+ LOG_ERROR("Can't get FT_SetLatencyTimer() function");
+ fail = TRUE;
+ }
+ if((FT_GetLatencyTimer_ptr =
(FT_GetLatencyTimer_t)GetProcAddress(dynamic_library, "FT_GetLatencyTimer")) ==
NULL)
+ {
+ LOG_ERROR("Can't get FT_GetLatencyTimer() function");
+ fail = TRUE;
+ }
+ if((FT
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
I take that back, what you propose is possible and works - I've done that wrong a while ago. I'll create a new version of patch soon. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
But you don't have to repace FT_Write_ptr with FT_Write, just keep it like that and do this: #define FT_Write (*FT_Write_ptr) but depending on how smart the preprocessor is, it might still complain about it, so likely it won't help. Thanks for trying, it's not that big of deal and actually I have nothing to say here anyways, so we can keep it as you made it :-) gr. Ronald Original Message Subject: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c From: Freddie Chopin To: openocd-development Date: Sat Jun 27 2009 20:16:41 GMT+0200 (Romance Standard Time) Ronald Vanschoren pisze: Did you actually try it? There is no redefinition normally (depends on how the .h file of ftd2xx is made) and I think I used this approach before (although slightly different). Guess it's a 2 minute check for you (just one function will do), so if you don't mind :-) When I replace FT_Write_ptr with FT_Write, and define: #define FT_Write (*FT_Write) I get: ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Ronald Vanschoren pisze: > Did you actually try it? There is no redefinition normally (depends on > how the .h file of ftd2xx is made) and I think I used this approach > before (although slightly different). Guess it's a 2 minute check for > you (just one function will do), so if you don't mind :-) When I replace FT_Write_ptr with FT_Write, and define: #define FT_Write (*FT_Write) I get: ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a different place then all the others? Isn't it cleaner to keep all the initializations together? As a trV embedded engineer I've saved some memory [; Keeping all together would be clearer, but I decided to minimise the number of globals and: 1. read() and write() are global, as these are used all the time 2. in ft2232_init() I initialize above two globals and functions that are used only once in ft2232_init() 3. as close() and (probably?) purge() are not used very frequently, I initialize theirs function pointers there - locally. This way there are only 3 globals (hangle + 2 fn pointers) Anyone can tell me whether my assumption about ft2232_purge_ftd2xx() is correct? If that is called often, than I'll make a global pointer for FT_Purge... Fair enough, us embedded engineers might be a bit too focussed on memory, but it's good practice anyway :-) 2) Isn't it possible to define a macro function for the FT_xxx functions in case of FTD2XX_DYNAMIC? Something like: #if FTD2XX_DYNAMIC == 1 #define FT_Close( handler ) (*FT_Close_ptr)( handler ) /* same for all other functions */ #endif This way you don't have to add ifdef's around all function calls and it'll make the patch smaller and less possibilities for mistakes in the future. That would be very cool, but you'd get milions of errors like "FT_Whatever redefined, previous definition was Somewhere", because the definitions of FT_Whatever() is in the header which has to be included, as there are many required constants (like FT_OK) and typedefs (like FT_STATUS) there Did you actually try it? There is no redefinition normally (depends on how the .h file of ftd2xx is made) and I think I used this approach before (although slightly different). Guess it's a 2 minute check for you (just one function will do), so if you don't mind :-) gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Ronald Vanschoren pisze: > I don't have any experience in OpenOCD development Just like me [; > 1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a > different place then all the others? Isn't it cleaner to keep all the > initializations together? As a trV embedded engineer I've saved some memory [; Keeping all together would be clearer, but I decided to minimise the number of globals and: 1. read() and write() are global, as these are used all the time 2. in ft2232_init() I initialize above two globals and functions that are used only once in ft2232_init() 3. as close() and (probably?) purge() are not used very frequently, I initialize theirs function pointers there - locally. This way there are only 3 globals (hangle + 2 fn pointers) Anyone can tell me whether my assumption about ft2232_purge_ftd2xx() is correct? If that is called often, than I'll make a global pointer for FT_Purge... > 2) Isn't it possible to define a macro function for the FT_xxx functions > in case of FTD2XX_DYNAMIC? Something like: > > #if FTD2XX_DYNAMIC == 1 > > #define FT_Close( handler ) (*FT_Close_ptr)( handler ) > /* same for all other functions */ > > #endif > > > This way you don't have to add ifdef's around all function calls and > it'll make the patch smaller and less possibilities for mistakes in the > future. That would be very cool, but you'd get milions of errors like "FT_Whatever redefined, previous definition was Somewhere", because the definitions of FT_Whatever() is in the header which has to be included, as there are many required constants (like FT_OK) and typedefs (like FT_STATUS) there. After the whole series of patches (everything loaded dynamically on all platforms), there won't be so many #ifs <: I tried to make my changes an addition rather than modification - this way I'm pretty sure that this patch won't break anything else. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Freddie, Thanks for this patch, I like the idea :-) I don't have any experience in OpenOCD development but I did have a look at the patch and have two questions/remarks: 1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a different place then all the others? Isn't it cleaner to keep all the initializations together? 2) Isn't it possible to define a macro function for the FT_xxx functions in case of FTD2XX_DYNAMIC? Something like: #if FTD2XX_DYNAMIC == 1 #define FT_Close( handler ) (*FT_Close_ptr)( handler ) /* same for all other functions */ #endif This way you don't have to add ifdef's around all function calls and it'll make the patch smaller and less possibilities for mistakes in the future. gr. Ronald Original Message Subject: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c From: Freddie Chopin To: openocd-development Date: Sat Jun 27 2009 19:08:20 GMT+0200 (Romance Standard Time) This patch enables dynamic loading of ftd2xx.dll in ft2232.c on Win32 platform. It's made to work only on Win32 and for ftd2xx.dll in ft2232.c - it doesn't affect linux, libftdi or any other modules that could use that. That's the first from a series that I am planing (win32 only): 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c 2. enable dynamic loading of libusb0.dll in ft2232.c 3. make it possible to have support for both libftdi and ftd2xx at the same time in ft2232.c n. enable dynamic loading for some other modules - jlink, rlink, presto n+1. make it possible to have support for both libftdi and ftd2xx at the same time in presto.c I can do the same for linux, but as I have no means for testing I'd rather pass that to someone else. With help in testing I can try to do that myself. What would be the opinion of maintainers? Should I continue? Anyone with FT2232 based dongle and Windows - please test. When compiling enable ft2232 with ftd2xx.dll only, as there are other interfaces that use dynamic libraries not yet "converted" to dynamic loading. I can also provide you with a compiled executable, as current trunk doesn't build on Windows - in such case contact me and I'll post such executable somewhere. The main difference is that patched copy would run WITHOUT ftd2xx.dll, so you may test in the following way: 1. locate all ftd2xx.dll occurencies that can be reached through system PATH (usually in /bin/ with openocd, Windows/system32, but sometimes may be more) and rename them to anything else - for example ftd2xx.dl_ 2. trying to run some earlier version would result in failure, as windows would not be able to load library. even "openocd -v" will fail 3. Modified version shoud run and in case of using ft2232 based config files should report an Error (on command line!) that the library cannot be loaded. "openocd -v" shoud work without problems. 4. Rename at least one ftd2xx.dll to original name and try again - modified version should work as expected. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
This patch enables dynamic loading of ftd2xx.dll in ft2232.c on Win32
platform.
It's made to work only on Win32 and for ftd2xx.dll in ft2232.c - it
doesn't affect linux, libftdi or any other modules that could use that.
That's the first from a series that I am planing (win32 only):
1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c
2. enable dynamic loading of libusb0.dll in ft2232.c
3. make it possible to have support for both libftdi and ftd2xx at the
same time in ft2232.c
n. enable dynamic loading for some other modules - jlink, rlink, presto
n+1. make it possible to have support for both libftdi and ftd2xx at the
same time in presto.c
I can do the same for linux, but as I have no means for testing I'd
rather pass that to someone else. With help in testing I can try to do
that myself.
What would be the opinion of maintainers? Should I continue?
Anyone with FT2232 based dongle and Windows - please test. When
compiling enable ft2232 with ftd2xx.dll only, as there are other
interfaces that use dynamic libraries not yet "converted" to dynamic
loading. I can also provide you with a compiled executable, as current
trunk doesn't build on Windows - in such case contact me and I'll post
such executable somewhere.
The main difference is that patched copy would run WITHOUT ftd2xx.dll,
so you may test in the following way:
1. locate all ftd2xx.dll occurencies that can be reached through system
PATH (usually in /bin/ with openocd, Windows/system32, but sometimes may
be more) and rename them to anything else - for example ftd2xx.dl_
2. trying to run some earlier version would result in failure, as
windows would not be able to load library. even "openocd -v" will fail
3. Modified version shoud run and in case of using ft2232 based config
files should report an Error (on command line!) that the library cannot
be loaded. "openocd -v" shoud work without problems.
4. Rename at least one ftd2xx.dll to original name and try again -
modified version should work as expected.
4\/3!!
Index: src/jtag/ft2232.c
===
--- src/jtag/ft2232.c (revision 2405)
+++ src/jtag/ft2232.c (working copy)
@@ -63,6 +63,38 @@
#include
#endif
+/* Dynamic loading of libraries at runtime - only for Win32 and ftd2xx.dll
currently */
+
+#if defined(_WIN32) && BUILD_FT2232_FTD2XX == 1
+#define FTD2XX_DYNAMIC 1
+#else
+#define FTD2XX_DYNAMIC 0
+#endif
+
+#if FTD2XX_DYNAMIC == 1
+
+// typedefs for all used functions from ftd2xx.dll library
+typedef FT_STATUS (WINAPI *FT_Write_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToWrite, LPDWORD lpBytesWritten);
+typedef FT_STATUS (WINAPI *FT_Read_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToRead, LPDWORD lpBytesReturned);
+typedef FT_STATUS (WINAPI *FT_OpenEx_t)(PVOID pArg1, DWORD Flags, FT_HANDLE
*pHandle);
+typedef FT_STATUS (WINAPI *FT_ListDevices_t)(PVOID pArg1, PVOID pArg2, DWORD
Flags);
+typedef FT_STATUS (WINAPI *FT_SetLatencyTimer_t)(FT_HANDLE ftHandle, UCHAR
ucLatency);
+typedef FT_STATUS (WINAPI *FT_GetLatencyTimer_t)(FT_HANDLE ftHandle, PUCHAR
pucLatency);
+typedef FT_STATUS (WINAPI *FT_SetTimeouts_t)(FT_HANDLE ftHandle, ULONG
ReadTimeout, ULONG WriteTimeout);
+typedef FT_STATUS (WINAPI *FT_SetBitMode_t)(FT_HANDLE ftHandle, UCHAR ucMask,
UCHAR ucEnable);
+typedef FT_STATUS (WINAPI *FT_GetDeviceInfo_t)(FT_HANDLE ftHandle, FT_DEVICE
*lpftDevice, LPDWORD lpdwID, PCHAR SerialNumber, PCHAR Description, LPVOID
Dummy);
+typedef FT_STATUS (WINAPI *FT_Purge_t)(FT_HANDLE ftHandle, ULONG Mask);
+typedef FT_STATUS (WINAPI *FT_Close_t)(FT_HANDLE ftHandle);
+
+// library handle
+static HINSTANCE dynamic_library;
+
+// global pointers for read and write functions
+static FT_Write_t FT_Write_ptr;
+static FT_Read_t FT_Read_ptr;
+
+#endif
+
/* max TCK for the high speed devices 3 kHz */
#defineFTDI_2232H_4232H_MAX_TCK3
@@ -343,7 +375,12 @@
#if BUILD_FT2232_FTD2XX == 1
FT_STATUS status;
DWORD dw_bytes_written;
+
+#if FTD2XX_DYNAMIC == 1
+ if ((status = (*FT_Write_ptr)(ftdih, buf, size, &dw_bytes_written)) !=
FT_OK)
+#else
if ((status = FT_Write(ftdih, buf, size, &dw_bytes_written)) != FT_OK)
+#endif
{
*bytes_written = dw_bytes_written;
LOG_ERROR("FT_Write returned: %lu", status);
@@ -381,8 +418,13 @@
while ((*bytes_read < size) && timeout--)
{
+#if FTD2XX_DYNAMIC == 1
+ if ((status = (*FT_Read_ptr)(ftdih, buf + *bytes_read, size -
+ *bytes_read, &dw_bytes_read))
!= FT_OK)
+#else
if ((status = FT_Read(ftdih, buf + *bytes_read, size -
*bytes_read, &dw_bytes_read)) !=
FT_OK)
+#endif
{
*bytes_read = 0;
LOG_ERROR("FT_Read returned: %lu", status);
@@ -1803,6 +1845,78 @@
