New Object Announcement: A User Friendly Memory Management System Version 1.0 R

Bobb Fwed

Just thought I'd put up a post on a new object I just released (seeing as there is no other way to notify people of new things).

This object is designed to allow programmers (and/or end-users) to store values to EEPROM, referenced by name rather than just a number. It is similar to a simple database system. The values can be stored in numerical byte, word, or long values. Strings, arrays, and stacks can also be stored to the EERPOM. All of the values are created, edited, and retrieved with a simple name.

This is great for storing user-created settings or values that need to be accessed at a later time with profile names or user entries. In the right hands, it can be used for just about any EEPROM application.

It is simple to create, edit, and access the values. You can simply create_str(name_str, value_str), then edit_str or get_str will do exactly what they sound like they do. Creating numerical values are just as easy.

Download here: Memory Storage Management

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 8/21/2009 11:37:17 PM GMT

StefanL38

that's OK to announce it here

anyway I found it before this announcing because of my habit to take a daily look into the obex with

the link below which is sorting the objects by release-date descending

http://obex.parallax.com/objects/?o=0&ot=dsc

this means the latest objects are always on top

best regards

Stefan

MagIO2

''      The more entries there are, the longer it takes to verify names (gather the
''        address associated with the name). Shorter names will help the problem a
''        little.      

That's why hashtables have been invented. You only calculate a hash-value which is then used as an index in your table of names. Guess wikipedia can give you more information.
But it's worth the efford, as you can decrease the number of reads of variable-names and compares a lot.

Bobb Fwed

I am guessing it would take up more memory but would be faster...I will look into it.
I was trying to think of any way to organize the index to speed things up! But couldn't think of anything that would be easy and guaranteed to actually be faster.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

jazzed

I found the DJB2 hash to be fairly effective with small memory availability.

  hchk  : "Checksum"            ' horrible hash for more than a few characters in a key
  hcrc  : "CRC16"               ' fair hash for small data set
  hjenk : "JenkinsHash"         ' horribly inefficient for small data set
  hsdbm : "HashSdbm"            ' good hash for small data set
  hobj  : "HashDjb2"            ' best hash for small data set it seems

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Bobb Fwed

I will look into integrating some of that once I get back from vacation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Bobb Fwed

jazzed said...
I found the DJB2 hash to be fairly effective with small memory availability.

  hchk  : "Checksum"            ' horrible hash for more than a few characters in a key
  hcrc  : "CRC16"               ' fair hash for small data set
  hjenk : "JenkinsHash"         ' horribly inefficient for small data set
  hsdbm : "HashSdbm"            ' good hash for small data set
  hobj  : "HashDjb2"            ' best hash for small data set it seems

Can I get links to these?
Only the CRC is listed under such a name in the Obex (and that is listed as CRC8).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

jazzed

Bobb Fwed said...
Can I get links to these?
Only the CRC is listed under such a name in the Obex (and that is listed as CRC8).

Attached are the hash objects I used for testing. A CRC16 demo is here ; look for "Corrected version". Checksum hash (mask sum of string chars, etc...) is not very useful. On any hash mechanism, it is possible to have multiple entries for a hash result. In such cases, use a simple array or list to hold the key/value pairs. I have a file that takes care of such details, but it is horribly messy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 8/17/2009 3:00:00 AM GMT

Bobb Fwed

MagIO2 said...
That's why hashtables have been invented. You only calculate a hash-value which is then used as an index in your table of names. Guess wikipedia can give you more information.

But it's worth the efford, as you can decrease the number of reads of variable-names and compares a lot.

I have taken your advice/knowledge and added a simple checksum to determine the table location. It is much faster than previous versions of the program (especially once more than a couple values are stored).

Version 0.9 available: obex.parallax.com/objects/493/

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Bobb Fwed

Version 1.0 has been release on the Obex with some significant changes:

Added lazy deletion method to clear table entries.
Strings can now span multiple blocks, but cannot exceed 255 characters.
Strings start at current data pointer location rather than at next available block. This reduces the amount of space strings use up.
Removed moving of strings before storing to EEPROM (speeds things up).
Added get_freedataspace which uses the new end_data constant.
Now create and create_str tests for enough data space before writing.

Download it here: obex.parallax.com/objects/493/

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!