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

[RFC] Make NuttX drivers cross platform (VDev -> CDev) and MS4525 linux driver #7864

Merged
merged 7 commits into from
Aug 31, 2017

Conversation

dagar
Copy link
Member

@dagar dagar commented Aug 24, 2017

On NuttX we have a large collection of well tested device drivers (I2C/SPI/serial) implemented using CDev (nuttx character devices). On non-nuttx posix platforms we have a nearly identical interface called VDev which uses virtual files/devices/ioctls.

If we combine them and instead treat VDev as the platform independent version of CDev we can fairly easily "port" our existing NuttX to the other platforms.

In this PR I've renamed VDev -> CDev and ported the NuttX ms4525 differential pressure sensor driver. I've successfully tested it on a Navio2 Raspberrypi. Porting consisted of removing unnecessary headers, prepending px4_ to ioctl, open, close, and making sure the ms4525 launcher didn't call exit.

I propose we consider this as a path forward for unified cross platform PX4 drivers. My next step is adding a Linux CDev SPI interface, then porting the bulk of the important drivers. I'd like to continue the Driver rearchitecture discussion, but doing so incrementally from CDev. I have another PR that cleanly combines the Device and CDev classes between NuttX and Linux, then each have separate I2C and SPI interfaces.

@davids5 @mcharleb @bgat @LorenzMeier

@TSC21
Copy link
Member

TSC21 commented Aug 24, 2017

@dagar did you see any differences in terms of performance after running top?

@LorenzMeier
Copy link
Member

Awesome! Originally we did bite the bullet on Driverframework as we were hoping for more stacks and verticals / users to join the effort. That never materialized, so it might be time to reconsider.

@dagar dagar self-assigned this Aug 24, 2017
@dagar
Copy link
Member Author

dagar commented Aug 24, 2017

If there's any chance that might matter I don't think it would be that hard to keep the PX4 portion (uORB and params) separate. I'd be fine supporting whichever framework (cross platform CDev descendant or DriverFramework) gets us to unified development effort and driver base as soon as possible.

@davids5
Copy link
Member

davids5 commented Aug 24, 2017

@dagar - This is a great step!

As we discussed: Once we have the SPI done, the API for a "driver runner" can be realized in Cdev and SPI and I2C with a task per bus. Then wrapping the hrt calls to as this->schedule_rt(...) should allow us to pass a config, that the implementations can then provide the best way to get the driver scheduled.
(I.E. DRDY, HRT or delayed) The net result will be either for HRT and DRDY an ISR->sem_post or a sw timer to sem_post. That should give us better realtime response (less interrupt off time) and the ability to do DMA on SPI. At the same time the other platforms can just continue to schedule the cycles as is.

Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

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

Very cool!
One key difference in functionality between CDev and VDev is that NuttX can handle Interrupts. But I only see that being used in the hc_sr04 sonar driver.

@@ -417,7 +400,7 @@ start(int i2c_bus)
int fd;

if (g_dev != nullptr) {
errx(1, "already started");
PX4_ERR("already started");
Copy link
Member

Choose a reason for hiding this comment

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

Be aware that errx exited the task, so exchanging it with PX4_ERR is usually not enough.

Copy link
Member Author

@dagar dagar Aug 25, 2017

Choose a reason for hiding this comment

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

Thanks, I'll take a closer look. One of my goals for the drivers is to remove the boiler plate that's manually duplicated across nearly all of these. Either a Driver ModuleBase or a shared launcher/driver runner.

@bgat
Copy link

bgat commented Aug 25, 2017 via email

@dagar
Copy link
Member Author

dagar commented Aug 25, 2017

Actually I don't think any of these drivers are currently using interrupts. In the hr_sr04 case they set irq to 0.
We might be changing that soon though.

@LorenzMeier
Copy link
Member

@dagar What are the steps required to get this in? Could you advise @PX4TestFlights what and how to test?

@dagar
Copy link
Member Author

dagar commented Aug 27, 2017

This PR is actually quite mundane, with hardly any functional change for existing usage. The new functionality is the nuttx differential pressure sensor drivers now work on linux. Some basic bench testing of a pixhawk setup with an airspeed sensor should be sufficient to ensure there aren't regressions.

The bigger question is if everyone is on board with this direction for unified drivers. There's a lot more detail to go into, but the core of it is merging the driver Device interface with I2C and SPI implementations for each platform. CDev/VDev merge to facilitate this, but that can soon be broken out as a separate optional interface. Then we gradually remove CDev usage from most drivers. Some things will still be CDev where appropriate (each orb topic, the iridiumsbd driver), but the majority of drivers won't need to be.

@mcharleb @davids5 @bgat @LorenzMeier Should we discuss this on a call?

@bgat
Copy link

bgat commented Aug 27, 2017 via email

warnx("\t-b --bus i2cbus (%d)", PX4_I2C_BUS_DEFAULT);
warnx("command:");
warnx("\tstart|stop|reset|test|info");
PX4_INFO("usage: meas_airspeed command [options]");
Copy link
Member

Choose a reason for hiding this comment

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

@dagar Do you think it would be good to establish the new set of "good driver" habits to use the module macros here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes although I'm more interested in doing in centrally (launcher or interface) and then deleting all of this code 😄.
Start with some notes for what you have in mind?

@davids5
Copy link
Member

davids5 commented Aug 28, 2017

@mcharleb @davids5 @bgat @LorenzMeier Should we discuss this on a call?

Yes. Would you like to do it sooner than just after then next dev call?

@LorenzMeier LorenzMeier merged commit fd8a564 into PX4:master Aug 31, 2017
@dagar dagar deleted the pr-cdev_linux_ms4525 branch August 31, 2017 13:32
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.

6 participants