I've been playing with this bit of code for a few days now and I can't see
what the problem is.
Using RB0 the code should generate a morse signal as DIT - DAH - DIT - DAH -
DIT - DAH reapeatedly. However I seem to be getting an extra DAH in there
somewhere. I am getting DIT - DAH - DIT - DAH - DIT - DAH - DAH repeatedly.
Looking at the code can anyone see a problem, or can i assume it is a
hardware problem.
************************************************************************
How many programmers does it take to change a light bulb?
They refuse. They say, "It's a hardware fault". -- Arthur Buse
************************************************************************
>
> Using RB0 the code should generate a morse signal as DIT - DAH - DIT - DAH -
> DIT - DAH reapeatedly. However I seem to be getting an extra DAH in there
> somewhere. I am getting DIT - DAH - DIT - DAH - DIT - DAH - DAH repeatedly.
I've been playing with this bit of code for a few days now and I can't see
what the problem is.
Using RB0 the code should generate a morse signal as DIT - DAH - DIT - DAH -
DIT - DAH reapeatedly. However I seem to be getting an extra DAH in there
somewhere. I am getting DIT - DAH - DIT - DAH - DIT - DAH - DAH repeatedly.
Looking at the code can anyone see a problem, or can i assume it is a
hardware problem.
************************************************************************
How many programmers does it take to change a light bulb?
They refuse. They say, "It's a hardware fault". -- Arthur Buse
************************************************************************
> I've been playing with this bit of code for a few days now and I can't
see
> what the problem is.
>
> Using RB0 the code should generate a morse signal as DIT - DAH - DIT -
DAH -
> DIT - DAH reapeatedly. However I seem to be getting an extra DAH in there
> somewhere. I am getting DIT - DAH - DIT - DAH - DIT - DAH - DAH
repeatedly.
>
> Looking at the code can anyone see a problem, or can i assume it is a
> hardware problem.
As someone else allready pointed out, your program stops at the END
directive, but the PIC's Program-counter does not. So it will continue
into uncharted lands :-) Amazing that your program went into a loop !
Another thing: You _did_ disable the WachDog, did you ... <grin>
>
> Another thing: You _did_ disable the WachDog, did you ... <grin>
>
> Greetz,
> Rudy Wieser
>
Ahah! I'm not sure.... I will check when I get home from work tonite.
> I've checked the watchdog timer, and indeed it was enabled.
> I've now disabled it and the circuit is working perfectly.
> What does the watchdog time do exactly?
Wachdog-timers are invented to mess-up programs of Newbies. Really ! :-)
Ah, well. Id see you don't beleive me. O.k. Another explanation of their
existence: It is possible that a controller will get stuck in some kind of
loop, due to bad programming (go kick the programmer :-) or due to power
spikes and the like. When this happens, the circuit has to be reset to
enable it to work again.
So, the first controllers where build wid a LED attached, that blinked when
all was well. If it stopped blinking, someone had to press the RESET
button.
After a while someone build a "missing puls" detector (a retriggerable
mono-flop) and connected that to the blinking led and the RESET button.
Now, whenever the led stopped blinking, the mono-flop would time-out, and
reset the system. No human needed anymore !
Later they decided to build the mono-flop into the system. That feature is
now known as a "WachDog". It will simply count pulses (from and
independend internal source). If the WachDog-counter overflows it will
either Reset the controller (or generate a Interrupt, depended on how it's
configured). The blinking LED was replaced by an Instruction to re-set the
WachDog (CLRWDT -> Clear WachDog Timer).
So, when a WachDog is enabled and not re-set every once-in-a-while, it will
eventually reset the controller, creating strange effects for unsuspecting
Newbies .... (Sorry, could not let this one go ... :-)
Just a quick message to say thanks for the explanation.
It does sound that if used properly the watchdog timer can be a very usefull
feature.
Is it just a case that when using it you must issue the CLRWDT command.
Thanks again
Dan
************************************************************************
Daniel Watford
CCTEC Ltd.
23 Station Road
Westgate
KENT CT8 8RB
UK
************************************************************************
How many programmers does it take to change a light bulb?
They refuse. They say, "It's a hardware fault". -- Arthur Buse
************************************************************************
Daniel Watford wrote:
>
> Hi Caisson,
>
> Just a quick message to say thanks for the explanation.
>
> It does sound that if used properly the watchdog timer can be a very usefull
> feature.
> Is it just a case that when using it you must issue the CLRWDT command.
>
> Thanks again
>
> Dan
Watchdog Timer's pretty much mandatory on life-critical systems (On
avionics, for example, you don't want a 747 crashing into the ground
because your ground proximity warning system's been hung for the last 3
hours, due to a cosmic ray ionizing things & crashing your GroundProx
system.) Wouldn't be good if the CPU in someone's pacemaker crashed,
either... I prefer "Feed the dog" to "Kick the dog" which some people
use when resetting the Watchdog Timer (Dogs're FAR happier when fed
treats, then when kicked!) WDT isn't particularly necessary on LED
blinkers & so on <G>
> It does sound that if used properly the watchdog timer can be a very
usefull
> feature.
It is !
> Is it just a case that when using it you must issue the CLRWDT command.
No. You have to set-up the Wach-dog timer first. It must be enabled (in
the configuration-word), and you can assign a pre-scaler to it, so that the
time-out of the wachdog-timer can be extended. And you can define what an
wachdog time-out does: Reset the device, or issue an interrupt. Default :
No prescaler, reset the device (as you have noticed :-)
cctec.ltd.uk
