[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openocd-development
Subject:    [Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with
From:       freddie_chopin () op ! pl
Date:       2010-10-29 9:21:18
Message-ID: Q25380809-f419ef17036c545bc866baec069b9c7a () pmq1 ! m5r2 ! onet ! test ! onet ! pl
[Download RAW message or body]

"Peter Stuge" <peter@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


[prev in list] [next in list] [prev in thread] [next in thread]