For libftd2xx1.0.4, which uses a different directory structure
than libftd2xx0.4.16
Note that this does not fix --with-ftd2xx-lib=shared
Also it assumes i386, not x86_64.
Signed-off-by: Steve Bennett ste...@workware.net.au
---
configure.in | 17 +
1 files changed, 9
Instead, just produce a warning
Signed-off-by: Steve Bennett ste...@workware.net.au
---
src/jtag/drivers/ft2232.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 38ead56..2e0495d 100644
---
The default is -Werror, so warnings become errors
and stop the build.
Might be better to simply #define FT_STATUS instead.
Signed-off-by: Steve Bennett ste...@workware.net.au
---
src/jtag/drivers/ft2232.c | 88 ++--
1 files changed, 44 insertions(+), 44
On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett ste...@workware.net.au wrote:
Instead, just produce a warning
Why?
It merits a comment at least?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett ste...@workware.net.au wrote:
On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote:
On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett ste...@workware.net.au
wrote:
Instead, just produce a warning
Why?
It merits a comment at least?
Seems
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
--
interface_signal add led 8000
interface_signal add led 8000
There are no signals
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name | Mask | Value
--
Sergey Lapin wrote:
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote:
//
// On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au
Please refrain from shouting(using uppercase). It's more likely
that people will ignore your email than read it.
As a maintainer, I'm not terribly excited about bitbanging and other
non-CPU related protocols. Projects like UrJTAG pursue
this sort of avenue. I'd like to see OpenOCD focusing on
Attached is an updated remote_bitbang patch with the additional error
propagation.
The remote_bitbang driver can be enabled and disabled by configure script
(unless I'm missing something).
If I get permission I'll answer the other questions that have been asked
regarding the remote bitbang
Hi Øyvind Harboe,
Please refrain from shouting(using uppercase). It's more likely
that people will ignore your email than read it.
Thank you for the advice.
As a maintainer, I'm not terribly excited about bitbanging and other
non-CPU related protocols. Projects like UrJTAG pursue
this
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
2. If you need to program I2C, SPI, or other kind of memory, you
simply write simple TCL script to do so, no need to rewrite
Am 06/20/2011 02:44 PM, schrieb Laurent Gauch:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
--
interface_signal add led 8000
Please explain the dangers.
If a driver can't implement a sane feature safely, then the driver shouldn't
implement that feature
One of the reasons I'm not excited about adding the IO features to OpenOCD
is that we have barely enough maintainer resources as is. If a maintainer
came out of
(Resending since I forgot to cc the list)
There is at least one useful end-user use case for bitbanging. There
are many IO lines unused on the FTDI port that can be used for GPIO.
Some dongles expose these and of course a custom FTDI interface that you
integrate with your prototype can
Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe:
Please explain the dangers.
If a driver can't implement a sane feature safely, then the driver shouldn't
implement that feature
Fine.
I *do* think hardware should be designed in a way that it can not be
damaged by software, but if existing
On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
(..) I would dearly like to see SWD done before
opening the floodgates to GPIO and other serial protocols.
SWD is packed-based half-duplex bus that defines TRN operation for bus
direction change and buffers
On Mon, Jun 20, 2011 at 7:46 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote:
i'm trying to apply these patches on the current head, and i get:
bitbang.c: In function ‘handle_bitbang_command’:
bitbang.c:90: error: implicit declaration of function ‘strnstr’
bitbang.c:90: error: assignment
Btw. is there any way in git to edit a commit? :-)
Yes:
git rebase -i origin/master
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and
On Mon, Jun 20, 2011 at 8:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Btw. is there any way in git to edit a commit? :-)
Yes:
git rebase -i origin/master
Aaaarg, could have figured that myself ;-P Tanks! :-)
I think I have found my problem - the bitbang can be used only after
cable is
I have found the issue - command init is mandatory for bitbang to
work as it initialize the interface (pretty obvious). On another place
I was using some configuration file that had this init inside and this
is why it worked there, I mislooked that :-(
So generally speaking the patches are
On 21/06/2011, at 1:07 AM, Laurent Gauch wrote:
/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote:
// // On Mon, Jun 20, 2011 at 12:50 PM, Steve
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use of the TCL procedure,
Here goes another patch to be applied on top of previous patches:
-it fixes strnstr() problem - sorry for that, man says clearly it is
FreeBSD specific!
-it changes command mode to COMMAND_EXEC so 'bitbang' is only
available after 'init'
-some minor string and constants fixes
Waiting for feedback
i found a bug in interface_signal del, the name of the signal was
not passed down to the functions thats look for it, so it didn't work.
attached a patch :)
since this stuff is not yet in the master branch (right?), i based
this patch on openocd-ifsigbitbang@git://repo.or.cz/openocd/libswd.git
i
On Mon, Jun 20, 2011 at 11:33 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote:
i found a bug in interface_signal del, the name of the signal was
not passed down to the functions thats look for it, so it didn't work.
attached a patch :)
Tanks, I will take a look, but signal deletion worked for
Øyvind Harboe wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a
release branch there.
You pick whatever you want from the master branch or whatever patches
2011/6/21 Jon Povey jon.po...@racelogic.co.uk:
Øyvind Harboe wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a
release branch there.
You pick whatever you
On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote:
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it
is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
Yes, easy but dangerous, because you are layout specific !!!
Tomek CEDRO wrote:
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use
31 matches
Mail list logo
