AVR fuse calculator

[MCUdude]

I'm amazed at how far Avrdude has come ever since the project was moved to Github. Bugs are being discovered and squashed almost every day, and new and awesome features are being added almost weekly. When I check my mail in the morning, there are usually at least 5+ unread Avrdude-related emails from Github. I absolutely love this project and it's a joy and an honor to be a contributor. And special thanks to @stefanrueger and @mcuee for being so enthusiastic, responsive, positive, and productive. My time is quite limited due to having two kids under three, but I try my best to help out with testing and tracking down bugs that require special hardware.

Avrdude is already the ultimate command line tool for programming AVRs, and there's virtually no tool out there that can compete. I use Avrdude for everything AVR related (well, except for writing and compiling code), but there's one feature I still have to use Microchip Studio or an online tool for, and that is figuring out fuse bits. Fuse bits are an essential part of the hardware aspect of the AVR, and can really be a pain to figure out, since older AVR datasheets may be hard to navigate in, due to the lack of a table of contents. The online fuse calculator also relies on someone hosting it. It also lacks all chips UPDI and PDI programming interface.

This is just a wild idea, and nothing else. Imagine a new tool (avrfuse?) or an extension to the Avrdude terminal where one can either pass fuse bits to show what they represent or use an interactive editor to "create" the correct fuse bits for a particular use case, just like you can with Microchip Studio. I have no idea how something like this can even be accomplished, but my first thought was a GUI-like interface that looks like ncurses. It would obviously have to scrape the appropriate atdf files pulled from one or more "packs". I'm sure something like this could be a useful addition to the open-source AVR toolchain!

I'd like to hear your ideas and thoughts as well!

[mcuee]

I will say this is a good idea. Fuse is important (https://microchipdeveloper.com/8avr:avrfuses).

I use the online fuse calculator quite a bit myself and they do not support new PDI/UPDI parts well.

Online tool may still be good, I think github can be the host. But a command line GUI or even proper GUI (using QT or things like that) will be good as well.

[mcuee]

Online AVR fuse calculator sites:

1. Classic AVR only
   https://www.engbedded.com/fusecalc/

2. Classic AVR + New Tiny 0/1/2 series UPDI AVR, using ATDF, Alpha version only
   https://www.engbedded.com/conffuse/

3. Classicic AVR + ATxmega
   https://eleccelerator.com/fusecalc/

4. Classic AVR + New Tiny 0/1 AVR, with github source codes available
   https://github.com/ele9i4/fuse-calc

PC apps? (seems no longer available, from palmavr project)
https://www.ladyada.net/learn/avr/fuses.html

Mobile apps: Android version (never tried this myself)
https://play.google.com/store/apps/details?id=me.chayan.avrfusecalculator&hl=en&gl=US

Someone has actually developed a command line fuse calculator under Linux as per his comment here.
https://eleccelerator.com/tool-fusecalc/#more-287

[mcuee]

@MCUdude

Interestingly I found a per based application called exactly avr-fuse..
https://metacpan.org/dist/App-AVR-Fuses/view/bin/avr-fuses

Looks quite cool to use as per the description.

$ avrdude -c avrisp -p m328 $(avr-fuses -p m328 CKDIV8=1)

[dl8dtl]

Basically, I'd not see this as "core competency" of AVRDUDE.
Meanwhile, the fuses have a multitude of facettes, so this requires a bit of work. Maybe it could be extracted from XML files though.

How about starting a real GUI, and then make it part of that? After all, the entire idea of separating the AVRDUDE library backend was since I always felt that all those AVRDUDE GUIs that just wrap around the commandline tool (which was never intended to be machine-usable) are a poor idea from the beginning, so a better interface between the core engine and the UI is needed.

[mcuee]

A GUI will be nice. I admit I know next to nothing about GUI toolkits. The projects I am involved in are not GUI related as of now,

At hidapi project, the fox based test app has been deprecated due to the difficulty of maintenance. QT may be a good replacement as per the current active maintainer.

[dl8dtl]

I think the quickest options to hack a GUI would be Python-based, either tkinter or PyQt. Needs a library glue wrapper then though.
To remain in pure C++, Qt is fine as well, and easily allows for a multiplatform GUI.

[mcuee]

BTW, I admit I use AVRDUDESS (https://github.com/ZakKemble/AVRDUDESS) sometimes to to set some fuse bits, even though now I also use terminal mode to manipulate fuse bits.

[stefanrueger]

I don't so much mind that I have to use a tool outside avrdude to deal with fuses but that the whole workflow is complex, even with fuse calculators (which at least save me the trouble of looking up the data sheet).

A new tool avrfuses: yes, that might scrape the atdf files and replace online tools. Good, probably still outside AVRDUDE, and will be useful.

If this endeavour is meant to be part of the AVRDUDE project then we could ask the questions

• What are the types of problems we are trying to solve?
• Which libavrdude functions would we write? (declaration)
• How would these functions be written? (definition)
• How to use of these functions in the terminal (eg, to solve the problems we started from)

Here one example problem: I want to change the level of the brown-out detection of a connected part in the terminal.

Now, this is a really hard problem to crack from a human-computer interaction point of view. Ideally, the user could write in the terminal

avrdude> bodlevel 4v3
avrdude> write fuses

And be done with it. No fuse calculator needed. Bliss. No bits, bytes and fuse names to deal with.

Different parts have different names for the brown-out voltage level and different values, too. There needs to be a functionality that shows the properties of the fuses. How to get there? It's indispensable to scrape the ATDF files for this. It would be necessary/cool/convenient to turn this into avrdude.conf properties. Once that hurdle is taken, a new command could be

avrdude> show fuses
sut_cksel: extxosc_8mhz_xx_16kck_14ck_65ms
ckout: disabled
ckdiv8: disabled
bootrst: enabled
bootsz: 256w_3f00
eesave: disabled
wdton: disabled
spien: enabled
dwen: disabled
rstdisbl: disabled
bodlevel: 2v7

These symbolic values come straight from the ATDF files. With increasingly more verbosity this could look like:

avrdude> show fuses
lfuse = 11111111 (0xFF)
        ||++++++_______ SUT_CKSEL: EXTXOSC_8MHZ_XX_16KCK_14CK_65MS
        |+_____________ CKOUT: disabled
        +______________ CKDIV8: disabled

hfuse = 11011110 (0xDE)
        |||||||+_______ BOOTRST: enabled
        |||||++________ BOOTSZ: 256W_3F00
        ||||+__________ EESAVE: disabled
        |||+___________ WDTON: disabled
        ||+____________ SPIEN: enabled
        |+_____________ DWEN: disabled
        +______________ RSTDISBL: disabled

efuse = 11111101 (0xFD)
        xxxxx+++_______ BODLEVEL: 2V7

or

avrdude> show fuses
lfuse = 11111111 (0xFF)
        ||++++++_______ SUT_CKSEL (Select Clock Source): EXTXOSC_8MHZ_XX_16KCK_14CK_65MS (Ext. Crystal Osc. 8.0-    MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms)
        |+_____________ CKOUT (Clock output on PORTB0): disabled
        +______________ CKDIV8 (Divide clock by 8 internally): disabled

hfuse = 11011110 (0xDE)
        |||||||+_______ BOOTRST (Boot Reset vector Enabled): enabled
        |||||++________ BOOTSZ (Select boot size): 256W_3F00 (Boot Flash size=256 words start address=$3F00)
        ||||+__________ EESAVE (Preserve EEPROM through the Chip Erase cycle): disabled
        |||+___________ WDTON (Watch-dog Timer always on): disabled
        ||+____________ SPIEN (Serial program downloading (SPI) enabled): enabled
        |+_____________ DWEN (Debug wire enable): disabled
        +______________ RSTDISBL (Reset Disabled (Enable PC6 as i/o pin)): disabled

efuse = 11111101 (0xFD)
        xxxxx+++_______ BODLEVEL (Brown-out Detector trigger level): 2V7 (Brown-out detection at VCC=2.7 V)

Again, the strings come straight from ATDF. Over time, the users can contribute cleaned-up versions in avrdude.conf. OK, assuming we have show fuses, this only tells the user it's the property BODLEVEL they are after. They would need another command, eg,

avrdude> values bodlevel
4v3: Brown-out detection at VCC=4.3 V
2v7: Brown-out detection at VCC=2.7 V
1v8: Brown-out detection at VCC=1.8 V
disabled: Brown-out detection disabled

Again, these values come straight from ATDF.

With that, it would be possible to fairly easily carry out functional programming as in

avrdude> bodlevel 4v3
avrdude> write fuses

That might be fun.

I have no idea how libavrdude could implement above with modular functions. Ideas on a postcard, please :)

[mcuee]

Now, this is a really hard problem to crack from a human-computer interaction point of view.

In this case, nothing beats a GUI. But what you proposed is also pretty good.

[MCUdude]

@stefanrueger I think this is a very interesting idea. Some sort of tool that has its own "avrfuses.conf" where pretty much everything (including long strings) is stored.

The "downside" of making this feature of the avrdude is that it's a little more difficult to "get in" when you just want to calculate or check some fuses, without actually connecting a target. It will also either totally fill the existing avrdude.conf file with even more data, or the user has to "carry" another conf file.

By making it a separate tool, it can be used in "interactive mode" like @stefanrueger cleverly illustrated, or "inlined" as @mcuee showed in this example: avr-fuses example: $ avrdude -c avrisp -p m328 $(avr-fuses -p m328 CKDIV8=1)

A GUI is also very convenient, but my initial idea was to have a fuse calculator that didn't rely on some webserver to work. Maybe a core/library can be made as some sort of backend that a potential future GUI?

Slightly off-topic on why it's a good idea to have a tool that doesn't rely on some webserver. I used to use Wormfood's online AVR baud rate calculator from time to time because it's very convenient to keep track of which baud rates one can use with which clock frequencies. Suddenly one day the website was down, and it took more than a year for it to pop up back again. Meanwhile, I had to find something else, and the second best alternative was from a Russian website called trolsoft.ru. To say it nicely, that name didn't put a lot of confidence in me!

[stefanrueger]

either totally fill the existing avrdude.conf file with even more data, or the user has to "carry" another conf file.

Or the data structures are secretly tucked away in the C source of avrlibdude. This is going to happen for vector bootloaders where some messages will want to print the symbolic vector name (as it is in the target's datasheet). The file avrintel.c holds these names for known MCUs without bothering avrdudes.conf. It is a departure from using avrdude.conf for everything, and it shifts the intelligence about parts from avrdude.conf to libavrdude.

I have always viewed mcu configuration bits in fuses as logic memory on a bitfield level, and I would be perfectly happy to have definitions (in avrdude.conf or libavrdude data structures) expressing bodlevel is efuse:0-2 or similar. This logic memory would enable us to avrdude -p... -c... -U bodlevel:w:4v3:m. The beauty is that you actually no longer need a fuse calculator for this: avrdude knows it needs to read efuse, modify bits 0-2 with the bit pattern that corresponds to the symbol 4v3 and write efuse back. I predict users don't really care which fuse holds the bodlevel, which bits are used and which bit pattern corresponds to 4.3 V. Well, I know I don't.

[mcuee]

This avrdude -p... -c... -U bodlevel:w:4v3:m will be a very nice feature.

BTW, if the fuse info is inside avrdude.conf or libavrdude, technically people can also write a separate tool (off-line or on-line version).

[MCUdude]

The issue with storing all this data in avrintel.c is that it makes it difficult to add new parts without recompiling the program. A conf file can easily be extended without having to do anything with the executable.

Another neat feature would be to insert the parts and their fuses and have avrdude/avrfuses to tell you exactly what they represent. BOD and other settings are easy to visualize, but many of the setup timers + clock settings (SUT_CKSEL) are kinda obscure, so the "full" description string is often very helpful.

[stefanrueger]

Well, the hard bit is scraping the atdf files. The easy bit is to decide whether you want the intel in avrdude.conf, in a structure in avrintel.c or in both (avrdude.conf trumps/overwrites avrintel.c)

[stefanrueger]

downside [...] you just want to calculate or check some fuses, without actually connecting a target

That can be done with a -c dryrun programmer that emulates reading/writing to the part. The dryrun programmer would allocate an AVRPART structure, initialize the fuses with the default values from avrdude.conf (taken atdf files), and implement read/write functions to just manipulate the allocated AVRPART memories rather than programming a target. With that you can do your -U bodlevel:w:4v3:m -U efuse:r:-:h spiel, test terminal scripts etc without connecting to a target. This basically can act as a fuse calculator.

I still think a world in which you don't need a fuse calculator (b/c the programming tool allows to set/read the logic parameters (bodlevel, bootsz, ...) directly) is a better world.

BTW, such a dryrun programmer would be useful for testing the avrdude logic, too.

[mcuee]

BTW, such a dryrun programmer would be useful for testing the avrdude logic, too.

Yes, that will be a good one, maybe for CI as well.

[MCUdude]

That can be done with a -c dryrun programmer that emulates reading/writing to the part.

A -c dryrun is a good idea. And perhaps the same can be achieved if the -c flag is omitted?

I agree that it would be very convenient to set the fuse bits needed in Avrdude without worrying about writing to the correct fuse like this, bodlevel:w:4v3:m. However, it would also be necessary to be able to look up what the chip actually supports. Terminal mode is one thing (a brilliant example by @stefanrueger paste below), but it could be neat to be able to view options directly at the command like

Terminal mode example:

avrdude> show fuses
lfuse = 11111111 (0xFF)
        ||++++++_______ SUT_CKSEL (Select Clock Source): EXTXOSC_8MHZ_XX_16KCK_14CK_65MS (Ext. Crystal Osc. 8.0-    MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms)
        |+_____________ CKOUT (Clock output on PORTB0): disabled
        +______________ CKDIV8 (Divide clock by 8 internally): disabled

hfuse = 11011110 (0xDE)
        |||||||+_______ BOOTRST (Boot Reset vector Enabled): enabled
        |||||++________ BOOTSZ (Select boot size): 256W_3F00 (Boot Flash size=256 words start address=$3F00)
        ||||+__________ EESAVE (Preserve EEPROM through the Chip Erase cycle): disabled
        |||+___________ WDTON (Watch-dog Timer always on): disabled
        ||+____________ SPIEN (Serial program downloading (SPI) enabled): enabled
        |+_____________ DWEN (Debug wire enable): disabled
        +______________ RSTDISBL (Reset Disabled (Enable PC6 as i/o pin)): disabled

efuse = 11111101 (0xFD)
        xxxxx+++_______ BODLEVEL (Brown-out Detector trigger level): 2V7 (Brown-out detection at VCC=2.7 V)

avrdude> values bodlevel
4v3: Brown-out detection at VCC=4.3 V
2v7: Brown-out detection at VCC=2.7 V
1v8: Brown-out detection at VCC=1.8 V
disabled: Brown-out detection disabled

Command line example (syntax highly debatable):

$ avrdude -p atmega328p -U bodlevel?

         0x04, 4v3:      Brown-out detection at VCC=4.3 V
         0x05, 2v7:      Brown-out detection at VCC=2.7 V
         0x06, 1v8:      Brown-out detection at VCC=1.8 V
         0x07, disabled: Brown-out detection disabled

$ avrdude -p atmega328p -U lfuse? hfuse? efuse?

lfuse = 11111111 (0xFF)
        ||++++++_______ SUT_CKSEL (Select Clock Source): EXTXOSC_8MHZ_XX_16KCK_14CK_65MS (Ext. Crystal Osc. 8.0-    MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms)
        |+_____________ CKOUT (Clock output on PORTB0): disabled
        +______________ CKDIV8 (Divide clock by 8 internally): disabled

hfuse = 11011110 (0xDE)
        |||||||+_______ BOOTRST (Boot Reset vector Enabled): enabled
        |||||++________ BOOTSZ (Select boot size): 256W_3F00 (Boot Flash size=256 words start address=$3F00)
        ||||+__________ EESAVE (Preserve EEPROM through the Chip Erase cycle): disabled
        |||+___________ WDTON (Watch-dog Timer always on): disabled
        ||+____________ SPIEN (Serial program downloading (SPI) enabled): enabled
        |+_____________ DWEN (Debug wire enable): disabled
        +______________ RSTDISBL (Reset Disabled (Enable PC6 as i/o pin)): disabled

efuse = 11111101 (0xFD)
        xxxxx+++_______ BODLEVEL (Brown-out Detector trigger level): 2V7 (Brown-out detection at VCC=2.7 V)


$ avrdude -p atmega328p -U sut_cksel?

         0x00, EXTCLK_6CK_14CK_0MS:             Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms
         0x10, EXTCLK_6CK_14CK_4MS1:            Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms
         0x20, EXTCLK_6CK_14CK_65MS:            Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms
         ...
         0x3F, EXTXOSC_8MHZ_XX_16KCK_14CK_65MS: Ext. Crystal Osc. 8.0-    MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms

For reference, here's a screenshot from the Engbedded fuse calculator. It shows some of the available SUT/CKSEL settings for the ATmega164P and it is next to impossible to memorize all of it. A "cheatsheet" like -U sut_cksel? or similar to show all available options could be very useful.

[stefanrueger]

AVRDUDE has made good progress with respect to its knowledge about fuses. There is the config terminal command that can also be utilised on the command line with -T. There are now tables in avrintel.c describing in detail the bitfields of all fuses of some 330 parts; avrintel.c has been moved into libavrdude, so anyone who wants to program their own fuse calculator can make use of that, and AVRDDUDE no longer needs a fuse calculator as it knows about the bitfields and can directly set them.

Hence, closing the dicsussion as resolved.