Pin speed control

[ua1arn]

Description

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

targets: STM32xxx based configs

Hello.
Have you any plans to add pin speed control to STM_PIN_DEFINE, STM_PIN_DEFINE_EXT or add new macro. Also need something like
uint32_t speed = STM_PIN_SPEED(data); in pin_function and using speed code for call LL_GPIO_SetPinSpeed with user-selected speed code;
Existing

#if defined (LL_GPIO_SPEED_FREQ_VERY_HIGH)
        LL_GPIO_SetPinSpeed(gpio, ll_pin, LL_GPIO_SPEED_FREQ_VERY_HIGH);
#else
        LL_GPIO_SetPinSpeed(gpio, ll_pin, LL_GPIO_SPEED_FREQ_HIGH);
#endif

may be used in ‘default’ case of selected speed for backward compatibility.

Sample of modified files shown in https://forums.mbed.com/t/pin-speed-control/5528

[0xc0170]

cc @ARMmbed/team-st-mcd

[LMESTM]

What is the final objective that you want to achieve ?

Rather than adding defines at TARGET_STM level, shouldn't we add a new pin control interface similar to the pull-up/down control one here:
https://github.com/ARMmbed/mbed-os/blob/master/drivers/DigitalInOut.h#L96
?
Maybe speed(PinSpeed speed) where speed could scale from 1 to 10 and be mapped to STM modes ? then you could control this settings from your app

[ua1arn]

Reasons for adding defines at TARGET_STM level:
Pins with limited (and different grade of limit) speed used deeply in initialization code with no hooks to modify, except the customized PeripheralPins.c file.
For example, in this file I can adjust pin parameters for solve specific needs (EMC levels).
Also. FMC (SDRAM connected) or USB pins still use TARGET_STM macros.

Please do not add ten-level grade with unpredictable (and version-dependent) mapping.
In target-sticked applications ("only specific CPU without any migration") this is a increase nervous only feature.

Initially, this enhancement born after silent changes default speed from LL_GPIO_SPEED_FREQ_HIGH to LL_GPIO_SPEED_FREQ_VERY_HIGH - and fail EMC test.

[LMESTM]

Ok, thanks for the details, I wasn't even aware this would impact on EMC tests. We were using the highest freq by default.

Modifying the PeripheralPins.c seems like a huge effort to deploy it widely. An alternative is to revert the change that caused you regression and EMC issue and switch back to default LL_GPIO_SetPinSpeed(gpio, ll_pin, LL_GPIO_SPEED_FREQ_HIGH);
and take more time to introduce a configuration mechanism...

Would that help in short term ?

[ua1arn]

Yes, this method already used,
But, detailed controlling (lowest for serial ports and static control interfaces, medium for SDRAM strobes and high for SDRAM clocks) is expected set of control knobs.

Already existing PeripheralPins.c should be leave untouched. Default implementation of pin definitions must provide HIGH or VERY_HIGH programmed speed.

[LMESTM]

I just had a quick look at your sample code - would you mind sharing it as a Pull request which would make it easier to review and might be accepted quicker.
As I understand it, the code you propose would be backward compatible and so you may only update the few targets (possibly only your target ?) and the few peripherals that really need a specific speed setting, right ?

[ua1arn]

Yes, backward compatibility guarantied.
At push commit time I got (expected) error:

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks push -v --tags --set-upstream origin PIN_speed_control:PIN_speed_control
remote: Permission to ARMmbed/mbed-os.git denied to ua1arn.
fatal: unable to access 'https://github.com/ARMmbed/mbed-os/': The requested URL returned error: 403

Pushing to https://github.com/ARMmbed/mbed-os


Completed with errors, see above.

TARGET_STM.zip

[LMESTM]

You'd need to create a fork of mbed-os repo to your ua1arn github account (fork button in github), add this new repo as a remote to your local development repo (git remote add myfork https://github.com/ua1arn /mbed-os.git) then push to "myfork" repo. From there you'll trig a pull request to mbed-os as described here:
https://help.github.com/en/articles/creating-a-pull-request-from-a-fork

[ua1arn]

Modified files atrtached.
TARGET_STM.zip

[LMESTM]

Modified files atrtached.

Pull requests really makes review easier and will keep your name on the changes :-)
I think it's worth a try - see the explanations

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1695