Am 06/20/2011 02:44 PM, schrieb Laurent Gauch: >> 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 explain the dangers. Do you sell hardware that can be damaged by misbehaving software?
I think this can be a very useful feature for dongles that have I/Os beside the JTAG/SWD ones - for LEDs, or other additional hardware (Tomek mentioned an ADC). If there is hardware that can be damaged by wrong programming of the I/Os, then the layout for that dongle should provide a mask that disables bitbang access to those signals that are critical. Completely disabling that functionality for everyone is no solution IMHO. > 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 ...). What if I need to access those pins *while* OpenOCD is running? I don't think you can put this of as a production-only feature. This may be true for your dongles, but not for everyone. > 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. I can agree that the driver should filter the access and only allow access to those pins that are deemed safe for the specific dongle. cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
