Los programas pueden, a veces, tener errores de tiempo de ejecución. A veces son difíciles de encontrar y se pueden pasar por alto fácilmente. ¿Hay alguna forma de probar el programa antes de quemarlo en el tablero?
Los programas pueden, a veces, tener errores de tiempo de ejecución. A veces son difíciles de encontrar y se pueden pasar por alto fácilmente. ¿Hay alguna forma de probar el programa antes de quemarlo en el tablero?
Respuestas:
Hay algunos proyectos de Arduino Simulator por ahí.
Quizás uno de los más maduros es el Simulador de Virtronics para Arduino , el video de YouTube aquí .
La página de Virtronics vinculada anteriormente también enumera algunos otros simuladores de Arduino, tanto gratuitos como de pago.
Dado el interés que evoca el Arduino, es probable que haya muchos más simuladores de este tipo, por lo que no tiene sentido tratar de enumerarlos a todos en una respuesta aquí.
Lo que vale la pena señalar es que también hay una aplicación para iPhone Arduino Simulator : esto no es una recomendación, aún no la he visto en funcionamiento.
En otros comentarios:
El Arduino es en sí mismo un tablero de prototipos / experimentación. Es ideal para programar código experimental, depurarlo, modificar y luego volver a flashear código nuevo, casi tantas veces como quiera . Si el código se bloquea, reinicie y vuelva a actualizar con cualquier cambio.
Por lo tanto, el mérito de usar un simulador, que nunca puede emular perfectamente los diversos tiempos del mundo real u otros problemas que podría enfrentar una aplicación, es cuestionable.
Si el costo del Arduino es la preocupación, hay un par de opciones abiertas:
Puede encontrar errores de tiempo de ejecución si puede recorrer manualmente su programa con Arduino conectado y depurar ( después de descargar el código en Arduino). Está disponible en Visual Micro, aunque requiere Visual Studio. Puede establecer puntos de interrupción, evaluar variables y cambiar valores de variables. También puede obtener visualización de la memoria con el tiempo:
Una forma de hacerlo sería crear un programa envoltorio para el código real que simule todas las entradas y acepte salidas (creando así un ciclo de retroalimentación) según el entorno real. Esto requeriría una cantidad variable de esfuerzo según el tipo de programa, el grado de prueba y el número de entradas.
Tenga en cuenta que al escribir el programa contenedor, debe seguir un enfoque de recuadro negro .
De lo contrario, es posible que su código externo no pruebe el programa tan bien como sea posible, ya que tener en cuenta el código real al crear el código de prueba puede sesgarlo para que ignore los casos límite o las áreas problemáticas (Esto se ha observado que ocurre mientras se realizan las pruebas de White-Box que es la alternativa)