-
Notifications
You must be signed in to change notification settings - Fork 14.6k
auterion pm: add eeprom-based pm selection #25136
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
Conversation
9eff71a
to
5bfafea
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 864 byte (0.04 %)]
px4_fmu-v6x [Total VM Diff: 864 byte (0.04 %)]
Updated: 2025-08-05T09:29:20 |
5bfafea
to
01923a0
Compare
Rebased to load recent fixes to the SITL tests |
@alexcekay what is the specific eeprom used? I am working on incorporating eeprom at the px4 platform common layer and then also incorporating a "device discovery" module in src/modules that handles the character device conversion using Cdev. If that works you can technically just call "px4_open("/dev/eeprom0", xx)" and abstract a lot of the low level i2c calls away. This is only targeting i2c eeproms for now as I am using this nuttx eeprom i2c driver, and you can use this in combination with Cdev to handle the struct file pointers. I guess this is in contrast to manually doing the i2c transfers, but if it works it works. |
Hi @dirksavage88, I think in general abstraction is a really good idea, just note that we already have the MTD abstraction In this particular case I did not use this abstraction due to the requirement of dynamically detecting EEPROMs that may or may not be present on the Power Module. The MTD abstraction sort of expects that the EEPROM is actually there. |
01923a0
to
e17f272
Compare
e17f272
to
e2e8b12
Compare
79ea004
to
2212448
Compare
Solved Problem
Solution
Changelog Entry
For release notes:
Test coverage