feat(PeriphDrivers)!: Add support for configuring GPIO Drive Strength

[sihyung-maxim]

Description

This PR adds a new configuration option to select the drive strength level for GPIO pins.

Support for GPIO drive strength was not added initially due to the varying drive strength name types, but the latest user guides have been updated with consistent drive strength names across all parts which help for code name stability.

Breaking change due to the new parameter with the mxc_gpio_cfg_t struct and the MXC_GPIO_Config(...) function now sets the drive strength. The new drvstr parameter was added to the struct because this was how the mxc_gpio_cfg_t was originally intended to be when it was first created.

Checklist Before Requesting Review

• PR Title follows correct guidelines.
• Description of changes and all other relevant information.
• (Optional) Link any related GitHub issues using a keyword
• (Optional) Provide info on any relevant functional testing/validation. For API changes or significant features, this is not optional.

[sihyung-maxim]

/clang-format-run

[sihyung-maxim]

/clang-format-run

[Jake-Carter]

The addition of SetDriveStrength is good.

I'm a little concerned about adding the drive strength to the GPIO config struct. Existing code will have the struct member uninitialized. I just tested this and got "16", for example:

The switch statement for MXC_GPIO_RevA_SetDriveStrength is well written, so in this case we initialize with drive strength 0 in the default case handler. But there is a non-zero chance that we hit 0, 1, 2, or 3, which will unexpectedly change the drive strength.

Drive strength is also only relevant in output mode.

I don't want to make you jump out of a window considering the number of files and pin config structs changed here... but I'm in favor of just adding the helper function and leaving the config struct unmodified.

[sihyung-maxim]

The addition of SetDriveStrength is good.

I'm a little concerned about adding the drive strength to the GPIO config struct. Existing code will have the struct member uninitialized. I just tested this and got "16", for example:

The switch statement for MXC_GPIO_RevA_SetDriveStrength is well written, so in this case we initialize with drive strength 0 in the default case handler. But there is a non-zero chance that we hit 0, 1, 2, or 3, which will unexpectedly change the drive strength.

Drive strength is also only relevant in output mode.

I don't want to make you jump out of a window considering the number of files and pin config structs changed here... but I'm in favor of just adding the helper function and leaving the config struct unmodified.

No worries. Adding the new parameter in the mxc_gpio_cfg_t struct was a concern when first making these changes, but I discussed this with Lorne before committing to making all the changes with the cfg structs. This change is not as dangerous compared to adding the .vssel (VDDIO/VDDIOH) parameter to the config struct. The main potential downside is that the current consumption could slightly increase when the drive strength increases from what it originally was if the setting was uninitialized to a non-zero value. However, this should not physically break anything, unlike if we were to add the VDDIO/VDDIOH setting to the config struct.

Note: support for GPIO drive strength was not added initially due to the varying drive strength name types, but the latest user guides have been updated with consistent drive strength names across all parts which helps for code name stability. The new drvstr parameter was added to the struct because this was how the mxc_gpio_cfg_t was originally intended to be when it was first created. It was decided the benefits of having this requested feature as its intended use outweigh the potential downsides.

Good call on the drive strength only being relevant in output mode. I've added a check where this setting is ignored if the pin function is set to input mode. There are alternate functions where this setting is still used though such as the SPI pins for high-speed transactions.