On Mittwoch, 28. Februar 2018 21:51:29 CET Christopher Head wrote: > I’ll be completely honest here: the reason I tried doing this is because the > algorithm approach *broke* with the FTDI adapter, not because I wanted to > improve speed. It kept issuing messages either timeout waiting for > algorithm or debug regions unpowered. So I tried bypassing the algorithm > and noticed that it was really slow, *then* tried speeding it up by moving > the CR and SR accesses out of the loop and noticed that it became really > really fast.
Not surprising, since the turn-around penalty over USB is quite substantial. This is the main reason why openocd uses all the "STICKY" features, which is OK in principle for throughput but makes error recovery really cumbersome. And the throughput can be quite substantial. I've timed uploads to DDR memory at 30 MHz JTAG clock to reach close to 1MB/s, as long as you just push data out and don't need to flush the queue to turn around and read back status registers. BR, Matthias ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
