>> > The read and init operation is different in error handling between JTAG 
>> > and SWD. Are there any other differences?
>> 
>> Yes, and init function should initialize selected adaptor instead of JTAG 
>> only.
>Adapter is another layer, an interface. Target functions should not touch 
>anything except target. The transport has its own routines: SELECT and INIT, 
>they are part of the transport dap_ops, maybe you are regarding to them? :-)
OK, it can be implemented when SELECT and INIT transport. It's a better 
solution.

>> No, all this is necessary. Again, no care how it is implemented, but it must 
>> be implemented in some way for SWD.
>Then it can be another function in dap_ops, a smarter replacement for current 
>ABORT..?
Yes, I prefer this. But OpenOCD maintainer should look into this and do the 
decision.

>> But if JTAG memap_read is transport independent, maybe there will be a 
>> performance problem.
>> I'm not sure how to process this patch.
>This can be true as the impelementation of this part can take retry and error 
>flags handling into account whereas other functions dont anf this could 
>produce a slowdown. Will take a look at this when swd is finished, right now 
>it it working and noone complains so I would not touch this part:-)
No, you mis-understanding, I mean that remove adi_jtag_dp_scan in 
mem_ap_read_buf_u32, so that this function can be transport independent.
And again, OpenOCD maintainer should look into this and do the decision.




simonqian.openocd

From: Tomek CEDRO
Date: 2012-04-17 14:25
To: simonqian.openocd
CC: openocd-devel
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor 
independent
On Apr 17, 2012 4:17 AM, "simonqian.openocd" <[email protected]> 
wrote:
>
> Hello,
>  
> > The read and init operation is different in error handling between JTAG and 
> > SWD. Are there any other differences?
>  
> Yes, and init function should initialize selected adaptor instead of JTAG 
> only.
Adapter is another layer, an interface. Target functions should not touch 
anything except target. The transport has its own routines: SELECT and INIT, 
they are part of the transport dap_ops, maybe you are regarding to them? :-)
> No, all this is necessary. Again, no care how it is implemented, but it must 
> be implemented in some way for SWD.
Then it can be another function in dap_ops, a smarter replacement for current 
ABORT..?
> But if JTAG memap_read is transport independent, maybe there will be a 
> performance problem.
> I'm not sure how to process this patch.
This can be true as the impelementation of this part can take retry and error 
flags handling into account whereas other functions dont anf this could produce 
a slowdown. Will take a look at this when swd is finished, right now it it 
working and noone complains so I would not touch this part:-)
Best regards,
Tomek
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to