i2c_target: Add attribute that exposes the number of bytes transferred. - #18485

Code size report:

Reference:  stm32/boards/STM32F469DISC: Add board.json file. [22cff2f]
Comparison: tests: Add tests for i2c_target numbytes attribute. [merge of 075b090]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:  +124 +0.031% PYBV10[incl +16(bss)]
     mimxrt:   +72 +0.019% TEENSY40
        rp2:  +160 +0.017% RPI_PICO_W[incl +8(bss)]
       samd:  +112 +0.041% ADAFRUIT_ITSYBITSY_M4_EXPRESS[incl +24(bss)]
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (22cff2f) to head (075b090).
⚠️ Report is 1196 commits behind head on master.

@@           Coverage Diff           @@
##           master   #18485   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22301    22301           
=======================================
  Hits        21940    21940           
  Misses        361      361           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Thanks for the contribution. And thanks for making a good PR with updates to both the docs and tests. The feature you've added is definitely useful.

@projectgus and I discussed this PR and the main concerns we had were around atomicity: if another transaction comes in while the Python code is reading memaddr and numbytes, then those values won't match and/or won't be correct. memaddr may now be the address of the next transaction. numbytes may be reset to 0 or currently being incremented as part of the next transaction.

In most applications this probably won't matter, the I2C transactions will be slow/synchronous. But it would be good to try and improve the situation.

One idea is to have an attribute (eg I2CTarget.last_mem_transaction) return a tuple containing (transaction_count, read_write, mem_addr, num_bytes). That would be an atomic snapshot of the last transaction. But that's going to need to allocate memory which isn't great.

Instead, maybe it's enough to modify this PR to make it so that the new numbytes attribute is only updated at the end of the transaction, so it's always a proper value (never something that's part way through a transaction).

And then add another attribute txn_count (transaction count) that counts the number of mem transactions. Then if you want atomicity you can read txn_count first, then memaddr and numbytes, then txn_count again and make sure it hasn't changed. If it changed, repeat that reading sequence.

Or, maybe something simpler that would still allow atomicity would be the following:

• when memaddr is changed, numbytes is set to -1 to indicate "transaction in progress"
• when the transaction is done, numbytes is set to the number of bytes written/read
• if a user wants to ensure atomicity (eg because they can't guarantee the controller will wait between transactions) then they can read memaddr and then numbytes and then memaddr again, and keep doing that until both memaddr values match, and numbytes is not -1

After recently playing around with I2CTarget, I stumbled across a possible need for this feature. Glad to see there's a PR in progress already!

I wish to convert a Pimoroni RP2040 board into an I2CTarget and it seems configuring it as a memory device is the most performant option. For this I want some sections of memory to be read-only, where a write has no effect. If the host does a single byte write, then I can use the memaddr to check for a change and reload the stored value, but I cannot tell when multiple bytes are written in a row.

I only have two read-only registers for now, so I am just using the hard irq to reset them both on every IRQ_END_WRITE.

@alectric-tr are you still interested in working on this PR?