> "Neil Cherry" <njc@cookie.uucp> wrote in message
> news:slrneg81ca.cic.njc@cookie.uucp...
>> On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
>>> Neil Cherry <njc@cookie.uucp> wrote:
>>>
>> OK, now I feel stupid. I thought the minimum time meant you can't send
>> a tickle before that time so I've been working on the assumption I
>> need to send a tickle between 62.5ms and 250ms (now you see why I
>> needed a timer). I can now just stick the tickle in the main loop (no
>> timer) and let it do it's work. I actualy have that version working
>> but since I didn't understand why it worked I couldn't consider it
>> valid (a fix without understanding is just voodoo, not acceptable).
>> BTW, the actual chip is the MAX1232. I just read the Dallas app note
>> 144 which explains things a lot better (exactly what you pointed out
>> above).
>
> I know the MAX/DS1232 well; it's my watchdog/reset controller of choice in
> most of my designs over the last few years.
>
> As others have said, using a timer to kick the watchdog both ways is the
> wrong way of going about things.
>
> My strategy is fairly classic. I pretty much always have a heartbeat
> interrupt running, i.e. a timer interrupt every (say) 5ms. I use this to
> update any software timers I need. My top level code is based on a
> round-robin, i.e. an infinite loop.
>
> So I set the watchdog I/O pin one way within the timer interrupt [1], and
> set it the other way at the top of my round-robin loop. This ensures that
> the watchdog is aware that a) the top-level code is running and b)
> interrupts are running. This strategy also has the nice side effect that I
> can watch the I/O line with a scope, and get an idea of system loading from
> the mark/space ratio of the signal [2].
>
> [1] Beware of doing *any* I/O from within interrupts - there be dragons. In
> this case I get away with it by ensuring that all I/O operations for the
> particular port I'm using are atomic.
In general yes, but not on the 8052 if SetB and ClrB instructions are
used. They don not read,modify,write. and are atomic.
Of course masking would not be atomic.
>
> [2] None of my software tasks pend (not a good thing to do in a cooperative
> multitsker ;)). Therefore there are no other places where I need to kick the
> watchdog. If you have lengthy tasks that could outlast the watchdog
> interval, you'll either need to duplicate the top-level kick, or better
> still, do as I do and turn them into state machines, and give control back
> to the round-robin sooner.
>
> Steve
> http://www.fivetrees.com
>
>
Reply by Neil Cherry●September 10, 20062006-09-10
On 10 Sep 2006 07:27:52 -0700, Mike Silva wrote:
>
> Neil Cherry wrote:
>> On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
>
>> > Your WD can be tickled as fast as you like, i.e. even a brutally
>> > simple
>> >
>> > while(1) {
>> > WD_PIN = 1; WD_PIN = 0;
>> > }
>> >
>> > would work.
>>
>> OK, now I feel stupid. I thought the minimum time meant you can't send
>> a tickle before that time so I've been working on the assumption I
>> need to send a tickle between 62.5ms and 250ms (now you see why I
>> needed a timer). I can now just stick the tickle in the main loop (no
>> timer) and let it do it's work. I actualy have that version working
>> but since I didn't understand why it worked I couldn't consider it
>> valid (a fix without understanding is just voodoo, not acceptable).
>> BTW, the actual chip is the MAX1232. I just read the Dallas app note
>> 144 which explains things a lot better (exactly what you pointed out
>> above).
>
> OK, that explains why you were talking about every 2nd interrupt. Yes,
> the trick is to tickle the WD as fast or faster than (in your
> situation) once every 62.5ms. The other trick is to make sure that
> _all_ your validation checks are met before giving a new tickle. All
> your checks can simply mean "I'm at this point in the main loop" or it
> can mean more. A typical strategy is to set a batch of flags after the
> WD has been tickled, and have a different flag cleared at every point
> in the program you want to monitor. Only when all the flags are
> cleared does the WD get tickled again, and the process starts over.
> This way you can check that all your tasks are running, your IO is
> working, etc. Just assure yourself that each flag will always get
> cleared in a timely manner when your program is running correctly, and
> that you check the flags often enough to guarantee that the WD is
> tickled in time after the last flag gets cleared.
This program is pretty simple take in some bytes from the serial and
display them (LEDs). The tickle lives in the main loop. Things will
get interesting in the next go around when the board will need to
receive data, process it (I/O) and respond back. Then the timer will
be more important. This will be one of my basic comm-link modules for
the HCS (a Home Control System - http://hcs.sourceforge.net/ - I need
to update the web page).
--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
http://home.comcast.net/~ncherry/ Backup site
Reply by Robert Adsett●September 10, 20062006-09-10
Neil Cherry wrote:
> On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
> > Your WD can be tickled as fast as you like, i.e. even a brutally
> > simple
> >
> > while(1) {
> > WD_PIN = 1; WD_PIN = 0;
> > }
> >
> > would work.
>
> OK, now I feel stupid. I thought the minimum time meant you can't send
> a tickle before that time so I've been working on the assumption I
> need to send a tickle between 62.5ms and 250ms (now you see why I
> needed a timer).
Some watchdog timers work in that fashion but not most. They do offer
some extra security by protecting against something that resets the
watchdog in a short endless loop.
Robert
Reply by Steve at fivetrees●September 10, 20062006-09-10
"Neil Cherry" <njc@cookie.uucp> wrote in message
news:slrneg81ca.cic.njc@cookie.uucp...
> On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
>> Neil Cherry <njc@cookie.uucp> wrote:
>>
> OK, now I feel stupid. I thought the minimum time meant you can't send
> a tickle before that time so I've been working on the assumption I
> need to send a tickle between 62.5ms and 250ms (now you see why I
> needed a timer). I can now just stick the tickle in the main loop (no
> timer) and let it do it's work. I actualy have that version working
> but since I didn't understand why it worked I couldn't consider it
> valid (a fix without understanding is just voodoo, not acceptable).
> BTW, the actual chip is the MAX1232. I just read the Dallas app note
> 144 which explains things a lot better (exactly what you pointed out
> above).
I know the MAX/DS1232 well; it's my watchdog/reset controller of choice in
most of my designs over the last few years.
As others have said, using a timer to kick the watchdog both ways is the
wrong way of going about things.
My strategy is fairly classic. I pretty much always have a heartbeat
interrupt running, i.e. a timer interrupt every (say) 5ms. I use this to
update any software timers I need. My top level code is based on a
round-robin, i.e. an infinite loop.
So I set the watchdog I/O pin one way within the timer interrupt [1], and
set it the other way at the top of my round-robin loop. This ensures that
the watchdog is aware that a) the top-level code is running and b)
interrupts are running. This strategy also has the nice side effect that I
can watch the I/O line with a scope, and get an idea of system loading from
the mark/space ratio of the signal [2].
[1] Beware of doing *any* I/O from within interrupts - there be dragons. In
this case I get away with it by ensuring that all I/O operations for the
particular port I'm using are atomic.
[2] None of my software tasks pend (not a good thing to do in a cooperative
multitsker ;)). Therefore there are no other places where I need to kick the
watchdog. If you have lengthy tasks that could outlast the watchdog
interval, you'll either need to duplicate the top-level kick, or better
still, do as I do and turn them into state machines, and give control back
to the round-robin sooner.
Steve
http://www.fivetrees.com
Reply by Mike Silva●September 10, 20062006-09-10
Neil Cherry wrote:
> On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
> > Your WD can be tickled as fast as you like, i.e. even a brutally
> > simple
> >
> > while(1) {
> > WD_PIN = 1; WD_PIN = 0;
> > }
> >
> > would work.
>
> OK, now I feel stupid. I thought the minimum time meant you can't send
> a tickle before that time so I've been working on the assumption I
> need to send a tickle between 62.5ms and 250ms (now you see why I
> needed a timer). I can now just stick the tickle in the main loop (no
> timer) and let it do it's work. I actualy have that version working
> but since I didn't understand why it worked I couldn't consider it
> valid (a fix without understanding is just voodoo, not acceptable).
> BTW, the actual chip is the MAX1232. I just read the Dallas app note
> 144 which explains things a lot better (exactly what you pointed out
> above).
OK, that explains why you were talking about every 2nd interrupt. Yes,
the trick is to tickle the WD as fast or faster than (in your
situation) once every 62.5ms. The other trick is to make sure that
_all_ your validation checks are met before giving a new tickle. All
your checks can simply mean "I'm at this point in the main loop" or it
can mean more. A typical strategy is to set a batch of flags after the
WD has been tickled, and have a different flag cleared at every point
in the program you want to monitor. Only when all the flags are
cleared does the WD get tickled again, and the process starts over.
This way you can check that all your tasks are running, your IO is
working, etc. Just assure yourself that each flag will always get
cleared in a timely manner when your program is running correctly, and
that you check the flags often enough to guarantee that the WD is
tickled in time after the last flag gets cleared.
Reply by Neil Cherry●September 10, 20062006-09-10
On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
> Neil Cherry <njc@cookie.uucp> wrote:
>
>> Something is wrong in my program and I need to resolve that.
>
> Good plan --- but how do you expect anybody to be able to help you
> with what's wrong in that program, if you don't show the program?
>
>> What I'd like to do with the final program is to keep the timer with
>> the WD but set a message in the main program. If the main program
>> fails the message won't be set, then the WD won't be tickled.
>
> Even done this way, it's still a waste of a timer. It would be a good
> deal simpler to just tickle the WD directly, in the place of the main
> code where you now plan to "set a message".
>
> Your WD can be tickled as fast as you like, i.e. even a brutally
> simple
>
> while(1) {
> WD_PIN = 1; WD_PIN = 0;
> }
>
> would work.
OK, now I feel stupid. I thought the minimum time meant you can't send
a tickle before that time so I've been working on the assumption I
need to send a tickle between 62.5ms and 250ms (now you see why I
needed a timer). I can now just stick the tickle in the main loop (no
timer) and let it do it's work. I actualy have that version working
but since I didn't understand why it worked I couldn't consider it
valid (a fix without understanding is just voodoo, not acceptable).
BTW, the actual chip is the MAX1232. I just read the Dallas app note
144 which explains things a lot better (exactly what you pointed out
above).
I'll be back with more information about the timer problem as that is
what the original post is about and I'm still not sure where the
problem is.
--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
http://home.comcast.net/~ncherry/ Backup site
Reply by Hans-Bernhard Broeker●September 10, 20062006-09-10
Neil Cherry <njc@cookie.uucp> wrote:
> Something is wrong in my program and I need to resolve that.
Good plan --- but how do you expect anybody to be able to help you
with what's wrong in that program, if you don't show the program?
> What I'd like to do with the final program is to keep the timer with
> the WD but set a message in the main program. If the main program
> fails the message won't be set, then the WD won't be tickled.
Even done this way, it's still a waste of a timer. It would be a good
deal simpler to just tickle the WD directly, in the place of the main
code where you now plan to "set a message".
Your WD can be tickled as fast as you like, i.e. even a brutally
simple
while(1) {
WD_PIN = 1; WD_PIN = 0;
}
would work.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply by Robert Adsett●September 10, 20062006-09-10
Neil Cherry wrote:
> Something is wrong in my program and I need to resolve that. I fell
> back to a simple RS232 program with hello and echo. The DS1232 was put
> on timer 0 to simplify things. What I discovered is that I have a
> problem with my timer. To make matters odder, I had this working with
> just one pass of the timer 0 interrupt. When I tried it again it
> failed (???). At that point I decided to simplify.
This is really a job for a 'scope or a logic analyzer. Even one of
those inexpensive USB based logic analyzers is likely to be more
illuminating that periodic resets.
I've not used them so I don't know how good they are but something like
the ant8 at ~U$200 will pay for itself pretty quickly even if it's only
halfways decent. Others here have probably used a few different ones
and may be able to recommend something inexpensive. If it's a
commercial project you'll eat up that much on your time pretty quickly.
Of course if you insist on a linux version you might have to do more
searching. Windows usually has a cost advantage here.
Robert
Reply by Neil Cherry●September 9, 20062006-09-09
On 9 Sep 2006 21:02:26 GMT, Hans-Bernhard Broeker wrote:
> martin griffith <mart_in_medina@yahoo.esxxx> wrote:
>> On 9 Sep 2006 19:49:53 GMT, in comp.arch.embedded Hans-Bernhard
>> Broeker <broeker@physik.rwth-aachen.de> wrote:
>
>> >Neil Cherry <njc@cookie.uucp> wrote:
>> >> I'm losing my mind with the timer and I can't find out what I'm doing
>> >> wrong. I have an 8051 (Atmel 89C2051 really), Xtal = 11.059200 MHz and
>> >> a DS1232 (watchdog chip). What I need to do is to pulse (active low)
>> >> the strobe line on the DS1232 to keep the 8051 from getting reset.
>> >
>> >Setting aside your problems with wrapping your head around how to
>> >steer a timer: petting the watchdog is no job for a timer. You want
>> >to inform the watchdog that your main program still runs, not that
>> >some timer survived a total crash of program.
>
>> Ah, I remember hearing of a 805x crashing, but the timer kept working,
>> so it did not reset, which tickled the WD. Is this what you meant?
>
> Not quite. You have the last two items the wrong way round. The
> problematic case is this: the main app crashes (e.g. got stuck in an
> endless loop waiting for some event that can't happen), but the timer
> interrupts kept working, which keeps tickling the 'dog, so the CPU
> never gets reset.
>
> A setup like that wastes any money, time and board space spent on the
> WD for no effect.
To everyone (this is not direct at Hans-Bernhard):
Something is wrong in my program and I need to resolve that. I fell
back to a simple RS232 program with hello and echo. The DS1232 was put
on timer 0 to simplify things. What I discovered is that I have a
problem with my timer. To make matters odder, I had this working with
just one pass of the timer 0 interrupt. When I tried it again it
failed (???). At that point I decided to simplify.
What I'd like to do with the final program is to keep the timer with
the WD but set a message in the main program. If the main program
fails the message won't be set, then the WD won't be tickled. This
will gaurantee the I get a tickle between 62.5 ms and 250 ms if the
program is working. But for now I needed to simplify. This is not the
final program.
--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
http://home.comcast.net/~ncherry/ Backup site
Reply by Neil Cherry●September 9, 20062006-09-09
On Sun, 10 Sep 2006 09:26:35 +1200, Jim Granville wrote:
> Neil Cherry wrote:
>>
>> Oh, that would be a good thing for me to describe. I can't watch the
>> time interval (no scope). I have a volt meter which gives frequency
>> but I doubt it's doing me much good (say 42KHz). The basic problem is
>> that the chip is reseting. I see the start up message approximately
>> every second. It looks like I'm getting no interrupt. If I run the
>> 8051 w/o the DS1232 I can manually reset it and the rest of the
>> program runs OK. I guess I could fall back on 'print' statements to
>> see if the interrupt is being run (I also have RS232 which is working
>> w/o interrupts at this time.
>
> If you have a Frequency Multimeter, then simply toggle a pin in the
> interrupt, and remove the 1232 reset line, while you are testing.
> That tells you both that the INT is alive, and you can easily
> calculate what the INT rate is ( half cycle = int time ).
This is what I have but the battery is getting low and I'm not sure it
working properly. I'll get a new battery tomorrow and remove that
doubt.
> Of course, you do realise that using a timer interrupt to ping a
> watchdog, will miss a whole raft of possible system failures ? :)