DS1307 SRAM Longs not Bytes

Sariel

I am working on a counter circuit that eventually uses a DS1307 for timestamp, along with Kye's (very elegant) object. I am very interested in having the counters backed up to the unused portion of the SRAM at every machine cycle. This is going into a piece of equipment that will be periodically shut down, but still needs to keep track of total cycles in the millions. From what I see from Kye's driver, it stores and retrieves SRAM values by the Byte. What would the best way to get the data in longs? Modify Kye's driver, or somehow arrange multiple bytes to longs? I looked into the DS1307 Data sheet, and the section about the "RTC and RAM address map" says something about multi-byte transfers, I am just unsure of how to go about doing it.

Any help is appreciated.

Kye

 
PUB writeLong(index, value)
 
  rtc.writeSRAM(index,       ((value)           & $FF))
  rtc.writeSRAM(index + 1, ((value >> 8  ) & $FF))
  rtc.writeSRAM(index + 2, ((value >> 16) & $FF))
  rtc.writeSRAM(index + 3, ((value >> 24) & $FF))
 
PUB readLong(index)
 
  result := ((rtc.readSRAM(index)                 ) | {
              } (rtc.readSRAM(index + 1) << 8  ) | {
              } (rtc.readSRAM(index + 2) << 16) | {
              } (rtc.readSRAM(index + 3) << 24) ) )
 

This should work, might have compile errors but you can fix them.

Heater.

Be careful. If the power happens to be pulled in between a sequence of writeSRAM calls in the above code then the LONG that you are storing will be corrupted.
Unlikely I know but unlikely things happen all the time.

I would want a mechanism to be able to check that the LONG is valid when I read it back and then something to ensure it can always be read back.

So perhaps keep two copies of the LONG in SRAM with a check sum on each one. Then when it is time to read back then read one and check the checksum, if it's wrong read the next and check the checksum.

Of course it might just be easier to store three copies and take the value of any two that are the same at read time.

Whatever you do you may end up missing an update of that LONG because of this so you would want to be updating quite often to minimize damage.

You might also want to consider detecting when power is about to fail, and writing it out immediately and the halting.

How much RAM does this thing have?

Sariel

Ooooooo. I see how that works. Very slick. I can feel myself learning more and more every day. Thanks for looking into this personally, Kye.

Sariel

ARGH! was replying to you, Heater, when IE crashed... here goes again.

How much RAM does this thing have?

Not Much. 64x8 from the spec sheet, and that says that the first 8x8 is used by the RTC itself. Kye has the user area addressed out to bytes 0 - 55, so that does not leave much room for me, considering that I am running and updating 8 counters at once that are fed off of the same hall effect switch. Doubling the used space would fill it up and then some right off the bat. I am not versed at all in checksums, so I don't know where to start in answering that.

You might also want to consider detecting when power is about to fail, and
writing it out immediately and the halting.

That's a good idea... is there any way that you have heard of to tie that into the Brown-out of the prop itself, or we talking a supercap to keep it running for a few cycles, and constantly monitoring the voltage with one of the prop IO's, and when that toggles a "power fail" situation, put the whole thing to rest?

What I originally planned on doing with this is having a seperate power supply running the prop than the rest of the machine. This will do 2 things. isolate the uC from any noise in the line generated by the large motor that runs the rest of the machine, and safeguard against data loss by the fact of "If it is not counting, it is not updating". If there is an outage on the level that the SRAM could get corrupted, there are bigger issues we will have to face getting this back online.

I also have to keep in mind that they want this thing as soon as possible, so I may simply not have the time to add in all of the bells and whistles. I think a 4x20 display with 8 selectable displayed counters 4 at a time, each line can cycle through the displayed counts, and each counter independantly resettable, with battery backup and time stamp is already more than they could want.

Sariel

Nevermind the post I had here earlier. I found out what was wrong. I'm an idiot. *cheers to everyone*

Sariel

Made up a little tool for the SRAM contents in the DS1307 RTC. It has 3 basic functions. Output contents in decimal bytes, output the contents in decimal longs, and clear all RAM, except the area used by the clock itself. Hope someone out there finds it handy. HEAVILLY commented w/schematics, and ready to rock with a copy of FullDuplexSerial, and Kye's RTC Engine.

DS1307 SRAM Tool - Archive [Date 2011.06.23 Time 13.02].zip