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 ev
>
> 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 a
On Wed, Nov 18, 2009 at 9:38 AM, Laurent Gauch
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
>> the value of a
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, uint32_
On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck 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);
> scan_field_u32_w(size_t bits, ui
On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe wrote:
> On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck 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();
>>
>>
On Wed, Nov 18, 2009 at 3:32 PM, Michael Bruck wrote:
> On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe wrote:
>> On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck wrote:
>>> I would suggest removing the fields completely from that layer and
>>> replacing them with function calls. For the most common
On Wed, Nov 18, 2009 at 15:35, Øyvind Harboe wrote:
> On Wed, Nov 18, 2009 at 3:32 PM, Michael Bruck wrote:
>> On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe wrote:
>>> On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck wrote:
I would suggest removing the fields completely from that layer and
>>
>> 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
On Wed, Nov 18, 2009 at 16:17, Øyvind Harboe 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 you misunders
On Thu, Nov 19, 2009 at 1:03 PM, Øyvind Harboe 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
> wrote:
>> On Wed, Nov 18, 2009 at 9:40 AM, Øyvind Harboe
>> wrote:
>>> On Wed, No
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 the
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
On Thu, Nov 19, 2009 at 22:01, David Brownell 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 the commands
On Thu, Nov 19, 2009 at 10:01 PM, David Brownell 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 the comma
> 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
> copy&paste errors. It also makes i
On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe 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 the readabil
On Fri, Nov 20, 2009 at 10:43 PM, Michael Bruck wrote:
> On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe 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
Ø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
On Sat, Nov 21, 2009 at 2:09 PM, Michael Schwingen
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 mimic, but re
Ø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 propos
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 f
> 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 para
On Wed, Nov 25, 2009 at 8:54 PM, David Brownell 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. jtag_execute_
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
http:/
26 matches
Mail list logo
