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

Reply via email to