Steve,
On Saturday, 14. February 2009 19:07:51 Steve DeLaney wrote:
> Thanks to help on this forum I was able to resolve this issue and get FTDI
> up and running. starting from examples/bitbang.c, I made a simple bulk
> transfer
> throughput test to measure the effect of baudrate and block size
>
On Tuesday, 17. February 2009 10:43:04 Thomas Jarosch wrote:
> So, which FTDI chip are you using?
Ah, I just noticed the chip type is in the subject :-)
I don't think the configured baudrate is matching the
familiar ones from RS232 times. Guess it's best if you
check the datas
On Sunday, 22. February 2009 19:47:19 frrrt_ wrote:
> The Fixed Serial Number of a device can be found by running MPROG
> utility on Windows.
You could also use "lsusb" to get the serial number.
> Can somebody explain what's the point of having a function called
> ftdi_read_chipid?
> From my und
Marius,
Am Friday, 27. February 2009 14:10:26 schrieb Marius Kintel:
> Any ideas how or if it's possible to recover from this?
> When I start frying hardware I better slow down a bit before playing
> further..
Does the kernel still detect the device when you plug it in?
Try to erase the eeprom,
Hi Marius,
Am Friday, 27. February 2009 18:13:14 schrieb Marius Kintel:
> Using a patched libftdi, I can now also write correctly to the EEPROM.
Nice one!
> I'll test and clean up my libftdi patches and submit them here. It
> would be cool if someone has got the time to take a look, verify and
>
Hello Marius,
Am Saturday, 7. March 2009 03:54:28 schrieb Marius Kintel:
> I'm attaching patches solving some issues:
> o CMake build system improved for libftdi and implemented for
> ftdi_eeprom
> o Corrected writing to EEPROM (only tested on FT232R)
> o Added ftdi_eeprom_decode() (the inverse of
Am Monday, 9. March 2009 15:21:06 schrieb Marius Kintel:
> On Mar 9, 2009, at 15:17 PM, Thomas Jarosch wrote:
> > One little thing caught my eye: The FindUSB macro is under
> > the BSD license while libftdi is licensed as LGPL
> > and ftdi_eeprom as GPL. Do you think it wou
Hello Marius,
Marius Kintel wrote:
The COPYING-CMAKE-SCRIPTS attached (yes, it's from the KDE project).
It's true that this file has an advertisement clause.
However, we're not redistributing the macro in binary form. We're only
using it to generate makefiles. We're thus not bound by any other
Marius Kintel wrote:
you return values but the function is void
True. It should be declared to return an int.
Thomas: Could fix this when and if you merge this function into libftdi?
Patches are all applied now, thanks.
Cheers,
Thomas (who is luckily almost back to normal)
--
libftdi - see
Hello Matthias,
Matthias Richter wrote:
The ftdi_read_chipid() function results sometimes in a different value
compared to the FTID_GetDeviceChipID() from the FTDI drivers (Linux or
Windows). The problem is in the two lines
b = b << 8 | b >> 8;
a = (a << 16) | b;
becaus
Hi Matthias,
Am Sunday, 15. March 2009 22:12:22 schrieb Matthias Richter:
> > I'll also ask Peter Holik about it as he contributed
> > the ftdi_read_chipid() code.
> >
> > Care to send a patch, preferably in "git format-patch" style?
>
> Sorry, I'm not very familar with git. Perhaps the following
Hi Marius,
Marius Kintel wrote:
+/* These commands were traced while running MProg */
+ftdi_usb_reset(ftdi);
+ftdi_poll_modem_status(ftdi, &status);
+ftdi_set_latency_timer(ftdi, 0x77);
ftdi_usb_reset and ftdi_poll_modem_status are unnecessary here
I suspected that, but MProg
Hello Pierre,
Pierre Bouffard wrote:
After a hardware reset of the FT232BL, I poll the modem status and I get
this value 0x7001 (unsigned short). The file ftdi.c says that the first
four bits of the first byte must be 0.
" Layout of the first byte:
- B0..B3 - must be 0"
What does this m
Hi Dave,
On Friday, 20. March 2009 07:45:27 David Challis wrote:
> We use the FT2232H to transfer large amounts of data (megabytes) between a
> camera and a Linux host (Fedora 10). We've used release libftdi 0.12 with
> the ft245BL without problems. We recently upgraded tolibftdi 0.15 and
> sta
On Monday, 23. March 2009 00:07:35 David Challis wrote:
> Here is my final answer:
>
> The ft2232H spaces the modem status bytes every 512 bytes rather that the
> expected 64 byte interval of prior chips like the ft245. Libftdi will have
> to be changed to detect the type of chip connected and ada
On Monday, 23. March 2009 16:55:47 David Challis wrote:
> The line in the patch:
>
> else if (dev->descriptor.bcdDevice == 0x800)
> ftdi->type = TYPE_2232H;
>
> for the FT2232H should be:
>
> else if (dev->descriptor.bcdDevice == 0x700)
> ftdi->type = TYPE_22
Hello Uwe,
Uwe Bonnes wrote:
cd libftdi
cmake .
...
-- Build files have been written to: /spare/bon/ftdi/libftdi
make
I never tried an in-tree build of libftdi, out-of-tree builds
are much better as they don't pollute the source tree.
Try something like this:
mkdir build
cd build
cmake ../
Hello Florian,
Florian Beier wrote:
Hi again,
I managed to use the libftdi without the D2xx commands to communicate
with my sensor.
I have on issue, I do not understand.
I am checking the buffer of my FT2232 chip. If it is empty, the
usb_bulk_read in the ftdi_read_data function takes almost 12 m
Hello Uwe,
Uwe Bonnes wrote:
Or otherwise, has anybody used libftdi with libusb-win32 with mingw as a
cross compiler?
I guess Marek Vavruša did this once when he contributed the cmake support
as it contains specific switches for Windows. He's not on the list (yet),
so you could try to contact
Hello Nicolas,
Nicolas wrote:
As I continued to search for an answer I finally managed to use this
CBUS thing using libftdi.
Great :-)
The fact is that's not simple for someone who never heard about serial
our USB developpement. So here is what I learned, in case of someone as
newbie as me
Hi Uwe,
On Monday, 6. April 2009 13:59:35 Uwe Bonnes wrote:
> sleep() and usleep(0 are not available on Win32. Provide workarounds and
> add some documentation for crosscompiling. It seems, I didn't send on the
> first attempt. This is my first patch with git, so if things need another
> form, ple
On Monday, 23. March 2009 18:10:41 David Challis wrote:
> Patch file attached for ftdi.c
Patch is applied (with minor tweaking):
http://developer.intra2net.com/git/?p=libftdi;a=commit;h=f2f00cb562550c876da2119edeb1dd228aa2abfa
Now we support FT2232H and FT4232H :-)
Thanks,
Thomas
--
libftdi -
Hi Florian,
On Monday, 6. April 2009 17:33:32 Florian Beier wrote:
> Actually I do not understand, what the set_latency_timer does. I
> thougth the ftdi_read_data would "wait" the given latency time, till
> something is in the buffer. But even if I do set the latency to 255,
> and nothing is in t
Hello Chris,
On Friday, 3. April 2009 18:48:47 Leahy, Chris M. (Xetron) wrote:
> I've been working on a project that uses libftdi. Recently I decided to
> try the ftdipp bindings and I had a few questions about them.
>
> In Context::open(int vendor, ...) ftdi_usb_open or ftdi_usb_open_desc is
> ca
Hello,
I've cooked up a release candidate for libftdi 0.16. Get it from here:
http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.16rc1.tar.gz
GPG signature:
http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.16rc1.tar.gz.sig
Changes since the last release:
* Relicense
Hello Dave,
On Tuesday, 28. April 2009 18:47:06 David Challis wrote:
> I've just completed testing 0.16rc1 with the FT245BM and the FT2232H in our
> cameras. No problems to report.
Thanks for testing! I'm waiting for one more patch
for the C++ wrapper, should be in on Tuesday/Wednesday.
Cheers,
> On Tuesday, 28. April 2009 18:47:06 David Challis wrote:
>> I've just completed testing 0.16rc1 with the FT245BM and the FT2232H in our
>> cameras. No problems to report.
>
> Thanks for testing! I'm waiting for one more patch
> for the C++ wrapper, should be in on Tuesday/Wednesday.
Alright, h
Hi James,
James Snyder wrote:
> I'm wondering if anyone is using the python bindings yet?
The python bindings are pretty new, so I guess you were the first
one to try them besides the original author.
> I've attempted to play around with them and found that at least with the
> SWIG I've got I ha
Hi Alex,
On Tuesday, 5. May 2009 05:03:42 Alex Harford wrote:
> This patch allows C/D BUS to be used on the 4232H, and initializes the
> default interface for 2232H/4232H.
Applied with some minor refactoring for better readability.
This patch was worth issuing libftdi v0.16rc3 as it improves
the
Have a nice weekend,
Thomas Jarosch
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Hello Arnim,
Arnim Läuger wrote:
> Recently switched on -Wstrict-prototypes with -Wall (and -Werror) and
> was confronted with a warning for ftdi.h:
>
> gcc -std=gnu99 -I/usr/local/stow/libftdi-0.16/include -g -Wall
> -Wstrict-prototypes -c main.c -fPIC -DPIC -o main.o
> In file included from ma
On Wednesday, 13. May 2009 08:09:44 Gregory Benjamin wrote:
> Hi. This is my first post here.
Hi :-)
> I just got 3 of the FT2232HQ mini modules.
> I bought 2 directly from FTDI, and got one from Saelig.
> The Saelig unit was ordered later, but arrived faster.
>
> I run a very small business and
Hello Koen,
On Thursday, 14. May 2009 18:35:21 Koen De Vleeschauwer wrote:
> On 08/05/2009, at 17:53, Thomas Jarosch wrote:
> > * Support for FT2232H and FT4232H (David Challis, Alex Harford and
> > Intra2net)
>
> A question:
> I see the FT2232H now supports a bitmode 0x40
On Friday, 22. May 2009 21:26:39 Jim Paris wrote:
> Signed-off-by: Jim Paris
All patches applied, thanks!
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
On Saturday, 23. May 2009 01:46:58 Aurelien Jarno wrote:
> ---
> bindings/python/setup.py.in |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Patch applied, thanks!
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to lib
Hello Jørgen,
On Thursday, 28. May 2009 15:09:45 Jørgen Kragh Jakobsen wrote:
> My problem is at the interface is broken from linux kernel 2.4 -> 2.6.
>
> I have debugged the error down to the ftdi_write_data not being done. That
> also what I have read in other forums and the only solution is to
Hello Kees,
On Wednesday, 10. June 2009 08:59:45 Kees Jongenburger wrote:
> When I try to run make install from the git repository I get the
> following error on ubuntu 9.04
> CMake Error: File /home/kejo/projects/libftdi/doc/Doxyfile.in does not
> exist. CMake Error at CMakeLists.txt:100 (config
Hello Matthias,
On Wednesday, 17. June 2009 22:33:37 Matthias Nagl wrote:
> I'm using libftdi to communicate with an AVR (via FT232R). To receive bytes
> sent from the µC I am currently polling the FT with repeated calls of
> ftdi_read_data() in a loop. However this method often doesn't notice new
Hello Zsuzsi,
On Thursday, 18. June 2009 16:35:45 Szük Zsuzsanna wrote:
> I have a question.
> Is it possible to to install libftdi to my router (WL500gp)? Openwrt
> runs on my router. If on Openwrt it isn't possible, what distribution is
> it possible to install?
> I would like to develop a softw
Hello Bas,
On Tuesday, 30. June 2009 11:51:08 Bas van Dijk wrote:
> I was wondering if work is being done on using libusb-1.0:
>
> http://libusb.wiki.sourceforge.net/Libusb1.0
Thanks for the link. AFAIK noone is activly working on this,
though there are reports you can use the compat wrapper
prov
Hello,
On Friday, 22. May 2009 00:56:50 Karl Cunningham wrote:
> We're setting up a programming station for FT245RL chips using libftdi
> 0.15 in Ubuntu. When we program chips using libftdi the first two bytes
> of the eeprom are being programmed with 0's. The problem is that chips
> programmed th
Hello Daryl,
On Tuesday, 23. June 2009 19:11:16 Daryl Lee wrote:
> I'm doing my first libftdi app, and I don't quite understand "chunk size"
> and latency. I'm sending 32-byte messages to my device and getting
> 32-byte messages back. I need to do this at 1 millisecond intervals. I
> find exper
Hello Daryl,
On Saturday, 11. July 2009 01:35:28 Daryl Lee wrote:
> I am trying to use libftdi in async mode, and have a question about the
> status of it, before I spend too much time wandering through the weeds.
>
> Questions:
> 1. Is it well-tested?
> 2. Is it known to work when the device is
Hello Nick,
On Thursday, 23. July 2009 04:36:24 Nick Hughart wrote:
> After looking I saw the ftdi_setdtr function so I thought I could use
> this to achieve what I needed to do. Unfortunately this seems to do
> nothing to DTR and yet returns no errors. Is there something that
> needs to be done
Hello Richard,
On Thursday, 23. July 2009 21:53:51 Richard A. Smith wrote:
> Uwe Bonnes wrote:
> >> "Xiaofan" == Xiaofan Chen writes:
> >
> > Xiaofan> Just wondering why not detach both interfaces? Or better
> > give Xiaofan> the user an option to detach the interfaces he wants to
> > det
Hello Nathan,
On Sunday, 26. July 2009 16:21:02 Nathan Fraser wrote:
> In some circumstances it is possible to send an invalid usb_dev
> pointer through to libusb after some errors or after an explicit
> close request. Result will be segfault or subtle corruption.
> This patch replaces all calls t
Hello Gary,
On Tuesday, 21. July 2009 08:04:29 Chunky Kibbles wrote:
> Small update: By putting this inside the inner loop, it appears mostly
> [but not completely] fixed:
>
> if(0 < (ret = ftdi_usb_purge_buffers(ftdic))) {
> fprintf(stderr, "unable to purge ftdi buffers: %d (%s)\n", ret,
>
On Monday, 27. July 2009 14:26:31 Xiaofan Chen wrote:
> You can probably borrow some codes from here.
>
> http://github.com/qdot/libnifalcon/tree/4c2a456459a75b5f03baeaafa335ba8bf
>5748d5d/src/comm
> http://github.com/qdot/libnifalcon/blob/4c2a456459a75b5f03baeaafa335ba8bf
>5748d5d/src/comm/FalconC
Hello Nathan,
On Monday, 27. July 2009 13:21:06 Nathan Fraser wrote:
> 2009/7/27 Thomas Jarosch :
> > Maybe we should prefix the function name with "ftdi_" to indicate
> > this belongs to libftdi. Something like ftdi_usb_close() ;-)
>
> Except this is not a fu
Hello jc,
On Tuesday, 28. July 2009 15:53:02 J.C. Wren wrote:
> Any thoughts on what the underlying problem would be? Is it a libftdi
> problem, or a kernel USB issue? This same board is used daily under
> Windows (bleh) and hasn't ever exhibited this problem.
IIRC our upgrade from kernel 2.4 t
Hello Jie,
On Sunday, 9. August 2009 16:44:54 Jie Zhang wrote:
> I have almost done the coding. Before sending out the patch, I need to
> know what's the best way to deal with libusb 0.1.
>
> Should we still keep support for libusb 0.1 because libusb 1.0 is not
> supported on Windows?
Thanks for
Hello Jie,
On Tuesday, 11. August 2009 12:02:41 Jie Zhang wrote:
> > Would it be possible to move the libusb interface into an abstraction
> > layer? Most libftdi functions are using usb_control_msg(),
> > so only a few functions need "specialization".
>
> Not yet. The API changes a lot between li
Hello Ben,
On Friday, 14. August 2009 22:49:05 Ben Plotnick wrote:
> Without configuring the chip at all I see a ~16 ms delay on a read
> command (I assume this is related to the timeout), which is out of spec
> for my application. When I go to lower the chunk size and latency using
> libftdi, I
Hello Oleg,
On Saturday, 24. October 2009 23:08:34 Signalyzer ( www.signalyzer.com )
wrote:
> I would like to submit a patch to ftdilib and add following functions
> to allow individual EEPROM locations reads and writes (similar to
> FTDI's FT_ReadEE() and FT_WriteEE():
>int ftdi_read_eeprom_
Hello Dave,
On Monday, 2. November 2009 05:29:56 David Brownell wrote:
> When running an FT2232H at full speed, we saw a new failure mode that
> turned out to be a bug in libftdi. Current git:
>
> int ftdi_read_data(struct ftdi_context *ftdi, unsigned char *buf, int
> size) {
> int offset =
Hello Oleg,
On Monday, 26. October 2009 17:53:40 Signalyzer ( www.signalyzer.com )
wrote:
> Thank you for your most prompt response on my message. I sincerely
> appreciate your support on this topic.
>
> Please let me know if you like to resubmit patch with corrected
> indentations?
We should
Hello Thimo,
On Monday, 2. November 2009 10:14:28 Thimo E. wrote:
> please refer to my post some months ago:
>
> http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00178.htm
> l
>
> There are some other bugs with FT2232H which are still not fixed
> upstream.
>
> Comments are highl
Hello,
I guess I've applied all outstanding patches to libftdi's git tree.
Please ping me if I might have missed one/yours.
Now we just need a fix for the
"FT2232H bug: wrong maxpacket at full speed"
issue ;)
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for d
Hello Jim,
On Tuesday, 10. November 2009 22:10:10 Jim Paris wrote:
> > Now we just need a fix for the
> >
> > "FT2232H bug: wrong maxpacket at full speed"
> >
> > issue ;)
>
> Probably something like the below patch. Note, only lightly tested
> (it returns 64 on my full-speed device here), and m
gh,
> and apply the right mask to wMaxPacketSize ... just in case.
Please give the attached patch a try. Works fine on my FT245BM type chip.
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.in
On Sunday, 15. November 2009 12:51:27 Thomas Jarosch wrote:
> Please give the attached patch a try. Works fine on my FT245BM type chip.
Anyone? :)
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsub
Hello Carl-Daniel,
which libftdi version do yo use?
The new high speed devices send the modem status byte
every 256 bytes. The current official libftdi version
thinks it's still at the 64 byte boundary.
Might be worth a try to use the latest libftdi from git
+ the patch you can find in the "Patc
On Tuesday, 24. November 2009 16:32:50 Carl-Daniel Hailfinger wrote:
> > which libftdi version do you use?
>
> I use latest git, but I don't have hardware to test right now.
Ok, that should provide basic support for the high speed devices. It's still
wrong if you connect it to a "normal speed" h
Hello Terry,
On Wednesday, 25. November 2009 17:40:08 T. Horsnell wrote:
> I'm struggling with what ought to be the most straightforward thing.
> I'm trying to write to channel A of an FT2232H mini-module in serial
> mode, but after writing a total of 4096 bytes, the writes hang
> and I get an err
Salut Albert,
On Thursday, 26. November 2009 07:58:13 Albert ARIBAUD wrote:
> I've come across a problem compiling OpenOCD with LIBFTDI, both from
> latest git: LIBFTDI puts headers in /usr/include/libftdi while OpenOCD
> expects them to be in /usr/include, and fails compiling files which have
> a
On Thursday, 26. November 2009 10:17:00 Albert ARIBAUD wrote:
> >> I guess this is a cmake vs. autoconf suite issue.
> >> Which one did you use to create the makefiles?
> >
> > I used CMake.
> >
> > So CMake and autoconf have discrepancies then?
>
> I meant, the cmake scripts and autoconf scripts
On Wednesday, 25. November 2009 17:40:08 T. Horsnell wrote:
> I'm using version 0.16 of libftdi
Oh, please try again with the latet git code. There's a specific
baudrate calculation fix in there for the 2232H chip.
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details
Hello Jim,
On Thursday, 3. December 2009 01:37:19 Jim Paris wrote:
> I finally got a chance to try this patch: "Determine maximum packet
> size via usb config descriptor". It works fine on:
> FT2232D, full speed
> FT2232H, high speed
> FT2232H, full speed (previously failed without the patc
On 12/04/2009 10:15 AM, Thomas Jarosch wrote:
> My current plan is to prepare a new libftdi release next week,
> so if there are any outstanding patches, send them now :)
I've extended that period for another week. We started
an official support request at FTDI regarding the baudrate
ra2net.com/en/developer/libftdi/download.php
Have a nice weekend,
Thomas Jarosch
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Hello Mike,
On Sunday, 20. December 2009 15:12:39 Mike Frysinger wrote:
> Listing the version here doesn't add anything to the content, and it is
> obviously forgotten during upgrades, so simply drop it.
Thanks for your patches. I've applied 1) and 2)
and replaced 3) with doc/release-checklist.tx
Hello Terry,
On Wednesday, 16. December 2009 12:40:12 T. Horsnell wrote:
> Hi all,
> I'm having a miserable time trying to use USB->serial on a FT2232H
> mini-module. I have:
> . Channel-A TX pin connected to Channel-A RX pin
> . Channel-A TXLED# connected to VCC
> . Channel-A RXLED# connected to
Hello Mike,
On Thursday, 14. January 2010 17:23:10 Michael Huang wrote:
> I'm new to libftdi. I'm developing an application running on FreeBSD 4.3.
> This application needs to communicate with a home-grown device with
> FT232R chip in it. Can someone help me on how to use libftdi in my
> applic
Hello Uwe,
On Tuesday, 2. February 2010 15:36:33 Uwe Bonnes wrote:
> I use libftdi git-head, Linux64 on AMDx2 6400 and the Windows machine has
> XP and a Pentium M 1700.
>
> Any idea how I can stop libftdi from scrambling data blocks.
>
> I will try to write a pure libusb(1) solution meanwhile.
On Tuesday, 2. February 2010 16:54:15 Uwe Bonnes wrote:
> >>>>> "Thomas" == Thomas Jarosch writes:
>
> Thomas> Hello Uwe, On Tuesday, 2. February 2010 15:36:33 Uwe Bonnes
>
> Thomas> wrote:
> >> I use libftdi git-head, Linux6
Hello Jie,
On Sunday, 14. February 2010 12:17:58 Jie Zhang wrote:
> On Sun, Feb 14, 2010 at 5:58 PM, Jim Paris wrote:
> >> +#ifdef __linux__
> >> +/* We can't set readbuffer_chunksize larger than
> >> MAX_BULK_BUFFER_LENGTH, + which is defined in libusb-1.0.
> >> Otherwise, each USB re
Hello Jonathan,
On 03/13/2010 05:20 PM, Jonathan Moreton wrote:
> I am using the python bindings for libftdi what type do i need to set
> the buf to when using ftdi_write_data as I get
>
> TypeError: in method 'ftdi_write_data', argument 2 of type 'unsigned
> char *'
I found a small piece of pyt
On Wednesday, 17. March 2010 02:16:14 Jonathan Moreton wrote:
> Thank you Thomas that was helpful, but not what I am trying to do.
>
> What i am trying to do is send a serial string out using the
> ftdi_write() method.
>
> can I do the following with out breaking anything?
>
> Change the functio
Hello,
does anyone have a little knowledge of swig?
Let's take this bit from bindings/ftdi.i:
%apply char *OUTPUT { unsigned short *status };
int ftdi_poll_modem_status(struct ftdi_context *ftdi, unsigned short
*status);
%clear unsigned short *status;
Shouldn't this be "%apply unsigned sho
Hello Logan,
On 03/30/2010 06:23 PM, Logan Gunthorpe wrote:
> I believe the bug is on the second last line of the ftdi_set_bitmode
> function. In 0.17 it is:
>
> ftdi->bitbang_enabled = (mode == BITMODE_RESET) ? 0 : 1;
>
> In 0.16 it is:
>
> ftdi->bitbang_enabled = (mode == BITMODE_BITBANG || m
On Thursday, 29. April 2010 03:18:44 Jie Zhang wrote:
> As I understanding of the "GPL compatible", it should be OK to have
> some files licensed under X11 license in a GPL software. But I don't
> know if it's OK to put some portion of X11 license code in a GPL
> licensed source file. Since if you
On Thursday, 29. April 2010 13:24:56 Uwe Bonnes wrote:
> If you could answer to
> libftdi@developer.intra2net.com
> I would appreciate.
Now he just has to join the list in order to post :o)
We don't allow non-member posting to keep the spam level low,
so I guess it's best if Micah would answer yo
Hello Uwe,
On Sunday, 2. May 2010 17:46:45 Uwe Bonnes wrote:
> Appended patch fixes a type that caused the creation of _64.[deb|rpm]
> also for 32-bit builds.
Applied, thanks. Your new stream code looks good from a license point
of view, I'll let Jie handle the technical side :)
I've seen the co
Hello Alexander,
On Wednesday, 5. May 2010 08:14:57 Lehmann Alexander wrote:
> I just learned that the configure script that comes with libftdi
> doesn't fully honour any given CFLAGS or CPPFLAGS. The problem arises
> from the fact that configure also creates the libftdi-config script
> which in t
Uwe,
On Monday, 17. May 2010 16:08:03 Uwe Bonnes wrote:
> int ftdi_usb_open_desc_index(struct ftdi_context *ftdi, int vendor,
> int product, const char* description, const char* serial,
> unsigned int index)
>
> doesn't expose and allow a check for the iManufacture String. Any reason
> no
On Monday, 17. May 2010 16:09:38 Uwe Bonnes wrote:
> Hello,
>
> is there any reason why the streaming read patch is not applied yet?
Any chance you could comment on the clock jump issue I mentioned?
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To un
On Tuesday, 18. May 2010 13:32:39 Uwe Bonnes wrote:
> Sorry, next time I will compiled before sending the patch...
>
> The variable "ret" in the #ifdef'ed code was missing. Appended code now
> defines this variable.
> -
Hmm. I guess we should also ignore the "LIBUSB_ERROR_NOT_SUPPORTED"
error cod
Helge,
On Friday, 14. May 2010 22:48:07 Helge Lenz wrote:
> So is there any way to make it work with this type of chip or should I
> stop trying and use something else? The one thing that I have not tried
> so far is to put the signal to one of the CBUS lines and use the CBUS
> bitbang mode. So co
Hello Manu,
On Tuesday, 4. May 2010 18:08:32 Emmanuel Blot wrote:
> I have not found a reference to this feature in the current FTDI lib,
> sorry if a patch has already been posted.
> Here is a quick patch to the current libftdi GIT HEAD to support
> hi-speed baudrates on recent FTDI devices
>
>
On Tuesday, 18. May 2010 13:43:53 Xiaofan Chen wrote:
> That is exactly right. And I think failure to detach the kernel driver is
> quite normal (eg: you already run libftdi once and the kernel driver
> is already detached) and should not return error. A warning is enough.
>
> ret = libusb_deta
On Tuesday, 18. May 2010 19:03:47 Helge Lenz wrote:
> Lets take a very simple example:
>
> #include
> #include
> #include
>
> int main(void)
> {
> struct ftdi_context ftdic;
> unsigned char testbuf[3];
> testbuf[0]=0;
> testbu
Uwe,
On Thursday, 20. May 2010 00:39:32 Uwe Bonnes wrote:
> > "Xiaofan" == Xiaofan Chen writes:
> >> The last patch doesn't use the libusb return, but the errno() set
> >> by the system.
>
> Xiaofan> I see. In that case, I think your patch is ok.
>
> Who does apply the patch in
On Tuesday, 25. May 2010 17:34:18 Uwe Bonnes wrote:
> >>>>> "Thomas" == Thomas Jarosch writes:
> Thomas> Uwe, On Thursday, 20. May 2010 00:39:32 Uwe Bonnes wrote:
> >> >>>>> "Xiaofan" == Xiaofan Chen writes: >&g
Hello Uwe,
On Monday, 31. May 2010 16:01:18 Uwe Bonnes wrote:
> with appended code and a revised verilog code, I can reliable read blocks
> of 16 Bytes of date generated about each Microsecond, like running for
> about 500 seconds:
>
> 8 errors of 375293955 blocks (2.131662e-08), 9 (2.398120e-08)
On Monday, 31. May 2010 17:26:56 Uwe Bonnes wrote:
> >>>>> "Thomas" == Thomas Jarosch writes:
> Thomas> Could you be so nice and comment on the possible time jump
> issue Thomas> I mentioned last time?
>
> I think some possible time jump is irr
by 0x806C22B: IOFtdi::~IOFtdi() (ioftdi.cpp:413)
> ==15786==by 0x8054EDC: std::auto_ptr::~auto_ptr()
> (auto_ptr.h:173) ==15786==by 0x8054C05: main (xc3sprog.cpp:824)
>
> I current git, it is fixed, probably by
> commit 8970ed7e36f5f4aa85dd5c3a47ee5d2e1044a870
> Author: Th
On Monday, 7. June 2010 16:19:47 Uwe Bonnes wrote:
> Well, on a second investigation of the dmesg and valgrind output, perhaps
> I misinterpreted some own error unrelated to above patch/problem...
A 0.18 release six months since the last release won't hurt anyway ;)
Can you check if the problem y
Uwe,
On Tuesday, 8. June 2010 13:48:40 Uwe Bonnes wrote:
> with appended patch and the two memory leak patches I have read 10's of
> Gigabyte of data at about 13.5 MByte/sec without any skipped data and any
> leaked memory.
Great!
> Thomas, is the possible clock skip still an issue?
Not at all
Emmanuel,
On Tuesday, 8. June 2010 20:00:03 Emmanuel Blot wrote:
> >> Isn't this enough to qualify for a new or a maintainance release?
> >
> > Yes, it is :) Thanks for pinging, I'll queued it up for the next days.
>
> I would suggest to take the opportunity of this new release to remove
> Linux
Hello Uwe,
On Tuesday, 8. June 2010 13:54:23 Uwe Bonnes wrote:
> in the examples directory, with cmake the executable were linked against
> the systel libftdi and not the new library built inside the source tree.
> This hinders testing. To avoid problems with dynamic linking, as a
> shortcut libft
1 - 100 of 673 matches
Mail list logo
