On Fri, Feb 24, 2012 at 3:54 PM, Spencer Oliver <[email protected]> wrote: > On 14 February 2012 01:07, <[email protected]> wrote: >> This is an automated email from Gerrit. >> >> Andreas Fritiofson ([email protected]) just uploaded a new patch >> set to Gerrit, which you can find at http://openocd.zylin.com/454 >> >> -- gerrit >> > > Thought i would reply to the list as this patch series is non-trivial, > so as many eyes as possible is good. > > This all seems a much cleaner implementation than we currently have, > and is working well in my tests.
Great! > I saw a negligible speed increase (0.5KiB/s), not sure if this is expected. Depends on what you tested. Flash programming (with async support) shouldn't benefit much. Verify and dump is *much* faster here, as well as raw throughput to RAM. At least on CM3. General debugging should be snappier too, but it's hard to quantify. I think I've posted these figures before, which is for STM32F1xx at 64MHz with 3MHz TCK (or was it 6?): Flash write 128k, 29.932 KiB/s -> 32.835 KiB/s Verify 128k, 97.452 KiB/s -> 221.608 KiB/s Memory dump 128k, 20.645 KiB/s -> 73.848 KiB/s RAM download 20k, 76.731 KiB/s -> 100.391 KiB/s Total elapsed time incl. startup, 13.588s -> 7.128s > Andreas, what is your plan with regards to merging/replacing the > current ftdi implementation? First I need a way to specify layouts in Tcl, I really don't wan't that mess in the driver. I'm going to need some help with that to make it simple and flexible enough. I've been thinking of having commands to specify set/clear bitmasks for each operation (assert_srst, deassert_srst, blink and so on). That should be generic enough, but it's a huge amount of obscure values that needs to be specified and a lot of ugly command handlers in C. The trouble is how to represent the necessary information cleanly in the Tcl config file and how to get that information into C (I have very little knowledge of the Jim-to-C binding). Ideas, anyone? After that it's a matter of writing config files for all the interfaces that are currently supported in the ft2232 driver. I guess the new driver will live side-by-side with the old for some time to gain some mileage. Hopefully the ftdi driver will be the default choice after a while, at which point the ft2232 driver could be deprecated and finally removed. Some special interfaces may not be portable to the new driver, i.e. signalyzer, so the ft2232 code may need to stay for those, or they can be broken out to separate drivers. > Has anybody else tested this patch series? Please do! I realize that the limitation of a single working layout makes it hard for many people, but if you have a jtagkey-compatible dongle, give it a spin. Most appreciated would be some non-ARM, non-Linux testing. Regards, Andreas ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
