On Wed, Jun 15, 2011 at 11:06 PM, Rodrigo Rosa <rodrigorosa.lg at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
>/ i'm not sure i'm getting this right, i think i know very little about
/>/ how this stuff works...
/>/
/>/ i had modified ft2232.c
/>/ in ft2232_execute_queue, instead of doing layout->blink was using some
/>/ mpsse commands to set/clear read/write gpio pins available on the
/>/ ft2232, which are not used by jtag.
/
SWD and other transports will use bitbang() and transfer() new
interface methods to work on the bus. queue_flush() / execute_queue()
is jtag only function and should not be used for transports other than
jtag, as it is too jtag-only as it works on commands queued on
CMD_CTX, but these are jtag only.
BAD ! and WHY it is too JTAG-ONLY?
For me the queue_flush and execute_queue should be the mechanism to be
used for ALL transport, JTAG and new one as SWD.
As you can see, the queue management is done in the DRIVERs, since it is
dongle specific.
I remember when I helped Dominic Rath, the author of openocd, about to
enqueue command for having a better download speed.
OpenOCD start with JTAG transport, but the mechanism of queue should be
present for any king of transport.
If not, we will degrade the transport speed.
We ALL know the pure bitbang is really bad when we talk about
"USB-x-transport" due to the latency of the USB.
There are ways to have both SWD and JTAG passed in a queue of command,
and the same queue. By definition, a queue of commands is not related to
any transport.
The command queue just pack the command bytes to have a better speed,
larger byte packets.
the idea is to become transport independent, so the context and queue
will be now part of given transport.
SWD is specific data transport protocol as the JTAG, as the I2C, as the
1-WIRE..
If libswd is transport independent, why do you call it libswd.
Or do you want to provide libjtag libswd libi2c lib1wire. In this case
openocd has jtag.c why not a swd.c ?
libswd for instance has swd_ctx
holding all settings and queue, each libswd function works on this
context, so there may be many different contexts in use with no
collisions. this swd_ctx will be hold by void pointer in transport
structure (void so any other context can be used as well).
>/ i need is some way to type "my_function_in_ft2232.c some_arg" in the
/>/ telnet interface so that the function my_function in ft2232.c gets
/>/ called...
/>/ i managed to make the chip do what i needed without using swd.
/>/ maybe i can get around with some patch on ft2232.c and jtag interface...
/>/
/>/ how are you testing stuff without the "jtag" command in the cfg files?
/
target operations are not yet ready. jtag functions are jtag only.
agree there is a mess because i am using some functions or structures
having "jtag" in their name only because some time ago noone
considered other transports than jtag, so instead oocd_interface there
is jtag_interface etc.
Why did you not copy/paste and rename the the JTAG_ by SWD_ and call the
SWD_ from you libswd, instead to call JTAG functions from you libswd.
OK, this will duplicate the code in the driver, but that's will help to
introduce the SWD API.
this must be fixed after transport is
functional,
This should be a priority.
i wanted to rename this stuff before but it took too much
time, so i decided to first make transport working and later
reorganize openocd interals as time is limited...
OK, time is limited.
But, the bad thing is that the SWD API is not yet specified. With
Dominic Rath, we have specified the JTAG API before implementing the
specific driver ...
ft2232 specifc comment:
------------------------
The ft2232.c must have specific SWD functions, but we cannot write it
before we specify the SWD API.
We cannot imagine to have a libswd making itself a kind of specifc
bitbang calls, just because a specific ft2232 layout (K T Link) needs to
tristate the SWD TMSIO signal, by bitbangging the ft2232.
The how we tristate the TMSIO is not the job of the libswd, but is the
job of the specific driver. Or your libswd should be called
libswdmpssebitbangkt.
As first step, the openocd should have a swd.c (maybe something like
your libswd) as we have jtag.c, with a well defined API. Then each
specific driver, as the ft2232, should integrate the SWD API calls. For
the ft2232.c, the SWD will certainly be coupled with the specifc layout.
Example, the Amontec JTAGkey-3 will come with an other layout than k T
Link, so there will be specific SWD transfer for each layout. More, the
Amontec JTAGkey-3 will not need to bitbang the FT2232 to tristate the
SWD TMSIO, but will use pure mpsse shift only :-) .)
Maybe my comments could be again a little bit negative to you, sorry.
But I try to be objective and to help the discussion.
Regards,
Laurent Gauch
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 HIGH-SPEED USB JTAG INTERFACE ADAPTERS CABLES
Best regards! :-)
Tomek
btw. maybe automatically executing autoreconf for libswd submodule
will fix the problem you mentioned.. i have created configure script
to avoid this, but there seems to be someissues with that.. will have
to take closer look :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
