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

Drivers: SPI & I2C config simplifications (2) #14386

Merged
merged 48 commits into from
Mar 18, 2020

Conversation

bkueng
Copy link
Member

@bkueng bkueng commented Mar 13, 2020

Follow-up to #14221.

This converts a large set of the drivers to use the new SPI and I2C board configuration. Mostly missing are mag's and imu's.

General

  • bus frequency and SPI mode is now configurable via CLI (with per-driver defaults)
  • common driver CLI interface
  • driver multi-instance support, also for I2C devices on the same bus (for the ones supporting different addresses). I tested with 2 spd3x airspeed sensors, on different buses and on the same bus with different I2C address.
  • compared to [RFC] Board config: SPI & I2C config simplifications #14156, driver instances are now maintained in a global linked list (saves a bit of BSS RAM, on the cost of runtime).
  • Flash size change is somewhat inconsistent, for some drivers it decreases, for others it increases (mostly due to ifdef'ed I2C code, and more arguments). Overall on v2 ~2KB increase.
  • RAM usage decreases by ~0.6KB on Pixhawk 4
  • I think if we have a general solution for the SPI vs. I2C device interface, we can get rid of the instantiate method.
  • The (SPI) bus will only be accessed from the work queue, allowing to remove the SPI locking after all drivers are converted.

Testing

Tested on:

  • Pixhawk 2
  • RPi with Navio2
  • Pixracer
  • Pixhawk 4
  • KakuteF7

@UAV-Pilot this will conflict with #14168 and I was hoping to get yours in first.

@dagar since you will probably have the fun to review this, let me know if you want to bring this in steps, and which step size you prefer.

Needed to distinguish runtime instance types of the same driver (e.g.
bmi055 accel vs gyro).
@bkueng bkueng requested a review from dagar March 13, 2020 09:35
@bkueng bkueng force-pushed the spi_i2c_config_refactoring_drivers_1 branch 2 times, most recently from 2d2ed7f to ec2d13a Compare March 13, 2020 12:17
To run a specific method on a work queue and wait for it to return.
Use it for custom methods as well (like reset), and run by default on the
work queue, since they typically access the bus.
instead of a static per-driver array.

Reduces BSS RAM usage by a couple of 100 Bytes (linear increase with num
drivers).

Downsides:
- a bit more runtime overhead
- less isolation, locking required
- a bit more complex
Also: remove device type auto-detection as it will not work with
together with the new SPI board config (which specifies a specific
device type)
- there was almost nothing shared
- it will fit better into the updated I2C driver structure
@bkueng bkueng force-pushed the spi_i2c_config_refactoring_drivers_1 branch from ec2d13a to 8d0d015 Compare March 13, 2020 12:57
int custom1{0}; ///< driver-specific custom argument
int custom2{0}; ///< driver-specific custom argument
void *custom_data{nullptr}; ///< driver-specific custom argument

// driver defaults, if not specified via CLI
int default_spi_frequency{20 * 1000 * 1000}; ///< default spi bus frequency [Hz]
Copy link
Member

Choose a reason for hiding this comment

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

1 MHz SPI and 100 kHz I2C might be safer defaults

Copy link
Member

Choose a reason for hiding this comment

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

What is the ripple effect if we inadvertently set lower frequencies without noticing on a bunch of boards? I've been there, done that and people didn't realize it until very late into the investigation. 20 MHz is high, but pretty much any SPI device takes 10 MHz.

Copy link
Member Author

Choose a reason for hiding this comment

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

I was going for what most drivers do, so that we don't have the problems Lorenz mentions.
We can also have no defaults and enforce all drivers to have to set their values.
Any preferences?

Copy link
Member

Choose a reason for hiding this comment

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

At the moment forcing all drivers their value seems appropriate.

These days we have quite a few sensors that operate below 10 MHz. https://docs.google.com/spreadsheets/d/1OUOSr8TDeFwcNdao5b00iQvMUCQIgpeUJf85VwGpIC0/edit#gid=0

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in 45c9899

@dagar dagar requested a review from a team March 17, 2020 16:32
Not a lot of drivers use the global default, which is somewhat arbitrary.
@dannyfpv
Copy link

dannyfpv commented Mar 17, 2020

Tested on pixhawk4 v4 f-450
Indoor Flight

Modes Tested:
Stabilized Mode: Good.
Note:
Slight vibrations noted.

Log:
https://review.px4.io/plot_app?log=d0afe875-a800-4641-a23c-bb08f4ca871c

@Junkim3DR
Copy link

Tested on NXP FMUK66 v3

Indoor test flight.

  • Mode tested in Stabilized

Procedure

  • Takeoff and landing in Stabilized

Note

  • No issue noted.

Log
https://review.px4.io/plot_app?log=bd8c77e4-3e57-41d8-9ca0-8d47b95b3983

@dannyfpv
Copy link

Tested on pixhawk4 mini v5 f-500
Indoor Flight

Modes Tested

Stabilized Mode: Good.
Note
no issues

Log:
https://review.px4.io/plot_app?log=fca7cd10-b00e-4939-8812-23ce674c138f

@dagar
Copy link
Member

dagar commented Mar 18, 2020

Flight logs look good and I did a pass on the test rack and everything is equivalent or better (pixracer internal lis3mdl start was broken in master). Great work on this, let's keep going!

@dagar dagar merged commit d6bb5b3 into master Mar 18, 2020
@dagar dagar deleted the spi_i2c_config_refactoring_drivers_1 branch March 18, 2020 03:31
@mrpollo mrpollo mentioned this pull request Mar 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants