On 08:42 Thu 09 Jun , Laurent Gauch wrote: > > > >On 15:25 Tue 07 Jun , Laurent Gauch wrote: > >>/ > > >/>/ >/If our ft2232.c patches are not merged quickly, Amontec Team will > >certainly > >/>/ >/>/ come with a new specific jtagkey.c API driver instead of the > >ft2232.c JTAG > >/>/ >/>/ driver. > >/>/ >/>/ The advantage with a specific Amontec JTAGkey API driver in > >openocd, will be > >/>/ >/>/ to see our patches merged in the minute, instead to wait 1 to 2 > >months ... > >/>/ >/>/ also the ft2232.c will still be usable for the JTAGkey. > >/>/ >/ > >/>/ >This is the solution, you will have your own driver to manage then :-) > >/>/ >But you will then create another DRIVER not API as the interface API > >/>/ >is already set :-) > >/>/ Yes, a specific jtagkey driver with a wrapper for the existing > >/>/ openocd API ! Yes, that's the idea. > >/>/ The user will be able to use the classic ft2232.c or the specific > >/>/ jtagkey.c as a jlink.c! > >/>/ Maybe that's the road to follow if our patches take so long time to > >/>/ be merged on ft2232.c. > >/except on jlink we have a 100% different API > All specific dongle interface (DRIVER) are based on the same API > (known as JTAG API). > API -> DRIVER -> DONGLE my key point the Amontec are based on ft2232 the jlink on the sam7 they do have 100% different API to deal with the chip/firmware
so as a Maintainer I NACK duplicate code as there is no good reason to do so exception for short term such a cleanup in progress or code refactoring but your proposal is not this as at all, it's to do it on long therm which is not acceptable Best Regards, J. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
