CNT Overflow/Wrap-around; What happens?

WildDave

Forgive me if·this has been documented somewhere else, but what happens if CNT is within say 100_000 ticks of its maximum value (almost ready to wrap around) and·a WAITCNT(3_000_000 + CNT) is issued?· Does the·SPIN interpreter handle the carry/overflow and perform the full wait of 3_000_000 ticks or does it only wait for 100_000 ticks?· Since the counter will wrap almost every minute at full speed, I was wondering if it might be something we need to program around.

All the examples seem to use that syntax (3_000_000 + CNT) with no mention of what might happen if the counter is ready to wrap, and I was just curious if it's handled or if it's something·we need to think about.

Thanks.

Ken Peterson

When you add 3_000_000 + CNT and it exceeds 32 bits, it wraps around with no carry. The waitcnt statement then stops until CNT equals this result (CNT also wraps around). Therefore no additional program code is necessary to handle the wrap-around.

Make sure you use "3_000_000 + CNT" and not "CNT + 3_000_000" to make sure you get the latest value of CNT in your calculation as the expression is evaluated left to right.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

CardboardGuru

Both CNT and the long that Spin uses for the result of 3_000_000 + CNT are both 32 bit values that wraparound in exactly the same way. So you don't need to worry about it, it just works.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

WildDave

Thanks, Ken. Considering the counter resolution for interpreted SPIN statements is somewhere around 400, I wasn't sure if it did an exact "equal" match or a "greater-than-or-equal" match on the CNT value.· It's good to know it's handled in the hardware.·I appreciate the fast response.

Take care.

deSilva

Ken Peterson said...
Make sure you use "3_000_000 + CNT" and not "CNT + 3_000_000" to make sure you get the latest value of CNT in your calculation as the expression is evaluated left to right.

This is an often repeated but nevertheless useless statement.
The Propeller has no delay instruction for good reasons, as a "delay" can NEVER be timed precisely without considering the EXACT time for instruction performance.

In most cases a delay is not needed with reference to the time of issueing the wait instruction, but from a quite different basis, either an exit from a former wait, or a CNT caught as soon as possible after a certain external event.

Something like WAITCNT(..CNT...) is always so far away from precise timing that the position of CNT within the expression makes little difference.

Recommended best practices for WAITCNT are:

  WAITPEQ...
  eventTIme := CNT ' use "eventTime" with WAITCNT later

or

  deadline := CNT
  REPEAT
     WAITCNT (deadline += period)
 ...

Post Edited (deSilva) : 1/8/2008 1:39:25 AM GMT

Phil Pilgrim (PhiPi)

The subtraction result is obtained without regard to the signs of the two numbers or to the consequences of any overflows that may occur. So the signs of the operands do not have to be checked. For certain very long delays, of course, the result itself may have the sign bit set — a possibility the astute programmer will be sure to consider in any subsequent signed comparisons. But if the delay can be that long, the possibility of more than one cycle through CNT's total range may also have to be considered.

-Phil

deSilva

The "timescale" Phil talkes of is 50 sec. That is the "aliasing" time after which you can no longer distiguish between the eras, so to speak. 50 seconds is an extraordinary long time in mircocontrolling....

Getting acquainted to "wrap around arithmetic" also needs some time. My imagination works best when I pretend all numbers are unsigned (so it's the mathematical "modulus" operation you perform). Then, only when using SPIN compare operations I consider the consequences. This last step is not necessary in assembly, as it has unsigned compare instructions as well.

What to do when you want to sync to 1 sec but cannot engage a WAITCNT as you want to do things during that time?

nextDeadline := CNT
REPEAT
' loop for  seconds
  nextDeadline += CLKFREQ
  REPEAT WHILE  CNT < nextDeadline
      ' do (repeatedly) things here

This will - sometimes - not work
The correct code is:

lastDeadline := CNT
REPEAT
' loop for seconds
  REPEAT WHILE  CNT- lastDeadline < CLKFREQ
      ' do (repeatedly) things here
  lastDeadline += CLKFREQ

Post Edited (deSilva) : 1/12/2008 12:08:26 PM GMT