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

driver/i2c: STM32: I2C performance issue solved. #14808

Merged

Conversation

affrinpinhero-2356
Copy link
Contributor

@affrinpinhero-2356 affrinpinhero-2356 commented Jun 21, 2021

Summary of changes

This commit solves issue related to i2c driver performance.
With this commit delay in read write when using i2c timing
algorithm is solved. Used flag mechanism which will check
tim reg value and hz passed.
Depends on #14776
since not merged.

Impact of changes

Delay in I2C read write while using i2c timing algorithm is solved.

Migration actions required

Documentation


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)


Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR


Reviewers


@ciarmcom
Copy link
Member

@affrinpinhero-2356, thank you for your changes.
@ARMmbed/team-st-mcd @ARMmbed/mbed-os-maintainers please review.

@jeromecoutant
Copy link
Collaborator

Hi
I will make the final review after #14776

But I would expect more in this PR.
In targets.json, I imagine 3 new config at MCU_STM32 level:

  • I2C-timing-value-standard-mode
  • I2C-timing-value-fast-mode
  • I2C-timing-value-fast-plus-mode
    With no value set

Then in each i2c_device.h; you could set something like:

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#endif

So for default user, ALGO is disabled, and no explicit timing values are defined,
=> everything is working as for now

If user makes an application that changes dynamically the frequency settings
=> ALGO macro should be defined

If user makes an application that changes the default settings
=> he can keep the ALGO macro disabled, and only change the default timing value

Regards,

@jeromecoutant
Copy link
Collaborator

@ciarmcom ciarmcom added the stale Stale Pull Request label Jun 25, 2021
@ciarmcom
Copy link
Member

This pull request has automatically been marked as stale because it has had no recent activity. @ARMmbed/Team-ST-MCD, @ARMmbed/mbed-os-maintainers, please complete review of the changes to move the PR forward. Thank you for your contributions.

@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Jun 25, 2021
@mergify mergify bot added the needs: work label Jun 29, 2021
@mergify
Copy link

mergify bot commented Jun 29, 2021

This PR cannot be merged due to conflicts. Please rebase to resolve them.

@mergify mergify bot removed the needs: review label Jun 29, 2021
@ciarmcom ciarmcom removed the stale Stale Pull Request label Jun 29, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented Jun 29, 2021

Depends on #14776

It was merged, please rebase

@affrinpinhero-2356
Copy link
Contributor Author

affrinpinhero-2356 commented Jul 1, 2021

@jeromecoutant

Hi
I will make the final review after #14776

But I would expect more in this PR.
In targets.json, I imagine 3 new config at MCU_STM32 level:

  • I2C-timing-value-standard-mode
  • I2C-timing-value-fast-mode
  • I2C-timing-value-fast-plus-mode
    With no value set

Then in each i2c_device.h; you could set something like:

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#endif

So for default user, ALGO is disabled, and no explicit timing values are defined,
=> everything is working as for now

If user makes an application that changes dynamically the frequency settings
=> ALGO macro should be defined

If user makes an application that changes the default settings
=> he can keep the ALGO macro disabled, and only change the default timing value

Regards,

For some targets, we have more system clock values defined.
https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-3a9aa9e0acd297be19962adede5965c6aaaa1fbcfc70fa4f2f2cf529e64c9da6R43-R51

@jeromecoutant
Copy link
Collaborator

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#endif

For some targets, we have more system clock values defined.
https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-3a9aa9e0acd297be19962adede5965c6aaaa1fbcfc70fa4f2f2cf529e64c9da6R43-R51

For STM32F3 for ex, I could propose?

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#  if !defined(RCC_CFGR_PLLSRC_HSI_PREDIV)
#    if ((CLOCK_SOURCE) == USE_PLL_HSI)
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#    endif
#  endif
#endif

@prasannaven
Copy link

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#endif

For some targets, we have more system clock values defined.
https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-3a9aa9e0acd297be19962adede5965c6aaaa1fbcfc70fa4f2f2cf529e64c9da6R43-R51

For STM32F3 for ex, I could propose?

#ifdef MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#define I2C_TIMING_VALUE_STANDARD_MODE MBED_CONF_TARGET_I2C_TIMING_VALUE_STANDARD_MODE
#else
#  if !defined(RCC_CFGR_PLLSRC_HSI_PREDIV)
#    if ((CLOCK_SOURCE) == USE_PLL_HSI)
#define I2C_TIMING_VALUE_STANDARD_MODE <default value>
#    endif
#  endif
#endif

@jeromecoutant Can we take this update with separate ticket ?

@affrinpinhero-2356 affrinpinhero-2356 requested review from LMESTM and removed request for a team July 1, 2021 15:41
Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non regression tests are failing with F303ZE and L476RG

@affrinpinhero-2356
Copy link
Contributor Author

Non regression tests are failing with F303ZE and L476RG

Let me check the same. Can you paste the error.

This commit solves issue related to i2c driver performance.
With this commit delay in read write when using i2c timing
algorithm is solved. Used flag mechanism which will check
tim reg value and hz passed.

Signed-off-by: Affrin Pinhero <[email protected]>
@jeromecoutant
Copy link
Collaborator

Non regression tests are failing with F303ZE and L476RG

In i2c_get_timing:
#if defined (I2C_PCLK_32M)
...
#elif defined(I2C_PCLK_64M)
#elif defined (I2C_PCLK_72M)
...

=> several I2C_PCLK_xxx can't be defined as for F3 or L4

Proposition:
#if defined (I2C_PCLK_32M)
#endif
#if defined(I2C_PCLK_64M)
#endif
#if defined (I2C_PCLK_72M)
#endif

@affrinpinhero-2356
Copy link
Contributor Author

Non regression tests are failing with F303ZE and L476RG

In i2c_get_timing:
#if defined (I2C_PCLK_32M)
...
#elif defined(I2C_PCLK_64M)
#elif defined (I2C_PCLK_72M)
...

=> several I2C_PCLK_xxx can't be defined as for F3 or L4

Proposition:
#if defined (I2C_PCLK_32M)
#endif
#if defined(I2C_PCLK_64M)
#endif
#if defined (I2C_PCLK_72M)
#endif

Modified already. Does it still cause errors?

https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-8669c41247ba3cd273836b6a4c4376b94293f4852ac54e47cd3c01b6c9c43c7aR1778-R1796
https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-8669c41247ba3cd273836b6a4c4376b94293f4852ac54e47cd3c01b6c9c43c7aR1872-R1890
https://github.com/ARMmbed/mbed-os/pull/14808/files#diff-8669c41247ba3cd273836b6a4c4376b94293f4852ac54e47cd3c01b6c9c43c7aR1910-R1928

@affrinpinhero-2356
Copy link
Contributor Author

Is this good to start CI?

@affrinpinhero-2356
Copy link
Contributor Author

@jeromecoutant is this good to start CI?

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 6, 2021

CI started

@mbed-ci
Copy link

mbed-ci commented Jul 6, 2021

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️

0xc0170
0xc0170 previously requested changes Jul 6, 2021
Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just readme update to fix grammar. sorry for late request, I've noticed it just now

targets/TARGET_STM/README.md Outdated Show resolved Hide resolved
targets/TARGET_STM/README.md Outdated Show resolved Hide resolved
@mergify mergify bot added needs: work and removed needs: CI labels Jul 6, 2021
This commit modifies readme file. Descption for using
I2C timing algorithm and how to enable and disable
included.

Signed-off-by: Affrin Pinhero <[email protected]>
@mergify mergify bot dismissed 0xc0170’s stale review July 6, 2021 14:21

Pull request has been modified.

@mergify mergify bot added needs: CI and removed needs: work labels Jul 8, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented Jul 8, 2021

CI started

@mbed-ci
Copy link

mbed-ci commented Jul 8, 2021

Jenkins CI Test : ✔️ SUCCESS

Build Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️

@0xc0170 0xc0170 added release-type: patch Indentifies a PR as containing just a patch and removed release-type: feature labels Jul 8, 2021
@0xc0170 0xc0170 merged commit 1d5d3b0 into ARMmbed:master Jul 8, 2021
@mergify mergify bot removed the ready for merge label Jul 8, 2021
@mbedmain mbedmain added release-version: 6.13.0 Release-pending and removed release-type: patch Indentifies a PR as containing just a patch Release-pending labels Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants