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.
> 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. 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. > >>>>> 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... 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. > 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. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
