Expose the KEEP_CS_ACTIVE option (This is important for chunked transfers in a single transaction)

[bjoernQ]

No description provided.

[MabezDev]

For the same reasons as #2795, this can be implemented later.

[Dominaezzz]

Unlike #2795 I don't think this can come later. This is not the sort of setting one puts in a config, it's the sort of thing you'd specify per-transfer. If there was some kind of TransferConfig struct that this could go into, then yes, it could be postponed, but right now it can't.

I think this needs a more concrete plan

[MabezDev]

If there was some kind of TransferConfig struct

There will be something like this, probably DeviceConfig that could contain this, which would come when we add our own Hardware managed SpiDevice later on.

Regardless, this is strictly to do with segmented transfers, right? Which are only possible with DMA, which we're not stabilizing yet.

[Dominaezzz]

Regardless, this is strictly to do with segmented transfers, right?

No, this applies to CPU transfers as well. It's used quite a bit in esp-idf-hal.

There will be something like this, probably DeviceConfig that could contain this, which would come when we add our own Hardware managed SpiDevice later on.

DeviceConfig sounds like something you would set once per device driver created, this option however is something that would still be specified per transfer, which I think should be a separate config.

[bugadani]

We might go in the same direction as with I2C transfers, and provide a low-level transaction api to build stuff like this. Regardless, it's not needed right now for what we intend to stabilize.

[Dominaezzz]

We might go in the same direction as with I2C transfers

That would be a little too restrictive 😅

I suppose it doesn't have to be stabilised now, my concern is I don't think you can add this afterwards, in a nice way.

[bugadani]

How do you know it would be restrictive? We haven't even started to design it. Anyhow, PRs are welcome in case you'd like the functionality before we get to it.

[Dominaezzz]

How do you know it would be restrictive? We haven't even started to design it.

Because I've dealt with it in esp-idf-hal where they pretty much did what you've described.
Having to specify all the transfers up front was an artificial restriction to make e-hal happy.

Anyhow, PRs are welcome in case you'd like the functionality before we get to it.

I'd make a PR but y'all still need to decide what to stabilise.
Almost every spi transfer method would get an extra keep_cs_active: bool parameter, and I'm not sure that would get approved as is 😄

[MabezDev]

Almost every spi transfer method would get an extra keep_cs_active: bool parameter, and I'm not sure that would get

but this would all still be internal right? and we can expose it via the low level transaction builder API in the future.

I'd make a PR but y'all still need to decide what to stabilise.

Doesn't even have to be a PR, just some more concrete use cases and scenarios might help me understand a bit more about what needs to be done here. I've seen the impl in esp-idf-hal, I don't think it's that bad, in each transaction loop it checks if there is more data to send and if there is it sets the keep cs active flag.

[Dominaezzz]

but this would all still be internal right? and we can expose it via the low level transaction builder API in the future.

This would have to be external really, like esp-idf does it.

A "transaction builder" API makes sense for something like I2C where the hardware interface makes you prepare a list of commands in some registers.
It doesn't make sense for SPI as each transfer is sent by itself. If this were for configurable segmented transfers, a transaction builder API could make sense.

If we're still trying to expose an inherent API, this flag has to be exposed in the lower level (no chunking) APIs.

Doesn't even have to be a PR, just some more concrete use cases and scenarios might help me understand a bit more about what needs to be done here.

That works, I'll come up with scenarios.

[Dominaezzz]

Use cases for a public "keep cs active" option.

• SpiDevice's interface can't be used for streaming transactions rust-embedded/embedded-hal#583
• How to maintain an SPI transaction while manipulating GPIO pins? rust-embedded/embedded-hal#478

I think these two issues actually describe the two use cases I'm thinking of pretty well.

The first being you may not know when the transaction is going to end.
The second being you may want to do something mid transaction like toggle a out of band GPIO pin.

Neither of which can be achieved with a transaction builder API but the hardware itself can certainly do it.