Escribir software embebido sin hardware


8

Tenga en cuenta que el equipo de hardware tardará 2 meses en desarrollar algo de hardware, pero para entonces tendré que tener el software listo.

Mi pregunta es: ¿cómo puedo escribir el software y probarlo sin tener el hardware?

¿Hay algún estándar / s a ​​seguir? ¿Cómo lo haces?


Dependiendo de cuán complejo sea el hardware, puede probar un simulador. Eso es bastante factible si es solo un microcontrolador con periféricos simples. Más que eso y no tienes suerte en esa ruta.
Mástil

66
Intente encontrar placas de desarrollo para el micro y cualquier otro dispositivo periférico que esté utilizando, e intente conectarlos todos de una manera que se parezca más al diseño de su equipo de hardware. Será grande y feo, pero usted debe ser capaz de armar un sistema que es lo suficientemente cerca de la cosa real - por lo menos en lo que el firmware puede contar ...
brhans

En el peor de los casos, si no puede simular correctamente el hardware, tenga una forma de desactivarlo. Hace solo un par de semanas, quería probar la comunicación de red con otro programa, solo para descubrir que lo haría exit()porque trató de mapear direcciones codificadas en / dev / mem.
isanae

1
En realidad, es preferible, en muchos casos, utilizar un simulador para el desarrollo de software integrado, mucho más fácil de depurar. El problema, por supuesto, es que necesitas un simulador decente. A veces hay uno genérico que se puede adaptar, a veces un interno inteligente puede escribir uno en un frenesí de codificación alimentado con cafeína.
Hot Licks

Respuestas:


34

No tiene hardware durante las etapas iniciales del desarrollo del firmware. Las estrategias comunes para lidiar con esto son:

  1. Dedique tiempo a diseñar el sistema por adelantado antes de escribir cualquier código. Por supuesto, debe hacer esto de todos modos, pero en este caso es aún más importante de lo habitual. Es mucho más fácil depurar software bien pensado que un desastre basado en pasta.

  2. Modular adecuadamente todo, minimizando las interfaces entre módulos. Esto ayudará a contener errores en módulos individuales y permitirá una prueba más fácil de módulos individuales.

  3. Escriba el código de abajo hacia arriba, los controladores que tocan el hardware van primero, la lógica de aplicación de alto nivel al final Esto permite descubrir inconvenientes impuestos por la arquitectura desde el principio. No tenga miedo de cambiar la arquitectura a medida que las realidades del hardware salgan a la luz, pero asegúrese de que toda la documentación se actualice en consecuencia.

  4. Simular. La mayoría de las compañías de microcontroladores proporcionan simuladores de software de sus microcontroladores. Estos solo pueden llegar tan lejos, pero aún pueden ser muy útiles. Simular las entradas y medir las salidas del hardware puede ser difícil, pero verificar la lógica de nivel superior de esta manera no debería ser demasiado difícil.

    Aquí es donde el diseño modular ayuda nuevamente. Si no puede simular razonablemente algunas interacciones de hardware de bajo nivel, utilice una versión diferente del módulo que toca ese hardware pero que pasa sus propias acciones simuladas a los niveles superiores. Los niveles superiores no sabrán que esto está sucediendo. No verificará el módulo de bajo nivel de esta manera, pero casi todo lo demás.

En resumen, use buenas prácticas de diseño de software, que por supuesto debería estar haciendo de todos modos.


Me gustaría agregar: obtener paneles de desarrollo (sí, múltiples, porque probablemente matará al menos uno ...) lo antes posible y obtener los controladores de bajo nivel en su lugar. Prueba de unidad tanto de tu código como puedas. Sí, puede unir el código que toca el hardware. No, no puede simular completamente el hardware, pero puede obtener el 90% de la funcionalidad correcta incluso antes de flashear por primera vez. Hice todo lo anterior en un proyecto reciente, y teníamos el 99% de funcionalidad en funcionamiento y funcionando cuando entró el hardware real. Fue magnífico.
CHendrix

13

Sin tener una idea de qué es lo que está desarrollando, o en qué familia de microcontroladores se basará su hardware, la mayoría de las familias de microcontroladores tienen sistemas de desarrollo de bajo costo disponibles que tienen un conjunto de periféricos comunes en ellos, lo que puede permitirle simule al menos parte de su hardware objetivo final.


1
Convenido. Lo diría con más fuerza. En una situación como esta en la que el software debe terminarse al mismo tiempo que el hardware, solo usaría un microcontrolador que tuviera una placa de desarrollo o evaluación adecuada.
Steve G

Incluso si tuvo una idea de lo que está desarrollando el OP, la mayoría de las familias de microcontroladores todavía tienen simuladores disponibles.
Olin Lathrop

Yo uso ambos métodos. Sin embargo, también vigilo el equipo de prueba de línea de producción requerido. Puede reunirse con los ingenieros de producción y el hardware de diseño para probar sus controladores que luego pueden formar parte de las pruebas de producción. Si tiene suerte, incluso pueden construir hardware para una placa de desarrollo / prototipo, por lo que también se adelantan al proceso. Todo se debe a cómo presentar la solicitud de ayuda ...
Cuchara

Esta es la mejor respuesta a esta pregunta, ya que siempre tengo una placa de desarrollo para programar las funcionalidades principales antes de intentarlo en el pcb.
lucas92

2

Dependiendo de cuán dependiente será el hardware de la aplicación, puede comenzar a implementar el proyecto en una PC estándar (Windows, Linux ...). La mayoría del acceso periférico debe abstraerse de todos modos, por lo que no es un gran problema implementar algunas funciones ficticias, que se reemplazarán más adelante. Si no es posible simular algún comportamiento, al menos podría hacer una maqueta del sistema (API ...), por lo que la implementación real será mucho más rápida y clara, tan pronto como el hardware esté listo.

Por supuesto, hay muchas cosas que no se pueden simular, como el comportamiento en tiempo real o los controladores de hardware complejos. Por otro lado, un ADC controlado por interrupción puede simularse fácilmente utilizando un hilo que lee valores de un archivo o un puerto de red.

Por supuesto, todo esto depende en gran medida de varios factores:

  • ¿Se puede usar la misma / similar cadena de herramientas en el controlador y la PC (por ejemplo, gcc)?
  • ¿Qué tan dependiente del hardware es el sistema?
  • ¿Qué experiencia tienes con la programación de PC?

Por mi parte, primero estoy diseñando prácticamente todos los módulos de firmware en una PC.


Igual que aquí. Algunas diferencias entre compiladores (intrínsecos, palabras clave especiales, sistema operativo de código cerrado y pila de red no totalmente compatibles con BSD) y errores (con C ++) que obligan a un uso intensivo de archivos preprocesados ​​y preprocesadores específicos de archivos, pero el código en sí puede ser casi idéntico entre DSP y PC. Para la versión de PC, puedo usar una verificación de errores de tiempo de ejecución fuerte y pesada (CodeGuard) y sus capacidades de depuración no se pueden combinar en plataformas integradas. Una ventaja adicional es que puedo tener pocos dispositivos virtuales adicionales para cualquier prueba de red y carga.
TMSZ

Con la disponibilidad de Raspberry Pi y BeagleBone, su entorno de desarrollo podría ser fácilmente su entorno de tiempo de ejecución: sin problemas con la cadena de herramientas, etc. Además, puede usar valgrind / helgrind, gdb, etc.
jhfrontz

1

Intenta obtener un simulador para tu chip. Debe simular todas las entradas esperadas y algunas inesperadas también. Modular / abstraer todo lo que pueda y escribir pruebas unitarias. Si puede, esas pruebas pueden convertirse en parte de su código real y convertirse en una función (autocomprobación de la placa).

Si no puede obtener un simulador, resuma tanto como pueda a través de una HAL (capa de abstracción de hardware). Todos los conductores lo respaldan. Intente abstraer todo el ensamblaje específico de la plataforma detrás de alguna llamada de función C y piense en ellos como controladores también. Escriba el resto como código C / C ++ portátil y cree un HAL delgado para x86 y ejecútelo en su máquina con todos los casos de prueba.

De esa manera, cuando obtenga el hardware, solo tendrá que depurar el HAL. Cuanto más delgado sea, más rápido lo depurará y tendrá todo funcionando. Recuerde que si usa un ensamblaje específico de plataforma para operaciones más rápidas, usted sí queremos MUCHO para obtener pruebas bit a bit .


La exactitud de bits es especialmente importante si se utiliza DSP de punto fijo.
Ronan Paixão

Puede o no aplicarse a un caso particular, pero en general la exactitud de bits tiene su precio. QEMU recientemente (hace 2 años) decidió implementar FPU de bit exacto, y ¿adivina qué pasó con el rendimiento ?
Dmitry Grigoryev

La exactitud de bits no es tan importante cuando se usa una FPU. Sin embargo, es extremadamente importante si se usa un punto fijo. Especialmente porque el punto fijo de software necesita controles adicionales en todas partes.
Ronan Paixão

Lo cual es el resultado de malas prácticas de codificación. Las personas han aprendido a tomar precauciones cuando usan a == bcomparaciones con flotadores, pero todavía las usan sin pensar con números de puntos fijos.
Dmitry Grigoryev

Si bien las malas prácticas de codificación son un gran problema, existen muchos otros problemas, especialmente en casos extremos. Los desbordamientos me vienen a la mente rápidamente, al igual que la pérdida de precisión , el redondeo , la saturación y el ancho frente al desplazamiento de bits . Con todo eso, es fácil ignorar alguna pérdida de precisión en casos de prueba comunes. El problema es cuando su aplicación llega a casos menores y los errores se mueven de los bits fraccionales a los enteros, lo que sucede si el rango se calcula mal. Simplemente consulte la página de características del diseñador de puntos fijos de MATLAB para ver qué más podría salir mal en un vistazo.
Ronan Paixão

1

Tu pregunta es un poco amplia. El hardware (HW) podría significar un desarrollo ASIC / FPGA totalmente personalizado, DSP programados por ensamblador, o "solo" un sistema embebido típico basado en microprocesadores / microcontroladores / SoC disponibles en el mercado (por supuesto, un SoC también puede contener un DSP que tal vez quieras programar ...). Para grandes cantidades de venta, convertirlo en un ASIC no es infrecuente.

Pero para un proyecto de 2 meses, espero que esté basado en algún microcontrolador:

En cualquier caso, debe insistir en que el equipo de hardware le dé un prototipo para que pueda comenzar a probar su código antes de la fecha límite absoluta; esto podría consistir en una placa de desarrollo genérica, como algunas personas ya han mencionado, pero en mi opinión es su trabajo para proporcionarle el correcto, y potencialmente también algunos periféricos requeridos / similares para las pruebas.

Los simuladores también son posibles hasta cierto punto, pero es posible que deba caracterizar algunos sensores / datos del mundo real que pueda obtener. Aquí el equipo de hardware también necesita al menos ayudarlo.

Aparte de eso, el diseño del software ya se puede hacer y todos los módulos de alto nivel pueden implementarse (y deberían) implementarse y probarse sin el hardware real. Idealmente, también definirá una API junto con el equipo de hardware, y le proporcionarán las funciones de nivel más bajo, por lo que cualquier cambio que hagan en el lado del hardware allí (por ejemplo, simplemente redefiniendo qué pines de puerto usan), no siempre será Sé crítico contigo.

En todos los casos, la comunicación es clave.


0

Sí, puede desarrollar su código para su placa de destino antes de que se fabriquen.

Cómo ?

Primero debes conocer el objetivo principal de ese sistema. Entonces, a partir de esto, puede elegir el controlador de manera apropiada de una gran fuente de disponibilidad como digikey, mouser.

Y elige un simulador como Proteus. Esto simulará el procesador / controlador exacto ahora puede comenzar su codificación. Pero no puede esperar la precisión como en el hardware.


¿Por qué downvote? ¿Puedo saber cuál es el problema con esta respuesta?
Photon001
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.