On 2010-12-04 00:00, Michael Schwingen wrote:
On 12/03/2010 11:11 PM, Freddie Chopin wrote:
How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz
internal clock. Doing "reset halt" sets that clock and prevents any
code from changing that (let's not talk about broken cases, because a
broken case can be found everywhere), so what's wrong with this approach?
So flashing is only supported after "reset halt"? That adds another step
during development in case I work with different clock settings. That's
what I meant by "broken": flashing does not work until I bring the board
into some configuration (reset halt) that is different from what I
normally need.
So you're all about correctness and you don't reset halt the chip before
flashing? How is that correct? Actually flashing does not work if you
don't "reset halt" the chip. The need for halting is obvious. The need
for reset is not, but think about what would happen if your code would
have a timer (or any) interrupt enabled and running during your
flashing. Actually you DO need to get the chip in some known (and
specific!) condition to flash it. Moreover - the new config file works
exactly the same way - you can specify the clock as a parameter, but to
be sure about it you need to reset halt or reset init.
Why use big chip? LPC2478 has an LCD driver, and there is no chip with
LCD driver that has less flash. Because for developement of the
project you take big chip just-in-case, and choose right one
(regarding flash size) for production when the code is ready. Anyway -
we should be talking about the average size of the upload, and that's
never 512kB - the code has to grow from 0 to this size during
developement.
BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based
JTAG)? I'm asking because if waiting 10s is worth breaking
configurations of OpenOCD's regular users, then I hope you use the
fastest library for the process.
C'mon! 10s?! Don't read mailing lists and that will save you much more
time (;
It's not about the total amount of time, it is about interrupting my
work on every upload.
Now how is the operating system I use relevant for this discussion? Just
because some things in OpenOCD might be improved does not mean that we
should slow down other operations as well - for no benefit, just because
you declare that it should be "good enough" for everyone.
Operating system matters because ftd2xx is faster only on Windows - in
Linux it's slower or the same.
I'm not telling "slow down" - I'm saying "don't use this file that can
speed things up because it also makes using OpenOCD a bit harder".
Technically this file does not speed anything up, because there is no
PLL setting anywhere in it - the new board config file (another patch)
does speed things up and it can speed things up exactly the same way now
or when lpc2478.cfg would use some default value.
BTW why isn't the pll configuration function placed in target file?
Then let's provide a board config file that works fine on those barebone
applications where OpenOCD does not need to know anything beyond the
CPU.
But there's no point in having a "board" file that in reality is not
for board but for target, that will do nothing more than include
target file... What for? What does that make easier? If one has it's
own board with some chip I don't think one would look for config
scripts in board directory... I wouldn't. Please - try to make OpenOCD
more user-friendly, not user-hostile!
The config file you need *is* for a board, so it belongs in the board
directory. The LPC target alone can not know the clock used.
If I'd have the microcontroller hooked up directly to JTAG and PSU with
thin cables would that be considered a board too? It's just a simple
microcontroller! It needs almost none configuration on OpenOCD's side -
every board with LPC2478 was using the old file and it was fine.
The problem is that "right now" OpenOCD provides all I need, because
there is no "lpc2478_std" config file, lpc2478.cfg works just fine - I
(and anyone willing to use OpenOCD with that chip) would have to
create it first. Same amount of typing and user experience? I doubt it
- right now I don't need to know ANYTHING about tcl, OpenOCD's config
files etc. They work out-of-the-box. People working with more complex
boards are not forbidden to set right clock speed now. Actually I
think they managed, because I've not seen any complaints...
Um - no. I proposed to add that file to OpenOCD, so no user would need
to learn TCL or write his own config file - just like it is now.
You said "use some file", not "I'll add that to OpenOCD"...
I've made a proposal to create target files for every chip that
OpenOCD could support and organize them neatly in directories. This
has a disadvantage of having hundreds of files. Your approach (having
board file just because target file was made dependent on some
parameters) creates a need for otherwise useless files...
It is not useless - it enables other board config files to specify the
real clock speed.
Again - it would be even more useful if it had default frequency with a
warning.
4\/3!!
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
