Hi Hamid,
An interrupt is not a called function from the main loop. The interrupt gets called either by an edge or level change at the input of the pin where DRDY is connected. The way this is structured is device and compiler dependent. As far as I can tell you are still polling. It is not possible to predict the precise timing of when an event will take place in a loop. It becomes worse when you have 2 independent processes taking place at the same time (like the microcontroller timing and the ADS1241 conversion process).
You need to determine how you want to do the data retrieval. It appears to me that it really isn't any different than the way you had it previously. You need to determine an acceptable rate of data capture. Let's say you continue with the loop and you can get one set of readings per second. As the data rate is much faster, you can either capture one reading and discard the others, or you can average several readings. You still need to make certain that the data is retrieved before the update period of the next conversion result. It appears that you still have this problem. A true hardware interrupt would resolve this problem.
A true hardware interrupt will retrieve the data as soon as the hardware triggers the interrupt. There is one hardware interrupt, so you need to determine which variable the data result should be stored. You can set a flag variable in the interrupt routine to tell the main loop there is new data available. In the main processing loop you check the flag status, and if new data is available you can print it out.
If we assign the variable to fTest, your polling loop would look something like:
while(1)
{ if(fTest==1){
// add your print stuff here
ftest=0;
}
}
The call to the interrupt service routine might have an additional flag for determining input 1 is retrieved or input 2. If both inputs have been retrieved since the last print, then fTest is set equal to 1.
Hope this gives a better idea what needs to take place.
Best regards,
Bob B