There's a lot of different ways to approach something like this and each
has their own merits.
My first thought would be to structure it like so: [skipping some details
here]

MainLoop{

if ((CurrentTime >=3D StartTime) && (CurrentTime <=3D StopTime)
         Output(ON);
else
         Output(Off);
}

With this loop being called quite frequently (somewhere between once/minute
to 1000/second)

Assuming that internally you're storing times as integers (opposed to some
type of data structure
that separates seconds/minutes/hours/days) this has the advantage that a
system reset mid
cycle is "self-healing". I used this type of mechanism on a project that
had a hard requirement
that a failure must NOT leave the thing running.


Later you mention "One of the issues was - when power failed during the
"ON" cycle - load
was switched off, and the cycle lost until next event" Well... Maybe I've
read too much garbage
coming from my marketing people, but that's a bit ambiguous and subject to
multiple
interpretations.
Suppose you programmed it to run the load from 0:00 to 1:00, Suppose the
power was out
from 0:20 to 0:25.
The code above would
0:00 ON
0:20 OFF (with some assumptions about how the load is being switched)
0:25 ON
1:00 OFF
(for the record, this is what my device did, and is exactly how we wanted
it)

Stretching that example a bit, if the power was out before 0:00 and did not
come on until
after 1:00, the system would never turn on at all that day.

But perhaps you actually _want_ it to run to 1:05 to make up for the time
lost???
Or come on when the power was restored and run for the difference between
Start and Stop times?
(this is the behavior of a typical mechanical timer device - more or less)

In that case, I would approach it a bit differently. The system would need
a nonvolatile variable.
(could be in EEPROM, some RTCs have a small amount of battery backed RAM,
there's ways
to use FLASH...) but it would become a count of time the load was on. In
that case:

MainLoop{

if ((CurrentTime >=3D StartTime) && (TimeRunToday <=3D PlannedTimeRunToday)
         Output(ON);
else
         Output(Off);


//RunTime housekeeping - add a 'tick' to the nonvolitile counter every so
often

TimeRunToday =3D TimeRunToday + (CurrentTime - LastLoopTime)  //concept onl=
y
- do not implement it like this.
LastLoopTime =3D CurrentTime;
}


There's a couple ways that can bite you because FLASH and EEPROM have
limited life span
and do not like to be continuously written to like this. There's "standard"
ways to deal with this,
but the details are quite messy for an example like this.

The added quirk here is you now need a _good_ method to manage the RunTime
variable.
Do you clear it to zero at 0:00? What if the power was off during 0:00?
What if the operation
has the system on as the time rolls over from 23:59 to 0:00? (either user
programmed that way
or a result of "clock stretch" because of power outage)
Do you clear it as part of the turn on / turn off event?
It can be managed with more nonvolitile memory and a series of flags
through a state machine,
it's not even terribly difficult - but there are plenty of places to get
tripped up. You really need
so spend some time examining all the corner cases.


Another point worth mentioning is the concept of "CurrentTime". I tossed it
around in that example,
but it's actually quite nuanced. This pseudo code treats it like a
variable, in reality it's probably a
function to retrieve the current time from [RTC, GPS, HTTP, etc] and
massage it into your numbering
system - that will take time... what happens when the minute changes part
way through the loop?...
Typical solution here is to retrieve it once at the beginning of the loop
LoopStartTime =3D CurrentTime()
Then replace all the later references to CurrentTime with LoopStartTime.


-Denny
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.