There seems to be a lot of interest in moving large amounts of data with the Spark, like for images for example. However, the Spark’s limited RAM resources and the slower external SPI flash limit the speed at which data can be moved. I was thinking that an external SPI (or even I2C) SRAM/FRAM/MRAM shield or module would be an interesting addition.
timb, BDub, any thoughts?
I2C is currently limited to 100kHz (fastest is really 400kHz if we enabled that).
SPI would be the way to go as you can clock it up to 36MHz. At some speed around 4.5MHz or 9Mhz the increase in speed at which you are clocking the SPI bus starts to lose it’s value because the function calls to the SPI Class take so long. DMA transfer would be the best in that case. As long as the R/W speed of SPI is faster than the Peripheral you are sending the data to, you should be ok without DMA.
A Micro SD / SRAM shield would be sweet. You could read in data from SD to SRAM, and then use it from SRAM super fast.
or just use FRAM for fast non-volatile storage, at the cost of it being a little more expensive than SRAM & Micro SD holder.
Nice thing is there’s no level shifter needed for the SD Card.
There’s also nvSRAM … it operates as SRAM, but in the event of power failure or power glitch, SRAM is written to non-volatile memory.
Lot’s of options!
A micro SD shield sounds useful. Like for logging lots of data and then blasting that data out to the web once a WiFi signal is present.
Using the SD cards makes it real easy to increase or decrease storage capacity at minimal cost.
BDub, I like your idea of combining microSD and a RAM component. Regardless of size, the nice part is true random access without the need for page boundaries like eeprom. My only concern is SPI sharing. I know this is in the backlog but not sure where it’s at.
In another thread, a member posted a port of SDfat that I will be testing shortly with a breakout I have. I am doing local compile so all the latest updates will apply. 
Hey guys, this is actually something I talked to @zach about and have on my design list. Give me about an hour and I’ll show you something cool! 
1Mbit (128KB) 30MHz SPI FRAM + MicroSD Card Slot
Why FRAM (Ferroelectric Random Access Memory) you ask? It can read and write nearly as fast as SRAM while being non-volatile (permanent storage without power) like Flash! You don’t have to erase an entire block before writing like Flash and you can write one byte at a time if you want. Some people want SRAM, some people want Flash and others want EEPROM. Having FRAM onboard answers all three of those requests!
FRAM can write at low voltages (1.8 to 3.6V) at just 5mA (which kills flash) and only draws 15uA during standby! Also, unlike EEPROM and Flash, FRAM has a virtually unlimited lifespan (the cells can be re-written at least 10^13—Ten Trillion—times per byte)!
Since there’s so much space left on the board, I might add some dedicated SRAM (or at least the footprints for it) for video/display use.
Anyway, since this is such a simple board it might be released relatively soon! Oh, and the routing on the board is not permanent! I’m going to go back in and re-do it after I move some stuff around and do my copper pours.
timb, which FRAM module are you considering. Cypress also has the 256KB FM25H20. I agree with you on choosing FRAM over others. I am not sure why you would dedicate some SRAM though. We have the 1.5MB of external flash (once the library is finished) and a 256KB FRAM/microSD combo would seem to fit the slow (microSD) and fast (FRAM) requirements.
What would be cool is to add an MPS430 that makes the FRAM act as a fast cache to the microSD. Or act as a microSD to FRAM loader to save on lots of I/O. The Spark could send commands via I2C to have the MPS430 fetch a block of data or file or whatever from the microSD and load the FRAM with it. You would have to isolate the SPI bus from Spark’s during the transfer so as not to hog the bus. Just thinking out loud mind you.
That is really nice–I like the combination of a faster RAM and SD card!
I would question the use of FRAM when (1) you have non-volatile SD card storage and (2) it costs about 4 times the price of SRAM for the same density and speed. I can get SPI SRAM for below $2 per Mbit, but I see prices just under $8 per Mbit for FRAM at the same size and speed.
I was looking at the Fujitsu MB85RS1MT which is the cheapest I could find, at $6/ea ($4.50/1k).
You know, TI just released the new MSP430FR5969 (FRAM Wolverine Line) which features 64KB of built-in FRAM and 3 SPI ports (two 10Mb/s and one 8Mb/s). Connect one to the Core and the other two to the external FRAM (or SRAM) and SD Card. Just have all the data funnel through it! Interesting idea.
Like I said, it fits three use case scenarios: People who want SRAM, people who want Flash and people who want EEPROM.
Maybe I just want to do some data logging in combination with the battery shield? FRAM is non-volatile storage that's extremely low power. If you can sell the shield for $10 or $15, just having the FRAM on there would be useful for a lot of people I think. (I've seen 512Kbit FRAM Arduino Shields sell for upwards of $40 on Tindie!)
Like I said, I could also add footprints for additional SRAM if people just wanted some volatile cache or something.
I think there’s something to be said for keeping these shields more like a reference design for various hardware that you can integrate into an overall product, and not do too much stuff with external micros and API’s that are harder to untangle when you want to put everything onto one PCB. I know you love those MSP430’s though, so that’s going to be a hard sell for you.
The flip side is sometimes people will just want to stack up 3 or 4 shields, dump in all of the libraries and get something prototyped that will never go to production.
The latter approach tends to not scale well though. There is definitely a limit to how reliable stacking all of these shields will be, especially considering we are talking about high speed data transfer, motor noise, switching power supplies, power management, wifi, etc…
Yeah, as much as I’d love to throw a 43oh on every shield, I do have a hard time justifying it for a plain SD Card Shield! 
All the shields I’m working on are designed to have the best combination of BOM cost and feature set, while still being 100% interoperable. I go to great lengths to make sure I keep noise out of places it shouldn’t be. The Core Motion Shield I’m working on has some pretty rad noise filtering on it so I can’t wait to do some testing on it!
You know, in reality when I put an MCU on a board, it really ends up as more of a “programmable IC” or an FPGA-light, if you will. Often times I can throw an $0.80 microcontroller on something an eliminate $3 of individual parts. Engineers have been doing this with PICs and 8051s for years—in production products, so it’s nothing new; the only difference here is I’m using an MCU that’s very accessible to the hobbyist.
If my firmware is 100% open source and the chips themselves are widely available, there’s no reason people can’t duplicate the design in a product. Plus it’s not even like they’ll have to dump libraries in or anything as the Core-side code for the Power Shield, Motion Shield and Wireless Pods will be part of the Core Firmware.
All that said, @peekay123’s idea does have merit. It would be cool to have up to 1MB of high-speed SRAM hooked to an MCU that could cache data to/from an SD Card. Put a FRAM based MCU on the board and have it just act like dumb FRAM with the ability the cache/store from an SD Card, then add 8 SOIC footprints on the bottom of the board so the user could add up to 1MB (8Mbit) of Microchip SPI SRAM.
That would basically be an easy to use way to add storage/cache to the Core. The reality is, if someone was going to build a product they could easily add an SD Card reader themselves. A shield like this would be good for rapid prototyping and hobbyist use. Especially if you could sell it for around $10!
@timb I say build the most feature rich version you can even if it cost $5 extra bucks. I like that about you, your always looking to use the latest and greatest technology and cram it into the size of a quarter. I think in the end people always want the best and since were only taking a few extra bucks the thats not to large of a hurdle to jump to get the best vs just enough to get the job done.
I like the low power memory. I can see the core being used in low power mode for data logging and then WiFi pumping that collected data to the web when the core comes in rage of WiFi Networks.
Just my 2 cents.
timb, I believe the idea of having a small, nimble and cheap processor on a shield should be a standard! With SPI and I2C you have so much capability. For example, with the microSD, you could use an I2C command to see if the card is inserted instead of using a digital pin. Besides caching, you could, much like the Digole concept, implement the SD interface library onboard, leaving small (standard) stubs on the Spark side. Extend that to motor control, LED control, etc. Lots of possibilities 
I think a lot of engineers are used to doing things with independent, monolithic chips because up until the last 10 years or so, microcontrollers were expensive, hard to program and had large footprints when you added in all the external components you’d need. That’s why I love the MSP430s so much, inexpensive, zero external components (they can run full speed with the built-in oscillator) and easy to program! Like @peekay123 said, spreading the computational power around is the future. I call this method of design “Micro Distributed Computing” and it falls straight inline with the Internet of Things mentality.
Take ThingM’s blink1 for example. It’s literally a tricolor LED you plug into a USB port. It’s running an ATtiny! I know what you’re thinking, it’s USB so it has to use an MCU of some type. Well, what about their BlinkM LEDs? They’re the same tricolor LED designed to be daisy chainable and talk over I2C. That’s literally an LED with a dedicated MCU!
So I don’t think it’s really a stretch to add MCUs to the shields I’m designing. In addition to potentially reducing the BOM cost, it also allows me to add some really cool features and get my product out the door quicker. How? Take the Power Shield, for example. Because I’m using a dedicated MCU, I’m able to add things like MPPT solar tracking, while keeping the cost and size down! I can also send the board to production before I’m finished with the firmware, since I can easily do an OTA update I’m able to get the board into your hands that much sooner.
It also allows me to add features I may have never even thought of when designing the board, six months down the road. Lastly, it makes your Spark Core that much more powerful! Take the Core Motion Shield I’m working on: Since it’ll have a dedicated MCU onboard, you can control 4 motors with just two pins (I2C); it’ll also have inputs for analog and digital IR proximity and distance sensors, great for keeping your robot from bumping into something or following a line, plus SR04/SR06/Maxbotics Ultra Sonic Rangefinders! That along is worth it to me (because I know how hard it is to deal with multiple ultrasonic sensors, since you have to use blocking code to measure a pulse width)! In addition to Robotics, the Core Motion Shield will also be supremely useful for security related stuff. You could use the motion inputs to monitor outside your house and send an alert to your phone; you could then hook the motor PWM outputs up to a larger motor controller so you can drive a gate motor, or just use a digital output to open your garage door! The Core can do what it’s good at: Making data available on the internet, while the co-processors on these shields can take care of all the time sensitive background tasks. It just makes sense to me!
Damn, that was a wall of text!
Anyway, I was thinking… You know, I think I’ve got room to add a MicroSD card holder to the Core Power Shield… I also noticed that Cypress Semiconductor’s SPI FRAM chips have identical pinouts to their SRAM chips! So I could put an unpopulated footprint on the Power Shield and allow the user to solder their own chip down if they need more storage. Wrap it all up into the Power Shield and damn son, that is a power shield!
So timb, what are you doing tonight… well, what you do every night, timb… try to TAKE OVER THE WORLD!!!
Dang son, that would be one fancy shield. Do you have enough space on the MPS430 for all that functionality?
Did this ever come to life? Would love a shield like that…