Sí, puede probar el firmware de la unidad escrito en C en prácticamente cualquier plataforma. Se supone que C es portátil. Puede escribir su firmware incorporado y probar la unidad fuera del objetivo. Tal vez eso no sea exactamente lo que estás preguntando, pero sigue leyendo.
En 1999, era un veterano de programación de sistemas integrados de 20 años. Asistí a la primera inmersión de programación extrema, pero en la compañía de Bob Martin, Object Mentor. Kent Beck estaba demostrando la programación Test-First, como se llamaba en ese momento (TFP ha evolucionado a Test-Driven Development). Cuando Kent ejecutó su código Java en el arnés de prueba JUnit, demostrando TFP, ¡me sorprendió! He estado vinculado a mi entorno de ejecución incrustado y no es necesario que lo esté. Podría ejecutar C incrustado en un arnés de prueba de unidad fuera de la plataforma de destino para tener la seguridad de que mi código se estaba comportando correctamente.
Durante los 20 años anteriores, tuve el desafío o escribir código para hardware que no existía. Si existía, generalmente tenía sus propios problemas, o los prototipos eran tan caros y raros que teníamos que programar el tiempo para ejecutar nuestro nuevo código. Además de eso, perseguir errores en el entorno hostil incrustado fue una hazaña fácil.
- ¿Cómo se compara LabView con C / C ++ para programar un robot móvil como el móvil remoto myExplorer?
- ¿Cuáles son algunos dispositivos que usan un microcontrolador que tiene 3 entradas y salidas? ¿Y cuál es su función?
- ¿Cuál tiene un mejor alcance en India, incrustado o VLSI?
- ¿Cuál es la forma correcta de conducir un LED en un sistema integrado?
- ¿Qué controlador se usa actualmente en las industrias, PIC o ARM7?
La semana después de ver la demostración de Kent TFP en Java, comencé a experimentar con TDD para C ++ incrustado. Hicimos un gran progreso en la funcionalidad principal del producto antes de decidir qué plataforma o sistema operativo usar. Desde entonces, he aplicado TDD a sistemas integrados pequeños y grandes. El tiempo dedicado a las pruebas de manejo me ha convencido de que ayuda a resolver muchos problemas en el desarrollo integrado.
A principios de la década de 2000, escribí y publiqué muchos artículos sobre la aplicación de TDD y Agile a C y C ++ integrados en mi sitio web (www.wingman-sw.com) y en mi blog (blog.wingman-sw.com). También escribí un libro sobre el tema (Test-Driven Development for Embedded C) y enseño clases (en el sitio y a través de la web) para equipos y personas que desean acelerar su aprendizaje de TDD para embebido. (Perdón por el comercial, pero quiero que los lectores sepan que hay muchos recursos para ayudarlos a acelerar el aprendizaje de TDD para Embedded C).
Piense en ejecutar pruebas fuera del objetivo como una vista independiente de cómo funciona su código. Es una técnica de reducción de riesgos para eliminar el riesgo de errores esparcidos por todo el código. Sin embargo, con las pruebas fuera del objetivo, se corre un nuevo riesgo. ¿Qué pasa si el código funciona fuera del objetivo, pero no dentro del objetivo? Es muy posible escribir C. no portátil. Ese código podría funcionar en mi sistema de desarrollo x86 y luego no funcionaría en mi ARM. Muchas personas que aplican TDD y prueba unitaria al código incrustado aceptan ese riesgo como el menor de los dos. También realizará pruebas de integración y sistema, por lo que debería poder encontrar estos problemas.
Si desea buscar más directamente los problemas de portabilidad, puede incorporar eventualmente el Embedded TDD Cycle, que incluye ejecutar pruebas en el destino.
En la etapa 1, está trabajando con retroalimentación rápida en una potente máquina de desarrollo que realiza TDD. Las etapas 2–4 se automatizarían por completo utilizando un servidor de integración continua como Jenkins. La etapa 5 podría ser las pruebas manuales que realiza hoy para demostrar que el sistema cumple con sus requisitos. A medida que aumente la habilidad en la automatización de pruebas, es probable que también encuentre formas de automatizar gran parte de la etapa 5. Cada vez que automatiza, reduce las aburridas pruebas manuales que realiza actualmente.
Cada etapa ayuda a encontrar problemas particulares como se describe en esta tabla.
Para ayudar con las pruebas en el objetivo, es posible que desee ver CppUTest. Es un arnés de prueba de código abierto que se ha portado a muchos entornos. (En total divulgación, soy uno de sus autores).
La mayor parte del software integrado creado se ejecuta y se prueba solo en el entorno integrado. Esto es muy malo, ya que ralentiza enormemente el desarrollo. Poner su código fuera de destino y probarlo puede ser una gran mejora de productividad además de ayudar a mejorar la calidad actual y futura de su código.
¿Desea escuchar algunas otras historias de TDD para incrustar? Consulte estos artículos (historias del campo). Tal vez algún día quieras agregar tu propia historia.
