Memory board add-on requirements

Status
Not open for further replies.
stevech said:
Be sure to program the serial flash chips in block mode of course. the single byte/word program (which assumes it's writing to an erased byte/word), is much slower due to overhead.

Probably not enough I/O bits, but I'm using the industry standard FSMC parallel interface for NAND flash. Some ARMs have an FSMC controller chip on the ARM. It takes 8 fdata bits (or 16) to do FSMC, but it is very fast. FMSC also has a mode in the ARMs and the flash to fetch instructions from FSMC flash. I think it's used to run boot mode code.
Click to expand...

oh, so this works with as little as 8 i/o? i remember the short-lived maple native beta had an extra 1MB SRAM using FMSC, which seemed pretty neat to have. pricey RAM chip though and seems to use up like 40+ i/o. anyways, was secretly hoping the 3++ might have that.

Donziboy2 said:
Question for those of you in the know, would it be effective to leverage the extra SPI channels on the Teensy 3.1 to read or write to 1 chip while the other erases?
Click to expand...

not that i'm in the know, but sure, i guess, depending on what's the application, you could come up with a scheduling scheme where you have two or more of those w25 chips going on, using different CSs (there's only one SPI, effectively (?)); you just couldn't move from A to B to A very fast; we're talking about 5-10 seconds for the complete erase; i haven't tried any of the block/sector erase modes.


edit: and back on topic:

here's my 2 cents so far:

- a board using the soic-8 footprint would be neat insofar it could be used with both w25 and 23LC1024 (and others, possibly); the former already is partly integrated into the audio library. as for the latter, not sure about other possible uses, but the SRAM thing should be interesting for audio, ie other than just storing stuff; though it's worth only 0.7 seconds or so of 16bit/44.1k data. that said, those chips are so simple and easy to solder by hand, i'm not sure making boards for them would make a whole lot of sense. then again, if a board happens, it wouldn't involve much more work to just make two boards, one using wson the other tssop (say)

- as for 1Gb: assuming that's ok (i mean the 100ma -- the datasheets are rather vague on that, no typical figures given, no clockrates), well, they offer more storage. soic 16 was already ruled out as being too large for an add-on board; leaving the BGA, which is 8x6 mm.
 
Last edited:
mxxx said:
not that i'm in the know, but sure, i guess, depending on what's the application, you could come up with a scheduling scheme where you have two or more of those w25 chips going on, using different CSs (there's only one SPI, effectively (?)); you just couldn't move from A to B to A very fast; we're talking about 5-10 seconds for the complete erase; i haven't tried any of the block/sector erase modes.
Click to expand...

Reason I said that was I was under the impression you had to leave CS pulled low while the chips erase, after reading the Microchip datasheet that does not seem to be the case(and winbonds). After you clock in the command and address for the erase you pull CS high and it executes the erase. Meaning you can set it to erase a page/sector/block/whatever and then go do other things, then just poll it every once in a while and it will let you know when its ready to do more work.


I just ordered a few W25Q64FVSSIG-ND(soic) from digikey to get me started, I have a large order i'm working on with mouser so I will grab some of the Microchip SST25's when they get in stock.
 
Donziboy2 said:
Reason I said that was I was under the impression you had to leave CS pulled low while the chips erase, after reading the Microchip datasheet that does not seem to be the case(and winbonds). After you clock in the command and address for the erase you pull CS high and it executes the erase. Meaning you can set it to erase a page/sector/block/whatever and then go do other things, then just poll it every once in a while and it will let you know when its ready to do more work.
Click to expand...

yeah, that was my understanding too. here's the erase from el supremo's 'flash_spi' code:

Code: 
void flash_chip_erase(boolean wait)
{
  write_pause();
  // Send Write Enable command
  digitalWrite(f_cs, LOW);
  SPI.transfer(CMD_WRITE_ENABLE);
  digitalWrite(f_cs, HIGH);
  digitalWrite(f_cs, LOW);
  SPI.transfer(CMD_CHIP_ERASE);
  digitalWrite(f_cs, HIGH);
  flash_wait_for_write = 1;
  if(wait)write_pause();
}
 
mxxx said:
yeah, that was my understanding too. here's the erase from el supremo's 'flash_spi' code:

Code: 
void flash_chip_erase(boolean wait)
{
  write_pause();
  // Send Write Enable command
  digitalWrite(f_cs, LOW);
  SPI.transfer(CMD_WRITE_ENABLE);
  digitalWrite(f_cs, HIGH);
  digitalWrite(f_cs, LOW);
  SPI.transfer(CMD_CHIP_ERASE);
  digitalWrite(f_cs, HIGH);
  flash_wait_for_write = 1;
  if(wait)write_pause();
}
Click to expand...

Can you drop a link to the full code, I cant seem to find it :/
 
mxxx said:
good question. i think it came with one of the earlier versions of the audio library but seems to be gone now.

my copy is here:

https://github.com/mxmxmx/eurotrash/blob/master/soft/libraries/Audio/flash_spi.cpp
Click to expand...

Just a quick observation. He used alot of digitalWrite High/Low transitions for CS pin, a normal digitalWrite High then Low takes about 750nS or 1.5uS full cycle if you where bit banging it on and off constantly. A digitalWriteFast High to Low takes about 10nS and if you need more time you add extra digitalWriteFast's to it. Since even the Teensy 3.0 can handle 25Mhz SPI its a waste to kill so much time just to transition a CS pin.
 
Donziboy2 said:
Just a quick observation. He used alot of digitalWrite High/Low transitions for CS pin, a normal digitalWrite High then Low takes about 750nS or 1.5uS full cycle if you where bit banging it on and off constantly. A digitalWriteFast High to Low takes about 10nS and if you need more time you add extra digitalWriteFast's to it. Since even the Teensy 3.0 can handle 25Mhz SPI its a waste to kill so much time just to transition a CS pin.
Click to expand...

true, i guess though the intention was simply to get it work and make it easier to get started. i only use it in setup and have since rewritten the stuff i need using SPIFIFO (that was for compatibility issues though, i guess i could have also used transactions in el supremo's code). it's not as fully featured, but take a look at frank's play_serialflash library, too; it's also using SPIFIFO.
 
Should we consider a separate thread so we aren't derailing onehorse's hardware discussion with software chat?
 
Donziboy2 said:
Just a quick observation. He used alot of digitalWrite High/Low transitions for CS pin, a normal digitalWrite High then Low takes about 750nS or 1.5uS full cycle if you where bit banging it on and off constantly. A digitalWriteFast High to Low takes about 10nS and if you need more time you add extra digitalWriteFast's to it. Since even the Teensy 3.0 can handle 25Mhz SPI its a waste to kill so much time just to transition a CS pin.
Click to expand...

This is not bitbanging, it's only the normal chipselect. But you're right the SPI-device can handle this automatically on some pins.
 
Should we consider a separate thread so we aren't derailing onehorse's hardware discussion with software chat?
Click to expand...

I don't mind... we can consider this thread all things memory.

I think my plan so far is to start with the small 128 Mbit add on and get it to work with existing libraries. Then see what is possible with the 1 Gbit chip. I know not everyone cares for the appallingly small add-on boards but I find them very useful and would like to push the limits to see what is possible. If we dont need reset and write protect then, with eight pins it might just be possible to squeeze 1 Gbit onto the small 0.3 x 0.7 inch 3 x 2 x 3 pin board without compromising the 16/17 I2C port. Data in/out/clock, two chip selects, power and ground are only seven IOs; I have one pin left over!
 
Last edited:
Donziboy2 said:
Some of the larger Spansions call for up to 100mA of current.
Are you writing ontop of existing data(which requires it to erase then write)?
Or are you writing to already erased pages/sectors?

One major drawback to the larger storage chips is that you end up having to erase larger and larger minimums of storage.
Click to expand...

Sorry missed this question: Easily answered.

In my case, at the moment, I'm using 4.5Mbytes for one set of samples for 16 pads. But I need an additional set for another 16 for a standard drumset at least, plus a collection of loops/samples for beatmashing.

So basically I'm already full, having reduced my samples to mono and shortened some of them against my wishes.

So yes, to apply a new patch with different samples for another track, would require a wipe & flash new data from the SDCard, largely to the whole chip.

My reasoning behind the 128Mbyte chip is that I could conceivably provide 15 sound patches for finger drumming, 10 drumkits, and a large collection of loops, and have this all flashed to the one chip, allowing any track to use any sample, at any given time, as much as they like.

One could then allow soundpacks which flash the entire chip with all new sounds, but it would not be considered as a live event. you would build your set on the contents of a single soundpack.

This is my dream, and whether it will ever be realised (i think it will) is not sure, but it would definitely be a shame to have 250Mhz or more on the Teensy 3++/4 or what have you, chewing through bits like lightning, only to end up running out of bits to chew.
 
Pensive said:
Sorry missed this question: Easily answered.

In my case, at the moment, I'm using 4.5Mbytes for one set of samples for 16 pads. But I need an additional set for another 16 for a standard drumset at least, plus a collection of loops/samples for beatmashing.

So basically I'm already full, having reduced my samples to mono and shortened some of them against my wishes.

So yes, to apply a new patch with different samples for another track, would require a wipe & flash new data from the SDCard, largely to the whole chip.

My reasoning behind the 128Mbyte chip is that I could conceivably provide 15 sound patches for finger drumming, 10 drumkits, and a large collection of loops, and have this all flashed to the one chip, allowing any track to use any sample, at any given time, as much as they like.

One could then allow soundpacks which flash the entire chip with all new sounds, but it would not be considered as a live event. you would build your set on the contents of a single soundpack.

This is my dream, and whether it will ever be realised (i think it will) is not sure, but it would definitely be a shame to have 250Mhz or more on the Teensy 3++/4 or what have you, chewing through bits like lightning, only to end up running out of bits to chew.
Click to expand...

From what I understand the Audio expander uses I2C, which is much slower then the up to 25Mhz you can get out of the SPI. If you did a continuous read on the 128Mbyte chip you can read the entire chip in about 41 seconds. Not sure the Teensy 3.1 could do much at that speed but the bottleneck is the erase speed, if your reading/writing its pretty fast but erasing takes forever.
Adding extra chips would probably be the easiest solution, erase takes a fairly long time, the 1Gbit chips take several minutes to fully erase.
 
Last edited:
Frank B said:
Not sure what you mean with "audioexpander", but if you're talking about the SGTL500: It uses I2S for Audiodata. I2S != I2C !!! I2C is for control only.


FRAM is a great solution, no erase-time, fast access-time. but very expensive.
Edit: and small.
http://www.digikey.com/product-highlights/us/en/ramtron-fm25v20-f-ram-memory/2675
Click to expand...

I was not aware of the I2S.

I can see occasions where the extra ram space and speed of the FRAM would be more useful then massive amounts of space with slow periodic erases.

Say for instance you have several lookup tables and they surpass the available progmem and ram space you have. The math to create the information on the fly(some complex formula with dozen + variables) is much slower then creating the table on startup and storing it in external RAM.
 
Donziboy2 said:
I can see occasions where the extra ram space and speed of the FRAM would be more useful then massive amounts of space with slow periodic erases.
Click to expand...

that's why the 23LC1024 cropped up further up-thread. it's more or less pin compatible with the W25Q128FV. either can/could be used with the audio board; the latter for storage, the former for longer delay lines etc; at least that was the idea, i guess.
 
mxxx said:
that's why the 23LC1024 cropped up further up-thread. it's more or less pin compatible with the W25Q128FV. either can/could be used with the audio board; the latter for storage, the former for longer delay lines etc; at least that was the idea, i guess.
Click to expand...

Exactly :)
And a bit extra RAM could be useful for the LC, too.
 
update

Just a quick update. I put together some of the 16 Mbyte boards and sent them out to be tested with existing libraries. If the feedback is positive and the boards prove useful I will offer them for sale at Tindie.

I finally got around to designing the next size up; a 128 Mbyte SPI flash add-on that is almost the same diminuitive size as you can see here:

i.png

It has a small over hang but it wont interfere with the I2C port on pins 16/17 on the Teensy 3.1. I submitted the boards to OSH Park and when I get some assembled and tested I will sell these too. This is a bit cheaper per Mbyte than the 16 Mbyte option and requires 2 chip selects because it is really two separate 512 Mbit dies in a single package.
 
The Micron N25Q512A SPI flash chip (512Megabits) have two die on one chip, as do Spansion and others, but Micron's has but one chip select. There's an address MSb decoder inside. Saves a pin, simplifies software a bit.
Like the others, these are $1 or so in modest volume. Less in die form.
 
One dollar for 512 Mbit is a great deal. These Spansion 1 Gbit chips are ~$6.50 in quantities of 100, or 5 cents per megabyte. The S25FL127 16 Mbyte chips on the first board is about 10 cents per Mbyte. There are plenty of pins available for an extra chip select even on these appallingly small boards but if the cost of Micron's Mbytes is really less that 2 cents then this would make it the best choice, all else being equal.
 
Last edited:
Are there any practical solutions currently available that can be used to replace a modest size (4GB) SD card?
 
The SPI flash boards here go as high as 1 Gbit = 128 Mbyte. There are higher capacity chips that IIRC go to 1 Gbyte but they require parallel communications (more pins) and, of course, they are physically larger so the shields or add-on would be ~twice this size. One could add more than one SPI flash chip, meaning two or maybe four with a doubling of the add-on footprint but then you would need two more chip selects for the Spansion solution. I think 256 Mbyte is the practical limit for a small board, 512 Mbyte for a larger add-on, and 1 Gbyte requires something other than SPI.

Edit: Just took a look at the Micron family. Can't get the data sheet without registering at their site but this shows a 10.5 x 13 mm size for a 4 Gbit SPI flash chip. This is doable even in a small add-on...

BTW, what does one do if pins 10 - 13 are required for another peripheral like an I2S mic or radio? Can these SPI flash chips be multiplexed with other peripherals?
 
Last edited:
For SPI sharing, there's Paul's SPI Transactions - but for a wireless radio on SPI, the latency has to be kept low or there will be lost messages and error-correcting retransmissions if using the reliable datagram option in a stack like RadioHead.
Any other real-time/latency sensitive SPI thing that's widely used?
I do wish we had an MCU for Teensy that has 2+ SPI ports. The MCU I'm using on a project has 3, in a 64 pin package.
 
Status
Not open for further replies.
Back
Top