only one transport option; autoselect 'jtag'
> interface_signal list
interface_signal list
Interface Signal Name | Mask | Value
----------------------------------------------------------
> interface_signal add led 8000
interface_signal add led 8000
There are no signals defined yet.
> interface_signal list
interface_signal list
Interface Signal Name | Mask | Value
----------------------------------------------------------
led | 0x00008000 | 0x00008000
> bitbang led=lo
bitbang led=lo
ftdi_write_data: USB device unavailable
Unable to write signal: led
in procedure 'bitbang'
> bitbang led
bitbang led
ftdi_write_data: USB device unavailable
Unable to read signal: led
in procedure 'bitbang'
Does OpenOCD need to handle this kind of bitbang fonction from TCL ?
For me, it does not, because it is too DANGEROUS for both the dongle and target
...
PLEASE COMMENT
The problem is that the result of a bit-bang procedures will be dongle and layout specific.
There are too many chances for the end-user to create short-circuit in the dongle or on the dongle port to the target board.
Also, we should not use and/or provide the possibility to the end-user to
manage himself the bitbang of the dongle port, from TCL or from any other
access.
This is JUST not the JOB of openocd but the job of other pieces of software (as
manufacturer post-production test program ...).
ALL dongle port access should be controlled and checked in the FT2232.c. The
FT2232 should not give to higher layer the possibility to have an direct access
to the dongle port.
Regards,
Laurent
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
