"Peter Stuge" <pe...@stuge.se> napisał(a): > Freddie Chopin wrote: > I was considering this too. I strongly prefer a single file for the > entire family if possible, but it should not cost very much, if any, > performance.
But in this situation single file costs performance, so that's not a good idea. BTW I do not prefer single file for whole family, anyway OpenOCD does not have it as a rule. > Too many levels IMO. Just put stm32, str7, str9 directly under > target. Number of level is not important. Can be my way, can be your way (; > Yes and no. I think that it's really nice to only need to specify the > family of chips that you're working with. Maybe yes, but naming the specific chip does no harm either. > Also yes and no. A typical openocd.cfg should just pull in some > existing files from tcl/ but there are a lot of bad examples which > confuse things, by copypasting everything into openocd.cfg instead of > sourcing the distributed cfg files. I strongly disagree. "User friendly" nowadays means GUI and total ease-of-use. You know NXP chips, so you probably know Flash Loader. It is possible to use this application right "out-of-the-box", you don't need to browse through the cfg files, change anything there, read manual with commands, etc. You just run and use it. Requiring somebody to write cfg files is not the right way to go. IMHO cfg files for all chips should be created, so that in std cases ppl would not need to write any files. > If there isn't one already then I think an example on the web would > go a long way. Do we have a wiki? That is your way, "my way" is to start OpenOCD with additional command line parameters (-f interface/sth.cfg -f target/sth.cfg -c "jtag_khz 1000"). It's pretty hard (impossible?) to override anything through command line parameters... You like your way, I like mine, probably neither of us will change their habits. I'm pretty sure there are some other ways and OpenOCD should allow to use it easily too. Separate CFGs for all chips is the way to go IMHO. BTW such files would not prevent using general "family" files. 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
