Tengo un acelerómetro analógico que quiero muestrear a 100 HZ, también quiero trazar los datos con el tiempo de cada muestra para tener aceleración con el tiempo. Para llevar la cuenta del tiempo, iba a usar millis(). Para muestrear a 100 HZ puedo usar un temporizador, pero AnalogRead() tiene una sobrecarga y me preguntaba cómo muestrear a 100 HZ corrigiendo la sobrecarga de AnalogRead().
También el envío de datos en serie tiene una sobrecarga, no estoy seguro de cómo compensar esto, quiero obtener una aceleración en el tiempo que sea al menos algo precisa si es posible. No tengo el dinero en este momento para un chip RTC
Puede enviar transmitir aproximadamente 11 bytes por milisegundo a 115200 baudios. Entonces, siempre que restrinja su salida a 10 caracteres y una nueva línea por muestra, debería estar bien.
La matemática detrás de eso es 115200 baudios significa 115200 tiempos de bit/segundo, y hay 10 tiempos de bit por byte transmitido en el UART (bit de inicio, 8 bits de datos y bit de parada). Entonces 115200/10 = 11520 bytes/segundo = 11.520 bytes/milisegundo (y redondeo hacia abajo).
En resumen, el muestreo de 100 Hz debería ser fácil.
El enfoque canónico de la temporización de intervalos se demuestra en el ejemplo de BlinkWithoutDelay Arduino. Consolidado se ve así:
long previousMillis = 0;
long interval = 10; // interval in milliseconds (10ms => 100Hz)
void setup() {
// whatever
Serial.begin(115200);
Serial.println("Hello World");
}
void loop(){
unsigned long currentMillis = millis();
if(currentMillis - previousMillis > interval) {
previousMillis = currentMillis;
// do your task
Serial.println(analogRead(0));
}
}
from Arduino: millis() - Devuelve el número de milisegundos desde que la placa Arduino comenzó a ejecutar el programa actual. Este número se desbordará (volverá a cero), después de aproximadamente 50 días.
es una representación convertida del contador del programa, que continúa ejecutándose, independientemente. No debe confundirse con delay() y delayMicroseconds(), que son básicamente nop calculados por separado. Usarlos entre muestras tendría retrasos y sesgos crecientes.
entonces usando
if ((millis() - lastTime) > _Delay) {
lastTime = millis();
blah...
}
no se desviaría. Del mismo modo, existe la biblioteca http://playground.arduino.cc/Code/SimpleTimer que hará lo mismo. pero en un formato de biblioteca y servicio más típico, que yo uso.
Donde ambos tendrán algo de fluctuación, no sesgada, de otras interrupciones y otras cosas que suceden. Dicho esto, usar la interrupción Timer1 para generar los 100 Hz debería reducir la fluctuación lo mejor posible. Como ejemplo http://www.pjrc.com/teensy/td_libs_TimerOne.html
El tiempo de lectura analógica es del orden de decenas de microsegundos con la mayoría de las configuraciones de selección de reloj, nada de qué preocuparse. La serie es similar a lo que dijo vicatu: 11 bytes en un milisegundo. Tiene diez milisegundos para hacer todo su trabajo y los retrasos no deberían sumar más de un milisegundo, no debería ser un problema. Simplemente implemente la verificación de tiempo como lo mostró en su publicación y debería estar bien.
pjc50