AVR-GCC for Linux doesn't handle well 16 bit words

Projects Programming
63

Back to the original problem in post #1 which still does not appear to have been solved. That is that a while loop appears, under certain circumstances, not to have executed when it should have.

I have made the following observation based on the output shown in post #1 and post #11 :

In the “failure” case, the number of ticks which elapse between the “before” and “after” time stamps is random and usually greater than one. In two cases, it is as much as 9 ticks.
In the “success” case the difference between the adjacent time stamps is 1 tick.

This would indicate that, in the failure case, the while loop is in fact executing, and a number of times, before prematurely failing. This supports the “non atomic read” theory in post #32.

The test is simpler than previously suggested although not necessarily a solution. Simply wrap the asynchronously updateable part in cli()/sei() as below. If that appears then to perform correctly, it would show that the attempt in xTaskGetTickCount() to handle multiple byte variables atomically has failed.

From post #1 :

void software_delay( TickType_t ticks )
{
   volatile TickType_t now = xTaskGetTickCount();

   Serial.print( "\nBefore: " ); Serial.println( now );

   volatile TickType_t next_wakeup = now + ticks;
   Serial.print( "Next: " ); Serial.println( next_wakeup );

   while( 1 )
   {
      if( now > next_wakeup ) 
         break;
      cli() ; // suspect the following is non atomic 
      now = xTaskGetTickCount();
      sei() ;
   }

   Serial.print( "After: " ); Serial.println( now );
}

If that is not compatible with the RTOS such that the above test cannot be carried out then, in the while loop, do a test to see if the value of the variable “now” is, at any time, less than its immediately previous value (as may be the case in a partial read operation) and, if so, print an error message.

1 Like