Parallel SPI Flash

Status
Not open for further replies.

Frank B

Senior Member
Hi,

some of you may have noticed, that i added an SPI Flash with 4-BIT parallel connection to an other project.
Maybe it is useful for other projects, too. I have uploaded the library to https://github.com/FrankBoesing/ParallelFlash, along with eagle schematics and board (you can upload the .brd-file to OSH-park or digistump).

It is highly experimental, but so far i have'nt had any problems with it.
The board is totally untested (but it is so simple that it should work :) ), i tested the library in my other project, with an W25Q128FV only.

I measured transfer-speeds (for reading) of more than 5 Megabytes / Seconds.

"TeensyTransfer" is compatible, just enable "_HAVE_PARFLASH" in the *.h file.

ParFlash.png
 
Last edited:
Frank,
Would this library work for a micro-SD card?

No, that's a diffferent thing..

I wrote some code for that long time ago, but i realized that you can speed up the raw transferrate, but the access-times stay the same (unless there is a hidden trick i'm not aware of..). So it would be of very limited use. So i stopped working on this...
 
uSD card with 2, 3 or 4 bit SDIO mode, rather than 1 bit mode SDIO, or SPI mode, is a lot faster. 2-4 bit SDIO has a lot lower overhead that SPI, as well.
Hardware needs to support SDIO 1-4 bit and DMA for these. Most mid-range and up Cortex chips has SDIO support and vendor driver software.
I'm using it on a project with 25Mbps x n bits, SDIO + FATFS, all vendor freeware. Not Arduino-esque though.

uSD cards have an on-card flash controller chip as well as the flash array. The controller is the magic - it deals with wear leveling, bad block remapping, strong ECC for MLC flash, caching, and so on.
 
Last edited:
Frank, I have an adafruit winbond W25Q80BV 1 MB (DIP) that I've used with Paul's SerialFlash, so I thought I'd give your library a try...
I got the latest ParallelFlash from github, and got a compiler error, n undefined in ParallelFlashChip::capacity() ?? So I commented out the n=0;, still a warning

libraries/ParallelFlash/ParallelFlashChip.cpp:656:1: warning: control reaches end of non-void function [-Wreturn-type]

but i can live with that.

I ran the ListFiles example (I had just run SerialFlash to verify it had files and such), but all i got was
Code:
All Files on Flash chip:
Status Register 1:0x2
Status Register 3:0x0
Status Register 2:0x0
I re-checked my breadboard wiring based on your pin table on github. still no workee. I tried a readID() and got FF's ...

any thoughts? wires too long for high data rates?

(i'll check my wiring again) I'm using teensy 3.2 @120 mhz (tried at 72mhz) with IDE 1.6.7

EDIT: I hooked CLK, d0, d2, (and pin 13 for start/stop) to analyzer around a ParallelFlash.read() of 256 bytes at CPU of 72mhz (analyzer max is 50mhz). I see lots of activity on CLK, but not a steady CLK stream, pauses , max short burst 12.5mhz?. Only a few spikes on d0, and no spikes on d2, of course it says it read all 0's. (actual block start was byte 32768 which should have non-zero file data).

@120mhz, the 256-byte read takes 48 us (= 42.7 mbs), for comparison, the SerialFlash SPI rate was 11.9mbs

(I hooked flash back up as SPI to confirm file data was still OK. it was OK)
 
Last edited:
God, I need holidays... yes, the last edit to capacity I made was errornous.

I did not test the library with other Chips than the W25Q128.
Tomorrow, I'll read the Datasheet of W25Q80BV. Maybe this chips want a bit different handling ?
But I don't have a W25q80, so i can not test it.
 
I just took a quick look. Seems Windbond updated a lot since W25Q80.
- it does not have status register #3 (this is not really needed, so: not important)
- More important, the Datasheet does not mention the QPI-Mode - and command 38h is missing.

Maybe we have to use quad-spi instead (thats a different mode. QPI is faster....)
More tomorrow (its after midnight here).
 
Last edited:
- More important, the Datasheet does not mention the QPI-Mode - and command 38h is missing.

Thanks. no QPI explains it.

probably not worth worrying about older product line. (adafruit no longer stocks the DIP)

Your library has some impressive GPIO manipulations!
 
Last edited:
Hi Frank,

This looks like just what I need to hopefully speed up sample reading from the flash memory. However I'm having some issues trying to get this all to work. I am using W25Q128FVSIG flash chip, Teensy 1.35, and Arduino1.8.1, and am using a Teensy 3.2.
I started off by transferring samples from SD card to the W25Q128FVSIG using an audioshield and the old code to do this. I can list the files and see they transferred correctly, using the old method.

Then I put the W25Q128FVSIG on it's own breakout board, and wired it up just like your board to the Teensy 3.2 (audioshield is no longer used). When I try to use the parallelflash listfiles example to read the files on the chip, most of the file names look good, others look like they are possibly corrupt with strange character names.
Would you recommend I reformat the card, and start all over moving the samples from the card to the flash, and try reading again?

Is there a way to hook up an SD card jack to the Teensy to allow transfers of samples from SD card to the flash chip using the new pin connections that parallelflash requires?

I want to use playserialflashraw to read audio sample more quickly with your parallelFlash code.
I downloaded the parallelFlash code and installed it in Libraries.
I Changed "#include <SerialFlash.h>" to #include <ParallelFlash.h> in my sketch,
and also changed, if(!SerialFlash.begin()), to if(!ParallelFlash.begin()) in my sketch.

Is there more I need to update to get this to work properly?

I see in the playSerialFlashRaw.h file #include <SerialFlash.h>, should this also be changed to #include <ParallelFlash.h>?

Are other changes needed, or should I be using the PlayRawFromSerialFlash listed on your github page, instead of the one provided with the Teensy 1.35 audio library?
 
Hi Frank,

This looks like just what I need to hopefully speed up sample reading from the flash memory. However I'm having some issues trying to get this all to work. I am using W25Q128FVSIG flash chip, Teensy 1.35, and Arduino1.8.1, and am using a Teensy 3.2.
I started off by transferring samples from SD card to the W25Q128FVSIG using an audioshield and the old code to do this. I can list the files and see they transferred correctly, using the old method.

Then I put the W25Q128FVSIG on it's own breakout board, and wired it up just like your board to the Teensy 3.2 (audioshield is no longer used). When I try to use the parallelflash listfiles example to read the files on the chip, most of the file names look good, others look like they are possibly corrupt with strange character names.
Would you recommend I reformat the card, and start all over moving the samples from the card to the flash, and try reading again?

Is there a way to hook up an SD card jack to the Teensy to allow transfers of samples from SD card to the flash chip using the new pin connections that parallelflash requires?

I want to use playserialflashraw to read audio sample more quickly with your parallelFlash code.
I downloaded the parallelFlash code and installed it in Libraries.
I Changed "#include <SerialFlash.h>" to #include <ParallelFlash.h> in my sketch,
and also changed, if(!SerialFlash.begin()), to if(!ParallelFlash.begin()) in my sketch.

Is there more I need to update to get this to work properly?

I see in the playSerialFlashRaw.h file #include <SerialFlash.h>, should this also be changed to #include <ParallelFlash.h>?

Are other changes needed, or should I be using the PlayRawFromSerialFlash listed on your github page, instead of the one provided with the Teensy 1.35 audio library?

Hi, I've stopped working on this, and I don't remember much :) maybe there are some issues left....
Overall I think it wasn't worth the effort, and as far as i know, nobody ever really used it.
 
I got it working. Much faster!

I for one, really appreciate your contribution of code Frank!

Anyone complaining latency and their audio glitching when trying to play RAW serial, should look into this to improve their flash chip performance. I was seeing glitching of audio at 64 blocksize and smaller. I'm reducing block size to decrease latency. But trying to play 2x samples directly to the DAC @ 64 blocksize would glitch the audio because the simple code of playing the 2x samples between noAudioInterrupts/AudioInterrupts was taking too long (something like 3.5ms @ blocksize16), and audioStream was unable to update. Now I can set blocksize down to 8 and it works without glitching with a latency of only 0.4-0.6ms.
 
Status
Not open for further replies.
Back
Top