Am 05/26/2011 10:47 PM, schrieb Paul Claessen: > > Thanks for your much appreciated quick response. > I'm using my own .cfg for file an Olimex Tiny. I simply added the > suggested 'adapter_khz' (with value 1000, although I'm not sure what a > reasonable value would be; I guess that depends on the target) and > everything now works as before. > I guess I was a bit thrown off by mentioning of adding function calls > to init routines and someone even mentioned mods to core.c. > > As for cleaning stuff up and keeping code tidy, I certainly can see > your point there, but I still think 'breaking' things should only be > allowed in extreme situations, IMHO, and then only with very clear > instructions on how to adapt to the new situation. > In this case, a system that didn't work for all cases (but did for > most), was replaced with one that didn't work for ANY. That's hardly > progress. Besides, the concept of (a documented!) default value that > works in many, but not all, cases seems like a very valid thing to > have, to me. The problem is that the default value would have to be ridiculous low - IIRC, for a synthesized core running at 32kHz, it would have to be 4kHz or lower, so most users would *have* to edit their configs anyway to put in a value that works for their board.
Otherwise, you get strange results, including "works part of the time" or "works partially". A clear error message is the much better solution IMHO. > Also, the one making this change must have realized that without also > fixing all the now broken sample scripts/cfg files, the implemented > solution wasn't complete and would trip up quite a few people. I > realize that fixing cfg files isn't very sexy, but still The change happened not long time ago - the master branch is work in progress. I agree this definitely has to be cleaned up before the next release. > I also realize that it seems a bit ungrateful to bitch about work > that's done by volunteers, for free. Let me assure everyone that I > only mention this in an effort to help create a better product, and I > hope to one day contribute some of my own resources. > Despite the bitching, I truly DO thoroughly appreciated everyone's > efforts put into this cool tool! > That's fine. Every bit helps - if you supply a patch that improves one ore more of the supplied sample scripts, or even the documentation, that will help improve OpenOCD without digging into the code. cu Michael
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
