Have Avrdude figure out the end address in terminal write mode

[MCUdude]

Currently, there's no way to tell Avrdude that I want to write from a start address to the end of the specified memory when using the ... ellipsis to fill the specified memory. Currently, you'll have to manually calculate how many bytes there are left in the memory (by looking in the datasheet for that particular AVR). And if you're not writing from start address 0, you'll have to subtract the start address from the total number of bytes the memory has in order to fill the entire memory.

Maybe the ellipsis ... or asterisk symbol * can be used for this?

Below are a few examples for the ATmega1284P, which has 4096 bytes of EEPROM.

# write 4096 0x55's to EEPROM
# write eeprom 0 4096 0x55 ...

# Write data to EEPROM starting from address 0x100, and write 0x55's to the rest of the memory
#write eeprom 0x100 3840 "Hello World" 1234 0x55 ...


# Maybe we could use ... or * to specify "end of memory"?


# Fill the entire EEPROM with 0x55's using ... to indicate end of memory instead of length
write eeprom 0 ... 0x55 ...

# With asterisk
write eeprom 0 * 0x55 ...

# Fill the EEPROM memory starting from address 0x100
write eeprom 0x100 ... "Hello World" 1234 0x55 ...

# With asterisk
write eeprom 0x100 ... "Hello World" 1234 0x55 ...

Any thoughts?

[mcuee]

Sounds like a good enhancement.

Just wondering if we can have a new from start_addr to end_addr command.

Eg:

write eeprom from 0x100 to 0x200 "Hello world"
write eeprom from 0x100 to end "Hello world"
write eeprom from start to 0x100 "Hello world"
write eeprom from start to end "Hello world"

[MCUdude]

Just wondering if we can have a new from start_addr to end_addr command.

That's certainly possible, but IMO only adds "synthetic sugar" and doesn't bring any new functionality.
The start address is always 0 anyways.

@stefanrueger do you have any thoughts or comments on the potential new feature, or should I just create a PR and see what happens?

EDIT: another nice thing this would bring us is that it would be trivial to enhance the erase command to erase a user-specified memory without having to remember the correct syntax for this:

# Write 0xff's to the entire EEPROM
erase eeprom

# Write 0xff's to the entire flash memory
erase flash

# "legacy" command that erases the flash memory, and possibly the EEPROM unless the EESAVE fuse is set
erase

[mcuee]

The erase function is nice. Hopefully it works for different type of AVRs without erasing other menory types. Initial tests show the results are good.

[MCUdude]

The erase function is nice. Hopefully it works for different type of AVRs without erasing other menory types. Initial tests show the results are good.

Yes, I think this is a good addition to terminal "toolbox". Since it just calls write <mem> 0 ... 0xff ..., it should work with all memories the write command supports.

[stefanrueger]

I am late to the party. I find the syntax with double ellipses confusing. Could we use negative numbers like in python or perl's substring operations?

addr	len	interval	comment
addr	len	[addr, addr+len-1]	current use
0x1700	12	[0x1700, 0x1700+11]	example
-256	2	[size-256, size-255]	negative addr means that many bytes from end
0	-1	[0, end]	all memory w/o having to know the memory size
0	-384	[0, size-384]	all memory except the last 383 bytes
-256	-1	[size-256, size-1]	last 256 bytes

• This is easy to remember (same in other languages)
• This is easy to compute
  • negative address -addr means start = size-addr
  • negative length -len means end address of size-len or, equivalently, a length of size-len-start + 1

Tip for implementation: First check and memorise whether the addr/len string starts with a minus; then eat up the - sign; then use the same current code to read addr/len as if it was an unsigned number (and complain if that is out of range); then compute effective addr and len; then complain about out of range addr and len as before (eg, complain about write eeprom -128 -130 0x55 ... as this has an an effective length of -1 (end before start).

[stefanrueger]

BTW, I would use the same syntax for the -U memory.addr.len notation that I suggested in Issue #1322

[MCUdude]

I don't find the double ellipsis confusing (probably because I came up with it), but negative numbers are way more versatile than a single .... By using negative numbers it's trivial to for instance write to the last 512 bytes in flash, even without knowing the end address. Maybe we can support both negative numbers and ...? After all, the erase command uses ... to indicate end of memory: read eeprom 0x100 ....

I'll have a look at how I can implement this tonight. It probably shouldn't be too difficult, but I'd have to add this to both the dump and write commands.

But are you OK with the extended erase command @stefanrueger?

[stefanrueger]

support both negative numbers and ...?

We should (try to) be backwards compatible.

The ellipsis has three meanings: in the read addr ... command it stands for memory end. In read ... it stands for all memory. Then in write the ellipsis denotes padding.

I would extended the notion of addr len with potentially negative values for padded write and introduce read mem addr len, so that arbitrary intervals in the memory can be specified for either. This makes the uses of ... in read redundant, but I would keep them working for backwards compatibility. Maybe their documentation could be downgraded to simplify it, eg, removing the ellipses from the terminal help menus for read, from avrdude.1 and avrdude.texi; in the latter two I'd add a sentence in the read description to the effect of read ... returns the full memory as shortcut and read addr ... returns the memory from addr to the end.

Doing so will give addr len the same meaning as in python, perl, etc, and it will give the ellipses at the end one (main) meaning (padded write). addr len could be added to the new erase syntax erase [mem [addr len]] too as a shortcut for write mem addr len 0xff ....

[stefanrueger]

Just to be clear, yes I think the extended erase command is cool.

When I wrote erase [mem [addr len]] I meant three forms: erase (chip erase), erase mem (that you already suggested) and erase mem addr len (using the same extended syntax as for read and padded write)