¿Cómo puedo probar el código Arduino?


187

Me gustaría poder probar la unidad de mi código Arduino. Idealmente, podría ejecutar cualquier prueba sin tener que cargar el código en el Arduino. ¿Qué herramientas o bibliotecas me pueden ayudar con esto?

Hay un emulador Arduino en desarrollo que podría ser útil, pero aún no parece estar listo para usar.

AVR Studio de Atmel contiene un simulador de chips que podría ser útil, pero no puedo ver cómo lo usaría junto con el IDE de Arduino.


Hay otro hilo sobre esta pregunta de 2011 en arduino.cc/forum/index.php?action=printpage;topic=54356.0
Jakob

Gracias @Jakob. Un simulador de Arduino al que se hace referencia en ese hilo (con otros enlaces potencialmente útiles en la parte inferior de la página): arduino.com.au/Simulator-for-Arduino.html
Matthew Murdoch

55
Desafortunadamente es solo para Windows, me gustaría ver una manera de simplemente compilar y ejecutar código Arduino desde la línea de comandos sin ninguna fuente cerrada o dependencias de hardware.
Jakob

3
Una pequeña actualización, 5 años después: Simavr todavía está muy activo y ha mejorado mucho desde que se hizo la pregunta, por lo que pensé que merecía ser empujado más cerca de la cima. Y podría ser la herramienta adecuada para pruebas de regresión, pruebas basadas en escenarios y por qué no también pruebas unitarias. De esa forma, el código que prueba es el mismo que el del hardware de destino.
zmo

Para proyectos importantes, considere un probador de hardware; otra MCU que puede cronometrar y probar reacciones de botón / interruptor, tiempo de arranque, temperatura, uso de v / ma, permutaciones de opciones extrañas, etc. Sí, es más hardware para construir, pero puede agregar una capa de seguridad en la realización de revisiones. muchos dispositivos profesionales usan jtag et al.
dandavis

Respuestas:


137

No ejecute pruebas unitarias en el dispositivo o emulador Arduino

El caso contra el microcontrolador Dispositivo / Emulador / Pruebas basadas en Sim

Se discute mucho sobre lo que significa la prueba unitaria y realmente no estoy tratando de discutir aquí. Esta publicación no le dice que evite todas las pruebas prácticas en su hardware objetivo final. Estoy tratando de hacer un punto sobre la optimización de su ciclo de retroalimentación de desarrollo eliminando su hardware objetivo de sus pruebas más mundanas y frecuentes. Se supone que las unidades bajo prueba son mucho más pequeñas que todo el proyecto.

El propósito de las pruebas unitarias es probar la calidad de su propio código. Las pruebas unitarias generalmente nunca deben probar la funcionalidad de factores fuera de su control.

Piénselo de esta manera: incluso si tuviera que probar la funcionalidad de la biblioteca Arduino, el hardware del microcontrolador o un emulador, es absolutamente imposible que dichos resultados de prueba le digan algo sobre la calidad de su propio trabajo. Por lo tanto, es mucho más valioso y eficiente escribir pruebas unitarias que no se ejecutan en el dispositivo (o emulador) de destino.

Las pruebas frecuentes en el hardware de destino tienen un ciclo extremadamente lento:

  1. Ajusta tu código
  2. Compila y carga en el dispositivo Arduino
  3. Observa el comportamiento y adivina si tu código está haciendo lo que esperas
  4. Repetir

El paso 3 es particularmente desagradable si espera recibir mensajes de diagnóstico a través del puerto serie, pero su proyecto en sí necesita usar el único puerto serie de hardware de su Arduino. Si estaba pensando que la biblioteca SoftwareSerial podría ayudar, debe saber que al hacerlo es probable que interrumpa cualquier funcionalidad que requiera una sincronización precisa como generar otras señales al mismo tiempo. Este problema me ha pasado.

Una vez más, si tuviera que probar su boceto utilizando un emulador y sus rutinas de tiempo crítico funcionaran perfectamente hasta que lo cargó en el Arduino real, entonces la única lección que aprenderá es que el emulador tiene fallas, y saber esto todavía no revela nada sobre la calidad de su propio trabajo.

Si es una tontería probar en el dispositivo o emulador, ¿ qué debo hacer?

Probablemente estés usando una computadora para trabajar en tu proyecto Arduino. Esa computadora es un orden de magnitud más rápida que el microcontrolador. Escriba las pruebas para construir y ejecutar en su computadora .

Recuerde, se debe suponer que el comportamiento de la biblioteca y el microcontrolador Arduino es correcto o, al menos, consistentemente incorrecto .

Cuando sus pruebas producen resultados contrarios a sus expectativas, es probable que tenga un error en el código que se probó. Si el resultado de su prueba coincide con sus expectativas, pero el programa no se comporta correctamente cuando lo carga en Arduino, entonces sabe que sus pruebas se basaron en suposiciones incorrectas y es probable que tenga una prueba defectuosa. En cualquier caso, se le proporcionará información real sobre cuáles deberían ser sus próximos cambios de código. La calidad de sus comentarios ha mejorado de " algo está roto" a "este código específico está roto" .

Cómo construir y ejecutar pruebas en tu PC

Lo primero que debe hacer es identificar sus objetivos de prueba . Piense en qué partes de su propio código desea probar y luego asegúrese de construir su programa de tal manera que pueda aislar partes discretas para la prueba.

Si las partes que desea probar requieren funciones de Arduino, deberá proporcionar reemplazos de maquetas en su programa de prueba. Esto es mucho menos trabajo de lo que parece. Sus maquetas no tienen que hacer nada más que proporcionar entradas y salidas predecibles para sus pruebas.

Cualquiera de sus propios códigos que tiene la intención de probar debe existir en archivos de origen que no sean el bosquejo .pde. No se preocupe, su boceto aún se compilará incluso con algún código fuente fuera del boceto. Cuando realmente te pones a ello, poco más que el punto de entrada normal de tu programa debe definirse en el archivo de boceto.

¡Todo lo que queda es escribir las pruebas reales y luego compilarlas usando su compilador C ++ favorito! Esto probablemente se ilustra mejor con un ejemplo del mundo real.

Un ejemplo de trabajo real

Uno de mis proyectos favoritos que se encuentran aquí tiene algunas pruebas simples que se ejecutan en la PC. Para el envío de esta respuesta, voy a repasar cómo simulé algunas de las funciones de la biblioteca Arduino y las pruebas que escribí para probar esas simulaciones. Esto no es contrario a lo que dije antes acerca de no probar el código de otras personas porque yo fui quien escribió las maquetas. Quería estar muy seguro de que mis maquetas eran correctas.

Fuente de mock_arduino.cpp, que contiene código que duplica algunas funciones de soporte proporcionadas por la biblioteca Arduino:

#include <sys/timeb.h>
#include "mock_arduino.h"

timeb t_start;
unsigned long millis() {
  timeb t_now;
  ftime(&t_now);
  return (t_now.time  - t_start.time) * 1000 + (t_now.millitm - t_start.millitm);
}

void delay( unsigned long ms ) {
  unsigned long start = millis();
  while(millis() - start < ms){}
}

void initialize_mock_arduino() {
  ftime(&t_start);
}

Utilizo la siguiente maqueta para producir una salida legible cuando mi código escribe datos binarios en el dispositivo serial de hardware.

fake_serial.h

#include <iostream>

class FakeSerial {
public:
  void begin(unsigned long);
  void end();
  size_t write(const unsigned char*, size_t);
};

extern FakeSerial Serial;

fake_serial.cpp

#include <cstring>
#include <iostream>
#include <iomanip>

#include "fake_serial.h"

void FakeSerial::begin(unsigned long speed) {
  return;
}

void FakeSerial::end() {
  return;
}

size_t FakeSerial::write( const unsigned char buf[], size_t size ) {
  using namespace std;
  ios_base::fmtflags oldFlags = cout.flags();
  streamsize oldPrec = cout.precision();
  char oldFill = cout.fill();

  cout << "Serial::write: ";
  cout << internal << setfill('0');

  for( unsigned int i = 0; i < size; i++ ){
    cout << setw(2) << hex << (unsigned int)buf[i] << " ";
  }
  cout << endl;

  cout.flags(oldFlags);
  cout.precision(oldPrec);
  cout.fill(oldFill);

  return size;
}

FakeSerial Serial;

y finalmente, el programa de prueba real:

#include "mock_arduino.h"

using namespace std;

void millis_test() {
  unsigned long start = millis();
  cout << "millis() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    sleep(1);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void delay_test() {
  unsigned long start = millis();
  cout << "delay() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    delay(250);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void run_tests() {
  millis_test();
  delay_test();
}

int main(int argc, char **argv){
  initialize_mock_arduino();
  run_tests();
}

Esta publicación es lo suficientemente larga, así que consulte mi proyecto en GitHub para ver más casos de prueba en acción. Mantengo mis trabajos en curso en ramas distintas a la maestra, así que verifique esas ramas para pruebas adicionales también.

Elegí escribir mis propias rutinas de prueba livianas, pero también hay disponibles marcos de prueba de unidad más robustos como CppUnit.


1
¡Esta es una respuesta genial! ¡Gracias!
Jonathan Arkell

55
@WarrenMacEvoy Nuevamente, creo que tomaste mi consejo y lo convertiste en algo que no es. Sin duda, debe probar su código en su entorno real EN ALGÚN PUNTO Mi argumento es que no deberías hacer eso todos los días y ciertamente no deberías llamarlo una prueba unitaria.
Iron Savior

1
@toasted_flakes No estoy seguro de dónde obtuviste esa cita, pero no es algo que haya dicho. Las pruebas unitarias que se ejecutan en el dispositivo tienen muchos problemas: bucle de retroalimentación muy lento, es posible que no tenga puertos serie o cualquier otro medio de E / S de sobra en su dispositivo de destino, y tienen una capacidad muy limitada que puede afectar el alcance de Su conjunto de pruebas.
Iron Savior

1
@ChristianHujer Sin duda, debe probar en hardware real, nadie dice que nunca debe probar en hardware de destino. Mi publicación trata sobre cómo ajustar su ciclo diario de retroalimentación de desarrollo mediante pruebas unitarias en su máquina de desarrollo. Su sobrecarga de prueba se minimiza de esta manera porque solo probará en su hardware de destino cuando sea necesario.
Iron Savior

1
Los archivos fuente de bocetos de @Benjohn Arduino solían tener la extensión "pde" aunque son C ++. arduino.cc/en/Guide/Environment#toc1
Iron Savior

63

En ausencia de marcos de prueba de unidad preexistentes para Arduino, he creado ArduinoUnit . Aquí hay un simple boceto de Arduino que demuestra su uso:

#include <ArduinoUnit.h>

// Create test suite
TestSuite suite;

void setup() {
    Serial.begin(9600);    
}

// Create a test called 'addition' in the test suite
test(addition) {
    assertEquals(3, 1 + 2);
}

void loop() {
    // Run test suite, printing results to the serial port
    suite.run();
}

18
Las pruebas parecen ejecutarse solo en el arduino, por lo que no puede ejecutarlas automáticamente en su máquina de desarrollo. La idea básica de las pruebas unitarias es ejecutarlas automáticamente, por lo que el diseño actual parece ser más una herramienta de depuración, pero no un marco de prueba de unidad real.
Jakob

1
Tienes razón. Para poder ejecutarlos en una PC, además, se requeriría un emulador Arduino o AVR. No hay una capa de abstracción de hardware real en las bibliotecas Arduino (por el momento) y los emuladores AVR cuando miraba todavía estaban en desarrollo. Si las cosas han avanzado ahora, entonces, en principio, esto podría hacerse.
Matthew Murdoch el

12
@MatthewMurdoch Me temo que eres incorrecto. Por definición, las pruebas unitarias nunca se ejecutan en el entorno de destino. De hecho, la idea detrás de las pruebas unitarias es eliminar completamente el entorno objetivo de las pruebas. Siempre se ejecutan en un entorno similar a un laboratorio que se burla de toda la actividad externa a la unidad que se está probando para garantizar que el éxito o el fracaso de la prueba SÓLO se refleje en la unidad bajo prueba. Esa es una de las principales razones por las que las personas usan el concepto de Inversión de control en proyectos complejos.
Iron Savior

2
@ marcv81 Es muy probable que las áreas donde existen tales problemas de portabilidad sean sujetos pobres para las pruebas unitarias. Recuerde que las pruebas unitarias solo deberían probar SU código, así que limite su alcance en consecuencia. Con la gran disparidad en hardware de la que estamos hablando aquí, puedo aceptar que algunas de esas circunstancias pueden ser inevitables. En esos casos, un ingeniero debe ser consciente y tomar medidas atenuantes. Esto podría significar alterar su diseño para mejorar la capacidad de prueba o incluso algo tan simple como simplemente documentar los hechos relevantes.
Iron Savior el

2
@Iron Savior, una prueba unitaria prueba su código, pero su código se ejecuta en algún lugar. Si ese contexto es o emula un contexto Arduino; entonces ArdunoUnit te ayudará a escribir pruebas unitarias. Si observa el proyecto ArduinoUnit, la metaprueba del marco carga, ejecuta y verifica automáticamente los resultados de la prueba en el objetivo multiplataforma. Al igual que lo haría en otros objetivos multiplataforma. Su punto de vista es una excusa para no probar el código en un entorno incrustado donde la corrección es tan importante, si no más, que otros contextos.
Warren MacEvoy

21

Tengo una unidad de éxito considerable probando mi código PIC abstrayendo el acceso al hardware y burlándolo en mis pruebas.

Por ejemplo, abstraigo PORTA con

#define SetPortA(v) {PORTA = v;}

Luego, se puede burlar fácilmente de SetPortA, sin agregar un código general en la versión PIC.

Una vez que la abstracción de hardware ha sido probada por un tiempo, pronto descubro que generalmente el código va desde la plataforma de prueba al PIC y funciona por primera vez.

Actualizar:

Utilizo una #include costura para el código de la unidad, #incluyendo el código de la unidad en un archivo C ++ para el equipo de prueba, y un archivo C para el código de destino.

Como ejemplo, quiero multiplexar cuatro pantallas de 7 segmentos, un puerto manejando los segmentos y un segundo seleccionando la pantalla. El código de pantalla interactúa con las pantallas a través de SetSegmentData(char)y SetDisplay(char). Puedo burlarme de estos en mi plataforma de prueba C ++ y verificar que obtengo los datos que espero. Para el objetivo que uso #definepara obtener una asignación directa sin la sobrecarga de una llamada de función

#define SetSegmentData(x) {PORTA = x;}

En principio, puedo ver cómo puedo usar la 'costura' del preprocesador para las pruebas unitarias. Sin embargo, no estoy seguro de cómo puedo hacer esto sin tener un emulador en el que ejecutar las pruebas o un compilador compatible con avr-gcc que genera (en mi caso) binarios de Windows ...
Matthew Murdoch

Gracias por la actualización. ¿Ejecutas las pruebas unitarias en el PIC o en tu PC?
Matthew Murdoch el

Las pruebas unitarias se ejecutan en una Mac usando Xcode. Para ejecutarlos en el Pic probablemente necesitaría un emulador de algún tipo. Abstrayéndolo lo que se ejecuta en el Mac hace que los procesadores de conmutación una gran cantidad easieer
David Sykes

El entorno Arduino usa el compilador avr-gcc que tiene algunas idiosincrasias, lo que significa que compilar con gcc (u otro compilador de C ++) y ejecutarlo en una PC puede no significar que el código también se compilará en avr-gcc.
Matthew Murdoch

¿De qué tipo de diferencia estás hablando? ¿Son cosas que no se pueden manejar con algunas directivas de preprocesador?
Joseph Lisee


12

simavr es un simulador AVR que usa avr-gcc.

Ya es compatible con algunos microcontroladores ATTiny y ATMega y, según el autor, es fácil agregar algunos más.

En los ejemplos se encuentra simduino, un emulador Arduino. Admite ejecutar el gestor de arranque Arduino y puede programarse con avrdude a través de Socat (un Netcat modificado ).


9

Puede realizar pruebas unitarias en Python con mi proyecto, PySimAVR . Arscons se usa para construir y simavr para simulación.

Ejemplo:

from pysimavr.sim import ArduinoSim    
def test_atmega88():
    mcu = 'atmega88'
    snippet = 'Serial.print("hello");'

    output = ArduinoSim(snippet=snippet, mcu=mcu, timespan=0.01).get_serial()
    assert output == 'hello'

Iniciar prueba:

$ nosetests pysimavr/examples/test_example.py
pysimavr.examples.test_example.test_atmega88 ... ok

6

No conozco ninguna plataforma que pueda probar el código Arduino.

Sin embargo, existe la plataforma Fritzing , que puede usar para modelar el hardware y luego exportar diagramas y cosas de PCB.

Vale la pena revisarlo.


6

Estamos utilizando placas Arduino para la adquisición de datos en un gran experimento científico. Posteriormente, tenemos que soportar varias placas Arduino con diferentes implementaciones. Escribí utilidades de Python para cargar dinámicamente imágenes hexadecimales de Arduino durante las pruebas unitarias. El código que se encuentra en el siguiente enlace es compatible con Windows y Mac OS X a través de un archivo de configuración. Para averiguar dónde se colocan sus imágenes hexadecimales con el IDE de Arduino, presione la tecla Mayús antes de presionar el botón construir (reproducir). Presione la tecla Mayús mientras presiona cargar para averiguar dónde se encuentra su avrdude (utilidad de carga de línea de comandos) en su sistema / versión de Arduino. Alternativamente, puede mirar los archivos de configuración incluidos y usar su ubicación de instalación (actualmente en Arduino 0020).

http://github.com/toddstavish/Python-Arduino-Unit-Testing


+1 ¡Grandes cosas! ¿Tiene alguna información sobre cómo realizó la prueba de su unidad una vez que se cargaron las imágenes?
Matthew Murdoch

Usamos pruebas nasales para ejecutar nuestras pruebas unitarias en el lado de Python. La configuración de cada prueba carga la imagen hexadecimal correcta para esa prueba. Comenzamos poco a poco y luego trabajamos en pruebas más completas. Asegúrese de que la comunicación en serie esté funcionando, asegúrese de que la integración en serie a la IU esté funcionando, verifique la integración en serie a la base de datos, etc. El pde y py analog_read_speed muestran los conceptos básicos de esto (vea el enlace de github arriba). Eventualmente, abriremos el código fuente de todo el proyecto, así que por favor estén atentos. :)
toddstavish

6

Este programa permite la ejecución automatizada de varias pruebas unitarias Arduino. El proceso de prueba se inicia en la PC, pero las pruebas se ejecutan en el hardware Arduino real. Un conjunto de pruebas unitarias se usa generalmente para probar una biblioteca Arduino. (esta

Foro Arduino: http://arduino.cc/forum/index.php?topic=140027.0

Página del proyecto GitHub: http://jeroendoggen.github.com/Arduino-TestSuite

Página en el índice del paquete Python: http://pypi.python.org/pypi/arduino_testsuite

Las pruebas unitarias se escriben con la "Biblioteca de pruebas de la unidad Arduino": http://code.google.com/p/arduinounit

Los siguientes pasos se realizan para cada conjunto de pruebas unitarias:

  • Lea el archivo de configuración para averiguar qué pruebas ejecutar
  • El script compila y carga un boceto de Arduino que contiene el código de prueba de la unidad.
  • Las pruebas unitarias se ejecutan en la placa Arduino.
  • Los resultados de la prueba se imprimen en el puerto serie y se analizan mediante el script Python.
  • El script inicia la siguiente prueba, repitiendo los pasos anteriores para todas las pruebas que se solicitan en el archivo de configuración.
  • El script imprime un resumen que muestra una descripción general de todas las pruebas fallidas / aprobadas en el conjunto de pruebas completo.

5

Mantenga el código específico del hardware separado o abstraído del resto para que pueda probar y depurar ese "descanso" más grande en cualquier plataforma para la que tenga buenas herramientas y con la que esté más familiarizado.

Básicamente, intente construir la mayor cantidad de código final a partir de tantos bloques de construcción conocidos como sea posible. El trabajo restante de hardware específico será mucho más fácil y rápido. Puede terminarlo utilizando emuladores existentes y / o dispositivos de emulación por su cuenta. Y luego, por supuesto, necesitarás probar la cosa real de alguna manera. Dependiendo de las circunstancias, eso puede o no ser muy bien automatizable (es decir, ¿quién o qué presionará los botones y proporcionará otras entradas? ¿Quién o qué observará e interpretará varios indicadores y salidas?).



5

Estoy usando Searduino cuando escribo el código Arduino. Searduino es un simulador Arduino y un entorno de desarrollo (Makefiles, código C ...) que hace que sea fácil piratear C / C ++ usando su editor favorito. Puede importar bocetos de Arduino y ejecutarlos en el simulador.

Captura de pantalla de Searduino 0.8: http://searduino.files.wordpress.com/2014/01/jearduino-0-8.png

Se lanzará Searduino 0.9 y se grabará un video tan pronto como se realicen las últimas pruebas ... en un día o dos.

Las pruebas en el simulador no deben considerarse pruebas reales, pero ciertamente me han ayudado mucho a encontrar errores estúpidos / lógicos (olvidando hacer pinMode(xx, OUTPUT) , etc.).

Por cierto: soy una de las personas que desarrollan Searduino.


5

Construí arduino_cipara este propósito. Aunque se limita a probar las bibliotecas Arduino (y no a los bocetos independientes), permite que las pruebas unitarias se ejecuten localmente o en un sistema CI (como Travis CI o Appveyor).

Considere una biblioteca muy simple en su directorio de Biblioteca Arduino, llamada DoSomething, con do-something.cpp:

#include <Arduino.h>
#include "do-something.h"

int doSomething(void) {
  return 4;
};

Debería probarlo de la siguiente manera (con un archivo de prueba llamado test/is_four.cppo algo así):

#include <ArduinoUnitTests.h>
#include "../do-something.h"

unittest(library_does_something)
{
  assertEqual(4, doSomething());
}

unittest_main()  // this is a macro for main().  just go with it.

Eso es todo. Si esa assertEqualsintaxis y estructura de prueba parece familiar, es porque adopté parte de la biblioteca ArduinoUnit de Matthew Murdoch a la que se refirió en su respuesta .

Consulte Reference.md para obtener más información sobre la prueba de la unidad de pines de E / S, el reloj, puertos serie, etc.

Estas pruebas unitarias se compilan y ejecutan utilizando un script contenido en una gema de rubí. Para ver ejemplos de cómo configurar eso, consulte README.md o simplemente copie de uno de estos ejemplos:


Esto parece interesante, pero no estoy seguro de que esté probando correctamente el código Arduino. A partir del resultado que publicó, está compilando la arquitectura x86_64, que obviamente no se usa para el Arduino. Eso podría introducir errores causados ​​por conflictos entre implementaciones de tipos.
Cerin

Ese tipo de error es ciertamente posible. ¿Tiene un ejemplo que podría usar para un caso de prueba?
Ian

3

Hay un proyecto llamado ncore , que proporciona un núcleo nativo para Arduino. Y le permite escribir pruebas para el código Arduino.

De la descripción del proyecto

El núcleo nativo le permite compilar y ejecutar bocetos de Arduino en la PC, generalmente sin modificaciones. Proporciona versiones nativas de las funciones estándar de Arduino y un intérprete de línea de comandos para dar entradas a su boceto que normalmente vendrían del hardware en sí.

También en la sección "¿Qué necesito para usarlo?"

Si desea construir las pruebas, necesitará cxxtest de http://cxxtest.tigris.org . NCORE ha sido probado con cxxtest 3.10.1.


Este es un proyecto interesante. Desafortunadamente, parece que ahora está muerto, ya que no ha tenido progreso durante 6 años.
Cerin

2

Si desea probar el código de la unidad fuera de MCU (en el escritorio), consulte libcheck: https://libcheck.github.io/check/

Lo usé para probar mi propio código incrustado varias veces. Es un marco bastante robusto.


El único inconveniente es que esto no es compatible con g ++, lo que lo hace inútil para probar la mayoría de las bibliotecas Arduino que usan características de C ++.
Cerin

1

Puede usar emulare : puede arrastrar y soltar un microcontrolador en un diagrama y ejecutar su código en Eclipse. La documentación en el sitio web le dice cómo configurarlo.


1

Use Proteus VSM con una biblioteca Arduino para depurar su código o probarlo.

Es una práctica recomendada antes de tener su código a bordo, pero asegúrese de sincronizarlo porque la simulación no se ejecuta en tiempo real como se ejecuta en el tablero.


1

Prueba el simulador de circuitos de Autodesk . Permite probar el código y los circuitos de Arduino con muchos otros componentes de hardware.


0

En Arduino básico se escribe con C y C ++, incluso las bibliotecas de arduino se escriben en C y C ++. Entonces, en términos simples, simplemente maneje el código como C y C ++ e intente hacer la prueba de la unidad. Aquí, con la palabra "manejar" me refiero a que cambies toda la sintaxis básica como serial.println a sysout, pinmode a varaibles, void loop a while () que se rompe en el teclado o después de alguna iteración.

Sé que este es un proceso poco largo y no tan sencillo. En mi experiencia personal, una vez que lo haces, resulta ser más confiable.

-Nandha_Frost


0

En caso de que esté interesado en ejecutar un boceto INO y verificar la salida en serie, tengo una implementación funcional de eso en mi suma de control NMEA de Arduino proyecto de .

El siguiente script toma el archivo y usa la CLI de Arduino para compilarlo en un archivo HEX que luego se carga en SimAVR que lo evalúa e imprime la salida en serie. Como todos los programas de Arduino se ejecutan para siempre sin tener realmente la opción de suicidarse ( exit(0)no funciona), dejo que el boceto se ejecute durante unos segundos y luego diferencie la salida capturada con la salida esperada.

Descargue y extraiga la CLI de Arduino (en este caso, la versión 0.5.0, la última en el momento de la redacción):

curl -L https://github.com/arduino/arduino-cli/releases/download/0.5.0/arduino-cli_0.5.0_Linux_64bit.tar.gz -o arduino-cli.tar.gz
tar -xvzf arduino-cli.tar.gz

Ahora puede actualizar el índice e instalar el núcleo apropiado:

./arduino-cli core update-index
./arduino-cli core install arduino:avr

Suponiendo que su boceto se llama nmea-checksum.ino, para obtener ELF y HEX, ejecute:

./arduino-cli compile -b arduino:avr:uno nmea-checksum.ino

A continuación, SimAVR para ejecutar HEX (o ELF): construyo desde la fuente porque la última versión no funcionó para mí:

sudo apt-get update
sudo apt-get install -y build-essential libelf-dev avr-libc gcc-avr freeglut3-dev libncurses5-dev pkg-config
git clone https://github.com/buserror/simavr.git
cd simavr
make

Una compilación exitosa le dará lo simavr/run_avrque puede usar para ejecutar el boceto. Como dije, de timeoutlo contrario nunca terminará:

cd simavr
timeout 10 ./run_avr -m atmega168 -f 16000000 ../../nmea-checksum.ino.arduino.avr.uno.elf &> nmea-checksum.ino.clog || true

El archivo generado tendrá caracteres de control de código de color ANSI que envuelven la salida en serie, para deshacerse de ellos:

cat nmea-checksum.ino.clog | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" > nmea-checksum.ino.log
cat nmea-checksum.ino.log

Ahora todo lo que necesita hacer es comparar este archivo con un archivo bueno conocido:

diff nmea-checksum.ino.log ../../nmea-checksum.ino.test

Si no hay diferencias, diffsaldrá con el código 0, de lo contrario, el script fallará.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.