Hi, sorry for the delay, I can confirm that the patch as of comment #32 indeed resolved the main problem I was having with os x and bitbang with Arduino.
Now the device responds correctly recognized etc. I haven't tested flashing something yet.

One little problem appeared however, now avrdude hangs after all the messages. The lst one says "avrdude: safemode: Fuses OK" and than nothing. It's necessary to force the process to terminate (ctrl-c).

I compiled latest trunk as of now, r1104.

I managed to fix the baud rate problem, which I believe was caused by the BitBang Mode variable Pulse Width issue described in

http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_120_FT232R%20Errata%20Technical%20Note.pdf

My solution is to write each byte 4 times (and decimate input accordingly), but I'm a bit puzzled that nobody else has run into this problem, which presumably should affect any FT232R.

> I thought Microsoft had added a "posix compatibility layer"
> to windows over a decade ago.

Well, AFAIK this is only an optional add-on, so its actual
value is questionable.  Second, threads are optional in the
Posix model, so you can obtain a UNIX branding without even
implementing threads.  The UNIX process model (with fork and
pipes and all that) is much more portable, and under Unix,
the difference between a thread and a process, performance-
wise, is neglicible.

> I'm not an "autoconf" hero.

Neither am I.  Nevertheless, it's not rocket science.  There's
already a good number of tests around in configure.ac which
could be used as templates to craft your own test.

Of course, the most preferrable option would be to use native
Win32 threads when compiling for a Win32 environment.  Win32
used to have threads for many years (because their processes
are fast as snails), and the subset of threading features
used here is not very large.  Perhaps some code for that
could be "borrowed" from the pthreads-win32 package without
requiring it being present as an external package?

Someone commented on the mailinglist that there is a pthread
implementation for Win32.  However, it's the responsibility
of configure.ac to probe for it then, and disable the
module if it's not around in the compilation environment.

Of course, it would generally be better to rewrite the code
to use Win32 native threads when running under Win32, unless
the prerequisite libftdi already requires pthreads anyway.

(One of the problems of the current implementation is that
the #include statement for pthreads.h is even outside the
check whether there's a libftdi at all.)

libftdi 0.19
libusb 1.0.8
libusb-compat 0.1.3

Here the output of otool:
Max:Lucifer$ otool -L /opt/local/bin/avrdude
/opt/local/bin/avrdude:
/opt/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.19.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/opt/local/lib/libusb-1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libftdi.1.dylib (compatibility version 21.0.0, current version 21.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0)
/opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)

@rewolf yep the first thing I checked was the connection. I'm using the same cable I used before with the old patch based upon libftd2xx wich worked.

Here: http://pastebin.com/2R4pMCEg

@rliebscher The buffer overflow message is indeed gone, however avrdude still hangs. Here the new output: http://pastebin.com/vnkPXgb9
(I tested with the normal serial port and it respond correctly with the signature)

Hi, I'm trying to use ftdi bitbanging with my arduino deuemilanove (ATmega328P) with latest avrdude trunk (rev. 1068) with my MacBook Pro and Os X Lion.
However the arduino do reset but then doesn't respond (I unloaded the FTDI kext).
Here my output: http://pastebin.com/p1FjuzS3

Rene, I think I see the progress bar do bad things. I'm probably passing the wrong arguments to the progress bar function.

If you already know what the progress bar function should be passed, I'm hoping it's a 2 minute fix for you. If not, let me know and I'll look in to it.

(Symptoms: progress bar progresses slowly that you're thinking: that'll take a while, and then suddenly it's done. It seems like only 10% of the progress bar is used).

I've added two lines that should cancel and wait for the reader thread. No apparent badness under Linux. Rene, can you test this under Windows? Does the sigfault go away?


(file #24986)

I added this in svn revision 1055.

The name used in the config file is ftdi_syncbb. But files are still named ft245r.

The reason for the difference is the fact that now the pin numbers start from 1 (as avrftdi and others do), where ft245r used numbers starting from 0. But 0 is also used internally for not set pin numbers, so if extending the programmer to support  leds, it would not be clear if it is not set or should use pin 0.

There are now some new programmer entries : ft232r, ft245r, bwmega, arduino-ft232r (and diecimila as its alias, see also http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html ).

I think it should be later merged into avrftdi, so it detects the chip, checks the pin configuration and uses then MPSSE or does bitbanging, if MPSSE is not usable, because not available on the chip or signals are not assigned to the MPSSE pins.

Hmm. I fixed up a new version a few days ago and I thought I had posted it. Maybe it was the SOPA protest that prevented me from posting it here.

Anyway, cleaner patch without serjtag is attached.

(file #24855)

Rene, thank you for checking things out (compile test) on Windows! I forgot about that part...

I have now also patched serjtag (where I don't know where the hardware comes from.... I have tried googling if maybe I can make the hardware on short notice, but no such luck. It is simply mentioned on the pages that link to the patches that I have ported here.)

My guess is that serjtag was copied by someone into ft245r, and then modified there. I guess the patches could be split: the serjtag driver should be considered less tested as I don't have the hardware to test it. (nor can I find documentation that tells me about this).

Rene, can you also perform functional tests?

I have removed the "report progress" calls from the programming loops. This is apparently now handled outside the loop in the driver.

Both ft245r.c and serjtag.c have "generic" paged_write functions that are used for eeprom writing. I think I saw some coding errors in that part and wondered how it could have passed my testing I claimed I had done below. The answer is that those are called (in my testing) with m->paged set to false, so that code was never executed. The question is: Can non-flash memory in AVRs be paged?

If not, that would allow me (us) to remove some error-prone (and for me difficult to test) code.....

Attached is the latest version and this time generated with svn diff.... (My understanding of svn has moved from cut-pasting examples found on the web to: I know two commands! :-) (they are: svn diff and svn add) ).




(file #24840)

Attached is the patch that compiles, builds and verifies against the SVN codebase....

avrdude-5.11.1 users beware:
(The previous patch might have non-functional eeprom reading/writing. )


(file #24807)

Dear avrdude maintainers,

I'm going to attach a patch that uses the FT2xxR synchronous bitbang modes to program the AVR chips. This can be done QUITE fast. I got over 2k/sec programming+verifying yesterday. I don't understand what's changed since yesterday, but I only  get just below 2k/sec today. :-( (this means over 4k/sec programming only).

I THINK this throughput can be increased even further but I haven't been able to get this to work just yet.

Previous versions of this "patch" relied on the non-free ftd2xx library from FTDI. This one works with libftdi.

I am not able to test it under windows.

The reads from the device have to be asynchronous under Linux. I therefore had to add a dependency on pthreads.

Otherwise, it seems a deadlock would develop: while sending a datablock to the FTDI, it needs to return the synchronous "return data". When the application hasn't issued the read yet, the kernel will prevent the device from sending the data, and then when the buffers in the ft2xxr fill up, it will also stop accepting data, blocking the write....

I have found that there is also a new avrftdi programmer in the current release. This programmer works for ft2232(h) chips and refuses to work for the ft232r that I have here.

(some) Arduino users will be able to download their sketches 4-10 times faster with this patch. :-)


(file #24806)

Please have a look at patch #4330, and tell us whether this
is what you had in mind.  If so, please give that patch a
try, and leave us some feedback about whether this is working
for you or not.