On Mon, Jun 20, 2011 at 8:31 PM, Michael Schwingen <rincew...@discworld.dascon.de> wrote: > Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >>> Please explain the dangers. >> If a driver can't implement a sane feature safely, then the driver shouldn't >> implement that feature.... > Fine. > > I *do* think hardware should be designed in a way that it can not be > damaged by software,
Couldn't agree more. > but if existing hardware has such problems, then > the driver needs to protect the hardware and restrict the user from > doing something stupid. Or minimally don't add support for features that are badly broken in the hardware.... >> One of the reasons I'm not excited about adding the IO features to OpenOCD >> is that we have barely enough maintainer resources as is. If a maintainer >> came out of the woodwork that would review, design and direct these efforts, >> then I wouldn't be in the way. I would dearly like to see SWD done before >> opening the floodgates to GPIO and other serial protocols. > I can agree to that. However, I do not think we should categorically > exclude such extensions on the simple basis that "this should not be done". I would love to do so, but I don't know enough about it.... We can exclude it from the point of view that none of the maintainers are currently giving this due attention, even to the point of canning the feature for good or saying that this might be something for the future. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
