From: Michael Schwingen Sent: Thursday, May 26, 2011 3:26 PM To: Paul Claessen Cc: [email protected] Subject: Re: [Openocd-development] Error: .. adapter speed not selected Am 05/26/2011 09:12 PM, schrieb Paul Claessen: In April (2011) I built openocd version 0.5.0-dev-00858 and used it successfully with an Olimex OpenOCD JTAG Tiny. I recently built version 0.5.0-dev-00882 and I now get the following error:
Error: An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed.in procedure 'init' I would argue that if you remove a concept of default values and thereby BREAK working systems and turn them form working systems into failing systems, then, IMHO, no matter how elegant and architecturally correct your ‘concept removal’ was, you violated the extremely important idea of backward compatibility and you have, for all practical purposes, introduced a bug. We’re now having a system, that used to work fine, that no longer works and gives me (just a simple user) some very vague hint about adding a call somehow somewhere without further details as to parameters etc. I hope someone can reverse all this. In the mean time, can someone provide me with some more detailed instructions on where and how exactly to add this call? The adapter_khz and jtag_rclk commands are described in chapter 8.4 of the manual (openocd.pdf). If you are using one of the config files provided with OpenOCD, then these need to be fixed - however, you don't tell which config file and which target you are using, so I can only guess. If you use your own config file, you have to expect some breakage both on development versions and new major releases. Backward compatibility is a nice goal, but it can hamper progress and produce layers of cruft in the code, so there are situations where it is best to enforce some change and keep the code clean. cu Michael Michael, 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. 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 ... 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! Kind regards, ~ Paul
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
