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.
> >>> 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!). > 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 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. > 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. > 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? cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
