stm32 comparator

[KozhinovAlexander]

Add stm32 comparator driver and simple comparator sample.

I've used to test it on nucleo_h745zi_q (m7 core only).

Build command with newly added sample:

west build -p auto -d samples/drivers/comparator/build -b nucleo_h745zi_q/stm32h745xx/m7 samples/drivers/comparator  -DDTC_OVERLAY_FILE=samples/drivers/comparator/boards/st/nucleo_h745zi_q.overlay  

My build result output:

-- Zephyr version: 4.0.99 (...../zephyr), build: v4.0.0-4417-g2c7031229fe0
[153/153] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       31316 B         1 MB      2.99%
             RAM:        6848 B       512 KB      1.31%
          EXTMEM:          0 GB       256 MB      0.00%
           SRAM1:          0 GB       128 KB      0.00%
           SRAM2:          0 GB       128 KB      0.00%
           SRAM3:         16 KB        32 KB     50.00%
           SRAM4:          0 GB        64 KB      0.00%
            DTCM:          0 GB       128 KB      0.00%
        IDT_LIST:          0 GB        32 KB      0.00%

The resulting output in the console could look like:

*** Booting Zephyr OS build v4.0.0-4417-g2c7031229fe0 ***
- comp_trigger_cb: comparator@5800380c output: 0
- comparator@5800380c output: 0
- comparator@5800380c output: 0
- comparator@5800380c output: 0
- comp_trigger_cb: comparator@5800380c output: 1
- comparator@5800380c output: 1
- comparator@5800380c output: 1
- comparator@5800380c output: 1
- comp_trigger_cb: comparator@5800380c output: 0
- comparator@5800380c output: 0
- comparator@5800380c output: 0
- comparator@5800380c output: 0
- comp_trigger_cb: comparator@5800380c output: 1
- comparator@5800380c output: 1
- comparator@5800380c output: 1
- comparator@5800380c output: 1

NOTE: To see the output value changing and comp_trigger_cb called the pins PB0 and PB2 shall be connected physically on the nucleo_h745zi_q board. Please consider the overlay file in the sample to find more about pinouts used.

I've not tested the driver with any other stm32, but I am planning to add support for stm32g4 soon.
Any testers with appropriate board (any stm32h7 would be fine as a good first choice) are very welcome.

[jilaypandya]

sort alphabetically

[KozhinovAlexander]

done

[jilaypandya]

here as well

[KozhinovAlexander]

done

[bjarki-andreasen]

The driver looks good :) The sample is not needed I believe. The test suite in tests/drivers/comparator/gpio_loopback validates the API behavior with a GPIO connected to the comp input. The build all test suite allows you to build varoius dt configurations tests/drivers/build_all/comparator, and lastly, given the nature of a comparator, just enabling the comparator shell in a blank application is sample enough :)

Please add the comp to the two test suites to validate and build the driver in CI

[KozhinovAlexander]

Thank you for your review.

The driver looks good :) The sample is not needed I believe. The test suite in tests/drivers/comparator/gpio_loopback validates the API behavior with a GPIO connected to the comp input. The build all test suite allows you to build varoius dt configurations tests/drivers/build_all/comparator, and lastly, given the nature of a comparator, just enabling the comparator shell in a blank application is sample enough :)

Makes sense. I have few questions just for my understanding:

• Is there also any HW or only twister, where tests are running?

• Will test-suite test the stm32 driver too?

Please add the comp to the two test suites to validate and build the driver in CI

Will do of course. Thanks.

Regarding comparator sample: I think - the major advantage of the sample is to give a very basic example coupled with physical functionality. Especially in my experience samples allow very fast peripheral testing on new hardware, device-tree problem findings with new BSP.
Additionally all the zephyr samples give west build command for an arbitrary sample. People learn it faster, than running twister, I would assume. Thus it is always faster for them to go with sample than with test.
Of course we may discuss it in a separate PR for sample. For the sake of simplicity I will drop the sample in this PR.

[bjarki-andreasen]

Thank you for your review.

The driver looks good :) The sample is not needed I believe. The test suite in tests/drivers/comparator/gpio_loopback validates the API behavior with a GPIO connected to the comp input. The build all test suite allows you to build varoius dt configurations tests/drivers/build_all/comparator, and lastly, given the nature of a comparator, just enabling the comparator shell in a blank application is sample enough :)

Makes sense. I have few questions just for my understanding:

* Is there also any HW or only twister, where tests are running?

* Will test-suite test the stm32 driver too?

Many vendors, including STM I believe, run twister tests on hardware in their own CI, zephyr only runs emulated platforms in CI. That's why we specify fixtures in the zephyr test suites, like gpio_loopback, to specify what hardware they can run on :) That's why the gpio_loopback comparator test was created, its widely supported by upstream boards (and simple to set up locally of course)

I don't know exactly what their gpio_loopback looks like, or if they test the board you use in this PR, maybe @FRASTM knows more?

Please add the comp to the two test suites to validate and build the driver in CI

Will do of course. Thanks.

Regarding comparator sample: I think - the major advantage of the sample is to give a very basic example coupled with physical functionality. Especially in my experience samples allow very fast peripheral testing on new hardware, device-tree problem findings with new BSP. Additionally all the zephyr samples give west build command for an arbitrary sample. People learn it faster, than running twister, I would assume. Thus it is always faster for them to go with sample than with test. Of course we may discuss it in a separate PR for sample. For the sake of simplicity I will drop the sample in this PR.

Tests don't require twister to run, they are just normal applications with a nice framework to set up cases without needing a bunch of printk() everywhere.

Simply west build -p -b nucleo_h745zi_q zephyr/tests/drivers/comparator/gpio_loopback and flash it (after you add the board overlay for it in the test suite of course). So, its just as fast as the sample, but about 90% less duplication :)

The reason I favor the shell above a "fixed" scenario like the sample in this PR, is that actually playing around with a comparator usually requires some external signal generator to generate a voltage or an edge, the GPIO case only shows that the API "works", not that the comparator is actually measuring and behaving correctly. That is quick to see using the shell to test "real" varying signals.