"Peter Stuge" <pe...@stuge.se> napisał(a): > Unless there is a way to tell devices apart.
Usually there is (; Sometimes some more logic is required, but generally that is possible (JTAG ID, special registers with ID, flash sizes, etc.) > > BTW I do not prefer single file for whole family, > > Why not? No big deal, but I'm curious. Usually you have to change something in such "generic" files. The need to change anything in chip-specific files is lower. > 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. As I wrote before, "generic" files would still be usable alone, so automatic stuff can use them. OpenOCD does not do anything automatically though... > Many may prefer GUI but please do not make the mistake of thinking > that GUI is the only way to have ease of use!! Sure it's not (; > 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. My curiosity now - what do you prefer to IDEs like Eclipse. Personally I love Eclipse and I cannot imagine using anything else with comparable efficiency and ease. > 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. I've received an LPC1114 mini-board recently. I knew nothing about those chips. I've installed Flash Loader and after few seconds the chip was programmed... Beat that (; > 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?) I don't think so. To grasp the configuration of OpenOCD you need to read the whole manual, check existing files, learn exotic TCL scripting (I've never heard about it before OpenOCD) from somewhere else (specifics are not included in OpenOCD manual) - it's far from being user-friendly... Of course such problems can and have to be solved by user, but I cannot agree to opinions that "it's right" that these are here, as they separate users from losers. In such case we could throw in some additional "tests"... > 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. :) IMHO having target files for almost all (most of) supported chips is realistic - for instance OpenOCD has interface files for many supported interfaces, even though most of them are FT2232 based and could use only one cfg file instead of few dozens. > 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.. Indeed Flash Loader is for flashing only, but there are many users who use OpenOCD only for that... > Yep! Please send patches. I will also. I'll wait for maintainters' opinions, because if they don't like the idea of separate cfg files any patch in that area would be just a waste of time. > 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. I (almost) never type that, as Eclipse does that for me [; You can always have a shell script to do that for you, but that would probably be no different than having openocd.cfg. > 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? -c "sth" can call anything from any cfg file or OpenOCD-specific commands, but it's pretty impossible to override TCL "variables" this way (like the workareasize for example). > > 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. Why? stm32.cfg file would probably require no changes at all to implement this chip-specific files, so why stop using it if someone prefers? Such generic cfgs will have default values for all overridable parameters, so using them alone would be the same as now. > 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. C is better than TCL, as probably 99.666% of ppl using OpenOCD know it (; C is not a scripting language, but I don't think that is a problem, there are programs that use C-like scripts - EAGLE (which I don't like) is an example. 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
