Searching \ for '[PIC] Can anyone explain this 16F88 behavior?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Can anyone explain this 16F88 behavior?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Can anyone explain this 16F88 behavior?'
2007\10\21@021706 by Don French

picon face
I got the following routine with the free CC5 compiler :

void delay_ms( uns16 millisec)
// Delays a multiple of 1 milliseconds at 4 MHz
// using the TMR0 timer
{
   char next = 0;
   OPTION = 2; // prescaler divide TMR0 rate by 8
   TMR0 = 2;  // deduct 2*8 fixed instruction cycles delay
   do  {
       next += 125;
       clrwdt();  // needed only if watchdog is enabled
       while (TMR0 != next)   // 125 * 8 = 300 (= 1 ms)
           ;
   } while ( -- millisec != 0);
}

It works quite well almost all the time.  However, when the following
code is executed first, delay_ms fails the first (and only) time it is
called after that:

SPEN = 1;
CREN = 1;
RCIE = 1;        
PEIE = 1;        
GIE = 1;        

The first time delay_ms is called it adds about 65 seconds to the
delay.  I am guessing that it actually adds something very close to
65.535 seconds, but I haven't tried to prove it. It doesn't matter if
the first delay is for 10ms or 20,000, it adds about 65000 ms to the
delay. However, on every succeeding call, delay_ms appears to work
just fine.

Actually, it appears that setting SPEN and any of the interrupt enable
bits or the continuous receive bits causes this odd behavior.   Maybe
some of you more experienced PIC folks can explain this.  It took me
the better part of the evening to isolate what was causing this. Is it
a bug? A feature?  Expected behavior?  It is definitely irritating.

-- Don French

2007\10\21@153613 by Don French

picon face
Sorry, one thing I said was incorrect.  I just ran an exhaustive set
of tests and the problem only occurs when ALL of the following are set
prior to calling delay_ms:

SPEN, CREN, RCIE, PEIE, GIE

Could it be that TMR0 doesn't start counting for 65,000 ms (65,535?)
when it is started with all these bits set?

-- Don French



On 10/20/07, Don French <spam_OUTdcfrenchTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

--
DC French

2007\10\21@162850 by John Temples

flavicon
face
On Sun, 21 Oct 2007, Don French wrote:

> Sorry, one thing I said was incorrect.  I just ran an exhaustive set
> of tests and the problem only occurs when ALL of the following are set
> prior to calling delay_ms:
>
> SPEN, CREN, RCIE, PEIE, GIE

I don't understand what your code is doing (what does 125 * 8 = 300
mean?), but it appears that you're expecting a busy loop to encounter
a specific value in TMR0 while interrupts are enabled.  TMR0 is still
counting during the interrupt, so that scheme isn't likely to work.

{Quote hidden}

> --

2007\10\21@164304 by Robin Abbott

flavicon
face
Looks to me like you have an unexpected interrupt occuring - can you
simulate the code, and if so check what happens when you call it?


Robin Abbott
Forest Electronics - Home of WIZ-C ANSI C Compiler for PIC's with RAD Front
end
robin.abbottspamKILLspamfored.co.uk
http://www.fored.co.uk


{Original Message removed}

2007\10\22@150603 by Don French

picon face
For the record, the delay routine is not code that I wrote.  It is
supplied with the CC5X compiler.  But it does work every time except
the first time after setting all five of the enable bits I mentioned:
Serial port enable (SPEN), Continuous receive enable (CREN),
Peripheral interrupt enable (PEIE), Global interrupts enable (GIE),
Recieve interrupts enable (RCIE).  If I omit setting any one of these,
the delay works perfectly.

I think that the 125 * 8 = 300 comment must have been a typo.  It
makes sense if it reads 125 * 8 = 1000.

My test program has no interrupt processing as it doesn't expect to
receive any, but that may be a mistake.  I have been testing this in a
PIC DEMO 2 Plus board and it may be that an unplanned interrupt is
occurring.  I have to look into that possibility.  If so, maybe after
the jump through the uninitialized interrupt vector to who-knows-what
location, the watchdog timer eventually restarts the program.  But if
this is what is happening, why do all five enable bits need to be set
for the problem to occur?


> I don't understand what your code is doing (what does 125 * 8 = 300
> mean?), but it appears that you're expecting a busy loop to encounter
> a specific value in TMR0 while interrupts are enabled.  TMR0 is still
> counting during the interrupt, so that scheme isn't likely to work.
>

2007\10\22@163357 by PAUL James

picon face

Don,

FYI, I was using a PICDEM2 board, actually two of them, here in our lab
to demo some I2C
Comms between the two boards and a PC.  We couldn't get it to work
reliably.  So we decided
To try SPI.  However, we found out that this acted similar to the I2C
scenario.

I contacted Microchip tech support, and they came back the next day with
the verdict that we
Couldn't use the boards for development.  They were intended to demo
software mostly that
utilized the peripherals already included on board.  

We tried removing the peripherals on board to eliminate the possibility
of conflicts between
Our components and those on the board.  This didn't work too reliably
either.  Although it was
Somewhat better than before.

Our final verdict...Don't use the PICDEM2 board for development
purposes.  We got two boards
that were designed for development purposes and used them.  About two
days later, we had a
working demo system.  The final tester used the demo with a few minor
changes.  It is still
running today.  And that was about three years or so ago.

Moral..When developing projects, use boards designed for project
development.  You'll be happier,
      you'll have fewer problems that you can't readily track down, and
development will go much
      quicker.  


       
Regards,

       
Jim



{Original Message removed}

2007\10\22@171436 by Jason Harper

picon face
On Oct 22, 2007, at 2:06 PM, Don French wrote:
> For the record, the delay routine is not code that I wrote.  It is
> supplied with the CC5X compiler.  But it does work every time except
> the first time after setting all five of the enable bits I mentioned:
> Serial port enable (SPEN), Continuous receive enable (CREN),
> Peripheral interrupt enable (PEIE), Global interrupts enable (GIE),
> Recieve interrupts enable (RCIE).  If I omit setting any one of these,
> the delay works perfectly.
>
> My test program has no interrupt processing as it doesn't expect to
> receive any, but that may be a mistake.

If you have no interrupt processing, then why the heck are you  
enabling interrupts?

With those five bits set, any noise on the RX pin will trigger an  
interrupt (after a delay set by your baud rate setting).

2007\10\25@070210 by Don French

picon face
(once more with the correct subject)


Right, I had no good reason for enabling interrupts.  I pasted in some usart
code to try to get something working fast and never expected interrupts to
occur so didn't pay that much attention to them.  It took me quite a
while to figure out what  was wrong with the program and to isolate
the problem to the setting those bits, but when I did, I wanted to
know exactly which ones were causing the problem.  And it turned out
it was all of them.

I accept your statement that a signal on the RX pin probably caused
the problem but why do both GIE and PEIE need to be set for the
unplanned interrupt to occur?

On Oct 22, 2007, at 2:06 PM, Don French wrote:
{Quote hidden}

If you have no interrupt processing, then why the heck are you
enabling interrupts?

With those five bits set, any noise on the RX pin will trigger an
interrupt (after a delay set by your baud rate setting).

2007\10\25@072348 by Jan-Erik Soderholm

face picon face
Don French wrote:

> ...but why do both GIE and PEIE need to be set
> for the unplanned interrupt to occur?

On the RX-pin specificaly ?
Maybe becuse that's how it's documented ?

GIE: Glabal enable (must always be set).
PEIE: Peripherial enable, and the USART is an peripherial.

Or did I missunderstand the question ?

Jan-Erik.

2007\10\25@073026 by Alan B. Pearce

face picon face
>I accept your statement that a signal on the RX pin
>probably caused the problem but why do both GIE and
>PEIE need to be set for the unplanned interrupt to occur?

The datasheet does explain quite clearly how the interrupt enable chain
works. Look at figure 15-7 (Rev B datasheet, page 139)

2007\10\25@124812 by Don French

picon face
Thanks!  As you can tell, I am new at this.

>
>  > ...but why do both GIE and PEIE need to be set
>  > for the unplanned interrupt to occur?
>
> On the RX-pin specificaly ?
> Maybe becuse that's how it's documented ?
>Or did I missunderstand the question ?

>Jan-Erik.

2007\10\25@132745 by Bob Axtell

face picon face
Forget about it!  We were all new once...

--Bob

Don French wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...