Simple and true :-) Each interface has its own config file anyway, so
this file can contain also signal definition for that interface. If
interface has no signals defined, no signals will be defined, so there
is no worry.
Here we have to select between Simple and Safe !
We know that a large part of TCL are copy past from tcl examples to
end-user dedicated TCL file (That's not what we really want, but the TCL
is the end-user interface). My experience tell me that a lot of users
are copy pasting to one file for the specifc use.
"What happen if a user force a '0' or '1' to RTCK input of the
interface, using your bitbang TCL.
The problem with your bitbang approach via TCL, is a REAL risk for the
end user to copy paste your TCL signal definition specific to a layout
and copy it for an other layout.
You will tell me, the user needs to know what he do ...
Anyway, you have to implement a mechanism to filter the bitbang in the
ft2232.
Please provide first a mechanism allowing to filter/mask the access of
the ft2232 IO port for each specific layout.
Then we can test and see if the bitbang port from TCL are enough safe to
be merged.
User can define his/hers own signals by hand, but it is
then his/hers choice :-) There can be some standard signals to be used
by general TCL scripts as signals are recognised by name string :-)
The best is to standardize at a lower level ... and to forget the idea
to have the possibility to bitbang from the TCL of the openocd.
That's as for the SWD, we have to standardize some function call in the
ft2232, and avoiding bitbang access from higher-level.
That's not simple to dev, but safe for end-user.
Best regards! :-)
Tomek
Laurent
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 USB JTAG CABLE
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
