Memory board add-on requirements

Status
Not open for further replies.
onehorse

onehorse

Well-known member
Since Frank B made the suggestion for a memory board add-on or some such, I would like to follow up by asking what such an add-on board might look like. For my purposes two I2C 256 kByte EEPROMs have been plenty but I recognize that some would like 1) more memory, 2) faster, and 3) communications via an SPI port.

I would like to keep the board small, say 0.3 in x 0.7 in (3-pin positions wide) or possibly 0.4 in x 0.7 in (4-pin positions wide) although the latter might interfere with the I2C port at pins 16/17 on Teensy 3.x (maybe not a problem on Teensy LC).

This means using 5 mm x 6 mm WSON packages, which for flash memory allows up to 128 Mbit of 16 Mb of fast (~100 MHz) memory. I have ordered some of these flash chips from Digikey (Spansion and Winbond) and will design a simple add-on for testing purposes and for me to get familiar writing sketches using SPI.

One attractive possibility is to use digitalWrite (HIGH/LOW) to power the add-on board as I have done in other instances where the power draw is much less that 10 mA. This would make it easier to design if I don't have to take power from the end 3V3/GND pins.

But I would appreciate some input: what would the "optimum" memory add-on board for Teensy 3.x/LC look like given the 1) small size and 2) SPI constraints?

If we can reach some kind of consensus I would be happy to design, assemble, and offer for sale such a board.
 
With the existing Teensy boards, it's hard to piggy-back 2+ boards.
Also hard to provide about 4 or so options for the NSS bit so that one can de-conflict.
 
The C/C++ code I wrote to talk to the generic SPI flash - Spansion FL127S in my case is...

C code part 1 - Is a C++ class that your application can use to store data. The flash erases are done as needed according to data size.
The class also has flash read. Your app must provide the address within the flash space (16MB in the FL127S), on a sector boundary.
This chip's sector sizes vary; the first is 4KB, then the rest are 64KB. Other vendor's chips do the same but use different mix of sizes.
The idea is that you can read the 4KB sector, alter, then write it back.
My C++ code is 175 lines and about 100 in the .h file.
Uses the Arduino SPI library.
Primary use: Receive new program memory code over wireless ($5 sub-GHz radio modules) and save it to flash. Then reboot itself. Bootloader sees the code in flash and rewrites program memory with it, then marks it "used" and reboots.
But one can write whatever into the flash and read it later. Or put a file system (FAT) on top of this code.

C code part 2 -
This code is small/tight, to go into a bootloader. Does read, no write. Knows where to look for and validate flash-stored new-program code. If found, read it and rewrite AVR program memory, mega328 or mega1284. No Teensy 2 o 3 version for obvious reasons.
This code fits into a 1024 byte boot area along with means to rewrite program memory from the UART (STK500). So it'll do either the UART or the wireless remote reprogramming scenario.
I dearly wish we could do remote ethernet or low cost wireless reprogramming with Teensy 3 so industrial applications become practical.
 
I dearly wish we could do remote ethernet or low cost wireless reprogramming with Teensy 3 so industrial applications become practical.
Click to expand...

This would be great and would open the door for many more T3.x/LC applications.
 
The C/C++ code I wrote to talk to the generic SPI flash - Spansion FL127S
Click to expand...

Code 1 seems small enough that even I could understand it. I just want to know what must seem obvious to most people here, how do I write functions to read/write to a device using SPI. So if you could provide a link to the source for code 1 I will adapt it (if necessary) to read/write from the same 16 Mb flash chips, the Spansion and Winbond brands. If I can get it to work as well as the read/write to/from eeprom I will be thrilled.

When I have the first board designed, assembled, and working I'll post the results.

Is there any advantage in having both 16 Mb flash and 256 kB EEPROM on the same board? How about 2x16Mb flash chips since there is another chip select on pin 15 of the Teensy 3.x? It might be possible to increase the memory size with a single flash chip but the footprint increases pretty rapidly above 16 Mb; I don't know if larger memories will remain appallingly small.
 
I designed a simple 16 Mbyte SPI flash memory board and will assemble and test it in the next few weeks. Here is what it looks like:

SPIFlash.front.png

Once I get it to work I will consider adding additional memory and/or memory types, if desirable.
 
Can you add a second empty soic-8 ?
Click to expand...

Yes, yes I can. But for what purpose?

Suggestions for improvement are welcome! Please elaborate on the purpose you envision for an extra SOIC-8 device.

There aren't any pins left over for other devices at the moment. I have thought about making it four pins on a side to allow access to the CS on pin 9, or leaving off the reset function and using the CS on pin 15, then a second SPI device could be added. All options are open; this is just the first board to test how these flash devices work with the Teensy.

re collaborating on trying my SPI code on this board
Click to expand...

I could test it with SPI-RAM.
Click to expand...

Yes, I would appreciate help testing it. Perhaps the easiest thing to do would be to send you two assembled boards and you could test and optimize your respective codes for them. I would like to understand how to use SPI flash but I would be happy to simply use someone else's well validated library!

Another likely improvement is a bypass capacitor on the VIN line. The datasheet did not show any and the Teensy 3.3 V power pin is pretty well regulated, still it is good practice and should be added.

This board is so simple and the flash chips so cheap I can imagine it selling for well under $10 on Tindie.
 
Last edited:
For me doing hardware is the easy part its the code that always drives me nuts. My current project which I have been working on and buying parts here and there for is an Electric Gocart. I plan to have 2 Teensy3.1's, 1 for the motor controller and 1 to run a 2.8" touch screen and do data-logging.

I have done the entire mechanical end and boards on Autodesk Inventor and Eagle already, I am just ordering parts and testing if it works the way I need it to. The Data-logger is one of the last things I am still unsure about. An SD card can be very slow at times so I started looking at spi Dataflash and Flash. From what I have read on the AT45 and the various "25" series chips they all seem to function roughly the same way.

One issue to be aware of is that each manufacturer has different specs for Erase speeds, so if your just storing data to be reused like audio its no problem but if your logging data and erasing the oldest pages you will have issues if your running at high speeds. My project is not exactly high speed but I need to keep from conflicting with other things I will be doing like receiving new data on Serial1 @ 4mhz using RS485 for distance. So if an erase or read drags on to long it will create conflicts.
 
Appreciate the info. I likewise find the hardware the easy part. I hope to have some help on the software end from stevech and FrankB, and maybe others.

I designed this board to accept the standard pinout for "25" series 128 Mbit flash. That way I (or we) can test a variety of chips to see which might be optimum for different uses, or maybe settle on one overall best choice for a small production run.

Some open questions include: Does it make sense to have two 128 Mbit flash chips on this size board? Does it make sense to increase the memory to 1 Gbit on a slightly larger sized board? Does it make sense to have more than one kind of memory on such a board? Should unpopulated placeholders for other chips be added (still don't quite understand the purpose of this one)?

The idea here is to start simple and work toward a generally useful memory add-on.

Should have the first few boards next week. If you send me you mail address by PM, I will send you a board for testing for those who know about the software side. For hardware weenies, you can order the board from OSHPark or design your own.
 
onehorse said:
Some open questions include: Does it make sense to have two 128 Mbit flash chips on this size board? Does it make sense to increase the memory to 1 Gbit on a slightly larger sized board? Does it make sense to have more than one kind of memory on such a board? Should unpopulated placeholders for other chips be added (still don't quite understand the purpose of this one)?
Click to expand...

as for audio uses, i'd probably say yes. having played around with the "25" series stuff for a while now, it has its definite appeals (ie compared to SD); while 16MB is ok for many purposes, it's not all that much. so 1Gb sounds attractive. on the small board, is it wson or soic-8? wson doesn't seem to be that much smaller; when using soic it could be used for the SRAM (23LC1024) ones, too?
 
onehorse said:
Appreciate the info. I likewise find the hardware the easy part. I hope to have some help on the software end from stevech and FrankB, and maybe others.

I designed this board to accept the standard pinout for "25" series 128 Mbit flash. That way I (or we) can test a variety of chips to see which might be optimum for different uses, or maybe settle on one overall best choice for a small production run.

Some open questions include: Does it make sense to have two 128 Mbit flash chips on this size board? Does it make sense to increase the memory to 1 Gbit on a slightly larger sized board? Does it make sense to have more than one kind of memory on such a board? Should unpopulated placeholders for other chips be added (still don't quite understand the purpose of this one)?

The idea here is to start simple and work toward a generally useful memory add-on.

Should have the first few boards next week. If you send me you mail address by PM, I will send you a board for testing for those who know about the software side. For hardware weenies, you can order the board from OSHPark or design your own.
Click to expand...

Do you have any specific manufacturers you plan to use?
I have had my eye's on the Microchip parts atm, I plan to order some shortly(next week or so) and start playing around with them, most likely using the soic8 64Mbit versions.
Another question is how indepth of a library is needed? Is read/write and erase page/sector/chip good enough. Will chip specific registry information be needed, or is there a true standard that they all follow.
 
I am going to start with Spansion S25Q127 and Winbond W25Q128 chips. I would think 128-Mbit Microchip flash in a WSON-8 package would work for this board also.

I expect to write simple read/write functions using the chip registers. I realize from a quick perusal of the data sheet that these chips have a lot of functions, including the ability to accept dual and quad data streams. I probably won't get that deep into it. I am hoping existing SPI flash libraries can be used to make these chips work.

so 1Gb sounds attractive. on the small board, is it wson or soic-8?
Click to expand...

Looks like the soic-8 is 5.3 x 8 mm, the WSON-8 is either 5 x 6 mm (this board) or 6 x 8 mm.

At 128 Mbit small WSON-8 or SOIC-8 is available.

At 256 Mbit large WSON-8 or SOIC-16 (at 10.3 x 10.3 mm).

So at best we might fit 2x128 Mbit 5 mm x 6 mm WSON chips on this small board (17.7 mm x 7.7 mm).

At 1 Gbit it is SOIC-16, or S70FL01GS which is a 6 x 8 mm BGA with two chip selects. If I increase the board size to 4 side pins (10.2 mm x 17.7 mm), then we could use this 1 Gbit chip with the two chip selects and keep the reset and write protect out also. There are 10 IOs required for this chip. This looks like an attractive solution. The SOIC-16 is a bit too large for my taste. The only problem with this board size increase is that now one of the I2C ports is sacrificed. The 1 Gbit chip is $7.50, about the same cost per Mb!

Of course, we can fit anything on an even larger board.
 
Last edited:
I used the winbond for a while now and can say that reset and writeprotect are not needed. 2/4 bit datastreams are not really useful for us, because there is no corresponding device in the teensy, and if you wan to use GPIO instead you need at last 4 pins on one port and a very good optimized loop to archive an advantage (i tried this with parallel SD - its possible but there are not much pincombinations that are usable (Port D0..D3 for xample) without too much shifts.

But i would like the possibility to use SRAM (maybe with an "empty board where the user can solder the preferred memory?). But my wish for RAM is a bit special.. don't know if there would be many users...
 
My two cents:

I've been testing Franks code with my beatmaker and it's very solid, and very fast, more than 16 channels of polyphony (44Khz, 16bit). I don't have enough buttons left on my device to trigger any more concurrently. :)

I'm all out of space already. I'm going to have to write a loader to load different sound patches from SD "on the fly".

but to use the term "on the fly" is misleading, because writing to these chips is SLOOOWWWWWWW. Just changing songs is going to take a good minute or two.

So it limits the usability of my device in a live situation. Not the end of the world, but nevertheless.



So I am +1 for a 1Gbit chip, 128 Megabytes would be plenty to store a plethora of sound patches and not only switch instantly between them but also to combine them into one song together, at will.

I would suggest you design this board not for the Teensy 3.1 but for the next generation. I'm sure it will open up further possibilities with touchscreens etc, 24bit/96khz audio (perhaps) and 16 Mbytes will quickly start looking small when you start needing media to match the CPU power....
 
mxxx said:
so 1Gb sounds attractive.
Click to expand...

Some of the larger Spansions call for up to 100mA of current.

Pensive said:
but to use the term "on the fly" is misleading, because writing to these chips is SLOOOWWWWWWW. Just changing songs is going to take a good minute or two.
Click to expand...

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. Most 64Mbit chips are 4Kbyte sectors, many of the 128Mbit chips and larger use 64Kbye sectors which take much longer to erase.

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?

And Frank B have you played with any of the FRAM chips?
 
Last edited:
Donziboy2 said:
Some of the larger Spansions call for up to 100mA of current.
Click to expand...

oh, i didn't study the datasheets all that closely. well, that's for page program, read doesn't look that bad. probably not worse than the average SD card. though true, might not work as a add-on board. (which i admit to never use)
 
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.
 
Last edited:
Status
Not open for further replies.
Back
Top