TARGET_STM: Add DEVICE_SPI_COUNT to use SPIs without interference

[VVESTM]

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

[ciarmcom]

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

[LMESTM]

LGTM

[kjbracey]

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]

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

[VVESTM]

@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]

@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]

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]

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]

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

[adbridge]

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

[kjbracey]

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]

CI restarted

[mbed-ci]

Test run: SUCCESS

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