Int storage time

Hello, I would like to ask of anyone is familiar with the procedure carried out by the arduino when saving an int, as I need to calculate (to compare with measurements) how long this takes. As an example, the analogread procedure should take the processor speed, divide by 128 from a prescaler and divide by 13 cycles, coming out at around 9.6khz.

While running some tests on analogread and storing the values into variables, I reached a value of 107mS with a really high certainty, coming out at 8.9kHz, and I want to know if the frequency difference comes from having stored the values or not.

Is anyone familiar with the int storage procedure? Is this more appropriate on a different section of the forums?

ed_p:
I reached a value of 107mS with a really high certainty, coming out at 8.9kHz

I have a really high certainty that there is a few orders of magnitude difference between those two values. I suggest you recheck your math before venturing any further down that rabbit hole.

Storing an integer to a (micro)SD memory ? Or to EEPROM ? Or just into a variable in sram ?
You can ignore the time that it takes to store an integer in ram, because that is very fast and the compiler might decide to not store it at all, and keep it in a register.

The ATmega328P is optimized for a high sample rate, but the Arduino functions don't use that. With a timer, an interrupts, and a analog input, it is possible to have a higher sampling rate.
The problem with high sample rates is that all that data has to go somewhere.

Are you trying to make some kind of oscilloscope ? That has been done by many others.

Im trying to have a high accuracy in the sampling time value for using Z transform to design digital filters. Im using standard arduino operations, e.g. int value = analogread, and others like that. My measurement also matches up with the stickied benchmark value, 112mS, so there is something going on taking up clock cycles consistently. If not the analogread or int storage, what could it be?

Something else in your code.

If you need a fixed sampling rate, you need to use a timer and a interrupt.

Arduino can use timing with the millis() function. The millis() function can be used if you, for example, want a sample rate of 10 Hz.

Do you want to do calculations as well ? The ATmega328P (the microcontroller in the Arduino Uno) can not do any DSP.

The dsp part will be done in matlab, z transforms can be made into simple recursive filters that only require multiplying so that is no problem. As it turns out, something takes up one clock cycle. With default parameters (10 bit conversion in the adc, 128 prescalar) it comes out to 16mhz/(13128 +1128) = 8929 hz, as tested. I'll try in a bit if the cycle is from the storage of ints or something else. The code has nothing more than a for cycle that stores the analogread value into an int, and shows the time difference over 960 cycles to reduce the time lag of the micros function over 960. It only has 6 lines so it is easy to figure out where the cycle is taken up. Still, this matches the stickied benchmark so I doubt it is an error of mine at this point.

Also, when I wrote "really high certainty," I meant a=0.01 with allowed error of 1 microsecond tested with a z score of 99% certainty to determine the mean, and again, it agrees with the benchmark sticky. The reason I asked about int storage is to find out where that frequency difference is coming from, because the sticky also has this same frequency difference. Thanks!

As it turns out, it is one extra cycle, but not from int storage or anything of the sort: as you guys said, the int storage time is negligible even when performing the operation thousands of times in a row. The issue is detecting the state of the ADSC bit when using single conversion mode, which the Arduino uses by default. This means it takes at least one more cycle (16MHz/128)^-1 to detect ADSC = 1 and commence the new conversion. Thanks for everyone's input.