avr_write_mem() does not really write something about avrdude HOT 13 CLOSED

I suspect the corresponding m->tags[] bytes are not set.

(off-topic: I also suspect the python implementation/wrapper of progress reporting does something else than the AVRDUDE progress reporting as I haven't seen the behaviour that "ing 0 %" is written for the latter.)

from avrdude.

The progress indication is indeed quite simplified.
Who is responsible for setting the tags? (and how is it done? :)

from avrdude.

As I've got that m->put method, it could certainly somehow handle setting the tags.

from avrdude.

Who is responsible for setting the tags? (and how is it done? :)

Reading in a file for writing sets the tags (to manage holes in files in the Intel hex or Motorola S record format)

from avrdude.

Yes, the progress reporter is a much simplified version in my test (it's a plain Python callback now).
I guess I have to assign m->tag[] in my m.put() helper then, yes.

from avrdude.

Yep, works now:

>>> m=ad.avr_locate_mem(p, 'eeprom')
>>> ad.avr_read_mem(pgm, p, m)
Reading 100 %
512
>>> m.get(10)
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
>>> m.put(b'The quick brown fox jumps over the lazy dog.')
44
>>> ad.avr_write_mem(pgm, p, m, 44)
Writing 100 %
44
>>> ad.avr_read_mem(pgm, p, m)
Reading 100 %
512
>>> m.get(44)
b'The quick brown fox jumps over the lazy dog.'

from avrdude.

All is working.
Finally, I could also write back my previously saved flash contents from the test device:

>>> m=ad.avr_locate_mem(p, 'flash')
>>> with open("dump.bin","rb") as f:
...  b=f.read()
... 
>>> len(b)
8666
>>> m.put(b)
8666
>>> ad.avr_write_mem(pgm, p, m, 8666)
avrdude: padding flash [0x2180, 0x21ff]
Writing 100 %
8666

from avrdude.

m.put and m.get are Python access methods to m->buf, accepting or returning Python bytes objects

m.put and m.get ought to take an address within buffer argument as well in order to provide random access to m->buf

from avrdude.

They do, it is called offset. It just defaults to 0.

from avrdude.

And for m.put, the length is taken from the input byte string, while for m.get, the length needs to be specified.

from avrdude.

Remember, this is Python, we can have default values for arguments. :-) (The SWIG wrapper can handle them, even though the C backend functions cannot.)

from avrdude.

They do, it is called offset. It just defaults to 0.

Ahh, great.

Yes, the progress reporter is a much simplified version in my test (it's a plain Python callback now).

In order to support the logic of libavrdude progress reporting, the application-specific update_progress() functions should not do anything before a header was provided and they should stop updating on progress as soon as a terminating progress report call was issued. Basically, it's a logic that dances around

This needs documentation, and this could be provided at the same time when Issue #1721 is dealt with.

from avrdude.

I think the existing progress_callback in my Python test code works basically like that:

# very simplified progress callback
global prog_hdr
prog_hdr = ""
def progress_callback(percent: int, etime: float, hdr: str, finish: int):
    if hdr:
        global prog_hdr
        prog_hdr = hdr
    print(f"{prog_hdr} {percent:3d} %", end='\r', file=sys.stderr, flush=True)
    if (percent == 100):
        print("", file=sys.stderr)

But that's merely a simplified example right now. There's room for fine-tuning. :-)

from avrdude.