Depuración remota stm32f4

No tengo experiencia en el campo de los microcontroladores, vengo de un entorno de Java, por lo que la pregunta puede parecer un poco novata, pero no encontré mucha información al respecto.

Entonces, ¿es posible depurar una placa STM32F4 a través de bluetooth (usando eclipse o algún otro IDE)? Y si es así, ¿podría enviarme algunos enlaces que podrían ayudar? Estamos construyendo un automóvil robótico controlado por una placa de descubrimiento y la depuración con un cable USB no es realmente una opción si no queremos desmontar todo cada vez que algo sale mal. Por lo tanto, esto sería realmente útil. Asi que se agradece cualquier ayuda

Respuestas (3)

Recomiendo encarecidamente la depuración de printf para este tipo de aplicaciones. Toma un tiempo acostumbrarse, pero es una herramienta muy poderosa ya que todo lo que necesita es un puerto serie y no interrumpe el flujo del programa. Hice la depuración de puntos de interrupción durante un tiempo en un proyecto de robótica y fue un verdadero fastidio. Por la forma en que se escribió el código de accionamiento del motor, cuando llegabas a un punto de ruptura, los motores no se detenían, por lo que alguien tenía que agarrar el robot para que no se estrellara. No tiene este problema con la depuración de printf. Un par de módulos XBee fueron suficientes para llevar los datos en serie a una computadora para su revisión. También debería ser posible con bluetooth, pero eso también implica más gastos generales en términos de configurar los módulos correctamente y emparejarlos con su computadora.

Nunca me acostumbré a la depuración al estilo de punto de interrupción, y no puedo imaginar que sea de mucha utilidad para ningún tipo de proceso de tiempo crítico o de interacción de eventos. En mi experiencia, printf (o más bien std::cout, porque prefiero C++) es EL camino a seguir para ese tipo de sistemas.
Wow, realmente no pensé en cosas como qué detiene los motores... Hm, tienes razón, supongo que no es la herramienta adecuada para el trabajo. Gracias por el aviso.
La depuración de estilo de punto de interrupción requiere un depurador, soporte de compilador para el depurador, el cable de interfaz correcto para el objetivo, mucha configuración, etc., etc. Y es muy intrusivo y puede causar problemas extraños con los periféricos. No es tan malo para el código de alto nivel que se ejecuta en una PC, pero para cosas en tiempo real es una mierda. Para cosas en tiempo real, la instrumentación pasiva es el camino a seguir. Incluso he usado un analizador lógico para rastrear la ejecución del código antes porque es menos intrusivo que un depurador.
Un buen ejemplo es que si su MCU tiene USB y llega a un punto de interrupción, interrumpirá las comunicaciones USB (el USB tiene conexiones regulares). En realidad, hay un montón de notas de la aplicación Atmel sobre cómo la depuración interactiva no se puede usar en dispositivos con interfaces USB.
@Wouter van Ooijen: Realmente depende, trabajé en algunas cosas basadas en eventos e insertar printf estaba ralentizando demasiado el sistema. Con los puntos de interrupción, tiene la opción de continuar el programa inmediatamente después de alcanzar el punto de interrupción y simplemente recibir una notificación cuando se alcanzó.
@ConnorWolf Al menos en gdb, agregaría un comando al punto de interrupción para que solo imprima lo que desea y luego continúe. De esta manera, sigue siendo lo suficientemente rápido como para usar USB.

Supongo que el iSYSTEM iONE.BT podría ser algo que podrías usar. Admite la depuración en Eclipse.

Pondría algunos de estos en los comentarios, pero mi reputación no es lo suficientemente alta.

Nunca (muy raramente) uso la depuración de printf. Según mi experiencia, tiene un gran impacto en el rendimiento y el diseño. Por ejemplo, el formateo y la serialización de valores a través de la interfaz de comunicación pasan factura. También necesita bibliotecas estándar e implementación mínima de llamadas al sistema (-lnosys no funcionará en GCC) que es posible que no necesite en su firmware. Además, el contexto con el depurador es mucho más rico que con printf.

Por supuesto, existe el miedo al comportamiento impredecible de los periféricos en la parada. Sin embargo, STM tiene un comportamiento de periféricos configurable cuando se detiene la CPU. Cada periférico puede detenerse con la CPU o dejarse en funcionamiento. Las herramientas iSYSTEM soportan la configuración común de estos. Usé el depurador iTAG gratuito de iSYSTEM con mi proyecto de referencia STM USB y no tuve problemas con USB mientras detenía la CPU.

Además, las herramientas profesionales admiten secuencias de comandos que se pueden usar para configurar sus periféricos cuando la CPU está detenida. Por ejemplo, el estado de ejecución del sondeo del script de Python y la aplicación de cambios (con escrituras en la memoria, ejecuciones breves del monitor, etc.) al detenerse y ejecutarse.

Una cosa más: es posible que deba probar y/o verificar su código. Esto no se puede hacer con instrumentación. La instrumentación básicamente significa cambiar su código con fines de depuración. Pero la versión FW sin printfs no es lo mismo que la versión de depuración probada con ellos. O puede dejar printfs en la versión FW :).

Recomiendo C sobre C++ para proyectos integrados. C++ necesita más recursos que C. Los compiladores no necesitan saber nada sobre el depurador. Es al revés. No podrá rastrear de forma inalámbrica porque no hay suficiente ancho de banda. Sin embargo, dejaría pines de seguimiento (si están disponibles en su paquete) libres en caso de que desee conectar la herramienta de análisis de puertos de seguimiento en el futuro.

Hay un depurador de bluetooth disponible para Cortex-M. Hace poco tiempo se publicó un artículo al respecto en Embedded.com: http://www.embedded.com/electronics-products/electronic-product-reviews/debug-and-optimization/4422586/iSYSTEM-introduces-wireless- depurador

Depuración remota stm32f4
RespuestasAquíPolítica de privacidad1y, 0v