Searching \ for '[PIC]: 16C73 vs 16F873: stability and timing' 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: '16C73 vs 16F873: stability and timing'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16C73 vs 16F873: stability and timing'
2001\04\04@180139 by Mike Mansheim

flavicon
face
Here's a general observation, but unfortunately it doesn't have anything
to do with differences between the C and F parts.

       // sync with transition of timer 1
       timer = T1_HIGH;        // changes at 128 Hz
       while (timer = T1_HIGH);

will loop until T1_HIGH equals 0, so the intent is to wait here until the
timer rolls over.  I am quite leery of trying to catch a timer at an
exact value while polling.  This while statement will compile into
several instructions - I would be concerned that the timer will roll and
go beyond zero while you're working on the compare, and you'll miss it.
Timer 1 is a 16 bit timer, so it will increment 65,536 times.  At 128 Hz,
that's approx. .12 us per timer tick.  If you are running a 10M clock,
each instruction takes .4 us.
This doesn't explain why a C would work and an F would not, unless
something else changed.  Did you:
 - change the timer frequency?
 - change the clock?
 - change the timer you are using?
   (the other two are 8 bit timers, which will increment only 256 times)

This doesn't relate directly to your question, but I'm curious about
this chunk:

       timer = T1_HIGH;        // update current state
       // count transitions of INBIT
       while (poll_count) {
               if (clk_bit != INBIT) {
                       clk_bit = INBIT;
                       result++;
               }
               if (timer != T1_HIGH) {
                       timer = T1_HIGH;
                       poll_count--;
               }
       }

With the disclaimer that it's been a long day, it's not immediately
obvious to me what the timer comparison does here.  I would think that
(timer != T1_HIGH) would always be true, and poll_count would simply
be decremented every time through the loop.  What am I missing??

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\04@182636 by embedded engineer

flavicon
face
Mike Mansheim wrote:
>
> Here's a general observation, but unfortunately it doesn't have anything
> to do with differences between the C and F parts.
>
>         // sync with transition of timer 1
>         timer = T1_HIGH;        // changes at 128 Hz
>         while (timer = T1_HIGH);

I should have included in my code:

#BYTE T1_HIGH = 0x0f

> will loop until T1_HIGH equals 0, so the intent is to wait here until the
> timer rolls over.  I am quite leery of trying to catch a timer at an
> exact value while polling.  This while statement will compile into

It blocks until a change only, indicating overflow from T1_LOW.  At a
32768 Hz input for timer1, that is 1/128 seconds (128 Hz) per transition
if I am doing my math correctly.  Nonetheless, with C it works very
well.

{Quote hidden}

All source code same: C and F compiles.  Only difference is to compile
for the respective targets, although I expect the  results are the same.

{Quote hidden}

pseudocode:

       result = 0
       counter = K
       while counter > 0 {
               if (polled clock bit changed)
                       result++
               if (real time clock tick)
                       counter--
       }

> With the disclaimer that it's been a long day, it's not immediately
> obvious to me what the timer comparison does here.  I would think that
> (timer != T1_HIGH) would always be true, and poll_count would simply
> be decremented every time through the loop.  What am I missing??

Remember T1_HIGH is a hardware register.


Thanks for the input.

David

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\05@104208 by David Cary

flavicon
face
Dear ``embedded engineer'' David,

embedded engineer <spam_OUTembeddedTakeThisOuTspamELUCIT.COM> on 2001-04-04 05:25:20 PM (David) wrote:

...
...
>#BYTE T1_HIGH = 0x0f
...
>         // sync with transition of timer 1
>         timer = T1_HIGH;        // changes at 128 Hz
>         while (timer = T1_HIGH);
...
> It blocks until a change only, indicating overflow from T1_LOW.

This may not solve your problem, but have you considered saying
        while (timer == T1_HIGH);
?
(Using single equals inside a if() or while() expression, when I meant to use a
double equals, is the number 1 mistake I make when writing C code. I set my C
compiler to give me a error when I do that.)

{Quote hidden}

I doubt this is your problem, but some people would write code more like
         BYTE end_time = timer+poll_count;
         while( 0 < (BYTE)(end_time - T1_HIGH) ) {
>                 if (clk_bit != INBIT) {
>                         clk_bit = INBIT;
>                         result++;
>                 }
>         }
so they don't lose time if T1_HIGH counts 3 or 4 times during a long interrupt.
The comparison above has the amazing property of Doing the Right Thing even when
T1 overflows,
unlike
         while( T1_HIGH < end_time ) { doesn't work when end_time = 0xFF and T1
skips a count to reach 0x00.}

Since you have disabled interrupts, this doesn't matter.
Also, this only works up to poll_count == 0x7F (um... I think ...), while your
method works even for poll_count == 0xFF.

...
--
David Cary

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


2001\04\05@135844 by embedded engineer

flavicon
face
David Cary wrote:
>
>
> ...
> ...
> >#BYTE T1_HIGH = 0x0f
> ...
> >         // sync with transition of timer 1
> >         timer = T1_HIGH;        // changes at 128 Hz
> >         while (timer = T1_HIGH);
> ...
> > It blocks until a change only, indicating overflow from T1_LOW.
>
> This may not solve your problem, but have you considered saying
>          while (timer == T1_HIGH);
> ?

Sorry about the typo.  It is not cut-n-paste and indeed, the original
reflects your correction.

{Quote hidden}

There is also the issue of size/speed of code when using signed versus
unsigned math. Hmmm...

> Since you have disabled interrupts, this doesn't matter.
> Also, this only works up to poll_count == 0x7F (um... I think ...), while your
> method works even for poll_count == 0xFF.

Thanks for the input,
David

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


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