TWIM chunking does multiple start+stops

[Dirbaio]

The TWIM Write impl does this when the buffer is not in RAM:

https://github.com/nrf-rs/nrf-hal/blob/1c76cbe819d054a5394d5f7eb5d168f2bbf88d7f/nrf-hal-common/src/twim.rs#L396-L401

This does this on the bus: start + chunk + end + start + chunk + end + start + chunk + end + ... while it should do : start + chunk + chunk + chunk + ... + end

Nordic has confirmed it's not possible to do multiple buffers without extra start/stops: https://devzone.nordicsemi.com/f/nordic-q-a/66615/nrf52840-twim-how-to-write-multiple-buffers-without-repeated-start-condition

The chunking should probably be removed, returning an error if the data is too big, like copy_write_then_read does.

[Yatekii]

I fought hard against auto-copying and auto-chunking. And we concluded that it would be sensible to have the embeded-hal surface employ chunking as the API is limited and intended for easy use anywas, while the proprietary nrf-rs API surface should not do any of that automatic stuff . This should be the case atm.

[Dirbaio]

Yeah, the problem here is that the trait contract explicitly states that write should do one start condition and one stop condition.

The impl is not doing this, so it's wrong.

Chips typically treat data after a new start condition as a different "command", with possibly a new register address etc, so this will cause stuff to not work silently.

I think it's better to not autochunk and return an error, so the user can know what the problem is.

[Dirbaio]

To clarify: it could still autocopy, but it shouldn't autochunk. copy_write_then_read already does this.

[Yatekii]

I see, yeah we should change that.

[jonas-schievink]

We might want to make FORCE_COPY_BUFFER_SIZE a user-definable constant instead of the current hard-coded value.