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 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 L
On Friday 26 June 2009, Michel Catudal wrote:
> > Correct me if I'm wrong here: currently, the *ENTIRE* reason
> > to care about the D2XX library is to get simpler Windows support.
>
> Windows is not the only platform so you can't just rip that stuff off
Why not? It's the only platform OpenOCD
On Sat, Jun 27, 2009 at 11:24 AM, David Brownell wrote:
> On Friday 26 June 2009, Xiaofan Chen wrote:
>> On the other hand, it may be easier to create a WinUSB backend for
>> OpenOCD which covers the needs for OpenOCD (or libftdi) and
>> OpenOCD (or libftdi) only. You may not need to be a Windows d
David Brownell a écrit :
> On Friday 26 June 2009, Xiaofan Chen wrote:
>
>> On the other hand, it may be easier to create a WinUSB backend for
>> OpenOCD which covers the needs for OpenOCD (or libftdi) and
>> OpenOCD (or libftdi) only. You may not need to be a Windows driver
>> developer to do t
On Friday 26 June 2009, Xiaofan Chen wrote:
> On the other hand, it may be easier to create a WinUSB backend for
> OpenOCD which covers the needs for OpenOCD (or libftdi) and
> OpenOCD (or libftdi) only. You may not need to be a Windows driver
> developer to do this.
Correct me if I'm wrong here:
On Friday 26 June 2009, Duane Ellis wrote:
> I believe the "WinUSB" solution is a solution, that for some reason
> keeps being left off your list.
>
> http://msdn.microsoft.com/en-us/library/aa476426.aspx
Technically, I'm beginning to think that's correct. Just
write directly to WinUSB instead
On Sat, Jun 27, 2009 at 6:14 AM, Zach Welch wrote:
> On Fri, 2009-06-26 at 11:15 -0400, Duane Ellis wrote:
>> Zach Welch wrote:
>> > Only libusb+libftdi serves our long-term interests.
>> >
>> Wrong.
>>
>> "libusb" is a *blocking* issue that we cannot control, fix, nor
>> whatever. LIBUSB is not su
Add various commands that had not previously been documented, which
were found courtesy of "grep -r register_command":
- exit
- lpc2000 part_id
- str7x disable_jtag
- test_image
- trace history
- trace point
- version
- virt2phys
- most of the optional ioutil commands
The largest changes
2009/6/27 Michel Catudal :
> I don't think that they want us to move to vista 64 bit as most of the
> drivers for our hardware would not work but there is a point
> where we may be forced to move to vista or windows 7 and
> isn't windows 7 only 64 bits.
No. Windows 7 has 32bit version as well.
ht
Continued call for help !
It still seems that these are hard to read on the posting, I will just
inline them here
1)
Eagle100_jtag_tiny-setup.cfg===
# From Source file: "olimex-jtag-tiny-a.cfg"
# REFERENCE: http://www.olimex.com
Xiaofan Chen a écrit :
> 2009/6/27 Michel Catudal :
>
>> Out of curiosity, do you mean to say that the driver will not load at
>> all if not signed under vista 64 and Win 7?
>> This would be a serious reason for me not to let IS change my system
>> from XP.
>>
>> I have several very expensive pi
Looks like my .cfg files were in a 7zip format I will send them individually
so they are more
visible to more people
In some cases I did not use UploadPgmAtZero.cfg when I used (gdb) load
instead...
Sincerley,
Joe
On Fri, Jun 26, 2009 at 6:39 PM, Joseph Kuss wrote:
> Gmail sent without my pro
Now I have completely taken Eclipse out of the picture, and am just using
openOCD and GDB 6.8.
I still am stuck and no breaky points !
I am following a template that was provided, this was helpfull but is not my
solution it seems.
//
Joe,
Try adding
2009/6/27 Michel Catudal :
> Out of curiosity, do you mean to say that the driver will not load at
> all if not signed under vista 64 and Win 7?
> This would be a serious reason for me not to let IS change my system
> from XP.
>
> I have several very expensive pieces of software at work that are no
Dominic a écrit :
> o the WinUSB backend brings a WHQL signed driver, which is good,
> because it
> runs on all windows versions that required signed drivers (Vista 64-bit,
> Windows 7)
>
>
Out of curiosity, do you mean to say that the driver will not load at
all if not signed under vista 64 and
On Fri, 2009-06-26 at 17:04 -0700, David Brownell wrote:
> On Friday 26 June 2009, Zach Welch wrote:
> > Any tips for handling N RTCK signals, other
> > than my brute force "use part(s) of a 7400 series IC" or plain "simply
> > don't" approaches?
>
> I found some info in a TI presentation when I
On Friday 26 June 2009, Zach Welch wrote:
> Any tips for handling N RTCK signals, other
> than my brute force "use part(s) of a 7400 series IC" or plain "simply
> don't" approaches?
I found some info in a TI presentation when I was
searching for 1149.7 or maybe ICEpick information ...
ICEPick ha
Hi all,
While reviewing some of the recent documentation improvements, I started
thinking about daisy chaining two (or more) of my targets together into
a single scan chain, allowing me to write a script that flashes each
unit in turn.
In theory, I think this could "just work" today, assuming tha
On Fri, 2009-06-26 at 16:32 +0200, Pavel Chromy wrote:
[snip]
> No offense but isn't this sort of GPL madness?
Yes. This is completely insane: that you would continue to ask me for
advice that should be best answered by legal counsel. I am not a lawyer
and cannot give you the advice that you nee
On Fri, 2009-06-26 at 11:15 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > Only libusb+libftdi serves our long-term interests.
> >
> Wrong.
>
> "libusb" is a *blocking* issue that we cannot control, fix, nor
> whatever. LIBUSB is not supported by *newer* windows platforms. Unless
> and unt
Pavel Chromy escreveu:
> David Brownell napsal(a):
>> And that's why GPL restricts distribution of GPL
>> software with non-Free libraries. If it didn't,
>> then the users relying on the non-Free code would
>> not have the full set of Freedoms intended by GPL.
>
> however, here we speak about d
> Just one more clarification. libusb-win32 can be made to support Vista
> 64bit and Windows 7 as well with a digital signature. It already works
> under XP 64bit.
>
> Vendors can also use libusb-win32 as their default device and get
> it WHQLed with their particular VID/PID if they want to do t
For Vista / Win7 64bit editions, driver files (.sys) must be signed to even
load.
Signing the .inf tells the user that the driver has gone thru some testing to
insure some quality.
For WinUSB, Microsoft already signed the .sys portion for us. You only have to
customize the .inf.
If you do not
On Friday 26 June 2009 19:26:38 Xiaofan Chen wrote:
> Hope this helps.
It does. Thanks a lot for your patience and your valuable information.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/list
David Brownell wrote:
> On Friday 26 June 2009, Harald Kipp wrote:
>> The intention of GPL is to explicitly give users the
>> freedom to use GPL software in any way they see fit.
>
> Assuming "use" doesn't include depriving others of such
> freedoms ... that's just *ONE* of its intentions
>
> Ano
On Sat, Jun 27, 2009 at 12:35 AM, Dominic wrote:
Firstly I am not a Windows driver expert and I do not and can not
code for live. But I know quite a bit of USB under Linux/Windows,
especially libusb and libusb-win32.
> Is the libusb-win32 1.0 branch compatible with libftdi (i.e. is it
> compatibl
Hello David,
David Brownell napsal(a):
> And that's why GPL restricts distribution of GPL
> software with non-Free libraries. If it didn't,
> then the users relying on the non-Free code would
> not have the full set of Freedoms intended by GPL.
however, here we speak about distributing binary W
Freddie Chopin wrote:
> About posts by Herald and Pavel - I personally agree totally with you,
> but - as you've already noticed - some maintainers just don't share our
> point of view, and I think there is no way of convincing them - they
> just don't want to be convinced.
Freddie, first of a
On Friday 26 June 2009, Harald Kipp wrote:
> The intention of GPL is to explicitly give users the
> freedom to use GPL software in any way they see fit.
Assuming "use" doesn't include depriving others of such
freedoms ... that's just *ONE* of its intentions
Another is to be able to *keep doing* t
Original Message
Subject: [Openocd-development] ftd2xx -> libftdi
From: Xiaofan Chen
To: Ronald Vanschoren
Cc: openocd-development
Date: Fri Jun 26 2009 18:30:22 GMT+0200 (Romance Standard Time)
On Sat, Jun 27, 2009 at 12:19 AM, Ronald
Vanschoren wrote:
IMHO,
On Friday 26 June 2009 18:10:56 Xiaofan Chen wrote:
> > o libftdi apparently works with libusb-win32's API (see for example
> > Freddie's post)
>
> Yes.
>
> > o libusb-win32 comes with 3 (maybe 4) backends
> > - a libusb driver and a libusb filter driver (not sure if this
> > differenciation is sti
On Sat, Jun 27, 2009 at 12:10 AM, Xiaofan Chen wrote:
> On Fri, Jun 26, 2009 at 11:56 PM, Dominic wrote:
>
>> I've been investigating the Windows USB mess a little yesterday. Maybe
>> someone can help fill in the uncertainties, here's what I have collected so
>> far.
>>
>> o libusb-win32 is API com
On Sat, Jun 27, 2009 at 12:19 AM, Ronald
Vanschoren wrote:
> IMHO, this makes any solution NOT based on FTD2xx unacceptable. People
> will not be willing to give up all their other tooling to run OpenOCD,
> instead they might find other solutions and stop using OpenOCD. I
> haven't read all the ma
Original Message
Subject: [Openocd-development] ftd2xx -> libftdi
From: Xiaofan Chen
To: Freddie Chopin
Cc: openocd-development
Date: Fri Jun 26 2009 17:54:25 GMT+0200 (Romance Standard Time)
> On Fri, Jun 26, 2009 at 11:49 PM, Freddie Chopin wrote:
>
>> Ronald Vanschoren p
On Fri, Jun 26, 2009 at 11:56 PM, Dominic wrote:
> I've been investigating the Windows USB mess a little yesterday. Maybe
> someone can help fill in the uncertainties, here's what I have collected so
> far.
>
> o libusb-win32 is API compatible with libusb 0.1, but is capable of
> somethings that l
On Friday 26 June 2009 17:15:12 Duane Ellis wrote:
> Zach Welch wrote:
> > Only libusb+libftdi serves our long-term interests.
>
> Wrong.
>
> "libusb" is a *blocking* issue that we cannot control, fix, nor
> whatever. LIBUSB is not supported by *newer* windows platforms. Unless
> and until it is su
On Fri, Jun 26, 2009 at 11:49 PM, Freddie Chopin wrote:
> Ronald Vanschoren pisze:
>> I have only taken a quick look at WinUSB, but if I understand the
>> concept correctly there might be an issue. I'm not sure of what I'm
>> saying here so shout if it's complete nonsense. To work with WinUSB,
>> y
Pavel Chromy pisze:
> Harald Kipp napsal(a):
AFAIK, adding support for a non-compliant DLL in GPL code is not
circumventing any GPL clause that I know of, neither directly not
indirectly.
>>> so is your belief that it is GPL compliant to also distribute
>>> GPLed binary that includes
Ronald Vanschoren pisze:
> I have only taken a quick look at WinUSB, but if I understand the
> concept correctly there might be an issue. I'm not sure of what I'm
> saying here so shout if it's complete nonsense. To work with WinUSB,
> your USB device has to indicate that WinUsb.sys is its drive
Original Message
Subject: [Openocd-development] ftd2xx -> libftdi
From: Xiaofan Chen
To: open...@duaneellis.com
Cc: openocd-development
Date: Fri Jun 26 2009 17:27:36 GMT+0200 (Romance Standard Time)
On Fri, Jun 26, 2009 at 11:15 PM, Duane Ellis wrote:
Zach Wel
On Fri, Jun 26, 2009 at 11:15 PM, Duane Ellis wrote:
> Zach Welch wrote:
>> Only libusb+libftdi serves our long-term interests.
>>
> Wrong.
>
> "libusb" is a *blocking* issue that we cannot control, fix, nor
> whatever. LIBUSB is not supported by *newer* windows platforms. Unless
> and until it is
Maciej Grela pisze:
> You've said, that libd2xx performs better than libftdi
> but is this only under windows ? What is the speed difference between
> libftdi + libusb under linux, libftdi + libusb under windows and
> libd2xx + native windows driver ?
I don't use linux, so I've just tested ftd2xx.
Zach Welch wrote:
> Only libusb+libftdi serves our long-term interests.
>
Wrong.
"libusb" is a *blocking* issue that we cannot control, fix, nor
whatever. LIBUSB is not supported by *newer* windows platforms. Unless
and until it is supported it becomes a dead end solution, period, end of
sto
Harald Kipp napsal(a):
>>> AFAIK, adding support for a non-compliant DLL in GPL code is not
>>> circumventing any GPL clause that I know of, neither directly not
>>> indirectly.
>> so is your belief that it is GPL compliant to also distribute
>> GPLed binary that includes support for a closed DLL w
Hello Zach,
Zach Welch napsal(a):
> On Fri, 2009-06-26 at 00:21 +0159, Maciej Grela wrote:
>> A friend of mine pointed me to the threads concerning
>> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an
>> idea came to my head - what if we implement our own GPL/LGPL version
>>
Hi Pavel,
Pavel Chromy wrote:
>> AFAIK, adding support for a non-compliant DLL in GPL code is not
>> circumventing any GPL clause that I know of, neither directly not
>> indirectly.
>
> so is your belief that it is GPL compliant to also distribute
> GPLed binary that includes support for a close
Hello Zach and the list,
Zach Welch napsal(a):
> If we are pursuing all of these at one time, our collective resources
> are not being used efficiently. It's nice to see all the activity, but
> I think we could make more productive use of our collective time. Now,
> I am *not* asking anyone to c
Hi all,
Having had time to reflect quietly about the FTD2XX situation, I have
started to grow concerned about the numerous options that have been
proposed to address the FTD2XX distribution issue.
All these efforts -- in N directions at once -- most trying to solve one
single problem, and this is
2009/6/26 Pavel Chromy :
> Hello Maciej,
>
> Maciej Grela napsal(a):
>>
>> A friend of mine pointed me to the threads concerning
>> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an
>> idea came to my head - what if we implement our own GPL/LGPL version
>> of libd2xx.dll ?
>
>
Hello Harald and the list,
Harald Kipp napsal(a):
> It's perfectly legitimate to _distribute_ a *GPL compliant* DLL with
> GPL'ed executables.
>
> It's perfectly legitimate to _run_ a *non GPL compliant* DLL with GPL'ed
> executables. The intention of GPL is to explicitly give users the
> freedom
Hi Øyvind,
Originally I intended to let the discussion settle and see how things
develop. Looks like there are still misunderstandings and I can't resist...
Øyvind Harboe wrote:
> Under Windows an executable will fail to load if it links
> implicitly to a dll even if that dll is not used.
When
> But we shall not become GPL slaves, solving how to pass literal
> interpretation of the license instead of pushing OpenOCD further.
GPL is our most vital line of defense against closed source
target/interface support in OpenOCD.
If the maintainers and contributors do not respect and follow
the
Hello Maciej,
Maciej Grela napsal(a):
> A friend of mine pointed me to the threads concerning
> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an
> idea came to my head - what if we implement our own GPL/LGPL version
> of libd2xx.dll ?
This is also an option, but there are pr
Hello Øyvind and the list,
Øyvind Harboe napsal(a):
> welcome back it's been a while! I hope that you'll stick around
> to submit some more good patches. You've contributed lots of nice
> stuff in the past!
I am still here, monitoring the forum and I surely also do have future
plans to contribute
On Thu, Jun 25, 2009 at 10:54 AM, Zach Welch wrote:
> Hi all,
>
> Michael Fischer posted the following survey on the SparkFun forum:
>
> http://forum.sparkfun.com/viewtopic.php?t=16044
I use linux and might want to use openocd on some embedded
target(ramdon arm board).
Greetings
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
I *HIGHLY* recommend the following approach:
- generate a .txt file
- have users email that .txt file as an attachment to an email
address using an email program of their choice
I believe adding code in OpenOCD to talk directly to the internet
would be a Bad Idea because firewalls will stop a hu
Hi all,
The following approach builds on the idea of providing OS version from
information inside of OpenOCD, which resulted from the platform survey
thread. That idea should be more meaningful, when you reconsider the
ideas for automated testing report generation:
openocd -f bug_report.cfg \
59 matches
Mail list logo
