On May 28, 2009, at 7:04 PM, Zach Welch wrote:
In addition, the following issues appear to require resolution, in orderto decided whether they should be accomplished for 0.2.0 or postponed: - ft2232 high-speed device support
Not necessary for 0.2.0, but if a patch was ready, it would go in. The patches I've seen for this before (that sadly don't apply cleanly today) are relatively small and just add detection of the new device, support for faster clock speeds, and RTCK support.
- finish work to allow parts of libopenocd to be exposed.
Definitely not for 0.2.0. I'd even go so far as to make the default -- disable-shared for 0.2.0 since the entire library hasn't been vetted for any sort of use except by the openocd binary. Once we have the API pruned, the default could be --enable-shared, but for now, it just makes the build take longer, installs unnecessary files, and potentially misleads users/developers into thinking we support this type of usage.
- continue reorganizing TCL files to provide more structure
I'm OK with this since it doesn't really have a big effect on users.
- longer usb timeouts (or non-blocking I/O?)
longer timeouts are OK for 0.2.0, but I don't think they really resolve the issue. Non-blocking I/O is definitely not for 0.2.0 as it would require some major restructuring.
- fix jlink to work with large scan chains (e.g. R.Doss svf test).
As long as the fix is relatively small, I'd be OK with this.
- fix endemic reset problems
I'd love to see this resolved. It has confused me a number of times with the Luminary FTDI-based demo board as well as when playing with the beagleboard.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
