Embedded Linux - Constant Loop time

Question

I am using a Colibri iMX6 DualLite SoM from Toradex. It is based on a multicore ARM Cortex™A9 processor. I'm running an Embedded Linux distribution provided by toradex in it. We are developing a precision analog DAQ product using it.

We use TI ADC IC - ADS8684 16-Bit 500-kSPS (125kSPS per channel) interfaced via SPI/SSI communication.

For testing purpose we acquire the data in a while loop continuously for 5 seconds and break the loop. We use dynamic memory allocation to realloc an array for every iteration to store the acquired data as shown in the code below.

time_t start, end; 
double *arr; int n=1;   
arr=(double*)malloc(n*sizeof(double)); 
start=time(NULL);   //get the present time stamp as start time 
end=start+5;        //to acquire data for 5 sec 
while(start<=end) 
{       
  for(int i=0;i<4;i++)     //to take data from 4 ch of adc  
  {
   libsoc_gpio_set_level(cs, LOW);  // For acquiring data from the IC
   libsoc_spi_read(spi_dev,rdata,4);    // For acquiring data from the IC
   libsoc_gpio_set_level(cs, HIGH);     // For acquiring data from the IC

   arr[n-1]=(10.24/65536)*((rdata[2]<<8) | rdata[3]);
   n=n+1;       // Once a data is acquired increment the size of the array
   arr=(double*)realloc(arr,n*sizeof(double));  // Re-Allocate the array for the new size   
  }     
  start=time(NULL);  }

// Once the data acquision is over we print the size of the array and the elements.

printf("The size of arr for 5 sec is %d\n",n);

for(int i=0;i<n;i++) 
{   
  printf("arr[%d] is  %f\n",i,arr[i]); 
}

The problem we are facing is that the loop iterations are not running at constant speed. So the number of elements in the array varies drastically like 8000,15000,11000,6000 etc. Since all the statements inside the loop execute at constant speed and there is no delay between iterations, the only possible reason could be change in loop time for each iteration.

Is there any way to run the DAQ while loop at constant speed? i.e The time interval between each iterations should be same.

Thank You for your time.

Answer 1

While the statements might operate at a constant number of clock cycles for each loop, there is no guarantee that they will have a constant clock time for execution.

There are any number of other things which the kernel must address, using clock cycles which your loop will not have available. Updating the system clock, checking for other processes to run, including possible cron jobs, and countless other housekeeping tasks. Such things are probably beyond your control and thus the cycles available to your code is unpredictable, and how many samples are collected will be constantly in flux.

The only solution I can propose is to evaluate what the truly important parameters are, and determine how to control them, as best as possible, while accepting the variability of all others.

Answer 2

A principal failing in your code is the use of time(). This returns a value in seconds, so your loop might last from 4 to 5 seconds. Instead you should use gettimeofday() which provides a microseconds field (though the resolution might be worse than that).

You might also reduce variability by making your process a real-time process. Use chrt -f to run your command, or call sched_setscheduler() with SCHED_FIFO.