On Friday 26 June 2009, Xiaofan Chen wrote:
Correct me if I'm wrong here: currently, the *ENTIRE* reason
to care about the D2XX library is to get simpler Windows support.
Not so sure about the word ENTIRE. I think it certainly is the
main reason.
There may be people who run Linux and
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 reports? It seems that I have missed another thing here...
4\/3!!
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, we need to
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
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 reports? It
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 strtok
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 latest reports, are at
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 patch that
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 best marginal.
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...
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 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 have a
On Sat, Jun 27, 2009 at 7:38 PM, Dominicdominic.r...@gmx.de 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
On Thu, Jun 25, 2009 at 8:55 PM, Michael Bruckmbr...@digenius.de wrote:
On Wed, Jun 24, 2009 at 17:34, Zach Welchz...@superlucidity.net 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
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.
Flashing
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
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
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
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
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
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 the
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 saved
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
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 :-)
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 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
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.
Like for
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 accept
any
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 getting
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
On 27/06/2009, Freddie Chopin freddie_cho...@op.pl 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
On Sun, 2009-06-28 at 01:23 +, Martin Panter wrote:
On 27/06/2009, Freddie Chopin freddie_cho...@op.pl 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
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
===
Author:
==
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
34 matches
Mail list logo
