Product Idea: USB Flash Drives

[barray]

Well, you're right and unfortunately there's some bad news.   Here's a quotation from the BL602 feature list, found on page 6 of the BL602 datasheet:

One SPI master/slave with max clock 40Mbps

Consequently, even with the quad-SPI flash connected to a completely separate controller and interface (according to the block diagram on page 9 of the BL602 datasheet), anything going through the BL602's SPI bus would be limited to 40 Mbit/s, which includes the required USB interface.  Quite frankly, a storage device that provides about 4 MB/s at its USB interface would be rather pointless.

Multiply that by four for quad SPI channels, so 12MB/s (or 96Mb/s) - still not great, but better. And yeah it's not ideal to share these with the USB interface too. We're also going to struggle to go much faster anyway if we're going through a header interface due to capacitance and interference.

Strictly in theory, another approach might be to use the BL602's SDIO 2.0 interface to connect a USB interface.  It should provide reasonable speeds, but I really don't think that an appropriate SDIO-to-USB bridge device exists.  There are USB devices that provide an SDIO interface, but there's pretty much no reason for an SDIO device that provides a USB interface to exist.

I think SPI is still the way to go, even if it means bit-bashing SPI to the USB interface for example (which should be able to clean it up ready for USB).

Unfortunately, I'm no longer optimistic about using the BL602 for the new storaga device, it would be unusably slow.   Quite frankly, everything says that we should look for a better microcontroller choice for the new storage device.

I never thought it would be the final controller, it would be much better to have something that supports USB without need for an interface chip - and offers more SPI channels. The entire point of using the BL602 is that we could concentrate on building the flash storage hat, then swap out the base-board later. It allows for incremental development. We can move to a different RISC-V chip at a later date. I think there is already tonnes of risk in this project, so starting with something known is much better.

A good candidate might be the RISC-V SBC mentioned here: https://www.pine64.org/2021/02/15/februa...-and-tell/

That could actually be way too powerful though...

Anyway, I suspect we will have our hands full with just getting the hat off the ground and working correctly - there's a lot of unknowns, such as interfacing with the flash chips and speaking USB, as well as RAID and storage integrity reporting. More than enough stuff to keep us busy.

According to the table on page 11 of the BL602 datasheet, the memory map includes space for 16 MB of XIP (execute in place) flash memory.  It is unclear whether those 16 MB present the liimit for the size of the external flash?  Probably not, but the XIP feature should require the flash to be part of the memory map?  Maybe only one part ("XIP window") of the flash is mapped at once?  Also, the memory map says nothing specific about the embedded flash.

I think the 16MB limitation is purely from that XIP limitation - but that shouldn't be a limitation for QSPI. Usually these 32 bit controllers will have some kind of memory address width of 24 bits (2^24 = 16777216). Then you memory map that in RAM at some offset. There is nothing stopping us sending any QSPI commands we want and address however much data we want to - it just can't be XIP.