Data Logging on EK-TM4C1294XL

Best is application specific.  Possibilities to look at

• FRAM (SPI) - simple and fast. May need multiple ICs. Probably the fastest development path for the storage portion at least.
• EE (SPI) - May need multiple ICs. Slower and cheaper than FRAM.
• Serial Flash (SPI) - a little more complex, inexpensive. May be the cheapest BOM cost.
• USB - Now you need USB but readily available storage. Removable
• SD Card - Need SD card and file system SW, Removable

Robert

Hi Robert,

Enjoyed & liked your, "Data storage, writing."   I agree w/your sense that "Serial Flash (SPI)" - especially the newer dual & quad (bit) manifestations appear (for now) very cost-advantaged.

Important too is speed - both write & read.   Robert - have you any recent experience with, "Speed testing" these storage mediums?   Perhaps you know of some reasonably recent link - which made such comparison.   (I'm told such is not quickly/easily found via Google)

USB & SD Card enable the "exchange" between user system & PC - which appears a nice capability - although (some) of that benefit may be degraded by coercing the memory device to "comply" w/strict PC "standardized" storage formats.   Any resultant impacts upon write/read speed - introduced by such PC compliance - should prove of interest to those here - too.

Thanks for sharing (above) and any further detail you (may) be able to provide...

(I would add - and suspect poster Robert would agree - that any recent experience by readers - reported here - would be appreciated...)

Agreed, any experience would be useful.

I've had a few projects where large amounts of data would need to be stored but they've either fallen through or recently there has been another device in the system to handle that task. I did look at SD in those cases. USB always appeared too large a complexity step.

For the smaller systems my concerns were
Security against corruption
Simplicity
Speed
Cost

EE and FRAM can be write protected by SW command. That leaves the window of vulnerability the period that the write protection is turned off. So speed pays dividends here as well.

Speed. FRAM is the hands down winner. EE generally is specified with a 5ms maximum write time (Tiva is horrendous in this regard). FRAM writes at full speed, with SPI running at 20MHz the write is finished when the clock is.

Which leads to simplicity. EE and FRAM have nearly identical protocols with the major exception that there is no required wait after write for FRAM, a big reduction in complexity. In addition FRAM allows infinite writes which often simplifies things further.

The only thing that matches FRAM's strengths is battery backed SRAM but it adds complexities of its own in HW that FRAM doesn't.

Where EE wins is cost. EE is a cheap commodity item, FRAM is quite a bit pricier.

Flash is similar to EE except it may not have the write protection and it must be erased and often written in blocks.

For small amounts of data updated in the field it should be apparent why I favour FRAM. Even more so if the updates are frequent.

Robert

Thank you, Robert - much valuable info for (all) here.   (et moi)

The appeal of the newest, multi-bit, serial flash memories is strong & growing - yet I believe their (relative) slow write speed restricts their use for "live data" capture. 

Original poster speaks to 1MB of storage - at extremely low data rates.   (I question that)

Perhaps a broader usage - of interest/value to many here - would be the highest possible (yet robust/reliable) data capture rate (likely via SRAM) and (then) the possible transfer of that SRAM stored data into a non-volatile, storage medium.   In such manner - the cost/size/complexity of "battery backed" SRAM is avoided.   (assumed here is that the measurement interval does not extend (forever) and that a method to "continue capture" - while the SRAM data is being transferred - has been implemented.)

Further (amplifying/challenging) comments invited.   (but do not venture - too close - to Robert's "light-bar" protected machines...)  (those the words of the (now) one-handed, "Captain Hook")

'Ware the hook!

Robert

Robert Adsett72 said:

'Ware the hook! 

NOW you tell him!   Minus "timely" warning - the good Captain now, "Wears the hook!"

FRAM, serial or parallel might serve as an intermediate buffer in that case. Store a sectors worth of data to FRAM, then copy to flash.

Basically use the FRAM to hide the latency of the flash and provide storage for sub sector sized data during power off. You would still need to ensure you had sufficient power before starting a flash write. You could also use the FRAM to verify the last write on power up.

Robert

Yes that's true.  Yet - in the broader use case my group envisions - more massive SRAM proves far less costly - thus wins our vote.

We're not confining our usage to, "isolated collection - from/in the field - running for long durations - from solar/batteries."

FPGA direct to SRAM is an alternative - yet still the (proper) MCU - able to "fast" A2D convert & "multi-bit digital" monitor - has its place.   (we're looking at a device w/7.2MSPS - 12 bit  capability < 10 USD @ 1K pcs.)

Sounds similar to what NIs compact RIO was designed for.

Robert

Yes - but that one is 200 times the cost of our base MCU... (and we rarely (if ever) require that "hard" of a chassis)

Yes, it's expensive even for PLCs. Although I had reason to work with a single board RIO which is less expensive and unarmoured.

Still has the disadvantage of Labview

Robert