==
Author: duane
Date: 2009-06-28 04:54:19 +0200 (Sun, 28 Jun 2009)
New Revision: 2410
Example:
Debug: 812 68734 gdb_server.c:823 gdb_connection_closed(): GDB Close, Target:
sam3.cpu, state: halted, gdb_actual_connections=0
==
Author: duane
Date: 2009-06-28 05:09:15 +0200 (Sun, 28 Jun
Replace common function call with simple refactorization.
For example:
OLD:
LOG_DEBUG("target->state: %s",
Jim_Nvp_value2name_simple(nvp_target_state, target->state)->name);
NEW:
LOG_DEBUG("target->state: %s", target_state_name(target));
-Duane.
SVN Details
===
Auth
On Sun, 2009-06-28 at 01:23 +, Martin Panter wrote:
> On 27/06/2009, Freddie Chopin wrote:
> > 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c
> > 2. enable dynamic loading of libusb0.dll in ft2232.c
>
> So why loading libusb rather than libftdi? Is it because libftdi is
> on
On 27/06/2009, Freddie Chopin wrote:
> 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c
> 2. enable dynamic loading of libusb0.dll in ft2232.c
So why loading libusb rather than libftdi? Is it because libftdi is
only built (or linked to) as a static library on Windows but still
nee
On Sat, 2009-06-27 at 20:50 +0200, Freddie Chopin wrote:
> Second version of previous patch improved with suggestions from Ronald.
>
> Pls try (; Works for me <:
This patch now looks 1000 times better with the changes from Ronald.
Thanks to both of you for producing and refining it.
My only rema
On Saturday 27 June 2009, Duane Ellis wrote:
> Today - the C code *controls* and *drives* the reset sequence.
>
> I'm suggesting we turn that inside out - and make the TCL code - drive
> the reset sequence - via commands above.
That's a good direction, I think. Details TBD, but
certainly gettin
>> This avoids switching
>> programming paradigm from procedural to
>> event based, i.e. we could add events until
>> the cows go home and still miss that crucial
>> event for the next target.
>>
>
> I'd call the current reset "events" procedural
> hooks, myself. Heck, they don't even accep
Second version of previous patch improved with suggestions from Ronald.
Pls try (; Works for me <:
4\/3!!
Index: ft2232.c
===
--- ft2232.c(revision 2405)
+++ ft2232.c(working copy)
@@ -63,6 +63,51 @@
#include
#endif
+/*
> > Does it seem to you like the reset process is flexible
> > enough yet?
>
> The idea is that those targets where the tcl reset
> proc doesn't cut it would implement their own
> tcl reset proc from scratch.
That seems undesirable when some key improvements can
be more generically available.
Li
I take that back, what you propose is possible and works - I've done
that wrong a while ago. I'll create a new version of patch soon.
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listi
But you don't have to repace FT_Write_ptr with FT_Write, just keep it
like that and do this:
#define FT_Write (*FT_Write_ptr)
but depending on how smart the preprocessor is, it might still complain
about it, so likely it won't help.
Thanks for trying, it's not that big of deal and actually I
Ronald Vanschoren pisze:
> Did you actually try it? There is no redefinition normally (depends on
> how the .h file of ftd2xx is made) and I think I used this approach
> before (although slightly different). Guess it's a 2 minute check for
> you (just one function will do), so if you don't mind
1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a
different place then all the others? Isn't it cleaner to keep all the
initializations together?
As a trV embedded engineer I've saved some memory [; Keeping all
together would be clearer, but I decided to min
Ronald Vanschoren pisze:
> I don't have any experience in OpenOCD development
Just like me [;
> 1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a
> different place then all the others? Isn't it cleaner to keep all the
> initializations together?
As a trV embedded engineer I've sa
>> I still am stuck and no breaky points !
Really? I'm confused. I'm seeing other problems - that are some what
related - but I'm not sure (see earlier email subject: Clearing all
breakpoints & watch points)
I see you only setting one breakpoint. I see the breakpoint working.
If I look at t
duane> Slowly target resources are consumed/leaked - specifically hardware
duane> compare registers.
duane> Suggestions?
BTW - this can also be caused by GDB croaking.. while leaving the target
running.
Examples - SVN 2408 - adds some useful debug information to help see
this problem
The g
Freddie,
Thanks for this patch, I like the idea :-)
I don't have any experience in OpenOCD development but I did have a
look at the patch and have two questions/remarks:
1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a
different place then all the others? Isn't it cleaner to k
>> Freddie Chopin wrote:
FYI - I already had stuff in the works for this... -Duane.
> 1. replace alloca with malloc - that's Øyvind's patch, but I've fixed
> r vs. retval and I've removed one useless part.
Alternate method committed:
New Revision: 2407
> 2. add Newlib's strtok_r to r
The cortexM3 - and perhaps other targets - have a problem.
When GDB exits/disconnects/reconnects - these two functions get called:
/* we must remove all breakpoints registered to the target as a previous
* GDB session could leave dangling breakpoints if e.g. communication
* timed ou
This patch enables dynamic loading of ftd2xx.dll in ft2232.c on Win32
platform.
It's made to work only on Win32 and for ftd2xx.dll in ft2232.c - it
doesn't affect linux, libftdi or any other modules that could use that.
That's the first from a series that I am planing (win32 only):
1. (this
Hello List,
I want to test the performance like Dominic had done before:
https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html
But here I use r2348 with libftdi and ftd2xx.
dump_image without the fast memory access was working,
but if I enable the fast memory access (arm7_
Dominic a écrit :
> > load_image /home/vmaster/test.img 0x2000 bin
> 1048576 byte written at address 0x2000
> downloaded 1048576 byte in 4.363197s (204.322 KB/s)
>
>
>
That was the problem I had, I will give another try. With results like
this I would say that I have no more objection.
Fla
On Thu, Jun 25, 2009 at 8:55 PM, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 17:34, Zach Welch wrote:
>> On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote:
>>>
>>> The libusb improvements certainly sound interesting, however no one
>>> has stepped forward to implement them or to pay someone
On Sat, Jun 27, 2009 at 7:38 PM, Dominic wrote:
> These tests show libftdi ahead of ftd2xx or only very slightly behind. This
> is by no means a complete performance evaluation and the devil might be in
> the details, but I think it shows that these days libftdi is on par with
> ftd2xx, at least o
On Saturday 27 June 2009 11:30:07 David Brownell wrote:
> > Pavel's explanation matches with what I remember about this issue. I'm
> > preparing a test setup to verify the numbers just now.
>
> ISTR Nicolas Pitre reported almost-the-same-speed too.
>
> At least, on Linux. I believe MS-Windows does
Second attempt:
1. replace alloca with malloc - that's Øyvind's patch, but I've fixed r
vs. retval and I've removed one useless part.
2. add Newlib's strtok_r to replacements so that membuf.c could be build
on Windows
4\/3!!
Index: src/helper/membuf.c
===
On Saturday 27 June 2009, Freddie Chopin wrote:
> How about here:
>
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html
That's Windows though -- different question.
> Libraries achieve same speed when uploading to RAM, but it seems that
> ROM speeds are different...
Dominic pisze:
> On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote:
> > David Brownell pisze:
> > >> There may be people who run Linux and Mac OS X and want
> > >> to use the FTDI D2XX library due to the perceived performance
> > >> reasons.
> > >
> > > Which, by latest reports, are at b
On Saturday 27 June 2009 10:10:16 Freddie Chopin wrote:
> David Brownell pisze:
> > For the record, why don't we label r2403 as "RC1"?
>
> Maybe because that fails to build of Windows without two patches I
> submitted 2 days ago, that weren't accepted yet?
Øyvind replied to your posting with a pat
On Saturday 27 June 2009, Dominic wrote:
> On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote:
> > David Brownell pisze:
> > >> There may be people who run Linux and Mac OS X and want
> > >> to use the FTDI D2XX library due to the perceived performance
> > >> reasons.
> > >
> > > Which, by late
On Saturday 27 June 2009, Freddie Chopin wrote:
> David Brownell pisze:
> > For the record, why don't we label r2403 as "RC1"?
>
> Maybe because that fails to build of Windows without two patches I
> submitted 2 days ago, that weren't accepted yet?
Exactly the kind of information we need!
The st
On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote:
> David Brownell pisze:
> >> There may be people who run Linux and Mac OS X and want
> >> to use the FTDI D2XX library due to the perceived performance
> >> reasons.
> >
> > Which, by latest reports, are at best marginal.
>
> Where are those r
David Brownell pisze:
> For the record, why don't we label r2403 as "RC1"?
Maybe because that fails to build of Windows without two patches I
submitted 2 days ago, that weren't accepted yet?
4\/3!!
___
Openocd-development mailing list
Openocd-developme
On Thursday 25 June 2009, Zach Welch wrote:
> Hi all,
>
> Here is my summary of what I think needs to be done to prepare for a
> "source-only" 0.2.0 release, which will help promote OpenOCD and maybe
> attract new developers that can help fix the binary distribution issue.
>
> ...
>
> So again, w
I know this wasn't addressed to me, but the advice I gave (about binary
Linux Kernel Modules) was cross-checked with the legal department of
that company, the legal department of the client AND with FSF, so don't
think you alone are right because you hired a lawyer.
Any lawyer will say "stay aw
35 matches
Mail list logo
