Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2c: Inherent transaction function, lift size limits #2262

Merged
merged 6 commits into from
Oct 4, 2024

Conversation

bjoernQ
Copy link
Contributor

@bjoernQ bjoernQ commented Oct 2, 2024

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

  • I have updated existing examples or added new ones (if applicable).
  • I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
  • My changes were added to the CHANGELOG.md in the proper section.
  • I have added necessary changes to user code to the Migration Guide.
  • My changes are in accordance to the esp-rs API guidelines

Extra:

Pull Request Details 📖

Description

Testing

  • examples still work
  • some testing with a logic analyzer
  • using a VL53L5CX sensor using new inherent transaction function and write/write_read functions

#[cfg(any(esp32, esp32s2))]
const I2C_CHUNK_SIZE: usize = 32;

#[cfg(not(any(esp32, esp32s2)))]
Copy link
Contributor Author

@bjoernQ bjoernQ Oct 2, 2024

Choose a reason for hiding this comment

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

technically not necessary but would be a subtle behavioral change for chips other than ESP32/ESP32-S2 otherwise

// filter out 0 length read operations
let mut op_iter = operations
.iter_mut()
.filter(|op| if op.is_write() { true } else { !op.is_empty() })
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
.filter(|op| if op.is_write() { true } else { !op.is_empty() })
.filter(|op| op.is_write() || !op.is_empty())

esp-hal/src/i2c.rs Show resolved Hide resolved
esp-hal/src/i2c.rs Show resolved Hide resolved
matches!(self, Operation::Read(_))
}

fn write_buffer(&self) -> Option<&'a [u8]> {
Copy link
Contributor

Choose a reason for hiding this comment

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

See above, I'm not too fond of these. They make sense in public code, but these aren't intended to be public as far as I can tell.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

me too - but see above

pub fn transaction<'a>(
&mut self,
address: u8,
operations: &mut [impl I2cOperation<'a>],
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this just take an IntoIterator? This method doesn't seem to need a slice.

Comment on lines +292 to +307
/// Transaction contract:
/// - Before executing the first operation an ST is sent automatically. This
/// is followed by SAD+R/W as appropriate.
/// - Data from adjacent operations of the same type are sent after each
/// other without an SP or SR.
/// - Between adjacent operations of a different type an SR and SAD+R/W is
/// sent.
/// - After executing the last operation an SP is sent automatically.
/// - If the last operation is a `Read` the master does not send an
/// acknowledge for the last byte.
///
/// - `ST` = start condition
/// - `SAD+R/W` = slave address followed by bit 1 to indicate reading or 0
/// to indicate writing
/// - `SR` = repeated start condition
/// - `SP` = stop condition
Copy link
Collaborator

Choose a reason for hiding this comment

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

In future, I hope we can make this contract optional as well and allow users to do this themselves.

I personally need a non e-hal conforming contract for the SCCB protocol.

Copy link
Member

@jessebraham jessebraham left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for this!

@jessebraham jessebraham added this pull request to the merge queue Oct 4, 2024
Merged via the queue into esp-rs:main with commit 00ad9b5 Oct 4, 2024
28 checks passed
@bjoernQ bjoernQ deleted the i2c branch November 26, 2024 08:41
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.

I2C: write, write_read and read are unnecessarily limiting
4 participants