Re: FTDI plus Atmel AVR programming

As Didrik Madheden wrote: > Yes, this is supported, but you need to add a programmer definition to > tell avrdude which pin is used for what. You should be able to use > this programmer in two different modes, but each mode has advantages > and disadvantages. Serbb, which is very slow. Or

AVRDUDE 7.0 released

I just released version 7.0 of AVRDUDE, the first release being rolled from the Github infrastructure. While I am sure there are many more things to do, and some of those might have deserved to go into the new release, it was already way behind its original schedule (March 2022) anyway. First,

Re: Which ISP programmer for FreeBSD?

As Axel Rau wrote: > Could it be that I have a wrong setup on my FreeBSD box? > How can I test? I don't think there's anything wrong with your FreeBSD, it's just that Diamex thingy is a bit strange. As they only claim Windows support, it's really hard to tell what they've done. If you want,

Re: Which ISP programmer for FreeBSD?

As Axel Rau wrote: > Am 16.04.22 um 14:50 schrieb Joerg Wunsch: > > Did you ever try running with STK500v1 as the protocol? > > > Looks a little bit different: But not better :-/ No idea what they are doing. Have you ever tried whether it really works under Atmel/Microch

Re: Which ISP programmer for FreeBSD?

As Axel Rau wrote: > What I see there, does this mean, that avrdude has received something at all > from the programmer? Doesn't seem so. There's no response at all. Did you ever try running with STK500v1 as the protocol? (I doubt it, since I think Atmel Studio would immediately want to

Re: source TeX file of avrdude-doc-5.11.pdf

As ME wrote: >Could I ask you to email me the TeX file (source) of >avrdude-doc-5.11.pdf? There is no TeX file but a texinfo file, in the doc/ subdirectory. Despite of similar names, their syntax (and purpose) is quite a bit different. -- cheers, Joerg .-.-. --... ...--

Re: New member and how to cross-compile AVRDUDE

As kristof.mul...@telenet.be wrote: > How to cross-compile AVRDUDE? Until now, I have been shipping the Windows builds for AVRDUDE built as cross-compilations on my FreeBSD system, using MinGW32 cross compiler. (Why? Because so far, nobody volunteered to offer a Windows build.) You can find

AVRDUDE 6.4 released * now transitioning to Github

Hello everyone, it's a pleasure to finally announce the release of AVRDUDE version 6.4. It's been a (too) long time since the last release. There are many bugfixes and many new features in this release - a personal "Thank you!" to everyone who contributed something. Without all your help, the

Re: [bug #61624] [Feature request] Serial/UART UPDI programmers

As Dawid Buchwald wrote: > There is, however, one more thing that mcudude mentioned - at the > end of programming AVRDUDE would list values of lfuse/hfuse/efuse in > its goodbye message. It is pretty irrelevant to the modern chips, > since they don’t really have any of these, they just have array

Re: [bug #61624] [Feature request] Serial/UART UPDI programmers

As Dawid Buchwald wrote: > After some more investigation I concluded that there are actually > different scenarios where Safemode is disabled, so I would really > leave that for now. Just as a side-note, and since there is also one large patch regarding safemode which I decided to not apply

Re: [bug #60575] Permission denied on macOS Big Sur

As Hans Eirik Bull via Discussion of avrdude development. wrote: > It is /usr/local/include, yes. There is no include folder inside the Cellar > folder. Oh, I see, /usr/local/Cellar appear to be just a library folder. Fine, mange tak / tack så mycket! -- cheers, Joerg .-.-.

[bug #60575] Permission denied on macOS Big Sur

Update of bug #60575 (project avrdude): Status: Postponed => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

Re: [bug #60575] Permission denied on macOS Big Sur

As Hans Eirik Bull via Discussion of avrdude development. wrote: > I figured out the issue! It's so dumb I'm a bit embarrassed. Glad you found it! > What really solved it for me was the "custom" configure command: > env LDFLAGS=-L/usr/local/Cellar CPPFLAGS=-I/usr/local/include ./configure

Re: [bug #60575] Permission denied on macOS Big Sur

As Hans Eirik Bull wrote: > Here's the output from the dtruss. Well, there's no errno 13 in it. However, what is remarkable compared to my trace file is open("/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib\0", 0x0, 0x1FF) = 3

Re: [bug #60575] Permission denied on macOS Big Sur

As Hans Eirik Bull wrote: > I'm not sure what I do wrong. > > After running ./configure I get the following output: > > Configuration summary: > -- > DO HAVElibelf > DO HAVElibusb > DO HAVElibusb_1_0 > DON'T HAVE libftdi1 > DO HAVElibftdi > DON'T HAVE libhid

Re: [bug #60575] Permission denied on macOS Big Sur

As Marius Greuel wrote: > Have you tried to build with libhidapi? Good point. I've been using port install autoconf automake \ libtool hidapi libftdi1 libusb libelf to install all prerequisites (just checked that again). If you use something else than Macports, translate that into the

[bug #60575] Permission denied on macOS Big Sur

Follow-up Comment #9, bug #60575 (project avrdude): Strange. I've meanwhile got a small Macbook, it shipped to me with 12.0.1 (Monterey). Just tested the 6.4 release candidate yesterday, and all in all, MacOS is the OS causing the least trouble in all respects (Linux and FreeBSD need device

Re: [bug #61624] [Feature request] Serial/UART UPDI programmers

As mcudude wrote: > One issue though. I've been using git for years, but never ever touched svn. > Embarrassing question, how do I clone your repo/fork? I've tried various > commands, but I always end up with an empty serialupdi folder. You do not "clone" it, you "checkout" (or just "co") it. In

[bug #53703] FT232H based programmer returns all 0xFF when reading flash from atmega2560

Update of bug #53703 (project avrdude): Status:None => Need Info ___ Follow-up Comment #1: Well, I think the logic behind this still has some issues. Looking at "native" programming

[bug #57453] [PATCH] fix reference to nonexistant -m option by changing to -U

Update of bug #57453 (project avrdude): Status:None => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

Re: Unexpected message : "avrdude: bad response to write memory command: 0xa0"

As Doom wrote: > Have you planned to make a new release soon ? Well, if you followed the mailing list messages, yes, you would have noticed these plans. > In that case, do you have a build documentation or a good link for that ? > I had a look at the documentation and see ,othing about this >

[bug #55123] Error in flashing / reading Eeprom on ATtiny45 under Windows

Update of bug #55123 (project avrdude): Status:None => Need Info ___ Follow-up Comment #1: Which "tiny"? Best, also provide a full commandline. Sorry, I have no idea about that

[bug #61626] jtagmkii_pdi improvements for jtag2updi use

Follow-up Comment #5, bug #61626 (project avrdude): [comment #4 comment #4:] > Would be great if the essence could be scissored out and added to the docs. A link to the repo is probably also a good idea. > Please do ;-) I welcome diffs, also for documentation updates. > Ah, the PDIUSBD12

Plans (was [bug #61626] jtagmkii_pdi improvements for jtag2updi use)

As mcudude wrote: > Is the current plan to apply patches and fix critical bugs and call it a day > (and that's totally OK), or will further development continue in the future, > perhaps driven by bug reports, feature requests and user-applied patches? > Regardless, I'm very thankful for all your

[bug #57338] if safemode has to change fuses avrdude should exit with non-zero exit code

Update of bug #57338 (project avrdude): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[bug #58994] VPP PWM still enabled at the end of programming process

Update of bug #58994 (project avrdude): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[bug #61626] jtagmkii_pdi improvements for jtag2updi use

Follow-up Comment #3, bug #61626 (project avrdude): [comment #2 comment #2:] > I'm not sure I follow you regarding the documentation and what you mean by "it", sorry. "it" = the proposed addition > The jtag2updi project is documented on its Github repo, and the hardware required for it to work

[bug #61626] jtagmkii_pdi improvements for jtag2updi use

Follow-up Comment #1, bug #61626 (project avrdude): We can probably add that entry in avrdude.conf. I'd love to also see a documentation update for it, including the reference to the hardware description. However, it's not the only UPDI programmer supported by AVRDUDE; EDBG-style programmers are

[bug #61624] [Feature request] Serial/UART UPDI programmers

Update of bug #61624 (project avrdude): Status:None => In Progress Assigned to:None => dawidbuchwald ___ Follow-up Comment #1: Dawid already

Re: Unexpected message : "avrdude: bad response to write memory command: 0xa0"

As Doom wrote: > When I write lock bits I have this message : > "avrdude: bad response to write memory command: 0xa0" > > It seems to work, but I want to know if it is normal or if I should search > something wrong somewhere ? > > mcu is avr128db64 > and programmer is atmelice_updi Please try

[patch #10154] Update to serial code management for custom connection parameters

Follow-up Comment #9, patch #10154 (project avrdude): OK, you're correct, union pinfo is not initialized. Dragging all that into pgm is probably not such a good idea, not sure. Nevertheless, I'd vote for some simplification in the cflags handling, as we'll for sure never use all combinations of

[patch #10154] Update to serial code management for custom connection parameters

Follow-up Comment #6, patch #10154 (project avrdude): [comment #4 comment #4:] > If anything I would ask why serial connection parameters (like number of databits and parity) are set in a function called setspeed(). We could rename it to "setparms" then, meaning it sets both the speed as well

[patch #10154] Update to serial code management for custom connection parameters

Follow-up Comment #5, patch #10154 (project avrdude): [comment #3 comment #3:] > If you do use some mechanism to ensure that the default value will always be 0, then sure. Thing is, AFAIK, without proper constructor you can guarantee that. There is a proper constructor, pgm_new() (in pgm.c),

[bug #60008] linuxspi programmer does not seem to release AVR reset when finished

Update of bug #60008 (project avrdude): Status: Confirmed => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #10153] linuxspi: Support "-E reset" and "-E noreset"

Update of patch #10153 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #10154] Update to serial code management for custom connection parameters

Update of patch #10154 (project avrdude): Status:None => In Progress ___ Follow-up Comment #1: I wonder whether we could get around those pinfo.serialinfo.cflags = SERIAL_DEFAULT_FLAGS;

Re: Moving avrdude to Git ?

As Hannes Weisbach wrote: > Just a comment about pthread dependencies, I think I’ve made > before. If nothing changed, only the ftdi_syncbb programmer used > that and it was required only, because buffer limits of the FTDI > chip were ignored. Given proper handling of buffer sizes (see > avrftdi)

Re: Moving avrdude to Git ?

Trying a mass-reply to all the answers that arrived. As greu...@mgtek.com wrote: > It is certainly too much work for a single person, and I really do > appreciate that you are donating your spare time to keep avrdude alive! Thanks! > Speaking of testing, I was wondering what kind of tests you

[bug #60008] linuxspi programmer does not seem to release AVR reset when finished

Follow-up Comment #3, bug #60008 (project avrdude): That's a bit odd though. If I use gpioset 0 25=1 the non-reset state persists even after gpioset terminates. What are they doing different then? ___ Reply to this item at:

Re: Moving avrdude to Git ?

As greu...@mgtek.com wrote: > I would have never dared to suggest moving the AVRDUDE project to a > Microsoft company :-) There's even one committer from Microsoft aboard, Wes Witt. ;-) When they tried to get a foot into the Fruit-Pi community by porting Windows and tools to it, they were also

Re: Moving avrdude to Git ?

As Doom wrote: > Regarding the already allocated name, would you reconsider the question to > move to GitHub > if I get back *avrdude* GitHub account name for the project ? Again, it's not a matter of Git or not, it's a matter of someone converting the remaining infrastructure. I can export the

Re: Moving avrdude to Git ?

As Doom wrote: > But don't you think it's time to move to Git ? The problem is not Git, the problem is the remaining infrastructure. I could probably easily convert everything to Git on Savannah (they offer it, obviously), but some people expressed interest in moving to a "more modern" platform

Re: Introducing SerialUPDI programmer

As Dawid Buchwald wrote: > Anyway, as for the implementation, I’m still working on it, and > probably will, at least for a while. What I do need to know right > now, is whether it is OK to change some of the core AVRDUDE serial > code. The thing is that for this particular implementation I need

Re: Improving Windows support for AVRDUDE

As Marius Greuel wrote: > Now, for Windows users, it would be nice if avrdude just "works out of the > box", as it does on Linux. One of the key points is to move away from the > libusb0.sys driver to the WinUSB driver. WinUSB is the Windows equivalent of > libusb, which is what people use

[patch #7275] Support for parallel port programmers on windows 7 64 bit and other versions of 64 bit windows

Follow-up Comment #4, patch #7275 (project avrdude): See mailinglist discussion: https://lists.nongnu.org/archive/html/avrdude-dev/2021-11/msg00082.html ___ Reply to this item at:

Re: [patch #7275] Support for parallel port programmers on windows 7 64 bit and other versions of 64 bit windows

(Cc'ing Henrik again - I think he isn't subscribed to the list.) As greu...@mgtek.com wrote: > What I meant to say was in the context of this patch, i.e. Windows specific. > I would not remove parallel port support altogether, but I suggest to > disable it for Windows (both x86 and x64), and

Re: [patch #7275] Support for parallel port programmers on windows 7 64 bit and other versions of 64 bit windows

As Marius Greuel wrote: > IMHO, we should drop support for parallel ports. I just cannot imagine > anyone still using parallel ports for AVR programming. As long as it's working, I wouldn't really want to drop it. We abstracted the "logical" layer from the physical one long time ago, and thus

Re: [patch #7275] Support for parallel port programmers on windows 7 64 bit and other versions of 64 bit windows

As Henrik Haftmann wrote: > > Is this really still relevant, given that parallel-port computers are no > > longer really available? > Yes, as InpOut32.dll, available as InpOutX64.dll for a 64-bit version of > avrdude, enables redirection of bit-banging to any hardware, not only the > parallel

Re: Introducing SerialUPDI programmer

As Dawid Buchwald wrote: > I might be wrong, but based on the information found here: > https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md > there are actually quite a lot of issues with jtag2updi > implementation in AVRDUDE, and the SerialUPDI utility provided by >

Re: Introducing SerialUPDI programmer

As Dawid Buchwald wrote: > I can provide more details, should there be interest, but for now I > can shortly describe the implementation process: I forked > https://github.com/sigmike/avrdude repo into > https://github.com/dbuchwald/avrdude, created new programmer > definition, and started

Re: [bug #55884] ft232r communication fails on programmed part if miso line toggles

As Hannes Weisbach wrote: > Maybe a mixup: > > > > Well, I tried to reproduce the problem. I wrote a firmware that toggles > > >>>MOSI<<< > > Email/bug subject line: > > ft232r communication fails on programmed part if >>>miso<<< line toggles Oops, sure. Will try tonight. Nevertheless, the

[bug #60008] linuxspi programmer does not seem to release AVR reset when finished

Update of bug #60008 (project avrdude): Status:None => Confirmed ___ Follow-up Comment #1: I observed the same behaviour. ___

[bug #55884] ft232r communication fails on programmed part if miso line toggles

Update of bug #55884 (project avrdude): Status:None => Works For Me ___ Follow-up Comment #1: Well, I tried to reproduce the problem. I wrote a firmware that toggles MOSI each 100 µs (on an

[bug #54603] Error in `avrdude': corrupted size vs. prev_size

Update of bug #54603 (project avrdude): Status:None => Confirmed ___ Reply to this item at: ___

[bug #55462] wrong programmer id check in jtag3_getsync() and jtag3_close()

Update of bug #55462 (project avrdude): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Fixed, see patch

[bug #58440] linuxgpio PIN limit too low

Update of bug #58440 (project avrdude): Status: Confirmed => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #8272] rfcomm devices can't connect in time to upload

Update of patch #8272 (project avrdude): Status:None => Need Info ___ Follow-up Comment #2: The audit trail refers to a problem inside Linux. Is that still an issue these days?

[patch #8923] Enable TPI for linuxgpio

Update of patch #8923 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #7275] Support for parallel port programmers on windows 7 64 bit and other versions of 64 bit windows

Update of patch #7275 (project avrdude): Status:None => Need Info ___ Follow-up Comment #3: Is this really still relevant, given that parallel-port computers are no longer really

[patch #5245] User mode IO access in WIN32 wiyhout giveio.sys

Update of patch #5245 (project avrdude): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #4: The audit trail

[bug #46759] avrdude 6.1 -> 6.2 regression: lock byte verification error

Update of bug #46759 (project avrdude): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed Release:

[patch #8996] Remove lock byte read mask (bug#21954, bug#46759)

Update of patch #8996 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[bug #21954] verify fails for masked ('x') bits

Update of bug #21954 (project avrdude): Status:None => Fixed Open/Closed:Open => Closed Release:None => 6.3

[patch #9757] Fix ATtiny817 Xplained Mini programmer

Update of patch #9757 (project avrdude): Open/Closed:Open => Closed ___ Reply to this item at: ___

[patch #9304] [Bug #48767] Implemented WinSock variation of "ser_drain(...)" functionality

Update of patch #9304 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #4330] Adds experimental FTDI bit bang mode interface

Update of patch #4330 (project avrdude): Status:None => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #8: With the latest

[patch #7811] Adds avr_pin_name()

Update of patch #7811 (project avrdude): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Reply to this item at:

[patch #9816] Implement new programmer type: linuxspi

Update of patch #9816 (project avrdude): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #5: I also added

[patch #10031] linuxspi: Support GPIO uAPI v2

Update of patch #10031 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

Re: linuxspi question

As Joerg Wunsch wrote: > I think I've got the connections wired correctly: > > RPiISP Name > > 19 4 MOSI > 21 1 MISO > 23 3 SCK > 24 5 /RESET > 25 6 GND I fi

[patch #10030] linuxspi: Support inverted GPIO pin

Update of patch #10030 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #10029] linuxspi: Report GPIO_GET_LINEHANDLE_IOCTL errors

Update of patch #10029 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #10028] linuxspi: close() only when necessary

Update of patch #10028 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #10027] linuxspi: Add reset pulse, according to AVR programming algorithm

Update of patch #10027 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

linuxspi question

With all the patches for linuxspi, I'm trying to set it up on an elderly Raspberry Pi 2B. I think I've got the connections wired correctly: RPiISP Name 19 4 MOSI 21 1 MISO 23 3 SCK 24 5 /RESET 25 6

[patch #8228] Added linux spi programmer type based on spidev userspace drivers

Update of patch #8228 (project avrdude): Status: In Progress => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #5: obsoleted by

[patch #9328] ft245r.c: add TPI support (patches 5-7)

Update of patch #9328 (project avrdude): Status: In Progress => Done Assigned to:None => joerg_wunsch ___ Follow-up Comment #3: Except of the

[patch #9327] ft245r.c: add TPI support (patches 1-4)

Update of patch #9327 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

Re: [patch #9328] ft245r.c: add TPI support (patches 5-7)

As David Mosberger wrote: > > I'm not sure about D2XX. The issue came up earlier, it might contradict > > Savannah's policy to offer "non-free" software hooks. Let's see. > > > > No strong feelings on that from my side. I'll postpone that one then. > We are Linux-based anyhow and for > our

[patch #9328] ft245r.c: add TPI support (patches 5-7)

Update of patch #9328 (project avrdude): Status:None => In Progress ___ Follow-up Comment #2: I'm not sure about D2XX. The issue came up earlier, it might contradict Savannah's policy to

[patch #9319] Add async bitbang FTDI driver with TPI support

Update of patch #9319 (project avrdude): Status:None => Wont Do Open/Closed:Open => Closed ___ Reply to this item at:

[patch #9507] Fix UPDI chip erase

Update of patch #9507 (project avrdude): Status: In Progress => Done Open/Closed:Open => Closed ___ Reply to this item at:

[bug #57169] MEGA32U2 mEDBG programmer on the ATtiny817 board does not work

Update of bug #57169 (project avrdude): Status: Need Info => Works For Me ___ Follow-up Comment #5: See audit trail of that patch. Current SVN works for me on that board.

[patch #9757] Fix ATtiny817 Xplained Mini programmer

-v avrdude: Version 6.3-20171130 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "avrdude.conf" User configuration file is "/home/joerg/.avrduderc&quo

[patch #9757] Fix ATtiny817 Xplained Mini programmer

Update of patch #9757 (project avrdude): Status: Need Info => In Progress ___ Follow-up Comment #11: OK, I added something similar to the patch below. Will look into the other issue before

[patch #9757] Fix ATtiny817 Xplained Mini programmer

Follow-up Comment #10, patch #9757 (project avrdude): Well, my Xplained Mini with the ATtiny817 arrived. It's got a completely different issue: most of the time, it doesn't accept the sign-on command, returning a response with fragment info 0x00. This triggers an "inconsistent fragment number"

Re: [patch #8719] xbee programmer

As David Sainty wrote: > What do you think about this? > > Brutal criticism gratefully received :) Looks good. I hope I translated it well to avrdude.texi (because that's the source for the PDF documentation). All done now, thanks! -- cheers, Joerg .-.-. --... ...-- -.. .

[patch #8719] Support Over-the-Air bootloading with XBeeBoot

Update of patch #8719 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9565] Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements

Follow-up Comment #3, patch #9565 (project avrdude): Well, all that timeout handling is a mess. A lot of that is probably just heritage from AVRDUDE's 22-year old history. I wonder whether there's a better way than introducing just another timeout hack^H^H^H^Hsetting though. The jtagmkII.c code

Re: [patch #8719] xbee programmer

As David Sainty wrote: > > Well, please add some kind of example and this explanation to the > > documentation. > Yes, I can do that, probably tomorrow. Great! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you

Re: [patch #9110] Let reserved fuse bits to be read as *don't care*

As David Sainty wrote: > Patch updated at https://savannah.nongnu.org/patch/index.php?8719 Thanks! > The XBee support adds a new programmer type with no other changes, so it's > a very light-touch patch - if the user doesn't select the "xbee" programmer > then there's no opportunity for the

Re: [patch #9110] Let reserved fuse bits to be read as *don't care*

As David Sainty wrote: > There is a patch https://savannah.nongnu.org/patch/index.php?8719 too, but > github is more up-to-date. I haven't tested it with the current trunk but > certainly will do if it may get it merged. I'd consider it if you can update it within the next few days. I have

Re: [patch #9110] Let reserved fuse bits to be read as *don't care*

As Matthijs Kooijman wrote: > Any plans for doing a release in the near future? Yes, that's the idea behind all that activity. Currently, I'm waiting for an Xplained Mini board to conduct some further tests on one bug. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

[bug #57169] MEGA32U2 mEDBG programmer on the ATtiny817 board does not work

Follow-up Comment #4, bug #57169 (project avrdude): OK. given the audit trail of patch #9757, in particular r1436 breaking this again, I just ordered an ATtiny817 devkit. ___ Reply to this item at:

[patch #9123] ftdi_syncbb: use FT245R_CYCLES in ft245r_set_bitclock()

Update of patch #9123 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9122] Fixed MISO sampling in ftdi_syncbb

Update of patch #9122 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9079] Fix ftdi_syncbb teardown

Update of patch #9079 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9320] fix TPI RESET in bitbang.c

Update of patch #9320 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9253] Fix for giving terminal_mode commands more than 20 arguments

Update of patch #9253 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[patch #9110] Let reserved fuse bits to be read as *don't care*

Update of patch #9110 (project avrdude): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

  1   2   3   4   5   6   7   8   9   10   >