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

TARGET_STM: Add DEVICE_SPI_COUNT to use SPIs without interference #10841

Merged
merged 1 commit into from Jun 26, 2019

Conversation

@VVESTM
Copy link
Contributor

commented Jun 17, 2019

Description

Extend to all STM targets the work done on #10752
Half works around #10827

Pull request type

[ ] Fix
[ ] Refactor
[x] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@embeddedteam103
@kjbracey-arm
@LMESTM

Extend to all STM targets the work done on PR10752.

Signed-off-by: Vincent Veron <vincent.veron@st.com>
@ciarmcom ciarmcom requested review from kjbracey-arm and ARMmbed/mbed-os-maintainers Jun 17, 2019
@ciarmcom

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

@VVESTM, thank you for your changes.
@kjbracey-arm @ARMmbed/mbed-os-maintainers please review.

@LMESTM
LMESTM approved these changes Jun 17, 2019
Copy link
Contributor

left a comment

LGTM

Copy link
Contributor

left a comment

Content's fine, but I'm doubtful it counts as a "fix".

Possibly it could be "target update".

This will notably change behaviour and memory footprint of apps, so a bit wary about going to a patch release either way, but I wouldn't totally rule it out.

I guess it fixes #10827, sort of, but he could fix his issue without this by driving the API correctly, as I described there. This is more a workaround so it doesn't matter that he sets his GPIO before selecting the SPI.

@ciarmcom ciarmcom requested review from kjbracey-arm and ARMmbed/mbed-os-maintainers Jun 17, 2019
@ciarmcom

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

@VVESTM, thank you for your changes.
@kjbracey-arm @ARMmbed/mbed-os-maintainers please review.

@VVESTM

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

@kjbracey-arm, I have updated the PR to "target update". I agree with you and I get some doubts to choose between "fix" or "target update"...
I have kept the comment saying it fix #10827. I let you remove it if you prefer. In this case, @embeddedteam103 will have to close #10827 manually.

@LMESTM

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@kjbracey-arm I'm a bit worried now :-/
I think that this change has already been deployed on L0 in #10752, right ?
So either this is reliable and can be deployed for all , or this should not be activated for any target.
Unless this is only a workaround and should be marked as such, to be later removed by some other fix

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

So either this is reliable and can be deployed for all , or this should not be activated for any target.

Oh, certainly it should be deployed for all, but the act of deploying it for any particular target does impact application behaviour on that target beyond a simple fix. It's a functional improvement, with a corresponding memory increase to implement that improvement.

So it tends to fall closer to the "this should be deployed in the next minor release" than "this should be issued as a 5.13 patch".

But there is also the counter-argument that "the other targets work nicely like this, this one doesn't, so that inconsistency/deficiency is a bug in this target".

I've no strong feeling either way - I'm willing to leave the 5.13.y backport choice to other maintainers, and ST's own to decide. But this is good for master either way.

Unless this is only a workaround and should be marked as such, to be later removed by some other fix

I phrased my comment above a bit badly. This patch isn't a workaround itself, but deploying it makes that reported issue go away - it's not the ultimate fix for his issue. The code in the issue is flawed, but works when his SPI devices aren't state sharing. This patch means that flaw stops being apparent, because we detect the separate buses and stop state sharing. His code would fail again if he put his devices on the same bus.

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

Actually there is a remaining glitch for #10827 even with this patch - SPI doesn't acquire when we construct the SPI object, but only on the first select or write. Therefore when he does his manual GPIO select before the first SPI::write, the reconfiguration glitch will be seen leading into that write.

He needs to modify his code as I suggested there - either use select before doing his own GPIO, or let SPI drive the GPIO for him in select/write.

@LMESTM

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

@kjbracey-arm Thanks - all clear now !
I agree that this does not necessarily need to be included in maintenance release.

@adbridge

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2019

@kjbracey-arm reading the last few comments I'm confused as to whether this is ready to go or not ?

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

This is fine to go for master, the debate is just about whether it's applicable for a 5.13 patch release (consensus = no), and how it relates to that other issue.

@0xc0170 0xc0170 added needs: CI and removed needs: review labels Jun 24, 2019
@0xc0170

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

CI restarted

@mbed-ci

This comment has been minimized.

Copy link

commented Jun 25, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels Jun 26, 2019
@0xc0170 0xc0170 merged commit 924af94 into ARMmbed:master Jun 26, 2019
26 checks passed
26 checks passed
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/build-ARM Success
Details
jenkins-ci/build-GCC_ARM Success
Details
jenkins-ci/build-IAR Success
Details
jenkins-ci/cloud-client-test Success
Details
jenkins-ci/dynamic-memory-usage RTOS ROM(+4488 bytes) RAM(+17104 bytes)
Details
jenkins-ci/exporter Success
Details
jenkins-ci/greentea-test Success
Details
jenkins-ci/mbed2-build-ARM Success
Details
jenkins-ci/mbed2-build-GCC_ARM Success
Details
jenkins-ci/mbed2-build-IAR Success
Details
jenkins-ci/unittests Success
Details
travis-ci/astyle Success!
Details
travis-ci/docs Success!
Details
travis-ci/doxy-spellcheck Success!
Details
travis-ci/events Success! Runtime is 8601 cycles.
Details
travis-ci/gitattributestest Success!
Details
travis-ci/include_check Success!
Details
travis-ci/licence_check Success!
Details
travis-ci/littlefs Success! Code size is 8448B.
Details
travis-ci/psa-autogen Success!
Details
travis-ci/tools-py2.7 Success!
Details
travis-ci/tools-py3.5 Success!
Details
travis-ci/tools-py3.6 Success!
Details
travis-ci/tools-py3.7 Success!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.