> Dick,
>
> Once again, "it's not you, it's me." Blah, blah, blah :)
>
English please. No idea what the above sentence is saying.
> On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote:
>
>> This patch is large and:
>>
>
> ... should have been split into pieces.
>
Take
I would like to start another holy war while we are at it:
1. Are false preprocessor variables in OpenOCD specified by not
defining a variable or by defining it as 0 ?
2. config.h generated by autotools and cmake use different paradigms for this
3. several files (including my latest patch for j
Dick,
Once again, "it's not you, it's me." Blah, blah, blah :)
On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote:
> This patch is large and:
... should have been split into pieces.
> ** allows the ft2232 cable to be detached and reattached without having
> to restart openocd.
Pat
If you build openocd with --enable-rlink (or probably with other options
that use USB) and at least usb.h is not present in the system headers,
you get a build failure.
"./configure --enable-rlink" does not check for presence of usb.h which
is the first compile error seen. I had to install package
Fixes some problems. Has worked on OS2, Linux, Windows, Cygwin now.
It generates both openocd executable and also now a libopen-ocd.so file
for folks wanting to make a shared object / DLL. That would be me. I
think I want to call it from Java now. So I will probably adding a SWIG
file sep
Dick, While I am responding to your initial post, I also use it as
launchpad for sharing my broader position on the topic, so it's not all
aimed at you. :)
On Fri, 2009-05-01 at 08:02 -0500, Dick Hollenbeck wrote:
> Are other folks having problems with tab expansion differences between
> editors
I guess I will try and get my ft2232.c patch in by end of the day, as
promised earlier, and add this stuff in too:
https://lists.berlios.de/pipermail/openocd-development/2009-March/005123.html
But I will not be able to test that usb chip.
Also, there was buffer overrun patch hanging around here
Øyvind Harboe wrote:
> On Fri, May 1, 2009 at 6:24 PM, Dick Hollenbeck wrote:
>
>> That function basically exists in the xsvf.c file, so some factoring may be
>> possible.
>>
>
> Ah. Thanks!
>
> Rename to jtag_add_statemove() & move into jtag.c as a helper fn? :-)
>
exactly what I was
Magnus Lundin wrote:
> Dick Hollenbeck wrote:
>
>> Laurent Gauch wrote:
>>
>>
Dick Hollenbeck wrote:
> / Are other folks having problems with tab expansion differences between
>
>
>
/>/ editors?
>>>
On Fri, May 1, 2009 at 6:24 PM, Dick Hollenbeck wrote:
>
> That function basically exists in the xsvf.c file, so some factoring may be
> possible.
Ah. Thanks!
Rename to jtag_add_statemove() & move into jtag.c as a helper fn? :-)
The only problem I see with doing that is that if xsvf needs *PREC
That function basically exists in the xsvf.c file, so some factoring may
be possible.
Here is a copy of my current work:
> Single stepping is broken in ARM11 w/parport interface(and
> others). I'm working on adding a jtag_add_statemove() fn
> that will sit on top of jtag_add_pathmove() that is
Dick Hollenbeck wrote:
> Laurent Gauch wrote:
>
>>> Dick Hollenbeck wrote:
>>>
>>>
/ Are other folks having problems with tab expansion differences between
>>> />/ editors?
>>> />/
>>> />/ I load jtag.c into two different editors and get two different
Laurent Gauch wrote:
>> Dick Hollenbeck wrote:
>>
>>> / Are other folks having problems with tab expansion differences between
>>>
>> />/ editors?
>> />/
>> />/ I load jtag.c into two different editors and get two different results
>> />/ when tab width is set to 4.
>> />/
>> />/ Th
Single stepping is broken in ARM11 w/parport interface(and
others). I'm working on adding a jtag_add_statemove() fn
that will sit on top of jtag_add_pathmove() that is probably
necessary to implement more robust ARM11 support.
--
Øyvind Harboe
Embedded software and hardware consulting services
h
Personally I'm looking and working with too many projects
with too different formatting rules to even be able to
see whitespace at all anymore
Here is some food for thought:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=45423
--
Øyvind Harboe
Embedded software and hardware consulting servi
>
> Dick Hollenbeck wrote:
> >/ Are other folks having problems with tab expansion differences between
> />/ editors?
> />/
> />/ I load jtag.c into two different editors and get two different results
> />/ when tab width is set to 4.
> />/
> />/ This makes it difficult to view a table like tms
Dick Hollenbeck wrote:
> Are other folks having problems with tab expansion differences between
> editors?
>
> I load jtag.c into two different editors and get two different results
> when tab width is set to 4.
>
> This makes it difficult to view a table like tms_seq in the two
> editors. Th
Are other folks having problems with tab expansion differences between
editors?
I load jtag.c into two different editors and get two different results
when tab width is set to 4.
This makes it difficult to view a table like tms_seq in the two
editors. The editors are well established, JEdit a
Øyvind Harboe wrote:
>> - Changing JTAG state transitions to use shortest path rather than 7 clocks
>> - Fixing all the drivers that assumed 7 clocks per transition
>>
>
> Why would you want to change this? We've got pathmove for those cases
> where the path matters...?
>
>
Said another way
Magnus Lundin wrote:
> Now compare the reported start addresses below with table 5-105 in
> OMAP35x TRM, SPRUF98B–September 2008,
> and table 2-3 in CoreSight Components, and the management registers in
>
>>> dap info 1
>> ap identification register 0x04770002
>> Type is mem-ap APB
>> ap debugbas
Zach Welch wrote:
> * JTAG/TAP changes:
> - use tap_set_state everywhere to allow logging TAP state transitions
> + rework TAP state table (started by JW, but still needs work)
> - update tap_get_tms_path API (suggested by DE)
> - slow boat: add tap_get_tms_path2 and allow both for a whil
On Fri, 2009-05-01 at 01:42 -0700, Zach Welch wrote:
> You beat me to posting a summary thread.
>
> On Fri, 2009-05-01 at 09:17 +0200, Øyvind Harboe wrote:
> > We don't have a way to measure consensus but I belive the current
> > consensus can be summarized as:
> >
> > - OpenOCD stays C for now.
Hi all,
Here is The List of outstanding tasks for the OpenOCD project and those
working on the various tasks. Please review those items in which you
have an interest and provide corrections, additions, or other feedback.
Since my last post, the mailing list has continued to hum with activity.
Th
You beat me to posting a summary thread.
On Fri, 2009-05-01 at 09:17 +0200, Øyvind Harboe wrote:
> We don't have a way to measure consensus but I belive the current
> consensus can be summarized as:
>
> - OpenOCD stays C for now. There has to be a good plan and
> major upside to budge the status
Øyvind Harboe wrote:
> of course in C "if (var==true)" is a nasty construct :-)
>
Indeed.
However, you can "improve" this still by adding
#define TRUE 0
#define FALSE 1
somewhere (yes, a friend had to maintain such code for a customer)
;-)
cu
Michael
_
Hi all,
The attached patch gives a minor upgrade to OpenOCD's autotools support.
Its commit message should provide ample detail for understanding all of
the changes that were made, though the patch itself is easy to read.
I would have simply committed these changes, but I recognize that they
coul
We don't have a way to measure consensus but I belive the current
consensus can be summarized as:
- OpenOCD stays C for now. There has to be a good plan and
major upside to budge the status quo.
- OpenOCD has a number of quaint constructs that mimick features in
other languages(virtual function ta
>
> bool var;
> if (var==true) a++;
of course in C "if (var==true)" is a nasty construct :-)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@l
Uwe Hermann wrote:
> On Thu, Apr 30, 2009 at 08:22:32PM +0200, Nico Coesel wrote:
>
>> My vote would be for OpenOCD to stay a C program.
>>
>
> Same here.
>
>
"Mee too".
cu
Michael
___
Openocd-development mailing list
Openocd-development@list
> Øyvind Harboe
> Verzonden: donderdag 30 april 2009 16:04
> Aan: Dick Hollenbeck
> CC: Openocd-Dev
> Onderwerp: Re: [Openocd-development] C99 compatibility (Was:
> MSVCcompatibility (Was: [PATCH] CMake))
>
> > Linux is an operating system. OpenOCD is an application. This
> > would be like b
30 matches
Mail list logo
