On Wed, Nov 24, 2010 at 12:10 AM, Wookey <woo...@wookware.org> wrote: > +++ Andrew Leech [2010-11-17 14:02 +1100]: >> >> Yep I rewrote the command line parser, so the usage is now: >> "usage: svf [-tap device.tap] [-quiet] <file>" >> >> Arguments are checked in a loop so it will accept switches and <file> >> in any order. quiet or -quiet are both recognised. And of course, -tap >> is optional. As such it is now back compatible, much nicer and more >> flexible. There's also a help switch that simply prints usage in case >> anyone tries it. > > As someone who has previously used svf and xsvf functionality with > chained devices I'd like to add another 'yes please this is great' > vote, and thank andrew for his work (I'm glad someone understands > this stuff :-) > > Oddly I have previously found that xsvf files would work even when > they were generated single but used in a chain (or maybe it was the > other way round). I was quite suprised about this and assumed that > openocd was already doing something clever equivalent to the > functionality this patch provides. But obviously that was just dumb > luck. > > And yes the above syntax is the right way tto do this. Breaking > existing scripts is something we should work hard to avoid as it can > make openocd updates in production environments very awkward.. > > Wookey
Yeah I'm much happier allowing previous syntax to work fine without modification. I haven't looked at the xsvf module at all, while it would be neater to bring it in line with this one, or even roll both of them rolled together, I don't have any xilinx parts or software so haven't had any call to use it. The xsvf parser or format may very well have chain functionality built into it, I'm not sure. Well I've made a whole heap more updates, and eventually realised I should be splitting them up into separate patches, as many of them are (or should be) somewhat independent. That was a bit of a hassle, but it's neater this way.... as well as being openocd policy from what I've read. svf_chain_cmd_parser.patch : Main patch, chain tap handling and updated command parser, mostly the same as earlier submitted patch. svf_file_handling.patch: converts file handling from open to fopen etc. Also input files are read as whole lines before parsing. Debatable whether this is neater code, but it does result in 10% speed improvement for me, and should be more portable. svf_progress_indicator.patch: Adds progress indicator (xx% readout) when (-)progress flag added to command line. this works in both quiet and non-quiet modes. This patch is dependent on svf_file_handling.patch being previously applied. svf_time_output_format.patch: time taken readout at end of svf operation converted from direct ms output to minutes-seconds-ms output for better readability. I've used this newer version to program my a3p125 and a3p060 parts on identical chains with lpc3131 multiple times with different flags and haven't had any problems. One significant finding is the time difference when non-quiet (default) mode is used, particularly on windows the verbose output slows the overall operation down a _lot_. I'm talking 1mins 19sec for quiet compared to 6mins 40sec on verbose. The time difference on linux was much much less severe but I haven't tested it with the full length file, but but on a much shorter test file it was a difference of 8 seconds to 14 seconds. The programming works fine either way, just printing the lines takes some time. This slow file is ~290,000 lines of svf, so not surprising that it takes some time to print all this to console. Andrew
svf_chain_cmd_parser.patch
Description: Binary data
svf_file_handling.patch
Description: Binary data
svf_progress_indicator.patch
Description: Binary data
svf_time_output_format.patch
Description: Binary data
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
