Avrdude "simple syntax"

[MCUdude]

In order to stay busy we need som crazy new ideas. So here's one I got when reading at the Avrfreaks forum.

If we implement Levenshtein distance checking for parts and memories too, would it be possible to support an "alternative syntax" without flags, for simpler things like flashing a file or setting a fuse?

Here are some made up examples:

# Write myprog.hex to flash and myprog.eep to eeprom
avrdude usbasp atmega328p flash myprog.hex eeprom myprog.eep

# Erase chip and set efuse to 0xff and hfuse 0xd6
avrdude usbasp atmega328p erase efuse 0xff hfuse 0xd6

# Write test_file.bin to flash using Urboot/Urclock
avrdude urclock ch340 250000 flash test_file.bin

If this unheard of, and practically impossible to implement, or is this something that would make Avrdude more accessible for the average AVR developer?

Could it be solved by a routine that parsed the input (avrdude urclock ch340 250000 flash test_file.bin) and then made it so that Avrdude can understand it (avrdude -c urclock -P ch340 -b 250000 -U flash:w:test_file.bin:a)?

[dl8dtl]

I think it might make sense to call the program differently then.

Basically, lex + yacc (which we already have) are able to parse any kind of grammar, as long as we can describe a grammar for the input language.

[mcuee]

Another idea is to embed scripting language like jimtcl or lua or even Python.

Reference: OpenOCD has embedded jimtcl
https://github.com/openocd-org/openocd

[mcuee]

In order to stay busy we need som crazy new ideas.

@MCUdude
You can put the ideas here as well. You can see actually there are quite some issues to deal with and some of them may be quite challenging.

• avrdude 8.0 release discussion #1654

[dl8dtl]

Another idea is to embed scripting language like jimtcl or lua or even Python.

The question is what's the goal:

Is it automation? Then it might make more sense to just build up Python bindings on top of libavrdude, and write up some nice examples on how to use that practically.

Is it ease of user interaction? Then I think we need a kind of "natural language" commandline parser.

I thought the topic is about the latter.

[mcuee]

The question is what's the goal:

Is it automation? Then it might make more sense to just build up Python bindings on top of libavrdude, and write up some nice examples on how to use that practically.

Is it ease of user interaction? Then I think we need a kind of "natural language" commandline parser.

I thought the topic is about the latter.

Good point. But I have different understanding of "easier user interaction". I think GUI is the way to go and not "natural language" commandline parser.

In that sense, we need to improve libavrdude. I can see AVRDUDESS is quite popular but it is built on top of avrdude CLI and there may be a better way to use libavrdude and other cross-platform GUI toolkit.
https://github.com/ZakKemble/AVRDUDESS

[dl8dtl]

I think GUI is the way to go and not "natural language" commandline parser.

Agreed, and allowing for a better GUI integration than all those on-top-of-CLI ones, was the primary reason for segregating libavrdude as the backend from the frontend CLI code.

[stefanrueger]

avrdude already has CLI and terminal syntax. I am not convinced their syntax is overly complex to solve

• Part selection
• Programmer selection
• Comms selection
• What you want to do

Some of the commands can be a bit complex, eg, terminal write, but there is always a simple way using hex byte values; you don't have to use strings, unsigned long integer data, floating point hexadecimal numbers or Roman numbers...

ChatGPT will probably be able to translate natural language into (halfway) correct syntax. 😮

In any case, it is probably best for avrdude to not invent a new syntax that competes with the existing one.

Better to use libavrdude to generate a new interface/program using a different way of expressing above 4 points.

avrdude usbasp atmega328p erase efuse 0xff hfuse 0xd6

BTW, this example is likely to suffer from ambiguity: do you want to erase the entire chip or only efuse? There is something to be said about the semicolon in -T "erase; write efuse 0xff; write hfuse 0xd6" and explicit operations.

[mcuee]

In this case, maybe we want to convert this issue to discussion.

[dl8dtl]

OK, done.