+++ Zach Welch [2009-05-21 15:12 -0700]: > On Thu, 2009-05-21 at 21:50 +0100, Wookey wrote: > > +++ Wookey [2009-05-19 12:29 +0100]: > > > As described on > > I like the idea for a base.cfg file, as it allows users to tweak the > defaults of their installed OpenOCD. In this light, I can see us > pushing default settings like this out of the C code and into TCL. > > More generally, I like the idea of building logical layers of TCL files, > which seems to be your principle thrust here.
It was. > > And no-one has said anything about the important issue I wanted to get > > some feedback on: how best to split up config files. Perhaps I should just > > send in a patch and see what people have to say about it? > > I think an opportunity exists for an architect to bring more order to > the TCL files. What little looking I did suggested this was indeed true. Currently it's a mess, and a mess in a multitude of styles. > The lack of response to your query indicates to me that > no one can "whip out" a quick description for you, so you may have given > this topic more recent and considered thought than others. That's quite worrying :-) (given that I've considered exactly 1.5 boards and 4 dongles, and been using openOCD for a whole 3 weeks) > A patch might be nice, but it might also be too concrete. I would enjoy > reading a description of a process that developers could use to > structure their own configuration files. Of course, it would be better > to have both, so we can see both your intentions and actualizations. > But best of all, you might even add said documentation as > doc/manual/<apropos>.txt. I figure that writing this up should not take > much effort, if you already have a plan in mind for making a patch. Hmm, I did wonder if asking questions like this might get me another job. Like everyone tuits are in very short supply. My biggest problem is that I don't feel I have any sort of good overview about other use cases and considerations. Novices re-arranging things might not be ideal. Things like: 1) Is there any agreement that the reset info doesn't really belong in the board file because it depends on the dongle and wiring too, or is that an unusual case? 2) How much room is there for standardising things like reset timeouts and speed settings to suitable defaults? (there is no way to tell from a given file wether the value in there is actually tested/looked-up/important or if it's a random number copied from some other file and actually means <sensible default> that's just a couple that spring to mind. Looking would no doubt sugest more. But I guess even some basic tidying and consistentifying would be a step in the right direction. > I suggest the doxygen manual rather than the user guide, because it > seems to be the intent for OpenOCD to provide "complete" configurations > that can simply be used without tinkering. Thus, their architecture and > development rules seems belong in the developer manual, and I think this > would be a great step forward for us. Never touched doxygen. Is it easy? latex on the other hand I can just about manage. > If nothing else, I hope this suggestion might spur others to consider > preempting this documentary effort with the architectural plans that led > us to the current status quo. If not, you will have a clean slate. Thanx for constructive comment. I'll try marking Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
