Skip to main content

You are here

Using Memory Plug - any filesystems ?

6 posts / 0 new
Last post
PavelE
Using Memory Plug - any filesystems ?

All, received my first Memory Plug and looking for a better ways to use it.

Of course I could use direct I/O commands in every sketch, but a special filesystem would be much better ;) Especially if it is a library could be re-used.

Lets looks what normally required from such a FS on a flash device:
= Index or Directory (could be just root one)
= Way to create/delete/list files/data streams
= Way to read/write data to files
= Implement paging for fast read/writes
= Hide physical implementation (number of chips etc)

So questions, of course:
= Did somebody done something alike?
= ANSWERED: Not an issue - Does Memory Plug EEPROM chips have any significant wearing out issues?

Links:
= http://jeelabs.org/2009/08/30/memory-plug-design/
= http://jeelabs.org/2009/09/19/memory-plug-v1/
= http://jeelabs.org/2009/11/15/memory-plug-redux/
= http://jeelabs.org/2009/12/13/serial-datalogger/
= A Library to Ease Accessing Flash-based (PROGMEM) Data
= 6.7 mln cycles for ATmega168 EEPROM and http://jeelabs.org/2011/05/12/assessing-the-damage/
= Couple of tankslappa post of how to use MP
= MP M24M01 chip spec sheet
= Seriot data format
= MemoryPlug classes: MemoryPlug and MemoryStream
= I2C classes: PortI2C and DeviceI2C
= Post about design of PortI2C

PavelE

Ah, found forum post "Memory Plug - read after write returns FF FF FF...". It states:
The memory plug code ensures that a 5ms delay is inserted between successive saves.

Looks like my idea of using Memory Plug for a scope is just died ...
What are actually limitations (like timings) of using Memory Plug ?

martynj

@PavelE - a scan of the M24M01 chip spec sheet is worth your time.

PavelE

Thanks.

The good news are:
= the page write (256bytes) is possible and it is the same 5ms. So paging is required...
= Declared in specs "More than 4 million Write cycles", so wearing out should not be an issue to be concerned about

What is I2C bus mode (speed) JN is using? The lowest one (100kHz), right?

PavelE

OK, lets go into functional design a bit:

= First about FS organisation:
FAT-like or just an array. FAT is perfect for more files, but much harder to code. Array could be one per memory chip - easy to code, especially if every element is a page (128k == 1000 pages). For beginning I like array.

= Second is how to hide/switch chips/banks:
When a memory bank is used for a single test run, a simple logic like overwrite oldest of available banks with new data could be used.


= v1 looks like:

  • Array per chip/bank
  • First page - header signature + timestamp init + counter of written pages + flags/attributes
  • Every following data page: data signature + timestamp + data of a custom format
  • A library to support operation: list bank, init array, list pages, write page, read page

    Implementation plan:
    = Code an extra layer on top of JeeLib
    = ? Patch to MemoryPlug::save to avoid page "roll-over" situations
    = ? Patch to MemoryPlug::save to check output of I2C write() call
    = ?? Fix I2C speed in Ports.h. see "@todo Speed up the I2C bit I/O, it's far too slow right now."
    = ?? Make a clone of JeeLib with async "stop()"

  • PavelE

    Now a really good news: According to specs section 5.1.2 the "Page Write" is only different from "Byte Write" by not doing the "Stop" operation after the one bytes send, but after "from 1 to 256 bytes of data" sent.

    This means that, I think, no changes to the existing Ports.cpp code needed to do "Page Write".

    The only caution needed about page boundaries (bold is mine):

    "If more bytes are sent than will fit up to the end of the page, a “roll-over” occurs, i.e. the bytes exceeding the page end are written on the same page, from location 0."

    Premium Drupal Themes by Adaptivethemes