Sorting blocks of data in EEPROM

[ardhuru]

Hi,

I am trying to implememnt a timer that would control a number of loads (max of 16) thru' any number of cycles.

Typically, each event would need 5 bytes to be stored; the unit address, on-hour, on-minutes, off-hour, off-min, and recurrence. The last is actually a bit, and defines whether the event is once-only or to be repeated every day.

These event parameters would be defined thru' the PC and downloaded into the PIC.

Here's the question; how do I set up a file system to store the events data in the EEPROM, so that the events are always sorted by say, increasing address units, and correspondingly moving the respective other parameters asssociated with it?

What makes it complex to me is that the no. of events could vary, and some units might be connected with multiple events, while some others might not.

I hope I have not made this description even more confusing than it really is...

Any advice, folks?

Thanks in advance.

Anand

[sayzer]

Hi Anand,

Here is your answer if I understood your question right.

http://www.picbasic.co.uk/forum/showthread.php?t=4907



With some simple modifications, you should be ok.
If you need clarification for the way it works, simply ask here or there.


-------------------------

[dhouston]

Are you trying to store macros that are triggered by unit addresses? You can take one of two approaches. The first stores an index table at the beginning of EEPROM with pointers to macros and a length byte. The macros are stored after the index table. The second merely stores them individually, which means you have duplicate entries for the unit addresses. It depends on how much EEPROM you have and on the complexity of the macros. The first makes more efficient use of the EEPROM while the latter is easier to implement but wastes some space as records must all be the same size.

I used the former method to store X-10 macros but am using the latter with a device that will translate between several different protocols. In each case I have an external EEPROM rather than just the internal EEPROM of the PIC so efficient use of the available space is not a major factor.

The latter allows for multiple events with the same trigger but with differing ON/OFF times depending on the day of the week. (I use one byte for the 7 days plus a bit left over.)

[ardhuru]

Hi Anand,

Here is your answer if I understood your question right.

http://www.picbasic.co.uk/forum/showthread.php?t=4907



With some simple modifications, you should be ok.
If you need clarification for the way it works, simply ask here or there.


-------------------------

Sayzer, that was a fast response, thanks!

I understood the part where an array is created from the values in the EEPROM. But I still dont get how to sort on the first variable.

In my code, the EEPROM will be filled up with records consisting of 6 bytes; I would like these to be stored (refreshing the EEPROM) so that they are sorted by the 1st byte of each record; that is, the bytes at 0, 6, 12 and so on..

Have I missed something here?

Regards,

Anand

[ardhuru]

Are you trying to store macros that are triggered by unit addresses? You can take one of two approaches. The first stores an index table at the beginning of EEPROM with pointers to macros and a length byte. The macros are stored after the index table. The second merely stores them individually, which means you have duplicate entries for the unit addresses. It depends on how much EEPROM you have and on the complexity of the macros. The first makes more efficient use of the EEPROM while the latter is easier to implement but wastes some space as records must all be the same size.



Dave, the 2nd method you describe is pretty much what I'm trying to achieve; since the records are all fixed at 6 bytes each, I too concluded that it would be easier this way. Now, there are no macros here; just simple on and off times tied up with a unit address. So, when I punch in these 6 bytes thru' Hyperterminal, how do I make the existsing entries (if any) accomodate the new one, and sort it by the first byte of the record, the address code?

Regards,

Anand

[sayzer]

Anand,

Lets first set up your table right and have the correct reading settled.



'bytes 1 to 6
' 1, 2, 3, 4, 5, 6
EEPROM 1, ["A","B","C","D","E","F"]
EEPROM 7, ["G","H","I","J","K","L"]
EEPROM 13,["M","N","O","P","Q","R"]
EEPROM 19,["S","T","U","V","W","X"]
EEPROM 25,["Y","Z",27,28,29,30]

Locator VAR BYTE
MyBytes var byte[31] 'Could be 30 but lets make it easy.

START:

'Say that the value of Locator (index) comes from somewhere.
'Locator should be in a form that will support the table in EEPROM.

READ Locator , MyBytes.[locator] 'First Byte of the desired block in EEPROM.
READ Locator +1, MyBytes.[Locator +1] '...
READ Locator +2, MyBytes.[Locator +2] '...
READ Locator +3, MyBytes.[Locator +3] '...
READ Locator +4, MyBytes.[Locator +4] '...
READ Locator +5, MyBytes.[Locator +5] 'Sixth Byte of the desired block in EEPROM.

'Once you set a working table, you should then use a FOR loop.


GOTO START




Will this code work for you?

I am not quite clear where you get your index variable (Locator) from? a serial comm. etc?


-----------------------------

[dhouston]

Dave, the 2nd method you describe is pretty much what I'm trying to achieve; since the records are all fixed at 6 bytes each, I too concluded that it would be easier this way. Now, there are no macros here; just simple on and off times tied up with a unit address. So, when I punch in these 6 bytes thru' Hyperterminal, how do I make the existsing entries (if any) accomodate the new one, and sort it by the first byte of the record, the address code?

Anand,

I just use a sorted listbox in the Windows program I write with VB and I rewrite all of EEPROM whenever I insert a new entry. I'm not sure how I would go about it using hyperterminal. Are you looking to use PIC code to sort them in EEPROM?

While it depends on your EEPROM, most EEPROMs can be written to a hundred or more times a day without any danger of wearing out. If you need more frequent writes, use FRAM which can withstand billions of erase/write cycles.

[ardhuru]

I just use a sorted listbox in the Windows program I write with VB and I rewrite all of EEPROM whenever I insert a new entry. I'm not sure how I would go about it using hyperterminal. Are you looking to use PIC code to sort them in EEPROM?


Exactly! I am hoping to avoid having to write a VB front end, VB not being one of my stronger points. Instead, the PIC interactively operates with Hyperterminal to add/delete new events. Of course, with this approach the easier you try to make the user interface the longer your pic code becomes (and, very fast), but like I said I'd like to avoid using VB, if I can. I have got this part working in a rudimentary way, but would like the table that shows up on the terminal to be sorted by the unit address.

Regards,

Anand

[dhouston]

I guess it depends on whether you want the records sorted in EEPROM or whether you just want to be able to sort them when they are output via serial comms.

If you do not need them sorted in EEPROM then I would just write them to EEPROM starting at the bottom of whatever block of EEPROM you use and write an index table which just consists of the addresses of the individual entries in sorted order at the top of the EEPROM block. This way you only need rewrite the index table when you make changes. (You will need to keep track of deletions so you can reclaim that space.)

If you need the records themselves to be sorted (faster lookup) then the simplest method is Insertion Sort where you move existing entries as needed to clear a slot for a new entry. This would be the worst case for EEPROM life.

I think it would be easier to learn VB. <img src="images/smilies/smile.gif" alt="" title="smile" class="inlineimg" border="0">

[ardhuru]

I agree with the last statement, Dave; I've been putting off getting my hands dirty with VB too long, and I think I'm missing out a lot as a consequence.

Shall re-surface when I have something going in that direction, and shall most probably need some handholding at that stage again!

Regards,

Anand