pietern/avr-i2c

gather based send

Opened this issue · 4 comments

brontide commented

FYI: This is a placeholder issue for code I have already written and tested.

I need to be able to send multiple distinct buffers as one operation. This is to facilitate interrupt driven display refreshes on i2c displays like the SSD1306. The code I have written allows for the i2c address of an operation to be 0 which indicates that it's an additional buffer for the previous operation. This allows me to send the video buffer without having to decompose or copy the in-memory copy.

For i2c based displays it allows a huge savings in cycles to be reclaimed for other operations since the main loop no longer has to block on the buffer write.

pietern commented

Interesting, didn't know about that trick (or devices that implement it).

FYI, I'm not using the code in this repository anymore, I'm using I2C from avr-tasks. This is essentially a superset of the functionality in this repo.

Do you want to upstream the code you've written?

brontide commented

I don't actually send the 0 address, I use it as a flag to the interrupt code to just keep sending from the next buffer without a new start.

A quick peek at avr-tasks shows that it might be difficult to get it upstream but I'll take another looks this evening since I would much rather keep the code someplace where it can get more eyeballs.

pietern commented

Ah, I see. This is possible in avr-tasks through the I2C readv/writev functions. You pass them a list of buffers/lengths and it will go over them in order.

brontide commented

I see three problems with avr-tasks.

  1. I want to fire and forget and check the status at a later time, the way I see it the writev can send multiple buffers but the task is suspended until it's done.
  2. I precompose 8 different operations ( start/restart, address, <command prefix buffer of 1 byte>, < video page, usually 128 bytes> ).
  3. The application is already seriously memory constrained ( 1k video buffer ) so using tasks directly as 256B/task is probably not possible.

So I'm thinking I will just continue to use the existing code pulled into my library for now until a suitable alternative can be found. I can slim it down if I don't have to consider other use cases.