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

Stable driver: SPI master #2494

Open
16 of 42 tasks
MabezDev opened this issue Nov 8, 2024 · 11 comments
Open
16 of 42 tasks

Stable driver: SPI master #2494

MabezDev opened this issue Nov 8, 2024 · 11 comments
Assignees
Milestone

Comments

@MabezDev
Copy link
Member

MabezDev commented Nov 8, 2024

As part of #2491, which has more details on driver analysis.

Note: we are not stabilizing DMA support right now.

esp-hal API-GUIDELINE omissions

Construction

Interop

API surface

Documentation

Maintainability

Driver Implementation


Rust API guideline omissions


Hardware feature omissions

Mode/features of the driver that are lacking

Misc


@MabezDev MabezDev added this to the 1.0.0-beta.0 milestone Nov 8, 2024
@bugadani
Copy link
Contributor

bugadani commented Nov 8, 2024

Note: we are not stabilizing DMA support right now.

What exactly does this mean, we're only aiming at stabilizing spi::master::Spi? That's a surprisingly small slice of the driver.

@MabezDev
Copy link
Member Author

MabezDev commented Nov 8, 2024

What exactly does this mean, we're only aiming at stabilizing spi::master::Spi? That's a surprisingly small slice of the driver.

Start small, and incrementally stabilize. It's easier to stabilize spi::master::Spi and then SpiDma than both at the same time.

Remember folks can always opt in to unstable to use the rest of the driver. We need to be 100% certain what we're stabilizing is solid, there are no take-backsies till 2.0 :D.

(I just realized I basically summerised what I wrote in #2491, in particular the "Can the driver as a whole be stabilized" section.)

@FloppyDisck
Copy link

Hello, I would prefer that SPI implemented SpiDevice. If needed I can help finish implementing whatever it needs to get added on the next version.

@Dominaezzz
Copy link
Collaborator

Hello, I would prefer that SPI implemented SpiDevice. If needed I can help finish implementing whatever it needs to get added on the next version.

Does ExclusiveDevice not suit your needs?

@bugadani
Copy link
Contributor

bugadani commented Dec 4, 2024

Just noting that we could provide a SpiDevice implementation that uses hardware chip select. We can also provide implementations that allow sharing an SPI bus with reconfiguring the pins for separate devices. Both of these are out of scope for this issue, which is explicitly about the current state of the SPI bus master driver.

What I'm unsure about, is, whether we have to provide any chip select functionality for the bus driver in the first place.

@Dominaezzz
Copy link
Collaborator

What I'm unsure about, is, whether we have to provide any chip select functionality for the bus driver in the first place.

I think so, otherwise how do people select which device they're talking to on the bus.

@bugadani
Copy link
Contributor

bugadani commented Dec 4, 2024

With a GPIO, as they already do when using ExclusiveDevice.

@Dominaezzz
Copy link
Collaborator

Ah I see.

Fwiw, when I created the issue asking to expose the CS signals, I meant adding it to Spi and SpiDma, alongside the keep_cs_active option.
Adding it to SpiDmaBus is a bit weird due to the chunking.

@bugadani
Copy link
Contributor

bugadani commented Dec 4, 2024

They are still bus drivers, not device drivers. The busses shouldn't care much about chip select, that's the responsibility of the device drivers. Whether the chip select ends up being implemented as a hardware signal or a software GPIO write, isn't something the bus driver have to know about. For single transfers, there is essentially no difference (you still need to write a register to select a particular chip select and make sure that chunking doesn't deassert it), except with hardware chip select, you have less flexibility in the CS-to-SCLK delay.

@Dominaezzz
Copy link
Collaborator

Hmm, I guess I just want an inherent GSPI-2/3 driver without the connotations of "bus" and "device", which will let me select a CS pin and create my own "device"s.
Software CS is rather inconvenient for interrupt queues and I generally don't want to rely on my async scheduler to de-assert the CS pin in a timely fashion. Some of the devices I talk to wait patiently for the de-assert before taking action, which is latency I'd love to do without.
So there is a UX and timing difference, even for single transfers.

Also on the DMA side, whilst the SpiDma is busy waiting for the RX channel to finish writing to memory, I'd like that time to also be spent performing the CS hold time delay rather than have a separate additional/excess delay, which is only possible if the hardware is doing it really.

@bugadani
Copy link
Contributor

bugadani commented Dec 4, 2024

I think the best resolution for this conversation is that we don't stabilize anything CS-related initially, and come up with a solution that everyone likes.

@MabezDev MabezDev assigned bjoernQ and JurajSadel and unassigned SergioGasquez Dec 11, 2024
@MabezDev MabezDev changed the title Stable driver analysis: SPI master Stable driver: SPI master Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

9 participants