Ардуїно час зберігання за допомогою millis () не є точним чи правильним?

Я використовую Arduino для запису деяких даних. У моєму ескізі Arduino я також використовував millis()функцію, щоб я міг відслідковувати час, за який приймається кожне значення, яке я вимірюю. Однак я помітив, що терміни невірні. Наприклад, 30 секунд у реальному житті виходить лише за 10 секунд (складений приклад).

Чи правильно я кажу, що функція затримки Arduino впливає на тривалість використання часу millis()? Іншими словами, припустимо, у мене затримка 50мс, це означає, що millis()функція також зупиняється на цю тривалість, а потім продовжується і так далі протягом тривалості з'єднання? Я помітив це, коли спробував побудувати деякі дані та виявив, що частота піків у моїх даних була занадто частою, враховуючи час, який минув. Тож я хочу знати, чи це міркування для цієї невідповідності термінів, і якщо так, то як я це виправити, щоб я міг тримати час виникнення кожного зразка?

Щоб дати деякий контекст, ось мій ескіз:

#include <eHealth.h>    

unsigned long time;
// The setup routine runs once when you press reset:
void setup() {
  Serial.begin(9600);  
}

// The loop routine runs over and over again forever:
void loop() {

  float ECG = eHealth.getECG();
  time = millis();
  Serial.print(time);
  Serial.print(" ");
  Serial.print(ECG, 5); 
  Serial.println("");    

  delay(50);
}

millis()приводиться в дію переривання, тому delay()це не вплине, принаймні, не на базі ATmega.

Це не означає, що millis()це абсолютно точно. Кожна галочка таймера не дорівнює 1 мс, але становить 1,024 мс. Ця помилка поступово накопичується, поки не буде здійснено виправлення. Це можна побачити в реалізації обробника переривань TIMER0_OVF (переповнення таймера 0).

Іншим джерелом неточності є сам генератор / кристал, який не є точно 16 МГц. Це досить близько, і поки температура не змінюється занадто сильно, є відносно стабільною.

Вищезазначене означає, що у вас може бути близько 1 мс при використанні millis(). Це не схоже на вашу проблему.

Іншим потенційним питанням може бути те, що getECG()робиться - це може бути дуже повільним.

float eHealthClass::getECG(void)
    {
        float analog0;
        // Read from analogic in. 
        analog0=analogRead(0);
        // binary to voltage conversion
        return analog0 = (float)analog0 * 5 / 1023.0;   
    }

analogRead() повільно, але не так повільно, щоб впливати на цикл, як цей.

Ще одна проблема, яку я бачив у людей - це коли вони змінюють тактову частоту, але неправильно змінюють дошки.txt. Це означає, що константи, які використовуються в millis()реалізації, помиляються, а часи - неправильні.

Якщо ви дійсно хочете читати значення кожні 50 мс, набагато кращим способом реалізації цього є виконання наступного

static long lastUpdate;

if (millis() - lastUpdate > 50)
{
    lastUpdate = millis();
    //Do stuff
}

Нам дійсно потрібно було б побачити часові позначки, які ви отримуєте. Якщо ви насправді бачите 30-ті, які відображаються як 10-ті, значить, є щось інше на роботі.

Якщо переривання буде вимкнено протягом будь-якої значної eHealth.getECG()тривалості виклику дробу , millis()кількість рахунків може відстати. В іншому випадку millis()слід повернути набагато точніший час, ніж описані вами 3х помилки.

Ви сказали, що ваш вибірковий сигнал виявляється вищим за частотою, ніж очікували, що може статися, якщо частота вибірки буде нижчою, ніж ви планували. Ви припускаєте частоту вибірки 20 Гц? Ваш цикл може зайняти досить тривалість, ніж 50 мс, що ви побачите в друковані часи, але вони все одно повинні відстежувати годинний час. Якщо ви цього не врахували, але припускали 50 мс / зразок, ви побачите очевидне прискорення даних.

Якщо це не проблема, наступним кроком буде перемикання виводу під час вашого перебування loop()та вимірювання частоти результуючої квадратної хвилі за допомогою вимірювача частоти (деякі недорогі DVM можуть це зробити) або «сфери застосування». Те ж саме зробіть із порожнім loop(). Перший експеримент визначатиме вашу реальну швидкість або інтервал вибірки; другий підкаже, чи millis()(тобто, частота timer0) - це те, що ви очікували.

Те ж саме. Можу додати, що якщо перерви вимкнено, вимірюваний час - це "реальний час". У будь-якому випадку, я не розумію, чому ця затримка, тому що якщо цикл триватиме занадто довго, все-таки millis () повинен повертати значення в реальному часі (тільки з більшою відстані між кожним значенням)