Hi Tomek, I have zero prior experience with the FT2232 so I took a very brief scan of its driver code. I get the feeling that this type of device allows fairly low-level access to interface port pins. If this is true I can see the logic behind a bitbang function as this provides the generic abstraction layer between any arbitrary signal name and its corresponding underlying hardware I/O pin. In theory you can make this type of device sing with just about anything.
Unfortunately I suspect a lot of dongles from different vendors may not have this type of low-level capability. The jlink device (at least from an official Segger published protocol standpoint) basically allows the host to select one of 32 different types of interfaces through the EMU_CMD_SELECT_IF command. Right now the only two interfaces supported are JTAG and SWD, however. It also allows transfer of data through the EMU_CMD_HW_JTAG3 and EMU_CMD_HW_JTAG_WRITE commands. The effect of the second and third command on the physical hardware depends on the mode set using the first command. The transfer function on the other hand looks cursorily like it can be implemented with the EMU_CMD_HW_JTAG3 command on jlink. Since I really have not studied libswd in any depth what happens if a particular dongle can only support the basic transfer but no bitbang command with respect to libswd? Like I indicated in the beginning, I only took a very superficial look at this, so I may be be missing information or other critical details. Feel free to chime in with perspective or correct any of my assumptions. Gary On 8/21/11 4:21 PM, "Tomek CEDRO" <[email protected]> wrote: > If you have good insight on JLink and maybe other high-level > command-based devices (like RLink) please concentrate on implementing > drivers API for those devices that will allow generic access to the > bus with "bitbang" and "transfer" operations as implemented for FT2232 > cables in "interface" structure. Only FT2232 cables are now capable to > run SWD with libswd as all drivers were designed to work only with > JTAG having jtag-specific calls I had to implement some generic > functions that could allow transports other than JTAG - this is why > "bitbang" (set selected bitmask on selected port pins) and "transfer" > (send/receive data stored in *char) was created and should do the job > for device with no logic that know nothing about SWD (or other > transport). This is why we need to create drivers using bitbang and > transfer for high-level interfaces, or something else that would allow > generic access to the bus and transport implementation. This way we > should be able to implement any possible transport on any possible > interface :-) Please let me know if the bitbang and transfer is enough > for high-level interfaces to implement the transport.. If so it would > be nice to see "bitbang" and "transfer" implementation for interfaces > other than FT2232. > > Best regards, > Tomek > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
