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

cpu/nrf52 i2c: Always buffer writes #20298

Merged
merged 2 commits into from
Jan 25, 2024

Conversation

chrysn
Copy link
Member

@chrysn chrysn commented Jan 25, 2024

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

  • To see that the old behavior works, run the saul demo on a microbit-v2, or any other board's I2C.
  • To see that things work even from flash, run the saul demo on a microbit-v2 with my lsm303agr-0.3 branch -- that updated the driver such that it can send its commands from ROM, which broke things here.

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.
@chrysn chrysn marked this pull request as ready for review January 25, 2024 14:31
@chrysn chrysn requested a review from aabadie as a code owner January 25, 2024 14:31
@github-actions github-actions bot added Platform: ARM Platform: This PR/issue effects ARM-based platforms Area: cpu Area: CPU/MCU ports labels Jan 25, 2024
@chrysn chrysn added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed Platform: ARM Platform: This PR/issue effects ARM-based platforms labels Jan 25, 2024
@chrysn chrysn requested review from maribu and dylad January 25, 2024 14:34
@riot-ci
Copy link

riot-ci commented Jan 25, 2024

Murdock results

✔️ PASSED

52a976e cpu/nrf52 i2c: Add shortcut when data is in RAM

Success Failures Total Runtime
8628 0 8629 11m:09s

Artifacts

@github-actions github-actions bot added the Platform: ARM Platform: This PR/issue effects ARM-based platforms label Jan 25, 2024
@chrysn chrysn added this pull request to the merge queue Jan 25, 2024
@maribu
Copy link
Member

maribu commented Jan 25, 2024

The branch name is quite confusing :D

@chrysn
Copy link
Member Author

chrysn commented Jan 25, 2024

If that's confusing than please don't look at #20299, which is nrf52-spi-bugs-2. Maybe it's a biotech thing: Genes are named after the property an organism has when you knock out the gene, so here the branch is named after the property that is removed from RIOT when it is applied :-)

Merged via the queue into RIOT-OS:master with commit 1073df2 Jan 25, 2024
27 checks passed
@@ -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) {
Copy link
Contributor

@kaspar030 kaspar030 Jan 25, 2024

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?

Copy link
Contributor

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

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: cpu Area: CPU/MCU ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants