Øyvind Harboe wrote:
> I need to test these changes.
> Comments welcome!
-jtag_khz 10, 3000
+
+jtag_khz 3000
+proc target_0_pre_reset {} {
+ jtag_khz 10
+}
+proc target_0_post_reset {} {
+ jtag_khz 3000
+}
+
Now this one I really don't understand in terms of what are the benefits of
changing the syntax of a well established and used command? What was there
before was simple and easy to follow - and now you have to define two event
procs to handle it - that does seem like a regression.
Adding in event procs for doing different things to me looks like a good
approach but changing a command syntax and forcing defining things around this
way doesn't seem like a good approach.
Pretty much every target script I've come across that isn't in the openocd
distribution has required work as commands have been changed / renamed - and
this is something I had hoped had settled down a little but these sorts of
changes make me thing that things will be moving around for a while longer and
all scripts will need reworking.
Is there some point in time at which the configuration API will get locked down?
One other scripting use case - assuming that an openocd version number is
available and that we end up with major.minor.bugfix numbering then scripting
could be used to have target scripts which work unchanged across multiple
openocd versions.
Tim.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
