Updating the DS1307 RTC Driver - If you like using it please read this post!!!

Kye

Hey guys,

I've been making alot of changes to my library code and included in my library of code is my DS1307 RTC clock driver that seems to be liked by alot of people.

So, I would like to pass the changes by everyone so that the best option can be choosen for how the new code will work.

Basically, the DS1307 RTC driver I have posted only executes data transfers one byte·at a time. This can be a problem when you grab a full time stamp. What happens is that the DS1307 keeps counting in the background between byte·data transfers. The only way to stop it from counting in the background is to grab all the time and date byte·info at once in one data transfer.

Thus to fix these issues I re-wrote the code so that it always executes data transfers of the time and date info as block transfers. (Setting the SQWOUT pin·and SRAM are still single byte transfers and work fine.)

So, to set the time I now have one function which just takes the current (seconds, minutes, hours, day, date, month, and year). I don't think anyone should have a problem with this because you usually need to set the whole time at once anyway.

However, for getting the current time I'm having alot of issues on how I should proceed.·The only way which I can guarentee everything will work·out correctly is by making the "checkTime" function which gets the current time take a pointer to a struct which it will then populate with the current time. However, as·SPIN has no support for structs this approach will be akward.

I have to devise a solution to this problem that will not have multi-include problems or multi-processor problems. So, if anyone has any ideas about this please speakup.·Thanks you.

...

Attached is·a version of the driver where I thought I had fixed all problems. However, if two processors·were to try to get the time at·once a problem could occur when one core is updating the time and the other is ampling the time. This is·why I cannot just use variable space within the driver to solve this dilema.

Thanks, for your help.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Timothy D. Swieter

Kye - I am not too familiar with the DS1307 yet. When reading the time out of of the device is there a way to latch in a time and read a non-changing time while the clock is still counting? If there is than that is great, but if there isn't, then I would recommend reading the time starting with the year and working towards seconds. THis method of reading the time will ensure the time doesn't rollover if we started with seconds and moved to years. I am picturing a situation where perhaps 59 seconds is read, and then depending on the transfer speed the next minute/hour/day/year could be read making the time look further along than it should be. Although I suspect the block transfer you mention is pretty fast.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

Kye

The block transfer method is the only way to ensure that no errors can happen.

My problem is what to do with the data after getting it. You can't return multiple values. So either I take a pointer to a struct or something else.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

localroger

Kye, you could use the Prop LOCK mechanism to prevent cogs from interfering with one another while sloooowly collecting the pieces of the sample that's been triggered. As with setting the time you usually do it all at once so it's not like any cog is going to keep the time server locked long enough to create a real problem for any of the others.