QSPI multiple thread access

Report here problems in any of ChibiOS components. This forum is NOT for support.
User avatar
FXCoder
Posts: 267
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 106 times
Been thanked: 85 times

Re: QSPI multiple thread access

Postby FXCoder » Sat Jul 11, 2020 6:37 am

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?).
--
Bob

steved
Posts: 719
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 10 times
Been thanked: 102 times

Re: QSPI multiple thread access

Postby steved » Sat Jul 11, 2020 9:15 am

FXCoder wrote: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.

I see start/stop and acquisition management as two separate tasks.
Given that my current QSPI application does large numbers of reads of small (usually 16-byte) blocks of data, start/stop on every access could introduce a noticeable overhead.
And while the start/stop overhead for QSPI is relatively small, it may not be for some other peripheral whose driver is intended to follow the same model.


FXCoder wrote: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.

Agreed (and in fact implemented in my LLD).


FXCoder wrote: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?).

This seems to be part of the problem with getting to a reasonable solution - QSPI/SPI has so many potential use cases that it's tricky to support the more complex cases without over-complicating the simple cases. Maybe it's possible to come up with, say, two or three models which reflect the main use cases and set all the flags accordingly.


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 6 guests