Free serial resources if not needed anymore #10924
Conversation
|
I tagged the proposal as |
|
@kjbracey-arm I created an alternative proposal according to your suggestions. |
|
@ghseb, thank you for your changes. |
|
Thanks! On a 5-second skim, the structure looks promising. Will review properly when I have time. |
|
@ghseb , please check the failing CI results. |
|
@kjbracey-arm If you have time, please review. |
|
CI started. |
Test run: FAILEDSummary: 2 of 4 test jobs failed Failed test jobs:
|
|
@ghseb Please fix those broken tests. |
|
Unittests are failing: |
|
And ARM builds with: |
|
I'm away on holiday for a few weeks after today, so someone else needs to take over review here. |
|
This presumably would require a fix to #11057 |
I just added a stub to get it compiling because i don't know about that target (please inform me if this is a way to go). |
|
During re-initialization probably flow control must also be considered to reestablish complete state. |
|
Missing What do you think is required with respect to flow control? I suppose we might want that the output line be put into "safe" state by I can see an alternative argument for the line actually being left in "ready to receive" just to stop the sender getting jammed if we're not intending to ever read anything. Let it get thrown on the floor... I admit I hadn't thought about this - I tend to forget flow control :) I was assuming input would just be binned, forgetting we maybe had the option of blocking the sender. |
|
@ghseb Please review latest comments. I see you pushed an update after a review (please also comment if any of these address the review comments to have it linked and easily found). What is left for this one to be integrated? |
|
@kjbracey-arm What i ment is when flow control was enabled before serial is deinitialized, it should be re-enabled with same settings after serial is re-initialized again. This would require to backup the flow control state. Regarding your thoughts for me it would be ok to leave it unspecified in which state hw flow control pins are left while serial input and output is disabled, because either way there might be potential issues that highly depend on the attached peripheral. |
|
Right, yes, if you're using And yes, can leave pin states unspecified for now. |
ghseb
force-pushed
the
free-serial-resources-2
branch
from
d5d6cdb
to
d0802c8
Compare
Test run: FAILEDSummary: 3 of 4 test jobs failed Failed test jobs:
|
|
I restarted the CI, will investigate if fails again |
Test run: FAILEDSummary: 1 of 4 test jobs failed Failed test jobs:
|
There is no Shutdown function for this target
|
Fixed the build error, restarting CI |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
|
@ghseb Thanks for the contribution |
0xc0170
added
release-version: 5.15.0-rc1
and removed
release-version: 6.0.0-alpha-1
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: ARMmbed#10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Related PR: #10924 The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized. I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split. If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
Description
As suggested this is an alternative to the proposal of #10843.
While in #10843 only
UARTSerialwas modified, this PR moves required changes intoSerialBase.Description of #10843:
Pull request type
Reviewers
Release Notes
The handling of enable/disable input/output of
UARTSerialis moved intoSerialBase. The underlying serial peripheral is freed if both input and output are disabled to reduce current consumption. If either input or output is enabled again, the serial peripheral is reinitialized.