Closed rasmuskleist closed 1 year ago
I'm no expert on flash chips either! For the moment I will leave the selectDie function as is, unless you have any comments to it. Afterall it is working and the overhead is probably not that significant, especially compared to the erase/program durations.
I have flipped the waiting as suggested, and will confirm that it works with my W25M512VJ flash chip tonight. Then I will convert it to a PR. I should add that flipping it will add some overhead for example in the read fuction, but I believe it is worth it since the driver only waits when it has to. This will also make the flow of the tests seem strange as it can enter the memory test while still busy erasing the chip. I can ignore this as it is only aesthetic or I can make the busy function public and wait the threads manually. What do you think?
Yeah, you should probably expose the wait method, otherwise it'll be confusing. You may also explicitly wait for completion sonetimes like when rebooting or going to sleep.
I have made the isBusy
and waitWhileBusy
function available in BdSpiFlash
and implemented similar functions in BdSpiStackFlash
. Here isBusy
returns true
if any of the stacked dies is busy which i presume is the desired behaviour. I also noticed whilst doing some further testing of integrating BdSpiFlash
with FatFs that the nesting level should be increased in order to use write
.
Currently, I do not see any operation in the BdSpiFlash
implementation that can wait for completion, which is not already waiting. After all, the intention is not to wait for erase and program to finish, so concurrent operations can take place inside BdSpiStackFlash
.
Thanks! Should I squash more than this?
It occured to me as I was testing the driver with fibers, that it is problematic if a void functions returns a result and vice versa. I have now fixed this issue.
I have changed the implementation of the BdSpiFlash to use the W25M512JV instruction set as discussed in #890. In addition, I have added a wrapper that makes the stacked die seem like a contiguous piece of memory for homogenous storage devices. This was also discussed in #890, although my implementation is somewhat different.
Currently, the dieSelect function does more than I probably want it to, so I would like your opinion on the following alternative implementation.
Finally, the current implementation waits for the BUSY bit to clear after issuing a command. Although I do find it nice that the operation finishes before returning, it does block the driver from issuing commands that can be done while busy. For example with the SpiStack concurrent operations can be performed. Therefore I like your opinion on waiting for the BUSY bit to clear in the program and erase function before issuing the command? Thereby I can select another die and double the troughput. However, I should add that the performance gain is probably very small in practice unless I change the BdSpiStack addressing to be modulo erase block. This could possibly double the throughput, but since I do not know my own throughput at the moment, this is possibly better suited for a later PR!