On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now inhandlers are supposed to
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now
On Friday 08 May 2009, Anders Montonen wrote:
If I remember the USB spec correctly, the lowest achievable round-trip
time (ie. one OUT transfer followed by one IN transfer) is two
milliseconds for low- and full-speed devices.
Depends on the implementation of the host controller driver
and
On May 8, 2009, at 9:04, Øyvind Harboe wrote:
For the sake of argument: if 16 roundtrips was the total # of
roundtrips
for a step, then I'd have to see real world numbers before I
believed that
that was observable.
If I remember the USB spec correctly, the lowest achievable round-trip
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 1628)
+++ src/target/arm_adi_v5.c (working copy)
@@ -77,22 +77,22 @@
fields[0].num_bits =
This patch, from 1636 to 1637 breaks the cortx targets.
I am not sure why but I really think removing the inhandler
functionallity is NOT ready for production use yet. Better testining is
needed before changes like this.
Regards
Magnus
Øyvind Harboe wrote:
Committed.
### Eclipse Workspace
The problem is that the inhandler is called asynchronosly from the jtag
layer when the indata has been received.
When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
not even sent the jtag data to the target son the in value is not
available untail after the next
On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
The problem is that the inhandler is called asynchronosly from the jtag
layer when the indata has been received.
When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
not even sent the jtag data to the
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
The problem is that the inhandler is called asynchronosly from the jtag
layer when the indata has been received.
When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
not even
Consider the simplifications you will have in 99% of all calling
code + the JTAG implementations.
The in_handler behaviour can be synthesized on top of the JTAG
API layer in various ways and if there is a performance problem,
then it will become more clear to the caller how to deal with this
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that is long after we exit this function and temp
is out of scope.
Did you look at jtag_add_dr_scan_now() implemenation?
It calls
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that is long after we exit this
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that is
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that is
Did you look at jtag_add_dr_scan_now() implemenation?
It calls jtag_execute_queue_noclear(), so we *can* use stack variables
here for in_value.
This is basically:jtag_add_dr_scan_now() == jtag_add_dr_scan +
jtag_execute_queue , we have that in the cortex code where it is
On Fri, May 8, 2009 at 1:55 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Did you look at jtag_add_dr_scan_now() implemenation?
It calls jtag_execute_queue_noclear(), so we *can* use stack variables
here for in_value.
This is basically: jtag_add_dr_scan_now() == jtag_add_dr_scan +
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now inhandlers are supposed to be bad, it is dictated that inhandlers
are bad. I know about the
I was wrong, there is one more comment :)
The problem with out of context in variables (a real problem, I agree,
but not what makes current code misbehave) has nothing to do with
in_handlers, it is really about the in_value field pointing to a
receiving value.
The inhandler simply transforms
18 matches
Mail list logo
