On Tuesday 29 December 2009, Laurent Gauch wrote: > The idea of the JTAG and Debug port over FT2232 as with the Amontec > JTAGkey ( now JTAGkey-2, in 2010 JTAGkey-3 ),
So on Friday (2010!) we'll be hearing all about JTAGkey-3! ;) > is to use one port for > JTAG / RTCK / TRST / RESET signal / EMUx signal ... Just out of curiousity: not also SWDIO/SWCLK? A second port could fairly easily be used with SWO/SWV, though it could be a trifle awkward to access that from OpenOCD; FTDI packages it as a composite device, so the second port would end up with another driver... Or with more work ... maybe even ARM's new compact JTAG with its narrow trace port, hooked up to ETM. (Might require a CPLD, and I've only happened across one board with that connector so far.) > The best to do: > 2. Split the actual ft2232.c to two file ft2232_new.c and mpsse.c . Then > Austin could call funtions from mppse.c. When all is working we will > rename ft2232_new.c to ft2232.c. Finally we will have : > ft2232.c > ft4232.c > mpsse.c And, preferably, jtagkey2.c and friends ... there are *two* sets of headaches with the current approach. One is how the core code is factored. Another is how all the wiring variants are handled. Oh, make that *three* sets of headaches. Another is the abuse of global state. Which starts to hurt even before one needs to support multiple JTAG links... Darn. Wait a second. That's *four* sets of headaches. With SWD there's also a problem with the assumption that There Is Only JTAG. Maybe I should stop counting? Sigh. An FT4232H could have multiple MPSSE ports, right? I've already seen FT2232H based parts with one port going to one JTAG link and another going to another. (Actually, to the CPLD controlling how the signals on the first port get routed.) - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
