Throw exception for illegal tx gpio ports in RMT tx channel

[MrCSharp22]

Description

• ESP32 legacy RMT driver does not allow using ports 34 to 39 as TX channel ports.
• This change adds a validation rule in the managed library to throw an ArgumentOutOfRangeException as it is clearer than CLR_E_DRIVER_NOT_REGISTERED error from the native lib.

Motivation and Context

• Fixes Issues with RMT TransmitterChannel and ReceiverChannel Home#1686

How Has This Been Tested?

Tested by creating a sample RMT nf app and testing TX channels configured with illegal ports and observing the exception being thrown as expected.

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
• I have added new tests to cover my changes.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (2)

• README.md is excluded by !**/*.md and included by none
• nanoFramework.Hardware.Esp32.Rmt/TransmitChannelSettings.cs is excluded by none and included by none

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[josesimoes]

1. Shouldn't these be referred as pins, instead of ports?
2. are these valid for all ESP32 series?

[MrCSharp22]

1. Absolutely! Sorry about that.. been doing a lot of web dev and networking-related stuff for a while now 😁
2. I based this on what I read in the RMT legacy driver code. Essentially rmt_config(..) calls rmt_set_gpio(..) which performs the following validation:

ESP_RETURN_ON_FALSE(((GPIO_IS_VALID_GPIO(gpio_num) && (mode == RMT_MODE_RX)) ||
                         (GPIO_IS_VALID_OUTPUT_GPIO(gpio_num) && (mode == RMT_MODE_TX))), ESP_ERR_INVALID_ARG, TAG, RMT_GPIO_ERROR_STR);

The GPIO_IS_VALID_OUTPUT_GPIO macro is used to make sure the pins are not 34-39:

/// Check whether it can be a valid GPIO number of output mode
#define GPIO_IS_VALID_OUTPUT_GPIO(gpio_num) ((gpio_num >= 0) && \
                                              (((1ULL << (gpio_num)) & SOC_GPIO_VALID_OUTPUT_GPIO_MASK) != 0))

There aren't any compiler directive around this validation code which tells me it is applicable to all ESP32 boards. However, The RMT docs on the Espressif website for IDF version 4.4.6 makes no specific mention of this.

[josesimoes]

Please note that we're currently at IDF v5.4. Not sure if that makes any difference in the API/docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AdrianSoundy]

You can't use any hard coded pin numbers to test for a pin that doesn't support output as these won't be correct for other ESP32 series chips.
You need to use the macro GPIO_IS_VALID_OUTPUT_GPIO to make sure correct test is done for the target chip, ESP32_S3, ESP32_C6 etc

i.e.

if (!GPIO_IS_VALID_OUTPUT_GPIO(pin)) 

[MrCSharp22]

You can't use any hard coded pin numbers to test for a pin that doesn't support output as these won't be correct for other ESP32 series chips. You need to use the macro GPIO_IS_VALID_OUTPUT_GPIO to make sure correct test is done for the target chip, ESP32_S3, ESP32_C6 etc

i.e.

if (!GPIO_IS_VALID_OUTPUT_GPIO(pin)) 

Thanks @AdrianSoundy. I suppose then we introduce a new method on the native RMT lib to perform this check and have the managed lib use it and throw an exception accordingly. Would you prefer that or do you have another approach in mind?

[AdrianSoundy]

The test would need to be done in the native code part.

[MrCSharp22]

Thank @AdrianSoundy for the clarification. I am closing this PR now and will submit a new one based on your feedback.