Giovanni wrote:I wonder if it is right to have to call (w)spiStart() from outside when SNOR_SHARED_BUS==FALSE.
The most desirable behavior, I think, would be:
SNOR_SHARED_BUS==FALSE -> start the bus on snorStart(), stop it on snorStop.
SNOR_SHARED_BUS==TRUE -> start/stop the bus in each operation, this is for allowing shared SPIs basically.
Perhaps this should be considered a bug because the (W)SPI configuration is passed to the SNOR driver in both cases.
steved wrote:In fact, why would one need to do this, even in a shared configuration? Unless the bus settings change, of course.
The mutex, when enabled, can have the dual purposes of managing access to the bus, and making those accesses thread-safe - as long as checks prior to the mutex don't interfere. (If grouped sequences are needed, they need to be managed at a higher level).
Maybe only enable certain checks if SNOR_SHARED_BUS==FALSE
I suspect this type of issue is going to arise more as Chibi acquires more complex drivers which sit on top of HAL.
Agreed. Anyway here are some further thoughts...
If we were to view the NOR flash as a "system service" versus a "driver" then the question is should that service manage the assigned underlying driver?
It makes sense to me that the "NOR service" manages the underlying driver (SPI or WSPI).
For SPI acquire-start-use-stop-release covers the handling of multiple devices on an SPI bus with differing rates, etc.
i.e. each "service transaction" should be handled by the service acquiring the underlying peripheral, executing the task and then releasing.
In the case of WSPI being used by the "NOR service" then the same sequence makes sense to me.
The overheads of starting/stopping are not substantial and where there are multiple concurrent applications running the acquire-use-release method is highly preferred by me.
QSPI does introduce some twists such as memory mapping.
However, once the "NOR service" enables mapping the safe approach is for the resource (the NOR flash) to remain busy until unmapped and disabled.
Additionally there is a use case where QSPI could be supporting two (possibly different) devices in 1 bit mode (selected by CR:FSEL).
Although the wspi driver does not support managing CR:FSEL at the moment it may make sense for that to be implemented (add a CR field to the config?).