I-CUBE-LRWAN V1.1.0 Why the -1 to Unsigned Cast?

[ron239955_stm1_st]

Posted on May 18, 2017 at 22:10

In I-CUBE-LRWAN V1.1.0 RegionCommon.c there's a function that returns the next duty cycle delay as follows:

TimerTime_t RegionCommonUpdateBandTimeOff( bool dutyCycle, Band_t* bands, uint8_t nbBands )

{

   TimerTime_t nextTxDelay = ( TimerTime_t )( -1 );

   // Update bands Time OFF

   for( uint8_t i = 0; i < nbBands; i++ )

   {

      if( dutyCycle == true )

      {

         if( bands[i].TimeOff <= TimerGetElapsedTime( bands[i].LastTxDoneTime ) )

         {

            bands[i].TimeOff = 0;

         }

         if( bands[i].TimeOff != 0 )

         {   

            nextTxDelay = MIN( bands[i].TimeOff - TimerGetElapsedTime( bands[i].LastTxDoneTime ),

            nextTxDelay );

         }

      }

      else

      {

         nextTxDelay = 0;

         bands[i].TimeOff = 0;

      }

   }

      return nextTxDelay;

}

This compares the period between the last transmission for the band and now with the duty cycle timeoff period, returning the next transmission delay period to comply with the duty cycle.

TimerTime_t is a 32 bit unsigned integer

So the first line 

TimerTime_t nextTxDelay = ( TimerTime_t )( -1 );

casts a signed to an unsigned integer, effectively setting it to a very large number 0xFFFFFFFF i.e. a huge delay.

So my question is, is that intentional?  If so, for what purpose, how does it work?  I would like to understand this code better.

Many thanks in advance, Ron.

[Tesla DeLorean]

Posted on May 18, 2017 at 22:38

Isn't it a way of indicating there are no usable entries in the table? Looks to be a purposeful setting of a maximal value (size agnostic)

[ron239955_stm1_st]

Posted on May 18, 2017 at 23:01

Thanks Clive for responding so quickly.  Yes, I agree it doesn't look like a typo. What you suggest could make sense if the very large value was being conditionally checked downstream, which I haven't seen (in any case a horrible way to flag a table entry!).

Although I haven't been able to trace the behaviour right through properly, it looks like that value is being used to setup a transmission delay timer. When a 100% duty cycle is configured for band 0 (IN865 region, which has a single band), the MAC seems to get stuck forever in a transmission delayed state (16).

[Tesla DeLorean]

Posted on May 19, 2017 at 01:41

It's clearly constructed to allow for downstream code to catch the empty list, or no usable values, whether it does so is a whole other matter.

There's quite a lot of egregious code in I-CUBE-LRWAN, stuff that blocks, interrupt priorities backarseward, etc.

I'll browse this path later, I'm mainly building pingers and listeners at the moment, in the 902-928 MHz band.