On 2010-12-03 22:42, Michael Schwingen wrote:
On 12/03/2010 10:06 PM, Freddie Chopin wrote:
On 2010-12-03 21:39, Rolf Meeser wrote:
The clock parameter is vital for correct and reliable flash programming.
It must be possible for the user to select the frequency that he is
using.
I don't know how about you, but me (and 99% of "normal users") "reset
halt" the chip before programming - so it does run at 4MHz during
programming.
And everyone else can live with unreliable results? I don't like this
approach. Correct operation should be the highest priority.
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?
Debugging is negligibly faster when using high clock, flash
programming duration gain is probably also negligible (what's the
difference between waiting for 20 seconds to waiting for 10 seconds?).
10 seconds? 100% (as seen by the the lucky 10s user)? And by the way
this is unrealistic. The penalty is much higher!
At 72 MHz I can program the LPC2478 (504 KiB) in 14s with a simple JTAG
interface. I feel no urge to wait longer than that.
And how often do you flash full 504kB? 100kB will take ~4s, so whats a
difference between ~4 and ~20 seconds? How about small program - 10kB?
In a day "your way" will give me maybe 1 free minute more. For me
that's not worth the trouble [; But that's not the main point...
What's the purpose of using a 512KiB flash micro if you only need 50K?
Lots of applications *will* use big parts of the flash, and yes,
programming times *do* matter in my development cycle, especially if we
are talking 10s vs. 20s (and for no good reason!).
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 (;
And you won't have because world does not end on "ready made boards".
That's why people don't use them and that's why IMHO there is no point
in creating them. What's the point for a board config file if most of
the boards with small microcontrollers don't have any external ram,
fancy reset circuitry and anything unusual - normal target file works
just fine, and what's most important for me (and not only me!) is that
it works standalone - without anything more.
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!
But most of all - this makes running OpenOCD with just command line
arguments impossible (openocd -f interface/sth.cfg -f
target/sth_else.cfg), as now you have to have your board config file.
Please - don't go this way.
Why would that be impossible? Who prevents you to use a script that sets
*your* clock frequency and includes the target script?
You don't get my point. To run OpenOCD "my way" I don't need ANY
scripts beside standard target/interface files that come with OpenOCD.
So what is the problem? Right now, you are using the LPC2478 target
config file. You could use some kind of "lpc2478_std" config file
instead - same amount of typing, same user experience, but those people
working with more complex boards will have the benefit of running at the
right clock speed.
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...
For this reply to be constrictive criticism, I suggest you leave 4MHz
default value in case no clock is specified.
I am not sure if this is a good idea - users won't notice when they
forget to specify the clock speed in their board config files - after
all, it *is* a required parameter.
Let's just add a standard board config file that supplies the 4MHz default.
In case of not-specifying that frequency there could be warning emitted
from the config script. It's possible to emit error, so it's probably
possible to emit a warning too. Or a scary message.
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...
I have a crazy idea - I think it is possible to measure frequency of
the external crystal (and check for it's existence) with simple code
using one timer. This way OpenOCD would work without specifying this
frequency. It could then - before programming - measure it (backup-ing
all settings of timer), switch PLL to max value (using external
crystal or internal resonator, also backup-ing all settings of clock
and PLL), flash, revert all changes made to clock, PLL and timer and
voila [; Problem gone
Nice idea. However, that goes way beyond what is required right now to
get reliable programming at the maximum possible speed.
Also, will this work without a "reset init" to get the system into a
known state?
I was thinking about embedding that within OpenOCD's flash handling code
specific for LPC, not in config files. Right now you have to supply that
speed, with such wise flashing algorithm this parameter would be useless
(could be provided, could be omitted - freq would be measured then).
4\/3!!
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
