Ok, started from scratch on just flashing LEDs using a timer overflow to
trigger.  Eventually on a fluke I found that it was the XTAL causing the
issues... or at least apparently so.  I remove the XTAL and magically the
PIC starts doing stuff... not sure why the XTAL would effect the timer stuff
and not a delay loop.  Even weirder is the fact that the flag is still set
for an external OSC and the PIC runs, instead of setting it for an internal
RC OSC.  So you would think this wouldn't work... unless the PIC defaults to
the internal OSC if an external isn't present.

Even weirder, using the Eggtimer example on
http://www.piclist.com/techref/piclist/cheapic/eggtimer.htm the statements

movlw           H'FF'
subwf           sec   ;sec equals 0 initially

and during operation on these statements the result of 00 - FF = 4F.  This
has me a bit confused, I mean if the result was 8F I could explain it away
as a signed value sitting in the sec location, but 4F?  Additionally there
seems to be some other values being changed when they shouldn't be.  It's
acting as if the variable's memory locations are overlapping and so some
bits are changing when the shouldn't.  But I can't seem to figure out why...
is there a way to declare how much space a value takes up or what type of
value is located in a given location?

I can't see why I'm having so much trouble with a PIC, I've worked with the
Motorola HC11 series and for some reason this stuff just seems to be acting
'flakey' is how to best describe it.  What I think should work doesn't, and
what shouldn't work (compiling telling the PIC that it's got an ext OSC, and
then runs withour one) does.  This is just frustrating!!

Keith L. Kovala
klk@renderelement.com

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of
> Richard.Prosser@POWERWARE.COM
> Sent: Monday, December 15, 2003 3:39 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC:] 16F818 Timer Interrupt and PORTB
>
>
> Keith,
>
> I suggest you simplify things, try just flashing an led using
> the interrupt to start with and then build from there.
>
> As someone else has indicated, there is an incorrect retfie
> after you initialise your ports although I can't see it
> causing too much of a problem. (His other suggestions look
> equally valid).
>
> I'd set up a simple interrupt driven flashing led program &
> get that running. It sounds very much "back to basics" but if
> the simulation is working OK & the real part isn't the usual
> suspects are  watchdog timer, brownout detector and
> oscillator setup. Since you have already had it working using
> delay routines, all of these seem unlikely, but would be
> worth checking. Failing that it is something less obvious and
> a back to basics approach may help.
>
> Or could there be a hardware problem?- I spent a day once
> tracking down a similar problem and found I had a short
> between the reset line and one of my outputs - every time I
> hit a particular instruction I got a reset - quite confusing.
>
> Richard P
>
>
>
> The final idea is yes, to have each value incremented via a
> timer interrupt. As it is currently set up it is NOT supposed
> to do that.  Right now, one timer interrupt should trigger a
> full count from 0 - 9 to show up, but as it stands it will
> trigger the interrupt and then freezes/stops after setting
> the display to 0.  It seems to execute no further instructions.
>
> Originally, PORTA was set to digital but taking it out of
> digital seemed to have no effect, especially since it's PORTB
> that isn't updating.  Just using the delay routine to display
> on the LED works fine with PORTA in digital or not... though
> one is slightly dimmer than the other.
>
> The original premise here was to use the code from AN557 to
> explore the multiplexing and A/D converter.  My final goal is
> a voltmeter, but I'm using this to learn along the way.
> Anyways, taking the source code straight from AN557 into the
> 16F818 did not work for some obvious reasons.  I changed the
> register name constants and register settings to the
> corresponding ones. The code would then compile and run fine
> in the simulator.  So, programmed the PIC, and saw nothing
> but the first digit to be displayed.  So I ripped up the
> code, wrote some rather hasty delay based code to see if I
> could get the PIC to count.  That worked... now when I start
> playing with the interrupt stuff again I'm back to the same
> problem.  Stops after displaying the same character.  I had
> programmed the PIC so many times (maybe 50 - but felt like a
> million) I thought maybe the chip was just bad.  I pulled a
> fresh one and same thing again, so led me back to it being
> the code. However, I am unable to find the problem.
>
> Keith L. Kovala
> klk@renderedelement.com
>
> --
> http://www.piclist.com hint: The PICList is archived three
> different ways.  See http://www.piclist.com/#archives for details.
>
> --
> http://www.piclist.com hint: The PICList is archived three
> different ways.  See http://www.piclist.com/#archives for details.
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body