Memory board add-on requirements

Status
Not open for further replies.
Yes, I am thinking 1 Gbit flash on SPI0 and an I2S microphone on SPI1 (or wherever the I2S port on the LC is) could allow ~40 sec of stereo audio to be recorded and used for internal FFT or other analysis.

This 1 Gbit Micron chip indeed has one chip select. This makes it easier to add two of these to a small add-on board for a total of 2 Gbit or 256 Mbyte on a 0.7 x 0.3 inch add-on at the end of the Teensy with the available 8 pins there, leaving pins 16/17 for the I2C port free as desired. They are not ~$1 though, digikey has them listed at $7.50 each in lots of 100, about $1 more than the Spansion chips.
 
Last edited:
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?
The chips yes, if they are deselected with cs (and that's the reason for the needed pullups on cs! - "default" deselect) they are invisible on the bus.
But the kinetis-on-chip periphals can not be multiplexed.
 
I expected that these Spansion chips would have internal pullups on CS like they do on RESET and WP; I didn't add any external pullup resistors.

If I de-select any SPI add-on device by holding CS HIGH (default) on all of them, then can I use the SPI port for the other Kinetis-on-chip functions like I2S, which also (in the simplest configuration) use Teensy 3.1 pins 11, 12, and 13?
 
I expected that these Spansion chips would have internal pullups on CS like they do on RESET and WP; I didn't add any external pullup resistors.

If I de-select any SPI add-on device by holding CS HIGH (default) on all of them, then can I use the SPI port for the other Kinetis-on-chip functions like I2S, which also (in the simplest configuration) use Teensy 3.1 pins 11, 12, and 13?

No, there is no pullup on CS, and i've never seen a built-in pullup on CS. I don't know why.
(BTW, i have a small, but gowing collection of datasheets in the "pdf" folder here: https://drive.google.com/folderview?id=0Bx2Jw84lqebkb2xIYUR4MU1rdzg&usp=sharing#list)

Yes, i think, with CS HIGH the other signals should be ignored, so it's possible to use them for other functions.
But CS should be pulled HIGH _before_ the other kinetis periphal gets initialized, to prevent that the flash interprets some signals as command... i think the most interesting moment is the time before and during setup()
 
Yes, there are internal pullups on RESET and WP but not CS. This can be handled in software as in the dorkbot tutorial so for now the testing of these add-on boards can continue, but I agree good practice would be to add a 0402 4K7 pullup resistor on CS as I have already added a bypass cap on VIN.

SPI is still a bit mysterious to me but it is becoming a bit clearer the more I work with it!
 
Yes, there are internal pullups on RESET and WP but not CS. This can be handled in software as in the dorkbot tutorial so for now the testing of these add-on boards can continue, but I agree good practice would be to add a 0402 4K7 pullup resistor on CS as I have already added a bypass cap on VIN.

SPI is still a bit mysterious to me but it is becoming a bit clearer the more I work with it!

fwiw: i'm regularly mixing SD and spi flash and this works entirely headacheless as long as the CS is one of the hardware CS, with no extra precautions taken (ie external pull-ups, pulling CS high, etc). with certain libraries (SPIFIFO notably) it quickly does get out-of-hand as soon as CS is any other pin (as described in some other thread). i have no clue what might be going on; but using transactions and/or using pull-ups doesn't seem to help.

i guess i'm saying there seems to be even more mystery to CS than pull-ups. it shouldn't matter though for those add-on boards.
 
"onehorse has exceeded their stored private messages quota and cannot accept further messages until they clear some space." :)
 
Update: first few boards have been assembled and tested (thanks Frank B and stevech!). They work well and, when I get the newest boards back from OSH Park with the bypass capacitors and CS pullups I will be assembling a small number for sale at Tindie.

Here is what they look like:

S25FL127.front.jpg S70FL021G.front.jpg

I hope these meet most people's needs, but i am still open to making modifications and improvements, as well as tackling other solutions to cheaper, faster, smaller, and better memory on-board Teensy.
 
Last edited:
What method are you using to read/write? Any possibility of accessing these memory chips using a FAT files system or similar? How about across multiple memory chips?
 
For now I'm just using a slightly modified version of the Audio Library SPI read/write functions put together for me by Frank B. Stevech has a more complete library which I hope we all get access to soon.
 
At the moment, i think it's better to wait until we know more about Pauls plans regarding usb-mtp before doing further steps.
@EK701: Out of curiosity: why do you need a FAT ? What do you want to do with it ?
 
Re SPI flash manager I've done. I've been testing using an ARM cortex board with several SPI flash chips.
I call it a manger as it handles an array of 1-n SPI flash chips. The array of chips, to the API, looks like one address space.
The manager uses library I/O calls for SPI flash send/receive of commands and another part of the library for the data transfers using DMA.

A bit more testing, then I check on releaseability as is or with reduced functionality.
Then a few simple changes to use Teensyduino or Arduino low level SPI calls and 99% of the code stays unchanged.

The next thing is a simple named file system for flash, with a linked list of files so as to avoid erasing flash or using a complex wear-leveling algorithm.

The API is just
read, write, erase
with a flash address of 0 to n <= 4GB. Chip selects are hidden internally.
The rarely used erase takes the flash array address and erases the chip and sector in which that address falls.

One read or write API call can span sector and chip boundaries - to make these things transparent. This was hard.

Several SPI flash chips are handled by the manager but an array must be all like-kind. 128MB per chip is supported and these chips are inexpensive.

It may be that few microprocessor apps need such a multi-chip high capacity flash SPI array! Big chips simplify the file system for flash - avoiding erasures and reducing the number of chip selects needed.
 
At the moment, i think it's better to wait until we know more about Pauls plans regarding usb-mtp before doing further steps.
@EK701: Out of curiosity: why do you need a FAT ? What do you want to do with it ?

I want to replace a micro sd card.
 
I hope the S70FL01G is one of them!
Yes - I plan to verify-test with that in the next week.

A snippet from the code
Code:
#if USE_SPANSION_FL512S || USE_SPANSION_FL01G
	/* Spansion Corp. flash SPI FL512S SPI Flash memory or the FL01G which is two FL512S in one package - NOTE!!! two chip selects needed for the FL01G.
...
#if USE_MICRON_N25Q512A

If the Teensy SPI flash add-on board were one (or so) longer, more chip select pins could reach the board. Then if the board has some solder-bridge jumpers to choose a certain CS bit, it would be possible to stack the boards on Teensy. Or some such.

Besides the high capacity SPI flash chips simplifying the file system (no frequent metadata erases), what do people need this big SPI flash size for?
 
Extending to four pins would reach one more CS on pin 9, but would interfere possibly with the I2C port on 16/17, which I use regularly. One possibility is to put two 1 Gbit chips on the small 2 x 3 pin board and use pin 14 for some kind of toggle enabling the two CS pins for one flash chip or the other. I'll have to think about how to do this but in principle it is possible.

But to your point about usage, 1 Gbit can log 100 Hz data for about a week. Why anyone would need more than this I do not know. On the other hand, if you want to record and analyze audio at 44.1 or 48 kHz for more than a few seconds, 2 Gbits is not nearly enough!

If we were to use the Microchip with one CS per Gbit, then stacking 2 Gbits onto one small board becomes easy.

Lastly, if a lot more memory (32 Gbits) is needed there are parallel chips but these require eight IO pins, I guess. Not very space efficient.

Just took a look at the Micron 1 Gbit 6 x 8 BGA-24 chip, basically the same size and cost as the Spansion 1 Gbit chip but the Micron indeed has only one chip selet. I think I will create yet a third SPI Flash board that has two of these Micron flash chips with one of the CS (pins 10 and 15) for each to give 256 Mbytes of data in one small add-on board. Unfortunately, this will push the cost of such a board to ~$40; some might balk at such a price for "only" 256 Mbytes. The operating current for these Micron 1 Gbit chips is max 20 mA. No problemo!

Stevech, does your library support Micron 1 Gbit (4 x 256 Mbit) chips as well?

In the Micron data sheet it shows a schematic with pullup resistors on the CS lines (which I now expect) but also a pull down resistor for the clock line! This seems very strange to me. Anyone understand this?
 
Last edited:
These serial flash chips are all highly compatible in terms of SPI commands due to the JDEC standards.
Pull-up on CS is good but I do that in the CPU too.
Pull-down on clock is just hyper-conservative. The MCU can do that too, after startup.
Most have a reset pin too.

The Micron is appealing in that it needs only one chip select (really important for Teensy) - they do on-chip address decoding. My code has definitions for the Micron chip but I have none.

parallel interface - too many pins needed for a board like Teensy that lacks a 100 pin ARM package - and in those 100 pin ARMs, one usually finds an FSMC controller for parallel flash. It's more elaborate than you'd think. With FSMC, some ARM vendors provide a file system with wear-leveling and bad block remapping, etc. FSMC isn't common in embedded with 64 pin and smaller MCU.

For Teensy, there's this horrid mess that most every SPI hardware add-on uses pin 10 for NSS. That pin should be avoided in any add-ons.
 
every SPI hardware add-on uses pin 10 for NSS. That pin should be avoided in any add-ons.

This is easy enough to do with a single 1 Gbit Micron chip by using CS = pin 15. But why is using pin 10 such a bad idea? With pin 10 we could put two Micron chips on the same small board. If we need to we could use pin 9 but I'd like to understand the reason.

Just discovered this beauty from Micron; 2 Gbits per chip with one CS, so a small add-on board could have two of these for a total of 4 Gbits or 512 Mbytes, each with its own CS. That's a lot of memory! I am having trouble finding any for sale though, but I will design a two chip board which can be populated with either the 1 G or 2 G Micron chips since the pinouts seem to be identical.
 
Last edited:
On the other hand, if you want to record and analyze audio at 44.1 or 48 kHz for more than a few seconds, 2 Gbits is not nearly enough!

Add to that the fact that a 24bit 96khz board is being developed, and the need for significant amounts of RAM/Flash-ROM becomes much clearer.
 
Status
Not open for further replies.
Back
Top