Skip to content

Conversation

soypat
Copy link
Contributor

@soypat soypat commented Jun 21, 2025

@ysoldak @aykevl @deadprogram
Discussion in #766 made me consider adding this logic which is common to many 8 bit address width drivers. The name comes from "Register Mapped"

I've added only the functions which have a trivial heapless solution. The trivial implementation for WriteDataSPI and WriteDataI2C would require copy+additional buffer provided so I avoided it for now to see if we can think of a solution that maybe does not require the copy, i.e: transactional API.

@ysoldak
Copy link
Contributor

ysoldak commented Jun 25, 2025

This PR looks more like a Draft, a conversation starter. Shall we convert it to Draft?

What do you mean by "transactional API", @soypat?

In #767 I had to allocate a buffer in I2C buser and return a part of it back to the driver to use.
Can we use something like this here probably?

@soypat
Copy link
Contributor Author

soypat commented Jun 25, 2025

By transactional API I mean approach something more similar to how DBs handle actions, see BboltDB's Tx method on DB type. It really is a rather complex way of approaching this and would likely not be required for 99% of drivers, so I'd rather leave it to a future conversation.

This current API is the most basic level of abstraction. We can add a dynamic buffer: Device8Buffered to cover your use case, though I feel the brunt of the work developing a new driver is this work, not the dynamic buffer length part, which can really be done in so many ways I'm hesitant to adding it. I'd like to see the pain point of needing a dynamic buffer implementation before writing it. The ssd1306 can maybe (?) get away with the following code? And it really feels like not worth generalizing just yet

type Dev struct {
  buf []byte
}

func (d *Dev) tx(data []byte) error {
    d.buf[0] = cmd
    n := copy(d.buf[1:], data)
    return d.bus.Tx(d.buf[:n+1], nil) // ...
}

@soypat
Copy link
Contributor Author

soypat commented Jul 13, 2025

Merging this since it provides no external API change but could be leveraged by driver developers immediately. No risk, only benefit :)

@soypat soypat merged commit 80356fd into release Jul 13, 2025
1 check passed
@soypat soypat deleted the regmap-package branch July 13, 2025 12:58
soypat added a commit that referenced this pull request Jul 13, 2025
@deadprogram
Copy link
Member

This PR was merged against release instead of dev, which is why the revert did not work correctly, and also why the release branch is "out of sync".

deadprogram added a commit that referenced this pull request Jul 14, 2025
soypat pushed a commit that referenced this pull request Jul 14, 2025
@soypat soypat restored the regmap-package branch July 14, 2025 14:17
@deadprogram deadprogram deleted the regmap-package branch September 14, 2025 12:12
deadprogram added a commit that referenced this pull request Sep 16, 2025
deadprogram added a commit that referenced this pull request Sep 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants