Solución:
El bucle se ejecuta tanto tiempo como sea necesario.
Las instrucciones en una CPU se ejecutan secuencialmente. Cuantas más instrucciones haya, más tiempo tardará en ejecutarse.
Cuanto más código ponga en el bucle, se ejecutará el bucle más largo.
Hay dos formas de saber cuánto tiempo tomará cada iteración del ciclo:
- Creación de perfiles: cronometra activamente cada iteración del bucle, aunque tenga en cuenta que el acto de cronometraje afectará la cantidad de tiempo que se tarda.
- Inventario cíclico. Compile la fuente en ensamblador y totalice el número de ciclos de reloj necesarios para todas las instrucciones (incluidas las llamadas a funciones). Arduo para bucles pequeños, una tarea gigantesca para cualquier otra cosa.
También tenga en cuenta que muchos factores externos pueden afectar el tiempo que tarda en ejecutarse el bucle (), como la velocidad de comunicación en serie, etc.
las instrucciones entre el final de loop () y la siguiente ejecución son un ret, jmp y una llamada.
Puede considerar que la función principal es eficaz:
void main(){
init();
while(1) loop();
}
Aunque en realidad se ha realizado alguna configuración antes init() para hacer millis() y tal trabajo.
Un vistazo a main.cpp (para el código avr en mi instalación) en el archivo:
C:Program Files (x86)Arduinohardwarearduinoavrcoresarduinomain.cpp
muestra que Arduino ejecuta loop () alternativamente con serialEventRun () en un bucle infinito:
int main(void)
{
init();
initVariant();
#if defined(USBCON)
USBDevice.attach();
#endif
setup();
for (;;) {
loop();
if (serialEventRun) serialEventRun();
}
return 0;
}
La inspección de HardwareSerial.cpp muestra que serialEventRun () simplemente llama a serialEvent (), si lo ha definido en su boceto.
Esto significa que puede escribir su propio bucle infinito dentro de bucle () con total seguridad, a menos que haya escrito el código serialEvent () y esté esperando que se ejecute con regularidad.
Esto plantea la pregunta: si serialEvent () se llama secuencialmente con loop (), ¿se llamará serialEvent () si loop () nunca regresa? En otras palabras, ¿serialEvent () es controlado por interrupciones además de ser llamado cuando loop () regresa? Una prueba rápida -ver abajo- muestra que es no impulsado por interrupciones, por lo que el párrafo anterior es verdadero.
/*
Serial Event Checker
A sketch to see if serialEvent() is interrupt-driven.
Will serialEvent() be called if loop() never returns?
This code is based on Tom Igoe's SerialEvent example.
On (at least) Arduino Uno we find that serialEvent() simply runs
sequentially with loop(). When loop() never returns serialEvent()
is never called.
NOTE: The serialEvent() feature is not available on the Leonardo, Micro, or
other ATmega32U4 based boards.
R Symonds-Tayler 2018-02-01
This example code is in the public domain.
*/
String inputString = ""; // a String to hold incoming data
void setup() {
// initialize serial:
Serial.begin(115200);
// reserve 200 bytes for the inputString:
inputString.reserve(200);
}
// comment out this definition to allow loop() to return
#define INFINITE_LOOP
void loop() {
#ifdef INFINITE_LOOP
while(1);
#endif
}
/*
SerialEvent occurs whenever a new data comes in the hardware serial RX. This
routine is run between each time loop() runs, so using delay inside loop can
delay response. Multiple bytes of data may be available.
*/
void serialEvent() {
while (Serial.available()) {
// get the new byte:
char inChar = (char)Serial.read();
// add it to the inputString:
inputString += inChar;
// if the incoming character is a newline, set a flag so the main loop can
// do something about it:
if (inChar == 'n') {
Serial.print("Got: '");
Serial.print(inputString);
Serial.println("'");
// clear the string:
inputString = "";
}
}
}
Esto significa que el código serialEvent () también podría entrar en su bucle principal () dentro de un:
if(serial.available()){
// your code here...
}
cuadra.