On Friday 20 November 2009, Øyvind Harboe wrote:
I'm very much against *forcing* interfaces to implement a queue
in memory. It should be possible to execute the commands
synchronously. The existance of a queue would make the code
*much* less efficient on embedded devices.
We saw contrary
Just to clarify the whole issue once more, my proposal was actually
three different things:
These seem like good directions to explore.
I'll suggest the post-0.4.0 development cycle (January++) as a
good time to have mergeable code that starts reworking any of
this stuff. I don't think 0.4.0
On Friday 20 November 2009, Øyvind Harboe wrote:
2. Eliminating the global variable jtag_command_queue.
The existing jtag_add_... commands would remain similar but would
operate on a local copy of the queue. jtag_execute_queue then receives
the pointer to that local copy as parameter
On Wed, Nov 25, 2009 at 8:54 PM, David Brownell davi...@pacbell.net wrote:
On Friday 20 November 2009, Ųyvind Harboe wrote:
2. Eliminating the global variable jtag_command_queue.
The existing jtag_add_... commands would remain similar but would
operate on a local copy of the queue.
I would beg of you that you study jtag_add_dr() and jtag_add_dr_out()
in oharboe/jtag32api *before* you go down the road of thinkg about
how to put lipstick on the current fields structures...
Especially jtag_add_dr_out() has a track record of being wickedly
efficient.
--
Øyvind Harboe
On Fri, Nov 20, 2009 at 10:43 PM, Michael Bruck mbr...@digenius.de wrote:
On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe oyvind.har...@zylin.com wrote:
Just to clarify the whole issue once more, my proposal was actually
three different things:
1. Making the use of scan_field safer by providing
Øyvind Harboe wrote:
3. Break up jtag_add_dr_scan etc.
This works best in tandem with (2). The general idea is not to pass
one array of scan fields but to pass them in separate function calls
(which would mimic, but replace the ones in (1)). To output a 7 bit
field the caller just hands the
On Sat, Nov 21, 2009 at 2:09 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
Øyvind Harboe wrote:
3. Break up jtag_add_dr_scan etc.
This works best in tandem with (2). The general idea is not to pass
one array of scan fields but to pass them in separate function calls
(which would
Øyvind Harboe wrote:
The important point is that the queuing of JTAG commands
can be done in hardware today, with no overhead.
We want to keep the actual queue implementation something
completely internal to the interface implementations.
Understood. I still do not see how the proposed
On Thu, Nov 19, 2009 at 22:01, David Brownell davi...@pacbell.net wrote:
On Wednesday 18 November 2009, Michael Bruck wrote:
I would actually prefer an API that is tightly linked to an
independent data structure that that builds up a jtag sequence in the
target driver and then executes it. All
On Thu, Nov 19, 2009 at 10:01 PM, David Brownell davi...@pacbell.net wrote:
On Wednesday 18 November 2009, Michael Bruck wrote:
I would actually prefer an API that is tightly linked to an
independent data structure that that builds up a jtag sequence in the
target driver and then executes it.
Just to clarify the whole issue once more, my proposal was actually
three different things:
1. Making the use of scan_field safer by providing standard handlers
for the most common cases.
This not only helps with the readability and reduces trivial
copypaste errors. It also makes it much
On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe oyvind.har...@zylin.com wrote:
Just to clarify the whole issue once more, my proposal was actually
three different things:
1. Making the use of scan_field safer by providing standard handlers
for the most common cases.
This not only helps with
On Thu, Nov 19, 2009 at 1:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Was this for the list?
Yeah it was, that Reply-to-all button seems to be hard to find sometimes.
On Thu, Nov 19, 2009 at 12:34 AM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Wed, Nov 18, 2009 at
On Wednesday 18 November 2009, Laurent Gauch wrote:
I do not understand what is the advantage to work on 32bit buffers
instead 8bit buffers for out_value and in_value.
For starters, in some contexts it's faster by a factor of more than
four ... one instruction moving N bits, not four (and then
On Wednesday 18 November 2009, Michael Bruck wrote:
I would actually prefer an API that is tightly linked to an
independent data structure that that builds up a jtag sequence in the
target driver and then executes it. All the commands would then work
on building up that structure and in the
I'm pondering how we could gently in a series of
non-breaking patches prepare the ground for switching from
8 to 32 bit words in the jtag_add_xxx API.
The attached patch gets rid of buf_set_u32() when setting
the value of a byte.
This achieves two things: the code is less obtuse and it
On Wed, Nov 18, 2009 at 9:38 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
I'm pondering how we could gently in a series of
non-breaking patches prepare the ground for switching from
8 to 32 bit words in the jtag_add_xxx API.
The attached patch gets rid of buf_set_u32() when setting
I would suggest removing the fields completely from that layer and
replacing them with function calls. For the most common types of data
like uint32_t.
scan_start_dr();
scan_tap(struct jtag_tap);
scan_field_u32_w(size_t bits, uint32_t value);
scan_field_u32_wr(size_t bits, uint32_t value,
On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck mbr...@digenius.de wrote:
I would suggest removing the fields completely from that layer and
replacing them with function calls. For the most common types of data
like uint32_t.
scan_start_dr();
scan_tap(struct jtag_tap);
On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck mbr...@digenius.de wrote:
I would suggest removing the fields completely from that layer and
replacing them with function calls. For the most common types of data
like
On Wed, Nov 18, 2009 at 15:35, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Wed, Nov 18, 2009 at 3:32 PM, Michael Bruck mbr...@digenius.de wrote:
On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck mbr...@digenius.de
Actually, the minidrivers don't clone today, so that's already taken care of.
Doesn't that apply only to zy1000.c ?
The USB case needs to delay execution to build a long
scan, so there copy is required.
The USB drivers have a 1ms roundtrip problem to contend with, the
rest is in the noise,
On Wed, Nov 18, 2009 at 16:17, Øyvind Harboe oyvind.har...@zylin.com wrote:
Actually, the minidrivers don't clone today, so that's already taken care
of.
Doesn't that apply only to zy1000.c ?
The USB case needs to delay execution to build a long
scan, so there copy is required.
I think
I'm pondering how we could gently in a series of
non-breaking patches prepare the ground for switching from
8 to 32 bit words in the jtag_add_xxx API.
The attached patch gets rid of buf_set_u32() when setting
the value of a byte.
This achieves two things: the code is less obtuse and it
is more
25 matches
Mail list logo
