Memory Storage Management V1.3 Released

Bobb Fwed

I have just released version 1.3.2 of Memory Storage Management. The easy way to automatically manage EEPROM storage by name rather than arbitrary numbers.

Download full version here: http://obex.parallax.com/objects/493/
Download lightweight version here: http://obex.parallax.com/objects/671/

Changes in 1.3.0:
Slight optimizations throughout the object.
Reducing the memory used.
Adapted commands to allow for use of unmodified version of Basic I2C driver. This also allows for PASM I2C driver compatibility for added speed.
Names are now truncated during "get" methods. This means a name that is too long while being created can be accessed without external truncation.
Added check_edit_create_str. It checks if the string already exists, then edits or creates accordingly.
Added more comments to the code, and corrected old comments.
Changed get_list to get_name_list to be associative with next_name.

Changes in 1.3.1 and 1.3.2 are listed below.

Enjoy. Please leave questions or comments if you have any.

Bobb Fwed

So, my bad.
I have had a bug in my program since I added the ability to edit strings. I didn't realize it until Friday. It only affected reading string after a string was edited, and before the object was rebooted (init called).

I have fixed it, and added a couple very minimal optimizations as the 1.3.1 release.

Everyone who uses the string features of this software is highly encouraged to update to the latest version.

It always sucks when hours of trying to nail down the cause of a bug is fixed with one line of code....

Bobb Fwed

For those who use this object, are there any feature requests people have?
There are two big things I've wanted to do, but they would need to be alternative versions of the object, rather than changes to the current one.

First big change (and the easier of the two) would be trim down the number methods in the object. The object is quite large, and I think many people do not use the string/stack/array functions, so those could go away. There are a few other methods that could go away, as there are alternate methods that produce similar results.

The second big change would be to rewrite portions of the object so as to not require the tables stored in RAM. This uses a significant amount of memory, but it speeds things up by about 60%. I theorize that if the tables were not stored in RAM, but the PASM I2C object was used, the net speed would be very similar.

Thirdly (I know I mentioned only two, but this one is easy), a combination of the above two changes. So it would create a very slimmed down version of the current object.

Any feedback would be very helpful.

Bobb Fwed

So, whatever, it was a slow day, so I did both of the above mentioned changes. I will be releasing them tomorrow.
Version 1.3.2: has a new method set_name_pointer to access specified names, and contains more optimizations.

What I am calling the Welterweight version has the above additions, but also no longer requires the primary table to be stored in RAM, and the names table size has been cut in half which greatly reduced the variable space as well as initialization time. But overall speed is about 70% slower.

A third version which I am calling the Featherweight version, has all the above changes, but also many methods have been removed to leave only integer methods (no strings or multi-block writing). This reduced the size to about 60% of the original. Speed is identical to Welter Weight version. Some of the previously PUB methods have been changed to PRI. This will help direct new users of the object to the more obvious/widely used methods.

By the way, the original (and largest) version will be named Heavyweight.
Also, using PASM instead of SPIN I2C driver will make the object more than three times faster. So the Welterweight w/PASM version is actually a little more than twice as fast as the Heavyweight w/SPIN version. So many options, to fit any need (hopefully).

Bobb Fwed

I have released the lightweight version as a separate object: http://obex.parallax.com/objects/671/ It requires only 55% of the combined program and variable space that the full version needs.

Along with the 1.3.2 release of the full version, a welterweight version is included. It has most of the variable space savings of the lightweight, but still all the features. Download here: http://obex.parallax.com/objects/493/

The full version is about 70% faster than the other two versions. But with the new compatibility with the PASM I2C Driver, the smaller versions can still be twice as fast as previous versions.

This should be the last of the rapid updating that I've been doing (unless a bug exposes itself).

Enjoy.

william chan

What are the application possibilities for this object?

jazzed

william chan wrote: »

What are the application possibilities for this object?

A string-value map? Example:

Oranges $1
Grapes $3
Peaches $4
Pears $2
Durian $5

Bobb Fwed

I use it for a device that stores and retrieves values based on the current user. It's handy (compared to "hard wired" addresses) because values can be added at any time, so as new users are added, I don't have to re-address values. And seeing as there are an undefined number of values for each user...well you get the idea.

It is also the only object I am aware of that is specifically designed to store and recall strings from EEPROM. This proposes a unique problem because the EEPROM is broken up into blocks. Long strings will be broken up, so storing them is different than simple integer values, and recalling them requires the string to be reassembled.

I haven't used it for such, but it could also be used to store a block of variables like an array or stack. This could possibly be used to put a current stack into EEPROM and shutdown. On reboot, it restores the stack to jump right back to where it was in a moments notice (this may or may not work -- maybe someone with more knowledge of the stack can help). But arrays are nonetheless a handy tool to store to EEPROM.

And because everything is indexed, it's faster than searching through and grabbing from a predefined list of addresses of a similar size (I guess it really depends on how you track your info and addresses though).

Overall it just makes reading and writing to EEPROM easy, though somewhat unconventional with the string name instead of an address.

TexFly

Hello,

Is there a way of managing the memory available?

I'm already using the eeprom to store the main program. Is it correct?

How do I know when I'm running out of space?

...or how much space available I have?

Can I connect an additional eeprom and use it only to store information?

Thanks!
Tex

Bobb Fwed

If you want to see how much space you are using, hit F8 in propeller tool. It will tell you how much free space you have. But the free space is also stack space. So you must always have some stack space available for your program to operate properly. The amount is based off the structure of your program, and number of method/temporary variables.

You can add another EEPROM, or, you can get a 64KB EEPROM. Either way works, but 64K EEPROM would be cheaper, less parts, less power, and less IOs, It won't let you hold more programming space though, just data storage.

By the way, the above software will let you use either one.

lardom

Can any part of your object be used for wear leveling? I'm still researching the subject. Thanks.

Bobb Fwed

It doesn't do leveling. I does do write reducing (surely it has a better name) where it checks to make sure the value is different before it writes it.

I think dynamic wear leveling wouldn't be too far of a stretch to do. Maybe I will look into that.

MacTuxLin

Thanks Bobb! I'll post my feedback in a week or 2.

KaosKidd

One idea is configuration options for more then one EEPROM.
It would need to know the length of the first one, and then add the second one at the "end" of it's address space to increase space...

The additional EEPROMS would be on the same I2C bus, just different addressess. The object would need only the address and size of the chip(s), then it could manage it internally (without user input)..

In theory it would just use the tables as it uses now, but pointers to other chips(s) as needed. Or, if needed if it didn't exist in one table, then change to the next chip and check that table on down the line. This would be expensive in time, so maybe the index table could include another byte, the address of the chip it's in?

Anyway, just an idea. The the cell rotation is always a concern for EEPROM usage.

Bobb Fwed

I've been brainstorming how I could implement dynamic wear leveling (the simpler of the wear leveling techniques) without making the size of the table 50% larger, but I don't know if it is possible.

As for the second EEPROM thing. It may not be too difficult. If you use the end of the first EEPROM, then it rolls over to the second EEPROM on the same bus, it may just be a matter of checking the address value. If the write location is over $7FFF, it just subtracts that and moves the EEPROM device address up one. In theory, that could be used for a infinite number of EEPROM (though I think a single bus is limited to 4, though it seems it should be 16).

Bobb Fwed

I think it is going to be more difficult to do it than I originally thought. I will likely have to completely re-write the object, and to make it easier, I will likely limit to just storing longs.