Skip to content

Conversation

@andreacoradi
Copy link

Before this small fix, I2C writes would incorrectly repeat the leading byte of the payload while excluding the last one.
By changing the order of the I2C commands, I was able to correctly write to my I2C device.
While consulting the TRM, I also noticed that calling self.update_config(); was unnecessary in that context.

.length = 1,
} });
}
try self.add_cmd(cmd_start_idx, .{ .write = .{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you understand enough of the esp-idf to have an idea why it was wacky like this? I basically just started with a port without understand fully why it split writes into extra commands

Copy link
Author

@andreacoradi andreacoradi Dec 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So not with esp-idf, but looking at the esp-hal they just do it like this:

            if cfg!(esp32) && !(start || stop) {
            // NOT US
            } else {
                add_cmd(
                    cmd_iterator,
                    Command::Write {
                        ack_exp: Ack::Ack,
                        ack_check_en: true,
                        length: write_len as u8,
                    },
                )?;
            }

And from my testing it works as intended, so I'm not really sure.
Also, TRM just mentions to create one single write command with length N+1 when starting transmission, and length M if it's in-between.
So I would trust that more.

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.

2 participants