I2C, I must be stupid.

RE: I2C, I must be stupid.

user114729 — Wed, 18 May 2022 21:02:15 GMT

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.

RE: I2C, I must be stupid.

user100109 — Wed, 18 May 2022 11:56:59 GMT

[quote user="CASWA_PK"]Good question. It's probably because I've come from a decade (or so) of developing on 8 bit hardware and pulling 513 bytes off the stack seems like a dumb way to solve the problem?[/quote]

I understand. I would recommend you to give it a try and play a little around. If you have specific suggestions on how we can improve our software, you are of course welcome to report them to us :-)

RE: I2C, I must be stupid.

user114729 — Wed, 18 May 2022 11:31:40 GMT

Good question. It's probably because I've come from a decade (or so) of developing on 8 bit hardware and pulling 513 bytes off the stack seems like a dumb way to solve the problem?

RE: I2C, I must be stupid.

user100109 — Wed, 18 May 2022 11:25:26 GMT

[quote user="CASWA_PK"]

What I don't want to do is
uint8_t buffer[513];

It's not clear to me that this is possible? But I may just be looking at it wrong...

[/quote]

Why would you not want to do that? The i2c_write() / i2c_transfer() API is designed to be assigned with a buffer and its size.

Regards,

Markus

RE: I2C, I must be stupid.

user114729 — Wed, 18 May 2022 09:54:50 GMT

OK, I acknowledge that the scope of my question was a bit broad. Lets zoom in on an example:
I want to send

0x40, 0x00, 0x00..... and another 509 of them to i2c address 25 in one transaction.

What I don't want to do is
uint8_t buffer[513];

It's not clear to me that this is possible? But I may just be looking at it wrong...

RE: I2C, I must be stupid.

user100109 — Wed, 18 May 2022 08:36:06 GMT

Hello Paul,

[quote user=""]Am I the only one who finds Zephyrs I2C implementation a little cludgy? Or am I just missing something?[/quote]

Since the Zephyr RTOS contains a lot of functionality, higher complexity is almost given and finding a good entry point can be challenging. So no, you are not stupid. Confused maybe, but I can definitely feel you there :-)

[quote user=""]What I'm looking for is and i2c_write() that I can tell not to send an I2C_MSG_STOP....[/quote]

A good starting point should be the I2C API documentation. If the peripheral to use is configured correctly in the devicetree and enabled via Kconfig, it should pretty much be straight forward to use functions like, i2c_write().

You could also have a look at this example for your reference, demonstrating a simple use case.

Regards,

Markus