-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
sensor: add TI FDC2X1X sensor driver and sample application #31056
sensor: add TI FDC2X1X sensor driver and sample application #31056
Conversation
360a949
to
f5a66e0
Compare
No, I made the changes to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall really nice work, thank you for contributing!
include/drivers/sensor.h
Outdated
/** Channel 0, raw data */ | ||
SENSOR_CHAN_RAW_CH0, | ||
/** Channel 1, raw data */ | ||
SENSOR_CHAN_RAW_CH1, | ||
/** Channel 2, raw data */ | ||
SENSOR_CHAN_RAW_CH2, | ||
/** Channel 3, raw data */ | ||
SENSOR_CHAN_RAW_CH3, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of adding channels without a type or standard unit. What does the quantity represent?
Sorry; I don't know how I missed that. Thanks. |
ff14a62
to
745b108
Compare
Thank you! |
253690c
to
60340fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts on sensor units. Note that we're now in 2.5 stabilization so this won't get merged until the 2.6 merge window re-opens.
include/drivers/sensor.h
Outdated
/** CH3 Capacitance, in Picofarad **/ | ||
SENSOR_CHAN_CAPACITANCE_CH3, | ||
|
||
/** CH0 Frequency, in MHz **/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure MHz is an ideal unit. Hz would allow for frequencies like 0.5 Hz, i.e. every two seconds; or 0.000012 (a very inaccurate once-per-day).
This would limit the frequency to 2 GHz, though, which might be limiting in some applications. Perhaps a future sensor API could select the best unit based on the value, and return either frequency in Hz or interval in some time unit, depending on which is more accurate.
This could be discussed in the API meeting. Sticking with MHz or even kHz would be a reasonable resolution of such a discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right. Hz would make more sense. I'm not sure if >2GHz would be necessary for sensors, but who knows. Would it be possible to have both units, Hz now and MHz later if needed? This way you could use Hz for <2GHz and MHz for values above. Also I agree with your other suggestion. Having the flexibility to get the value returned in the most accurate unit would be really nice.
I will wait for the resolution of the API meeting though and then change it based on that. Could you give me an update on the resolution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about converting these sensor channel enums to be private to the FDC2X1X driver instead? Similar to how it is done for the MCUX ACMP sensor driver in
zephyr/include/drivers/sensor/mcux_acmp.h
Line 21 in f71cd2a
enum sensor_channel_mcux_acmp { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API meeting 26th Jan 2021:
Moving the enums to the driver-specific header is the concluded best approach for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you both for your suggestion! I moved the channel enums to the driver-specific header now
drivers/sensor/fdc2x1x/fdc2x1x.c
Outdated
}; \ | ||
\ | ||
static const struct fdc2x1x_config fdc2x1x_config_##n = { \ | ||
.i2c_name = DT_INST_BUS_LABEL(n), \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi again. I just see one more round of churn before this PR LGTM from a driver model perspective.
We are making changes to the way that sensor devices access their buses for Zephyr 2.6. These mean that getting them by name using device_get_binding is discouraged.
You should now store the device directly in the configuration structure in ROM by moving these fields to struct fdc2x1x_config
from struct fdc2x1x_data
:
const struct device *bus;
const struct device *gpio;
These should now be initialized using DEVICE_DT_GET
. For example, .bus = DEVICE_DT_GET(DT_INST_BUS(n))
.
You should then check the device in the init routine using device_is_ready
.
Finally, fields like i2c_name
which exist only to store devicetree label properties should be removed. You can use bus->name
instead if you need a name.
For an example, see the drivers/led/led_pwm.c changes in #32558.
Thanks for your patience!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi. I addressed your comments. The bus and gpio devices are now initialized with DEVICE_DT_GET
and checked with device_is_ready
. I also removed the i2c_name
and both gpio labels.
27324d2
to
3bbf94a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Sorry for the delay.
@skullbox305 could you please rebase? |
Adds support for the Texas Instruments FDC2X1X Capacitance-to-Digital Converter for Proximity and Level Sensing Applications. Signed-off-by: Igor Knippenberg <igor.knippenberg@gmail.com>
This sample application periodically reads raw data from the FDC2X1X sensor in polling mode or optionally with data ready trigger. It is able to read the 12-Bit and 28-Bit, as well as the 2-Channel and 4-Channel versions (FDC2112, FDC2114, FDC2212, FDC2214). The 4-channel versions are chosen through devicetree properties. The default is FDC2112. Signed-off-by: Igor Knippenberg <igor.knippenberg@gmail.com>
@mbolivar-nordic Not a problem. Thank you and the others for the review! It was really helpful |
This patch adds support for the Texas Instruments FDC2X1X Capacitance-to-Digital Converter for Proximity and Level Sensing Applications.
Along with the driver, a sample sensor application is provided which tests the device driver.
Signed-off-by: Igor Knippenberg igor.knippenberg@gmail.com