Skip to content

drivers: sensor: microchip: mtch9010 Added MTCH9010 Device Support #91812

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

robertperkel
Copy link
Contributor

Added new driver for MTCH9010 liquid leak detector along with test patterns.

@robertperkel
Copy link
Contributor Author

If possible, could we add this for v4.2

Comment on lines 724 to 726
#define MTCH9010_OPERATING_MODE_INIT(inst) \
COND_CODE_1(DT_INST_ENUM_HAS_VALUE(inst, mtch9010_operating_mode,\
capacitive), (MTCH9010_CONDUCTIVE), (MTCH9010_CAPACITIVE))
Copy link
Contributor

Choose a reason for hiding this comment

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

unless i'm mistaken:

Suggested change
#define MTCH9010_OPERATING_MODE_INIT(inst) \
COND_CODE_1(DT_INST_ENUM_HAS_VALUE(inst, mtch9010_operating_mode,\
capacitive), (MTCH9010_CONDUCTIVE), (MTCH9010_CAPACITIVE))
#define MTCH9010_OPERATING_MODE_INIT(inst) \
COND_CODE_1(DT_INST_ENUM_HAS_VALUE(inst, mtch9010_operating_mode,\
capacitive), (MTCH9010_CAPACITIVE), (MTCH9010_CONDUCTIVE))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I seem to remember a test error before I swapped it ... I'll look at it again

Comment on lines 338 to 340
gpio_pin_set_dt(&config->enableUARTLine, GPIO_OUTPUT_LOW);
} else {
gpio_pin_set_dt(&config->enableUARTLine, GPIO_OUTPUT_HIGH);
Copy link
Contributor

Choose a reason for hiding this comment

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

copy-paste error from previous block

Copy link
Contributor Author

@robertperkel robertperkel Jun 18, 2025

Choose a reason for hiding this comment

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

Ah, I see. UART EN is active LOW. Clarified intention in comments

Copy link
Contributor

Choose a reason for hiding this comment

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

no the issue is basically the same thing @msalau commented on. You want to be controlling enableCFGLine here, not enableUARTLine??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks - I think I see the issue now

{
/* Note: nRESET is handled in device reset function */
int rtn = 0;

Copy link
Contributor

Choose a reason for hiding this comment

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

you're missing gpio_pin_configure_dt steps for the enableUARTLine and enableCFGLine output pins

{
int ret = 0;
const struct mtch9010_config_t *config = dev->config;
struct mtch9010_data_t *devData = dev->data;
Copy link
Contributor

Choose a reason for hiding this comment

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

val->val1 = data->heartbeatErrorState;
break;
}
default: {
Copy link
Contributor

Choose a reason for hiding this comment

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

you're missing SENSOR_CHAN_MTCH9010_MEAS_RESULT_AND_DELTA case?

.reference = MTCH9010_REF_VAL_INIT(inst), \
.threshold = DT_INST_PROP(inst, mtch9010_detect_value), \
.heartbeatErrorState = false, \
.lastResult = {0, 0}}; \
Copy link
Contributor

Choose a reason for hiding this comment

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

lastWake also needs to be initialized to zero to not have issues w/ first sample reading

mtch9010_command_send(uartDev, config, tBuffer);

#ifdef CONFIG_MTCH9010_LOCK_ON_STARTUP
mtch9010_lock_device(dev);
Copy link
Contributor

Choose a reason for hiding this comment

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

undeclared function? did you mean mtch9010_lock_settings?

Comment on lines 358 to 359
/* Keep LOW until ready to configure */
gpio_pin_configure_dt(&config->lockLine, GPIO_OUTPUT | GPIO_OUTPUT_INIT_HIGH);
Copy link
Contributor

Choose a reason for hiding this comment

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

comment doesn't match the code

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comment is incorrect - fixed

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch 3 times, most recently from cf24bb0 to e4ac4a3 Compare June 19, 2025 04:08
@robertperkel robertperkel requested a review from kartben June 19, 2025 04:15
@robertperkel
Copy link
Contributor Author

@kartben I'm looking at the twister failures, and it doesn't seem related to my PR, as I don't utilize with the file system. Can you confirm or rerun/ignore that twister error?

@robertperkel robertperkel requested a review from msalau June 19, 2025 04:16
@kartben
Copy link
Contributor

kartben commented Jun 19, 2025

@kartben I'm looking at the twister failures, and it doesn't seem related to my PR, as I don't utilize with the file system. Can you confirm or rerun/ignore that twister error?

yep, had nothing to do with you, and fixed now :)

data->last_heartbeat = k_uptime_get();

/* Wait for boot-up */
k_msleep(CONFIG_MTCH9010_BOOT_TIME_MS);
Copy link
Contributor

Choose a reason for hiding this comment

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

Just highlighting that this will delay boot up process for all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately, things stop working when I remove this delay. I have some theories, but for now, I'd like to keep this.

LOG_INST_DBG(config->log, "UART setup not enabled");

#ifdef CONFIG_MTCH9010_LOCK_ON_STARTUP
BUILD_ASSERT(true, "MTCH9010_LOCK_ON_STARTUP cannot be set without UART enabled");
Copy link
Contributor

Choose a reason for hiding this comment

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

Location of this BUILD_ASSERT() is somewhat strange to me. It is not a part of the initialization routine. I think it should be closer to MTCH9010_DEFINE() and be checked at build time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved assertion to define section 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not resolve comments. This is for the reviewers to do

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My bad - thanks for letting me know

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The BUILD_ASSERT keeps causing issues, and since this is an optional feature anyway, I've removed the BUILD_ASSERT.

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch 3 times, most recently from 511c14e to 3b46797 Compare June 19, 2025 19:17
@robertperkel robertperkel requested a review from msalau June 19, 2025 19:50
@robertperkel
Copy link
Contributor Author

Looks like everything is good to go on our side 👍 Local test bench is functioning as expected

@robertperkel
Copy link
Contributor Author

Hi @msalau @kartben ,
Since the feature freeze date for v4.2 is this Friday, could you let me know any remaining changes and/or approve the PR?

Additionally - do I need to notify anyone of this for v4.2, or is it automatic?

Thanks for your feedback!
Robert

@kartben kartben added this to the v4.2.0 milestone Jun 23, 2025
@kartben
Copy link
Contributor

kartben commented Jun 23, 2025

Hi @msalau @kartben , Since the feature freeze date for v4.2 is this Friday, could you let me know any remaining changes and/or approve the PR?

Additionally - do I need to notify anyone of this for v4.2, or is it automatic?

Thanks for your feedback! Robert

I am marking it as tentative for 4.2 but my guess is that it will be tight as it is quite a significant PR and it will take time for reviewers to go through it. Thanks!

@robertperkel
Copy link
Contributor Author

Fixed double interrupt setup
Missing mode configure
Found missing case in decode, patched with error code if triggered.

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch from ba2ea80 to 8c97c6d Compare June 24, 2025 04:40
@robertperkel
Copy link
Contributor Author

Removed BUILD_ASSERT due to persistent issues with logic. (System Lock does not affect core functionality - is optional)

@robertperkel robertperkel requested a review from msalau June 24, 2025 05:36
@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch from 8c97c6d to 2eeef0d Compare June 24, 2025 07:13
@robertperkel
Copy link
Contributor Author

Fixed missing binding in yaml file

@robertperkel
Copy link
Contributor Author

Just for clarification - the single SonarQube issue (init complexity > 25) is not a blocker, correct? I can try to rework init down to <25, but I think it would be pretty tricky.

@msalau
Copy link
Contributor

msalau commented Jun 24, 2025

@robertperkel

Is UART mandatory for this driver?

If mandatory: UART check should not be optional during initialization. Also asserting the UART configuration at build time may be a good idea. I.e. checking that speed is 38400, parity is None and 8 bits mode.

If optional: A separate binding is needed to not require an UART bus.

@robertperkel
Copy link
Contributor Author

robertperkel commented Jun 24, 2025

@robertperkel

Is UART mandatory for this driver?

If mandatory: UART check should not be optional during initialization. Also asserting the UART configuration at build time may be a good idea. I.e. checking that speed is 38400, parity is None and 8 bits mode.

If optional: A separate binding is needed to not require an UART bus.

Technically the answer is no, but I think practically speaking, it would be unusual for someone to use this driver and not have a UART bus. Do you think I should require the UART bus for now? If you're not using the UART, it's very easy to emulate using basic drivers.

Edit: Decided to make it required for this driver.

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch from 2eeef0d to 209abb7 Compare June 24, 2025 16:52
@robertperkel
Copy link
Contributor Author

Added __ASSERT Validation of UART Parameters to Init function
Made UART Mandatory

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch from 209abb7 to adbeaf3 Compare June 24, 2025 17:49
Copy link

@robertperkel robertperkel requested a review from kartben June 26, 2025 17:42
@robertperkel
Copy link
Contributor Author

@kartben @msalau
Any other changes to make to this PR?

@robertperkel
Copy link
Contributor Author

Also, should this be retagged to v4.3.0 milestone, or is v4.2.0 still open?

@kartben
Copy link
Contributor

kartben commented Jun 30, 2025

Also, should this be retagged to v4.3.0 milestone, or is v4.2.0 still open?

Yes, unfortunately this missed the deadline for the 4.2 release as feature freeze was last Friday. Getting a brand new 2000-line PR reviewed in just 10 short days right as everyone was wrapping up their own contributions was probably a bit ambitious unfortunately. Hope you understand!

@kartben kartben modified the milestones: v4.2.0, v4.3.0 Jun 30, 2025
@robertperkel
Copy link
Contributor Author

Just to check - until v4.2 is released (7/18), merging is blocked, correct?

@kartben
Copy link
Contributor

kartben commented Jul 14, 2025

Just to check - until v4.2 is released (7/18), merging is blocked, correct?

Correct. Everything goes into main branch so until vN is released, vN+1 features are queuing up :)

@kartben kartben dismissed their stale review July 21, 2025 20:21

comments have been addressed

@robertperkel
Copy link
Contributor Author

robertperkel commented Jul 21, 2025

Since 4.2 has released, can the reviewers take a look at this when they get a moment?

We're planning a follow-up to this merge with another commit containing a device sample *(in the near future)

}

/* Sensor APIs */
static const struct sensor_driver_api mtch9010_api_funcs = {
Copy link
Member

Choose a reason for hiding this comment

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

Use DEVICE_API

@@ -0,0 +1,16 @@
&uart1 {
Copy link
Member

Choose a reason for hiding this comment

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

overlay files are missing license/copyright headers

status = "okay";
compatible = "microchip,mtch9010";

// Device Configuration
Copy link
Member

Choose a reason for hiding this comment

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

no c99 comments please

Added support for MTCH9010 and applied edits from reviewers.

Signed-off-by: Robert Perkel <[email protected]>
@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch from 0906ad8 to 6b8e278 Compare July 26, 2025 23:52
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants