Hello Gary :-)
On Tue, Aug 23, 2011 at 2:24 AM, Gary Carlson
<gcarl...@carlson-minot.com> wrote:
> 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.
Yes, exactly, this is general IO bridge and libswd is there to
construct packets/bitstream for this kind of device as the interface
knows nothing about transport. This is not true for interface with
some logic, but there might be some way to create general
bitbang/transfer functionalities so we can overcome their limitations
in matter of transport so it can perform operations on transports it
knows nothing about :-)
Libswd dirvers have 4 transfer functions and 2 dedicated TRN
functions. I hava named direction MISO and MOSI to be less confusing
where Master is the OpenOCD. There are functions:
-swd_drv_mosi_8 that send data out of the char array with selected
number of bits {1,..8} - write request, control and parity transfers
-swd_drv_mosi_32 that send data out of the int array with number of
bits {1,..,32} - write data transfers
-swd_drv_miso_8 that read data into char array with selected number of
bits {1,..,8} - read ack and parity transfers
-swd_drv_miso_32 that read data into int array with selected number of
bits {1,..,32} - read data transfters
-swd_drv_miso_trn - sets bus to input/miso
-swd_drv_mosi_trn - sets but to output/mosi
As you can see all those functions require at least only two functions
to work: transfer and bitbang. Maybe there are some high-level
commands to implement them using interface commands...
> 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?
Bitbang is mainly necessary to perform TRN operations, it can be
implemented as this only specific signal "RnW" (by sending come
interface command) support and return error for other signals. Bitbang
in general also gives ability to create external (tcl?) scripts that
make use of target device without need to hardcode the
functionalities.
> 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.
Maybe it is not necessary to use libswd at all with interfaces that
can construct transport packets on their own so high-level-interface
would rather need to use "target" structure directly if it can. We
need to sort it out to create common API that would suit most
high-level-interfaces, or simply force them to pass our bitstream
generated with some external library (such as libswd) which seems more
versatile but can have some impact on speed..?
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
