On 2010-12-04 00:32, Rolf Meeser wrote:
This is a misconception. When OpenOCD tries to take control after a
reset, the CPU is already running. ISP mode or existing user firmware
may or may not have changed the clock tree. Like it or not, but there is
no a priori knowledge of CPU clock.
When doing "reset halt" (which would halt the chip immediately after
reset) the clock would be 4MHz.
With LPC23xx you are in the same situation as with older LPC2000 which
required an external crystal. The operating frequency is *not* a target
parameter, it is a board/application parameter.
Indeed - older LPCs don't work this way, because there is no internal
oscillator. So why change lpc2478.cfg that CAN work with default value,
and leave all older files that CAN'T?
C'mon! 10s?! Don't read mailing lists and that will save you much more
time (;
I'm afraid but professional embedded development is different. Speed
matters.
Why would I renounce the comfort of a fast download when I can get it
for free?
I want OpenOCD to be as efficient as possible.
If you don't like that, you may always run at a slower clock, and help
yourself with a cup of tea.
I like that I can take my mind off firmware for a few seconds and trade
a few words with a co-worker sitting next to me. Actually "professional
embedded development" in here must not look like in your place - we're
not racing for the fastest upload on the market, because the client
probably would not care if you could deliver the product a few hours
earlier due to these tremendous savings on upload time (;
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!
That's the whole point of OpenOCD's layered config file approach.
Do you refuse to work with an LPC2138 device just because its target
config file cannot include a clock frequency? There is no way to avoid a
board file here. And at the risk of repeating myself, the situation for
LPC23xx is the same.
I've stated on multiple occasions that for me this whole policy is wrong.
As for the second paragraph, you are wrong. All LPC2xxx target config
files have that frequency embedded without possibility to change with
some parameters in board config files and - somehow - people manage to
use it without problems. And I like those files very much, because they
work standalone, so in my favorite way.
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...
Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not
getting it.
We're talking about a three-liner: 1. your interface, 2. your clock
frequency, 3. your target.
That's clearly a no-brainer!
I don't have to do that with ANY LPC2xxx file now. You're wrong here,
because all these target files have frequency embedded inside without
any parameters.
Just for the record - typing names of 2 files in command line is
more-no-brainer than creating a config file that includes them.
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).
Deep inside I have a feeling that this proposal is on a head-on
collision course with your wish for simplicity...
Technically, I do not know how you want to measure frequency without a
timing reference.
And why on earth would I *temporarily* enable the PLL to circumvent the
difficulty of enabling the PLL at all?
I'm lost.
The idea with timers was wrong, but I've come with even simpler one. A
simple algorithm is being executed on the chip (count++;) after some
time (say 10ms) you halt it and check the value of count which gives you
an estimate of frequency the core is running at.
How can "not-requiring a parameter" be more complicated than "requiring
it"? Deep inside OpenOCD is complicated way beyond that.
Why enable and then disable. Because I want the chip to be in an
after-reset state after flashing - I thought that's obvious. Having PLL
enabled after flashing has completely NO advantage and possible problems
with user code.
4\/3!!
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
