-
Notifications
You must be signed in to change notification settings - Fork 2k
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
cpu/nrf52 i2c: Always buffer writes #20298
Conversation
The underlying peripheral can only read from RAM. This uses the existing infrastructure (already needed to work around the lack of a hardware support for I2C_NOSTART) to unconditionally copy any to-be-sent data into RAM.
The branch name is quite confusing :D |
If that's confusing than please don't look at #20299, which is |
@@ -331,6 +339,31 @@ int i2c_read_regs(i2c_t dev, uint16_t addr, uint16_t reg, | |||
|
|||
int i2c_write_bytes(i2c_t dev, uint16_t addr, const void *data, size_t len, | |||
uint8_t flags) | |||
{ | |||
if ((unsigned int)data >= CPU_RAM_BASE && (unsigned int)data < CPU_RAM_BASE + CPU_RAM_SIZE) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is done a bit simpler for spi:
return ((uint32_t)data & RAM_MASK); |
Would that work here, too? Is that too relaxed for SPI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... embassy-nrf does this:
const SRAM_LOWER: usize = 0x2000_0000;
const SRAM_UPPER: usize = 0x3000_0000;
ptr >= SRAM_LOWER && (ptr + len * core::mem::size_of::<T>()) < SRAM_UPPER
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SPI version is probably good enough, we could unify. The embassy version is IMO excessive, as the slice is a single object, and objects don't span memmapping areas.
Contribution description
The underlying peripheral can only read from RAM. This uses the existing infrastructure (already needed to work around the lack of a hardware support for I2C_NOSTART) to unconditionally copy any to-be-sent data into RAM.
There is certainly an alternative where we determine at runtime whether the data is in RAM or in ROM and only lock and copy if it's in ROM, but I'd only do that if we have concrete benchmarks that show that this is an issue.
Testing procedure