Scrolling Data

[gregmcc]

I'm using the 16F628 to read in the time from a RTC and store in the eeprom whenever a certain criteria is met on a IO pin.

I plan to keep the last 5 times read so the data should should be scrolling - the oldest time always overwritten by the previous oldest time etc.

What would be the easiest way programatically to do this? Save the times to location a,b,c,d,e and then start again at a - or to move the data from d to e, c to d, b to c, a to b and then save the new time to a.

I also want to display the last 5 times - so if I use method 2 I could display A through E.

To display with method 1 could be more tricky?

Am I on the right track or is there an easier way to accomplish this?

 

[richard.c]

Hi,

Would have thought the easier way would be to place all the event times in 5 sets of variables, you can then readily arrange the order and have them available for the lcd routines.

When an event occurs, you store the time into the variables, arranging and updating them in the order you want, then call a simple subroutine to write out the same 5 sets variables to EEprom.

Rearranging the data once in eeprom is just making hard work for yourself.

Just wondered why you don't use a 32k xtal on timer1 and generate the rtc from within the pic? - its accurate to the odd second per week.

hth

 

[donniedj]

Your method 2 (current = prior, reassign current) is the right track. As richard said, you may either take action on static ram or on EEPROM.

Acting on EEPROM is a more universal choice because code does not necessarily have all 5, or all of a Table of any size, stored in static ram due to the usual ram resource limitations.

Acting on a static ram buffer, (storing the table here) has the advantage of speed, yet consumes space. This also adds the possibility of data corruption given that the mean time between saving the buffer to EEPROM is very long.

 

[Pommie]

I would suggest that you treat the EEPROM as a circular buffer, write the first record to location 0, second to location 4 (dependent on record length) etc. Once you have written the 6th record you can overwrite the first one with 0xffs. To find your first record, look through the EEPROM for a FF record and then for a non FF record. Doing it this way ensures that the writes to EEPROM are minimised and spread evenly over all the EEPROM. If you want to keep all the records then just have one record set to FF.

Mike.

 

[gregmcc]

Thanks for the tips - I'll try storing the data in variables, sort and then write to eeprom. Pommie got's a good method as well - I'll see which one is easier. I'm still learning atm so maybe I'll try both just for fun

Richard - I didnt realize the pic was that accurate for a rtc. Maybe I'll try that next after I get the sorting working

 

[ericgibbs]

hi,
I have used a similar method as the one Mike proposes, it works OK.

Another way is to use a circular/ring buffer to store the 5 individual data blocks and in a PIC register have a EEPROM address pointer that keeps track of the next EEPROM address.
A register holds the length of the ring buffer, so that it loops around.

I would avoid shuffling the stored data 'up' the ring buffer, its messy and takes time.

 

[Nigel Goodwin]

Richard - I didnt realize the pic was that accurate for a rtc. Maybe I'll try that next after I get the sorting working

Accuracy is down to the crystal, by using the same 32KHz clock crystal as an RTC it should have similar accuracy.

 

[picasm]

If your RTC includes battery-backed ram it would be ideal for storing the timestamps.

The pic eeprom has a limited number of writes (1 million) which may or may not be a problem depending on how often you write to it during the life of the chip.

 

[Nigel Goodwin]

RTC's often include EEPROM, and are actually addressed as I2C EEPROM's (for I2C versions), and are presumably subject to similar writing constraints?.

 

[richard.c]

Would just like to share some info on the eeprom writes.

I've been working on the 18F2520 but think the specs are the same for the 16F range as well.

The reference to 1million writes is correct, but this refers to spec D120.
In practical use, where eeprom is regularly rewritten/refreshed then the D124 spec applies, which is 1 million minimum and 10million typical.

These facts have been confirmed by Microchip support.

Just to prove the point, I've been running an endurance test over the last week+, writing and reading, different data to eeprom and counting the number of writes to each byte, currently at 12,500,000 to each byte, with no byte read errors given.

Please also note that the specification refers to the number of writes to a specific Byte, and not the total number of writes to the eeprom array.

Hope that clears things, because like you I originally though it was just 1 million writes to the whole eeprom array.

 

[gregmcc]

Thanks - my code will be writing the timestamps 3 or 4 times a day max, so I think the eeprom will long outlive me