Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin speed control #11362

Closed
ua1arn opened this issue Aug 28, 2019 · 13 comments
Closed

Pin speed control #11362

ua1arn opened this issue Aug 28, 2019 · 13 comments

Comments

@ua1arn
Copy link

ua1arn commented Aug 28, 2019

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
Copy link
Contributor

0xc0170 commented Aug 28, 2019

cc @ARMmbed/team-st-mcd

@LMESTM
Copy link
Contributor

LMESTM commented Aug 28, 2019

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
Copy link
Author

ua1arn commented Aug 28, 2019

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
Copy link
Contributor

LMESTM commented Aug 28, 2019

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
Copy link
Author

ua1arn commented Aug 28, 2019

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
Copy link
Contributor

LMESTM commented Aug 28, 2019

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
Copy link
Author

ua1arn commented Aug 28, 2019

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
Copy link
Contributor

LMESTM commented Aug 28, 2019

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
Copy link
Author

ua1arn commented Aug 28, 2019

Modified files atrtached.
TARGET_STM.zip

@LMESTM
Copy link
Contributor

LMESTM commented Aug 28, 2019

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
Copy link
Member

ciarmcom commented Sep 3, 2019

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

@ua1arn

This comment has been minimized.

@jeromecoutant
Copy link
Collaborator

Hi
Could we close this issue as #11368 is merged?
Thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants