Feature/esp pulse cnt

[eren-terzioglu]

Summary

Pulse counter (PCNT) peripheral support added for ESP32, ESP32S2, ESP32S3, ESP32C6, ESP32H2 which is count the number of rising and/or falling edges of input signals. PCNT module can be used in scenarios like:

• Calculate periodic signal's frequency by counting the pulse numbers within a time slice
• Decode quadrature signals into speed and direction

Commits

• esp32[c6|h2]: Add pulse counter support
• esp32[s2|s3]: Add pulse counter support
• esp32[s2|s3]: Add qencoder defconfig
• esp32[h2]: Add qencoder defconfig

Impact

ESP32, ESP32S2, ESP32S3, ESP32C6, ESP32H2

Testing

esp32c6-devkitc:qencoder and other qencoder configs used to test qencoder devices with qe example. Also sample pcnt test used to test pcnt peripheral individually for every chip which supports PCNT(only esp32c3 does not have that peripheral support).

[nuttxpr]

[Experimental Bot, please feedback here]

Fill In The Commit Message: This PR contains a Commit with an Empty Commit Message. Please fill in the Commit Message with the PR Summary.

Yes, this PR appears to meet the NuttX requirements, although some sections could be more detailed. Here's a breakdown:

Strengths:

• Clear Summary: The summary explains the "why," "what," and "how" of the changes. The use cases provided are helpful.
• Impact Section Started: The impact section identifies the affected architectures, which is a good start.
• Testing Information Provided: Testing information is present, mentioning the specific configurations and examples used.

Weaknesses (and suggestions for improvement):

• Missing Issue References: If this PR addresses any specific issues in the NuttX or NuttX Apps repositories, those should be linked in the Summary.
• Incomplete Impact Assessment: The Impact section needs to be significantly expanded. Each of the sub-points (user impact, build impact, hardware impact, documentation, security, compatibility) should have a "YES" or "NO" answer followed by a description even if the answer is NO. For example: "Impact on build (will build process change)? NO (No changes to the build process are required)."
• Insufficient Testing Detail: While testing configurations are mentioned, the provided logs are placeholder text. Actual log output demonstrating the functionality before and after the change is essential. Ideally, these logs should show both successful operation and any error handling. Be specific about the tests performed and the expected results. Quantify the results if possible (e.g., "Frequency measured within 0.1% accuracy").
• Commit Messages Could Be Improved: While functional, the commit messages could be more descriptive. Instead of "Add pulse counter support," consider a message like "Implement PCNT driver for ESP32S2, adding support for pulse counting and quadrature decoding." This provides more context and makes the commit history easier to understand.

Example of a more complete Impact section:

• Is new feature added? YES (Pulse counter peripheral support)
• Impact on user (will user need to adapt to change)? YES (Users can now access the PCNT peripheral through the provided driver interface. New configuration options may be required in their applications and device trees.)
• Impact on build (will build process change)? YES (New Kconfig options will be available to enable the PCNT driver. Users will need to select these options in their defconfigs to use the new functionality.)
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES (New drivers are added specifically for ESP32, ESP32S2, ESP32S3, ESP32C6, and ESP32H2. No changes to existing hardware are required, but new hardware using these features can now be supported.)
• Impact on documentation (is update required / provided)? YES (Documentation updates are required to explain how to use the new PCNT driver, including configuration options and API usage. This documentation has been provided in [location of documentation]).
• Impact on security (any sort of implications)? NO (No known security implications are introduced by this change.)
• Impact on compatibility (backward/forward/interoperability)? NO (This change is backward compatible and does not impact interoperability with other features.)
• Anything else to consider? None.

By addressing these weaknesses, the PR will be much stronger and easier for reviewers to evaluate.

[acassis]

@eren-terzioglu I suggest using Pulse Counter in the text because PCNT acronym is not used by all vendors (although at least Espressif and Silicon Labs use it)

[raiden00pl]

I see that PCNT can count pulses and edges. capture.c can be used to count edges OR freq OR duty (capture low-level ops all are optional). Another option is to add optional CAPIOC_PULSES to capture.c instead of providing another driver with similar functionality.

The question is wheter CAPIOC_EDGES should be added to capture.c at all (9e388d1, #13126).
I agree with this PR that capture and pulse count are different functionalities. One measures events, the other measures time.
If we add a separate driver to count pulses, then CAPIOC_EDGES should be removed from capture.c.

[acassis]

@raiden00pl I agree! Let's include this driver for now and open an issue to extend capture.c to support pulse counter as well.

[eren-terzioglu]

@xiaoxiang781216, Do you have different opinion?

[eren-terzioglu]

Thanks @raiden00pl, updated

[eren-terzioglu]

@xiaoxiang781216, I refactored the code with using capture driver. Fyi

[eren-terzioglu]

Thanks @acassis, updated

[ppisa]

The change seems as total nonsense, please review and correct, @eren-terzioglu, @acassis, @Vajnar

The return value should not be clipped to 16-bits if you compare return to zero at the next line. The logic around counter seems to be totally broken as well. The value has been converted to int16_t in the Martin Vajnar to allow modulo arithmetic. I have open Issue #15319 for more communication and very probable breakages fixup.