• State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 25 subscribers
  • Views 210 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289183
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I2C, I must be stupid.

user114729

Am I the only one who finds Zephyrs I2C implementation a little cludgy? Or am I just missing something?

It may be that I'm just used to bare metal I2C but I can't seem to figure out how I can send a few bytes, followed by 512 zero's without allocating a 514 byte array?

What I'm looking for is and i2c_write() that I can tell not to send an I2C_MSG_STOP....

Or am I just looking at it the wrong way?

Thanks folks, I promise I'm working hard to get past the dumb questions.

Parents
  • 0

    In my view, and yours may vary, an API that provides high level abstraction is better if it also provides some lower level functionality. Mainly because it's never possible to envision every use case.

    I get the impression that i2c_transfer() is intended for this purpose, it has some flexibility.  If it had something like I2C_MSG_RAWBYTES as a flags option, that would just send the buffer on the bus without a start bit or address, then that would allow for just about any scenario, including mine.


    In this case, I'm clearing a small OLED screen and my workaround/compromise was to define a buffer with enough data to clear one line, then iterate. There's a performance hit, but you don't notice it.

Reply
  • 0

    In my view, and yours may vary, an API that provides high level abstraction is better if it also provides some lower level functionality. Mainly because it's never possible to envision every use case.

    I get the impression that i2c_transfer() is intended for this purpose, it has some flexibility.  If it had something like I2C_MSG_RAWBYTES as a flags option, that would just send the buffer on the bus without a start bit or address, then that would allow for just about any scenario, including mine.


    In this case, I'm clearing a small OLED screen and my workaround/compromise was to define a buffer with enough data to clear one line, then iterate. There's a performance hit, but you don't notice it.

Children
No Data
Related
Terms of service