@Heater
Yes, you want to use the DS1307 without Unix time.
You ask what is the problem? (or what are the problems?)
A. How do you set the time for DS1307?
B. How do you poll the DS1307 for each minute roll over? Or each second?
C. How do you collate the DS1307 output into a display for the a real clock?
I think those are the issues that the OP desires to resolve.
My gut feeling is that since the OP is essentially making a clock that will run 24/7, he could entirely eliminate the DS1307 and set the clock through the serial port to the Propeller from a computer. Having one 32-bit value that represents time and dates stores minimally and is quite easy to set.
The only real reason to have the DS1307 involved is to have an automatic reset if power goes down. The Propeller has to provide intermediate services and drive display logic, but doesn't actually need a DS1307 to operate as a clock. The Propeller only needs the DS1307 for an automatic restart.
I have found that using Unix Time in Forth on the Propeller works quite well for setting from a laptop. And the code is not that hard to manage. In fact, it provides one 32 bit long for a time stamp that is easily available.
I don't think the DS1307 is going to perform much better beyond 2099. This is a silly issue. None of us or the device is going to be around then to see what time it is.
And the DS1307 doesn't know about Daylight Savings Time.
You are merely raising arguments that distract us from getting anywhere.
On the other hand, the DS1307 does indeed create output that is intended to be Binary Coded Decimal and that might be directly useful to the final display routine.
Thanks guys for the good discussion on RTC vs UNIX_time. I am not even close to deciding what method to use
as I am still trying to learn about the Propeller and coding in SPIN. I will have to start SMALL and make my
mistakes doing very simple programs before I even attempt to tackle this project.
Edit: I have saved all of your comments so I can study them some more.
One should be aware of the "Unix Millennium" problem. After 03:14:07 UTC on 19 January 2038 that Unix counter overflows and we are back to a date in 1901.
That's it, the end of the world is only 24 years away!
This has already bitten me. A few years back I was generating self signed SSL certificates for a VPN. On my 32 bit PC this was sometimes not working. Recently I found out it was because I was setting the expiry date far into the future and the generated certs were already expired due to this Unix Millennium problem. Sure enough that same procedure on a 64 bit machine worked fine.
I guess what Heater is saying is that you should set up a UTC clock with a second contiguous 32bit register as a 64 bit integer.
And in that way, 28 years from now the DATE will roll-over correctly.
Sorry for my neglecting this. At 67, my life expectancy isn't another 28 years and I am not concerned with building a device for my heirs. Nonetheless it can be done.
Since your goal is a Decimal output, just migrating BCD readings may be easier for your to code than to conver UTC time... especially the Date aspect.
With Unix Time, you would have to have a formula for conversion of year and a look up table for conversion of month. Academtically, it is a nice exercise. But maybe not what you desire to get into for a first project.
I suspect you will have to watch for the rollover of a second in a loop that reads the DS1307 about 10 or 20 times per second. I believe that the DS1307 doesn't automatically generate new data output when the time changes.
I set up UTC in Forth primarily for a 32bit time stamp to be added to raw sensor data. Spreadsheet such as Excel can manipulate it and convert it to a human friendly display.
From the source file: This object provides methods that convert back and forth between Unix time and
year.month.day hour:minute:second values. Unix time is a signed, 32-bit integer
representing the number of seconds elapsed since 01 Jan 1970 at 00:00:00 UTC,
ignoring leap seconds. The object also provides date and time from Unix time in
ASCII string format.
My thinking at this point (for my Resistor Color Code Clock – RCCC) is to do just the time function and forget about the date (that could come in version 75). Also forget
about using a RTC (real time clock) and just use the Propeller for all time functions. I envision a cog just doing the timing function.
I just need to know when a minute has occurred. This cog could then set a ‘minute flag’ in some register/storage location which
could be checked by the main routine (which is looping just checking for things to do) and then go to another cog to update
and display that color for that minute/hour. That routine would also have to check for ‘overflows’ from the low minute digit
to the high minute digit and ‘overflows’ to the hour digits also. This would be the ‘main smarts’ routine. The timing
function cog routine could also set other flag bits for other different times, like 1 sec, 5 sec, 20 sec etc. which could be used
by other functions. If multiple functions needs a 5 sec tick (for example) then the timing function could set multiple bits
one for each function needing a 5 sec tick.
The time would have to inputted to the clock manually after every power up/failure. Have to think
some more on this but it could be something like:
Touching one of the touchpads on a Quickstart card which would
start the high minute digit flashing and then start advancing thru the colors every five seconds until the correct
color is shown and then touch the pad again which would set that color and advance to next digit and repeat the
process until all digits are set with the correct color. If after 20 seconds the touch pad is not touched (which would
start the process all over again ) the clock function now begins.
Other input options for setting the clock could be an IR Remote control, a serial connection to a PC,
and my favorite Voice Recognition (“set clock”, “set hours to 12”, “set minutes to 30”, “start clock”).
Future enhancements(assuming I complete the basic function) could be an alarm feature, a ‘talking clock’
“time is now twelve forty-five PM”, and a Westminster chime function (did this on a IBM PcJr years ago.)
I would like to thank everyone who offered advice on my ramblings to this point and to wish everyone
a Merry Christmas and to those that don’t celebrate Christmas have a Happy Thursday.
I think you have a good plan, skip the RTC, skip the date. Just get the minimal 24 hour (or 12) clock working. The "Minimum Viable Product" as the kids like to say now a days.
You have enough work to do sorting out that funky resistor color code display, which I think is a very cool idea, and the time setting interface etc.
When that is all up and running you sit back, admire your work, show it off to family and friends (That's us out here:)) and then contemplate what you want to do next. Perhaps you want to add that RTC, perhaps you date functionality.
Or perhaps an entirely new and different project captures your attention....
Personally I would dedicate one COG to time keeping. It can keep track of seconds, mins, hours. I would want to go to millisecond resolution but that's just me. That COG would dump the seconds, mins, hours values into a structure in HUB RAM.
From there you can have another COG, pick up those values for display.
I'd have the time keeper set a flag in HUB when time is updated and have the reader COG clear the flag. In this way you can avoid race conditions on reading all those time values.
You can even do a simple timer/rtc -- with 1ms resoltuion -- in Spin (no Assembly required). Here's the working part of the code. Full demo is attached.
pri run_rtc | mstix, t ' lauch with cognew
mstix := clkfreq / 1000 ' tix in 1ms
t := cnt ' sync timebase
repeat
repeat while (rtchold) ' if rtc on hold
t := cnt ' re-sync
waitcnt(t += mstix) ' wait 1ms
if (++millis == 1000) ' update milliseconds
millis := 0
if (++scs == 60) ' update seconds if needed
scs := 0
if (++mns == 60) ' update minutes if needed
mns := 0
if (++hrs == 24) ' update hours if needed
hrs := 0
Comments
Yes, you want to use the DS1307 without Unix time.
You ask what is the problem? (or what are the problems?)
A. How do you set the time for DS1307?
B. How do you poll the DS1307 for each minute roll over? Or each second?
C. How do you collate the DS1307 output into a display for the a real clock?
I think those are the issues that the OP desires to resolve.
My gut feeling is that since the OP is essentially making a clock that will run 24/7, he could entirely eliminate the DS1307 and set the clock through the serial port to the Propeller from a computer. Having one 32-bit value that represents time and dates stores minimally and is quite easy to set.
The only real reason to have the DS1307 involved is to have an automatic reset if power goes down. The Propeller has to provide intermediate services and drive display logic, but doesn't actually need a DS1307 to operate as a clock. The Propeller only needs the DS1307 for an automatic restart.
I have found that using Unix Time in Forth on the Propeller works quite well for setting from a laptop. And the code is not that hard to manage. In fact, it provides one 32 bit long for a time stamp that is easily available.
I don't think the DS1307 is going to perform much better beyond 2099. This is a silly issue. None of us or the device is going to be around then to see what time it is.
And the DS1307 doesn't know about Daylight Savings Time.
You are merely raising arguments that distract us from getting anywhere.
On the other hand, the DS1307 does indeed create output that is intended to be Binary Coded Decimal and that might be directly useful to the final display routine.
as I am still trying to learn about the Propeller and coding in SPIN. I will have to start SMALL and make my
mistakes doing very simple programs before I even attempt to tackle this project.
Edit: I have saved all of your comments so I can study them some more.
Actual Time = Fri, 19 Dec 2014 18:47:15 GMT
One should be aware of the "Unix Millennium" problem. After 03:14:07 UTC on 19 January 2038 that Unix counter overflows and we are back to a date in 1901.
That's it, the end of the world is only 24 years away!
This has already bitten me. A few years back I was generating self signed SSL certificates for a VPN. On my 32 bit PC this was sometimes not working. Recently I found out it was because I was setting the expiry date far into the future and the generated certs were already expired due to this Unix Millennium problem. Sure enough that same procedure on a 64 bit machine worked fine.
And in that way, 28 years from now the DATE will roll-over correctly.
Sorry for my neglecting this. At 67, my life expectancy isn't another 28 years and I am not concerned with building a device for my heirs. Nonetheless it can be done.
Since your goal is a Decimal output, just migrating BCD readings may be easier for your to code than to conver UTC time... especially the Date aspect.
With Unix Time, you would have to have a formula for conversion of year and a look up table for conversion of month. Academtically, it is a nice exercise. But maybe not what you desire to get into for a first project.
I suspect you will have to watch for the rollover of a second in a loop that reads the DS1307 about 10 or 20 times per second. I believe that the DS1307 doesn't automatically generate new data output when the time changes.
I set up UTC in Forth primarily for a 32bit time stamp to be added to raw sensor data. Spreadsheet such as Excel can manipulate it and convert it to a human friendly display.
From the source file:
This object provides methods that convert back and forth between Unix time and
year.month.day hour:minute:second values. Unix time is a signed, 32-bit integer
representing the number of seconds elapsed since 01 Jan 1970 at 00:00:00 UTC,
ignoring leap seconds. The object also provides date and time from Unix time in
ASCII string format.
about using a RTC (real time clock) and just use the Propeller for all time functions. I envision a cog just doing the timing function.
I just need to know when a minute has occurred. This cog could then set a ‘minute flag’ in some register/storage location which
could be checked by the main routine (which is looping just checking for things to do) and then go to another cog to update
and display that color for that minute/hour. That routine would also have to check for ‘overflows’ from the low minute digit
to the high minute digit and ‘overflows’ to the hour digits also. This would be the ‘main smarts’ routine. The timing
function cog routine could also set other flag bits for other different times, like 1 sec, 5 sec, 20 sec etc. which could be used
by other functions. If multiple functions needs a 5 sec tick (for example) then the timing function could set multiple bits
one for each function needing a 5 sec tick.
The time would have to inputted to the clock manually after every power up/failure. Have to think
some more on this but it could be something like:
Touching one of the touchpads on a Quickstart card which would
start the high minute digit flashing and then start advancing thru the colors every five seconds until the correct
color is shown and then touch the pad again which would set that color and advance to next digit and repeat the
process until all digits are set with the correct color. If after 20 seconds the touch pad is not touched (which would
start the process all over again ) the clock function now begins.
Other input options for setting the clock could be an IR Remote control, a serial connection to a PC,
and my favorite Voice Recognition (“set clock”, “set hours to 12”, “set minutes to 30”, “start clock”).
Future enhancements(assuming I complete the basic function) could be an alarm feature, a ‘talking clock’
“time is now twelve forty-five PM”, and a Westminster chime function (did this on a IBM PcJr years ago.)
I would like to thank everyone who offered advice on my ramblings to this point and to wish everyone
a Merry Christmas and to those that don’t celebrate Christmas have a Happy Thursday.
You have enough work to do sorting out that funky resistor color code display, which I think is a very cool idea, and the time setting interface etc.
When that is all up and running you sit back, admire your work, show it off to family and friends (That's us out here:)) and then contemplate what you want to do next. Perhaps you want to add that RTC, perhaps you date functionality.
Or perhaps an entirely new and different project captures your attention....
Personally I would dedicate one COG to time keeping. It can keep track of seconds, mins, hours. I would want to go to millisecond resolution but that's just me. That COG would dump the seconds, mins, hours values into a structure in HUB RAM.
From there you can have another COG, pick up those values for display.
I'd have the time keeper set a flag in HUB when time is updated and have the reader COG clear the flag. In this way you can avoid race conditions on reading all those time values.
pri run_rtc | mstix, t ' lauch with cognew mstix := clkfreq / 1000 ' tix in 1ms t := cnt ' sync timebase repeat repeat while (rtchold) ' if rtc on hold t := cnt ' re-sync waitcnt(t += mstix) ' wait 1ms if (++millis == 1000) ' update milliseconds millis := 0 if (++scs == 60) ' update seconds if needed scs := 0 if (++mns == 60) ' update minutes if needed mns := 0 if (++hrs == 24) ' update hours if needed hrs := 0