Dick Hollenbeck wrote: > The new driver is working ok with the calls to > tap_get_tms_path_len(start_state, goal_state); > > If I use the old version of the new binary tms_seqs table with the new > driver, I see the exact same behavior on my ARM9 board as with the > ft2232.c in HEAD. > > If I use the new version of the binary tms_seqs table, I see less clock > cycles being consumed and it is working at 99.9%. I think however the > problem I am seeing with this combo is related to the new binary table > and not this un-commited driver. > > > new driver + old table = 100% OK > new driver + new table = 99.9 % OK > > > new table sends out less clocks. No timing information available yet, > as to whether the reduced clock support was worth the trouble. But that > will come. > > > So I will use the new handy state transition logging to track down the > differences in behavior and submit a final patch to ft2232.c sometime > this week. This code adds: > > > ** the reduced clock cycle support and > ** the state transition logging and > ** some asserts to trap buffer overruns. > > > I have merged in the recent icebear patch. > OK, with one tweak to the new table, the new driver + new table seems to me that it could be at 100%. I also did some benchmarking, comparing
new driver + new table to new driver + old table and the only test I could think of was writing to an 4 mbyte CFI flash on ARM9: new table: 5.55 kb/s old table: 5.47 kb/s So this is about a 1.4 % reduction. So I guess USB turnaround latency is the bottle neck, not the bitrate? Or the flash burn rate? Maybe writing to RAM is a better test. I still want to play with the ft2232.c code for another day or so before I post the [PATCH] here. I want to test it under the xsvf.c code, which will finally give me state transition logging. The state transition logging was nice in finding this problem. I just took the two log files, loaded them both into Jedit. Then I stripped the leading "Debug 123 455" stuff off of both files and then used the JDiff plugin to show me the differences between the two logs. The location of the problem revealed itself in minutes. The solution was a little black magic however. We needed another clock while in RESET when going from RESET to DRSHIFT. Don't know why. But the old table had 3 such clocks. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
