freddie_cho...@op.pl 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,
Unless there is a way to tell devices apart. > BTW I do not prefer single file for whole family, Why not? No big deal, but I'm curious. > anyway OpenOCD does not have it as a rule. No, but I think that it is very important to have only a single recommended hierarchy for cfg files. Ie. that files in board/ must always be "higher level" than files in target/. I think this is the case now, and it is very important for understanding. > > 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 (; I do think number of levels is important. Fewer levels allows for a much quicker overview. > > 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. It requires more detailed manual configuration, ie. less automation, which is really annoying if it can be avoided. But sometimes it can't be avoided. I guess this is the case here. > > 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. Many may prefer GUI but please do not make the mistake of thinking that GUI is the only way to have ease of use!! GUIs such as Eclipse are sometimes so bad that they become counter- productive. I've touched on the Eclipse surface a few times in different contexts and it has always been an absolute disaster. It's the very definition of bloat if you ask me. On the other hand, if all circumstances are right and it fits the user's needs, then I am sure that it is wonderful. I know others who also quite strongly prefer command line control over OpenOCD as well as the other development tools. And I know several who are conditioned into thinking that GUI or IDE is the only way of working. Eclipse and other GUIs are very important since it helps them. Ease of use is another story however; I certainly agree about out-of-the-box being important, both for GUI and CLI! > You know NXP chips, so you probably know Flash Loader. No, I've only used OpenOCD, mtools (for the USB storage bootloader in LPC134x since it makes assumptions about sector allocation which mismatch what the kernel vfat driver does) and vsprog so far. I avoid Windows as much as I can. It's really sad that NXP has even gone so far as to put in datasheets that the USB bootloader will only work with Windows. I guess we will only see more such nonsense in the future, as vendors try to focus on core business but must also integrate with a whole world around them that they do not understand the least bit. Difficult! Sorry, back on topic now. :) > 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. I did a few hours of research before starting with ARM last year, bought a nice development board with cfg in board/ and a JTAG adapter with cfg in interface/, and then I spent about 60 minutes on stuff before I had everything from toolchain to debugger and blinking LED working. I think that is pretty amazing, and it proves that the tools are really good already. No doubt they can get even better, but 60 minutes is already very close to out-of-the-box. I don't think it's useful to optimize that process too much more, because someone who can not manage to overcome such a small hurdle will inevitably fail miserably later in their project anyway, and should just be doing something else, or the same thing but in a different way. (Maybe using Flash Loader?) > Requiring somebody to write cfg files is not the right way to go. Yes and no. I agree that it would have sucked if I had to write a target cfg for the device on my development board. But I didn't, because I made sure to buy a board that was already supported. Since OpenOCD is an open source project I don't think that it is realistic for anyone to expect that *every* possible target will already be supported. I also don't think you suggested this either, but clearly we all want more target cfg files. :) As for Flash Loader, the name suggests that it is a download-only program, maybe not so much involved in debugging. OpenOCD does both, and since the latter requires a lot more information it is unneccessarily complicated to just do a firmware download. This might actually be a significant possible improvement for OpenOCD. On the other hand, you typically want the debugger working pretty soon as well.. > IMHO cfg files for all chips should be created, so that in std > cases ppl would not need to write any files. Yep! Please send patches. I will also. > > 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"). Yes! I've tried to play with this a few times. I think it looks like a nice way to use openocd when openocd.cfg would do nothing but source existing files. I didn't get it to do exactly what I wanted, but I like this approach too because it doesn't require a config file. On the other hand the long command line is very annoying to type. > It's pretty hard (impossible?) to override anything through command > line parameters... Hm? I was not really clear about how -c relates to e.g. procedures defined in openocd.cfg. Do you know more about the ordering? > 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. I don't know if I really have a habit yet. ;) I haven't been using OpenOCD for that long.. > Separate CFGs for all chips is the way to go IMHO. Only if optimal family cfg files are impossible. I think they are. :\ > BTW such files would not prevent using general "family" files. Hm? I agree that a "base" family cfg would still be there, but I think that it's important to emphasize that users should never source family cfg files directly then, and should always use or create a device specific cfg file. Otherwise it will be really difficult to understand how OpenOCD is meant to work, and what to do when. Using Tcl cfg files in the first place already creates a bit of confusion, but I also can't say that I disagree with it or that I can suggest something better. //Peter _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
