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/stm32/periph/i2c: export PERIPH_I2C_MAX_BYTES_PER_FRAME #19279

Merged
merged 1 commit into from
Feb 14, 2023

Conversation

fabian18
Copy link
Contributor

Contribution description

This exports the previously internally defined MAX_BYTES_PER_FRAME in cpu/stm32/periph/i2c_1.c.
If such a limit exists, a driver must know about it.

Testing procedure

CI

Issues/PRs references

The problem came up in #19270.

@github-actions github-actions bot added Area: cpu Area: CPU/MCU ports Platform: ARM Platform: This PR/issue effects ARM-based platforms labels Feb 14, 2023
@fabian18
Copy link
Contributor Author

Maybe someone remembers why this is not the case for i2c_2.c?

@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 14, 2023
@benpicco
Copy link
Contributor

It uses length when generating the start condition

start(i2c, (addr << 1) | (length << I2C_CR2_NBYTES_Pos) | cr2_flags, flags);

so this must be some sort of hardware limitation.

@fabian18
Copy link
Contributor Author

I have seen this too but I2C_CR2_NBYTES_Msk is defined by (almost) every stm32 so I don´t know why this limit exists for only a few of them

@fabian18
Copy link
Contributor Author

Maybe @aabadie knows why this limit exists?

@HendrikVE
Copy link
Contributor

Why not putting it to the corresponding periph_cpu.h files? BTW I'm wondering: Is BYTES_PER_FRAME really the correct wording for this in I2C terminology?

@riot-ci
Copy link

riot-ci commented Feb 14, 2023

Murdock results

✔️ PASSED

26363e9 cpu/stm32/periph/i2c_1: export PERIPH_I2C_MAX_BYTES_PER_FRAME

Success Failures Total Runtime
6865 0 6865 16m:30s

Artifacts

@benpicco
Copy link
Contributor

bors merge

@fabian18
Copy link
Contributor Author

I have seen this too but I2C_CR2_NBYTES_Msk is defined by (almost) every stm32 so I don´t know why this limit exists for only a few of them

Nevermind its exactly those as in the Makefile and stm32h7

@fabian18
Copy link
Contributor Author

Why not putting it to the corresponding periph_cpu.h files?

It would be more lines of change, and it seems to be equal for all according to the current code

BTW I'm wondering: Is BYTES_PER_FRAME really the correct wording for this in I2C terminology?

At least it is what was there before. What would be better?

@HendrikVE
Copy link
Contributor

At least it is what was there before. What would be better?

To be honest I don't know^^ But I thought we are requesting multiple frames and not a single big one. But I really don't know I2C internals so I can't give a proposal on that

@bors
Copy link
Contributor

bors bot commented Feb 14, 2023

Build succeeded:

@bors bors bot merged commit 1472a76 into RIOT-OS:master Feb 14, 2023
@MrKevinWeiss MrKevinWeiss added this to the Release 2023.04 milestone Apr 25, 2023
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants