John Chris
Senior Member
Hi there,
I am working with a 28X2 that has a DS1388 RTC on I2C. My goal recently has been to create a variety of subroutines that allow accurate scheduling of events according to local calendar time, e.g. a function that takes two calendar times and returns the difference in Y,M,D,h,min,s.
Here is how I have gone about this:
Firstly, pointers to eprom locations
t0_pos = 0
t_pos = 10
dt_pos = 20
temp_pos = 30
then offsets for units
second_offset = 6
minute_offset = 5
hour_offset = 4
date_offset = 3
month_offset = 2
year_offset = 1
so generically, any unit of any time can be written to memory with,
LET temp = value
LET pos = pointer + offset
WRITE pos,temp
and loaded into a temporary variable by,
LET pos = pointer + offset
READ pos,temp
also required would be the maxima, minima, and conversion factor for each unit so the pointers,
max_pos = 40
min_pos = 50
conv_pos = 60
are defined. For instance these 'arrays' or memory blocks would look like this (note I have closed things off at the year level, assuming that events will be no greater than 12 months apart, yet events on either side of 31-DEC / 1-JAN can still be handled)
'maxima' starting @ 41: 0,12,31,23,59,59
'minima' starting @ 51: 0,1,1,0,0,0
'conv' starting @ 51: 0,12,31,24,60,60
A subroutine (called SubtractDateTimes) possesses primary and secondary DO loops. The extent of each are from 6 (second_offset) to 1 (year_offset). Seconds are considered first in the primary loop, and in the secondary loop, as many units of time as needed may be adjusted (cycling from 5 to 1, minute to year) should any 'borrowing' be required. After all 'borrowing' has been sorted out, the primary counter is decremented and the 'minutes' are considered. This continues to the year level. The memory block associated with the pointer 'temp_pos' is loaded with the values at 't_pos' initially, yet is adjusted throughout the to loops.
The biggest problem arises when dealing with date / times that my be offset by a couple months. One has to continuously adjust the values of the 'maxima' and 'conv' at the date level depending on the month associated with 't0' and / or the month prior to that associated with 't', the future time.
It occurred to me that if a subroutine did calculate a difference between two calendar times (returning values for each of the units from years to seconds) the meaning of a difference greater than a couple of months seems a little strange. It's almost as if you would have to store a 'track' or a list of the months and associated number of days. I suppose it depends also on how one intends to employ the resulting time difference.
All of this has probably been worked out by someone. I suspect that 'time.h' is what is used on other processors and microcontrollers.
I believe I read somewhere that calendar times are kept track of as seconds relative to an arbitrary reference year. Perhaps this approach would prove to be simpler ? Still, converting number of seconds relative to a reference year into a calendar date / time probably still has challenges associated with it.
So where I stand right now is I've got a subroutine that can subtract two calendar date / times for MOST cases. For instance, any combination of date and times within a month work always, spanning a month works well too. I set the s.r. up to calculate the difference between 27-JAN-2010 XX:XX:XX and 1-MAR-2010 XX:XX:XX and was off by a couple days due to the difference in the number of days in the months of FEB (28) and JAN (31). I started to think about how I could sort this out, have made some progress, yet have not resolved the issue completely.
Now, for my particular application, I only ever have to compute times that are on the order of hours later or earlier than the present time. For this reason I think I will be alright. I am interested, however, in developing the subroutines so that they may be relatively free of limitation.
1) I have not yet programmed a C-programmable uC - is time.h typically what is used to perform calendar date/time computations ?
2) Has anyone implemented something similar for the PICAXE ?
3) Can anyone suggest an approach that may be simpler than the one that I have described here? / Condone an approach where seconds are being kept track of and only for display purposes is a calendar date/time computed
Thanks,
Chris
I am working with a 28X2 that has a DS1388 RTC on I2C. My goal recently has been to create a variety of subroutines that allow accurate scheduling of events according to local calendar time, e.g. a function that takes two calendar times and returns the difference in Y,M,D,h,min,s.
Here is how I have gone about this:
Firstly, pointers to eprom locations
t0_pos = 0
t_pos = 10
dt_pos = 20
temp_pos = 30
then offsets for units
second_offset = 6
minute_offset = 5
hour_offset = 4
date_offset = 3
month_offset = 2
year_offset = 1
so generically, any unit of any time can be written to memory with,
LET temp = value
LET pos = pointer + offset
WRITE pos,temp
and loaded into a temporary variable by,
LET pos = pointer + offset
READ pos,temp
also required would be the maxima, minima, and conversion factor for each unit so the pointers,
max_pos = 40
min_pos = 50
conv_pos = 60
are defined. For instance these 'arrays' or memory blocks would look like this (note I have closed things off at the year level, assuming that events will be no greater than 12 months apart, yet events on either side of 31-DEC / 1-JAN can still be handled)
'maxima' starting @ 41: 0,12,31,23,59,59
'minima' starting @ 51: 0,1,1,0,0,0
'conv' starting @ 51: 0,12,31,24,60,60
A subroutine (called SubtractDateTimes) possesses primary and secondary DO loops. The extent of each are from 6 (second_offset) to 1 (year_offset). Seconds are considered first in the primary loop, and in the secondary loop, as many units of time as needed may be adjusted (cycling from 5 to 1, minute to year) should any 'borrowing' be required. After all 'borrowing' has been sorted out, the primary counter is decremented and the 'minutes' are considered. This continues to the year level. The memory block associated with the pointer 'temp_pos' is loaded with the values at 't_pos' initially, yet is adjusted throughout the to loops.
The biggest problem arises when dealing with date / times that my be offset by a couple months. One has to continuously adjust the values of the 'maxima' and 'conv' at the date level depending on the month associated with 't0' and / or the month prior to that associated with 't', the future time.
It occurred to me that if a subroutine did calculate a difference between two calendar times (returning values for each of the units from years to seconds) the meaning of a difference greater than a couple of months seems a little strange. It's almost as if you would have to store a 'track' or a list of the months and associated number of days. I suppose it depends also on how one intends to employ the resulting time difference.
All of this has probably been worked out by someone. I suspect that 'time.h' is what is used on other processors and microcontrollers.
I believe I read somewhere that calendar times are kept track of as seconds relative to an arbitrary reference year. Perhaps this approach would prove to be simpler ? Still, converting number of seconds relative to a reference year into a calendar date / time probably still has challenges associated with it.
So where I stand right now is I've got a subroutine that can subtract two calendar date / times for MOST cases. For instance, any combination of date and times within a month work always, spanning a month works well too. I set the s.r. up to calculate the difference between 27-JAN-2010 XX:XX:XX and 1-MAR-2010 XX:XX:XX and was off by a couple days due to the difference in the number of days in the months of FEB (28) and JAN (31). I started to think about how I could sort this out, have made some progress, yet have not resolved the issue completely.
Now, for my particular application, I only ever have to compute times that are on the order of hours later or earlier than the present time. For this reason I think I will be alright. I am interested, however, in developing the subroutines so that they may be relatively free of limitation.
1) I have not yet programmed a C-programmable uC - is time.h typically what is used to perform calendar date/time computations ?
2) Has anyone implemented something similar for the PICAXE ?
3) Can anyone suggest an approach that may be simpler than the one that I have described here? / Condone an approach where seconds are being kept track of and only for display purposes is a calendar date/time computed
Thanks,
Chris
Last edited:
