Andreas, this is great..
some of these optimisations i have tried but some i havnt, so this gives me
something to go on, i can try optimise my use of jtag_execute_queue(); some
more.
one other thing, as far as i see it in other targets, reg_cache is filled
up with valid register values when a cpu is halted, then the "reg" command
reads from the reg_cache but not the target hardware itself, is there a way
to force the "reg" command to read regs from hardware ? i can see this
notion with the "gdb_sync" command but that still reads from reg_cache
if i can make the "reg" command read from the target registers then i can
postpone time consuming register reads/writes that happen at halt/resume
time
thank you
On Mon, Jun 17, 2013 at 8:50 PM, Andreas Fritiofson <
[email protected]> wrote:
>
>
>
> On Mon, Jun 17, 2013 at 3:37 PM, Adrian Burns <[email protected]>wrote:
>
>> hi,
>> a newbie here,
>>
>
> Hi!
>
>
>> using flyswatter2 and olimex arm debuggers
>> working with openocd 6.1 codebase
>>
>> in order to read back some registers i have to issue a number of ir/dr
>> scans to my tap chain and its working fine but im looking at ways to speed
>> it up if possible
>>
>> so im calling jtag_add_ir_scan() and jtag_add_dr_scan() a number of times
>> in sequence
>>
>> is this the most efficient way to do a number of ir/dr scans in a row?
>>
>
> If you follow the hints below, the generated commands to the FTDI chip in
> the adapter *should* be close to optimal. Then of course it depends on how
> high you can boost the frequency.
>
> And as always, profiling is the key to optimization.
>
>
>>
>> code looks something like this...
>>
>>
> It would be easier to help if you showed more than an incomplete extract
> from the code.
>
> ...
>> ...
>> /* setup IR with correct opcode */
>> struct scan_field *fields;
>> fields = malloc(sizeof(struct scan_field));
>> memset(fields, 0, sizeof(struct scan_field));
>>
>
> You can avoid the (probably insignificant) malloc overhead if you keep the
> fields on the stack. You only need to maintain the fields array and the
> out_value until after the corresponding jtag_add_*_scan(). It's only the
> in_value storage you need to keep available until the queue is executed.
>
> fields->num_bits = ir_len;
>> fields->out_value = in;
>> fields->in_value = out;
>>
>
> (Reversed in/out? Not that out_value is scanned IN to the TAP and in_value
> is scanned OUT. But you had this working already.)
>
> I guess this is a made-up example anyway, but it will be slightly more
> efficient if you keep in_value = NULL for the IR scans and out_value = NULL
> for DR scans (assuming data scanned into DR is irrelevant).
>
> jtag_add_ir_scan(t->tap, fields, TAP_IDLE);
>> ...
>> ...
>> /* then do drscan */
>> /* then do next irscan */
>> /* then do next drscan */
>> etc
>>
>
> Since you're not showing the complete code I can't tell if you're doing it
> already, but it's important that you queue up all scans first and then
> execute the queue once.
>
> I.e.
>
> jtag_add_ir_scan();
> jtag_add_dr_scan();
> jtag_add_ir_scan();
> jtag_add_dr_scan();
> ...
> jtag_execute_queue();
>
> not
>
> jtag_add_ir_scan();
> jtag_add_dr_scan();
> jtag_execute_queue();
> jtag_add_ir_scan();
> jtag_add_dr_scan();
> jtag_execute_queue();
> ...
>
> Each execute will incur a significant delay due to USB roundtrip. So don't
> call jtag_execute_queue() until you really need the data.
>
> Also you'll want to use the new ftdi adapter driver instead of the ft2232
> one because it's much faster on some workloads.
>
> /Andreas
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
