Shop OBEX P1 Docs P2 Docs Learn Events
Any methods similar to FSRW to write to EEPROM instead? — Parallax Forums

Any methods similar to FSRW to write to EEPROM instead?

Don MDon M Posts: 1,652
edited 2013-12-08 22:31 in Propeller 1
I understand how to use FSRW- mount, open file (name) then pputc into the file, etc. When done close file (name) then unmount.

What I can't get my head around is how something similar to this would be done using the upper 32K of eeprom. Does there exist some code & examples to do this? I found Jonny Mac's 24xx512 object in another thread and can see how to write bytes, words, longs etc to eeprom. How do I apply this to what I am looking to do?

Maybe I'm making this harder than what it should be...

Comments

  • JonnyMacJonnyMac Posts: 9,107
    edited 2013-12-08 12:55
    Have you looked at this:

    -- http://obex.parallax.com/object/30

    Maybe I'm making this harder than what it should be...

    Probably! :)
  • Don MDon M Posts: 1,652
    edited 2013-12-08 13:16
    No I hadn't but I will. I guess what I'm wondering about is contiguous data being stored in order. I am guessing that either the FSRW object or the SD card itself takes care of putting the data locations in order so I was wondering if I need to do the same somehow with an eeprom object. Does this make any sense?
  • JonnyMacJonnyMac Posts: 9,107
    edited 2013-12-08 18:31
    I understand, but do you need to complexity of a file system for EEPROM storage? You may for your project; I'm asking sincerely. I never have. I've done many projects that store data in the EEPROM, hence my object devoted to it. I've designed at least two commercial products that store information that is recorded on-the-fly. My solution is a table at the beginning of the [upper] EEPROM that tells me the starting and ending addresses of the things I recorded. It's flexible enough for those products.
  • MagIO2MagIO2 Posts: 2,243
    edited 2013-12-08 22:31
    Maybe you should tell us more about the purpose of the EEPROM storage. How big is the data you want to store and what's the variety of sizes, do you have a lot of delete and create new operations or is it more like appending a lot ....? In microcontroller programming it's always about optimization. And analyzing the use cases helps to find the right strategy for optimizing.

    FAT is optimized for flexibility with the downside that special structures are needed (the directory entries and the cluster table) which need some special handling in terms of extra I/O just for maintaining. So, if you don't need such a flexibility, it's better to have another solution. I for example prefer to use SD card with huge swap-files. Having a table at the beginning of the swap-file which tells me where to find what. This table is usually read at boot-time. But during operation there is no need to open several files or append bytes to existing files. Both slows down the system, because of the directory and cluster tables which need to be read/searched through and written back ....

    What I do with my upper EEPROM is using it as storage space for PASM drivers. As a PASM driver can be max. 512 longs, I simply organized the upper EEPROM in slots where each slot has 2kB. The first slot is reserved for a directory which tells any program that makes use of PASM drivers which drivers are installed in which slot. So in total there can be 15 PASM-drivers installed. Of course a slot could also be used for data.
Sign In or Register to comment.