¿Qué pueden aprender los ingenieros de firmware de los ingenieros de software?[cerrado]

Question

A juzgar por mi conocimiento de la historia de las herramientas, prácticas, etc. de ingeniería de firmware.Se ha quedado constantemente rezagado con respecto al campo de la ingeniería de software durante varios años.Por ejemplo, hasta donde puedo decir, todavía hay bastante debate en el mundo del firmware sobre si realmente vale la pena usar C++ para nuestras aplicaciones, y algunos compiladores de C++ están notablemente ausentes (¿¡¿microchip?!?).Imagino que en gran parte esto se debe a las diferencias de requisitos entre firmware y software.Una vez más, a juzgar por la historia, parece que es sólo cuestión de tiempo antes de que las herramientas y técnicas debidamente examinadas lleguen al mundo del firmware.

¿Qué métodos, herramientas, mejores prácticas, etc., que los ingenieros de software modernos utilizan con regularidad, podrían aprovechar también los ingenieros de firmware para mejorar su oficio?

Específicamente estoy pensando en los siguientes ejes (pero no dejes que te limiten):

• Mejorar la limpieza/mantenibilidad del código
• Reducir la introducción de defectos y mejorar la detección.
• Mejorando la documentación
• Gestión de requerimientos
• Mejorando la reutilización

También me encantaría ver que las tiendas integradas respondan o comenten las respuestas para brindar comentarios sobre la viabilidad teórica o, mejor aún, experiencias personales.

ACTUALIZAR
Estoy especialmente interesado en adelantarme un poco a la curva.Cosas relativamente nuevas que han sido examinadas razonablemente bien (funcionan bien para la mayoría de las personas), como C++, TDD, etc.¿Qué usas todo el tiempo y amas?

ACTUALIZACIÓN 2
Hasta ahora, estoy recibiendo muchos buenos consejos generales de programación en las respuestas, lo cual es genial, pero realmente estoy buscando enfoques menos convencionales que hayan demostrado ser exitosos para las personas.Estoy tratando de descubrir a los practicantes de Agile, los TDDers y el resto de ustedes que han probado cosas y han visto cómo dieron sus frutos con creces o fracasaron horriblemente.Como ingeniero de software, ¿ha habido alguna herramienta o práctica que haya adoptado en los últimos años que haya tenido un impacto notablemente positivo o negativo?

Answer 1

¿Qué se puede aprender de firmware ingenieros ingenieros de software? Un montón!

Me sorprende la similitud de desarrollo de firmware se practica hoy como lo fue hace 25 años cuando empezamos a usar C para el desarrollo integrado. C fue un gran paso hacia adelante desde ensamblador, pero hay muchas más lecciones aprendidas que los ingenieros de firmware puede y debe aprender. Sí, algunas de las herramientas son mejores, pero muchas prácticas están atrapados en los años 70 y 80.

desarrollo de software incrustado le añade algunos retos adicionales en la parte superior de los retos que enfrentan los desarrolladores no incrustados. Pero todos los principios y prácticas que utilizan los desarrolladores de software cualificados son aplicables al desarrollo incrustado. Por cierto:. No son sólo los desarrolladores de software integrados que no está para estos estado de las prácticas de la técnica, pero muchos desarrolladores de software no-incrustados, así

Las personas que conozco y he encontrado haciendo firmware son por lo general un grupo muy hábil, que trabaja para resolver problemas difíciles. Por desgracia, por cualquier razón, muchos no han mantenido al día con los acontecimientos en el mundo del software. Creo que tiene que ver con una barrera imaginaria construida por los ingenieros de firmware.

Embedded y los desarrolladores no incrustados hablan diferentes idiomas, pero resuelven problemas similares. Mantener código incrustado independiente de un dispositivo de hardware es esencialmente lo mismo que mantener el código de aplicación independiente de la interfaz de usuario o base de datos. Los principios subyacentes son los mismos.

Aquí hay algunas cosas que creo que los desarrolladores integrados deben prestar más atención a. Algunos de estos principios y prácticas se pueden usar nada más sacarlo de la caja, mientras que otros pueden necesitar un poco de ajuste para hacer frente a los retos implícitos. Si desea sustituir la palabra firmware para el software a continuación, seguir adelante, yo realmente no distinguir entre los dos.

gestión de la dependencia

Las dependencias entre los módulos deben ser manejados. La dependencia de software para el hardware es un caso especial que debe ser gestionado de forma activa por el desarrollador de software embebido. Si usted no maneja la dependencia, que se encargará de usted.

En la práctica esto significa que sólo un subconjunto limitado de los módulos de software debe tener conocimiento del hardware subyacente (y el sistema operativo). A medida que evoluciona el hardware, y siempre lo hace, la inversión en el código independiente de hardware puede ser preservada. Véase mi ah ja! momento.

Robert Martin ha escrito mucho sobre los principios de diseño sólido. desarrolladores de sistemas integrados deben llegar a conocerlos y aplicarlos a sus diseños.

  
• S-Singled Responsabilidad Principio
  
• Principios Cerrados O-Abrir
  
• L-Liskov principio de sustitución
  
• I-Interface Segregación Principio
  
• D-Dependencia Inversion Principio

Estos principios conducen a diseños que se destacan mejor la prueba del tiempo. Los sólidos principios fomentan la creación de módulos de cohesión e independientes. Son construir sobre las ideas orientadas a objetos, sino que puede aplicarse a C. Tenemos que dejar la estructura de datos de la función de llamada gratis para todo lo que es muy común en el código C incrustado.

C ++ y OO idiomas

¿Por qué no se puede utilizar C ++ y OO? Debido a que son demasiado lentos o demasiado grande. ¿Cuáles son los hechos? C ++ es un lenguaje grande, y misterioso, pero que no tiene que utilizar todo eso. Echar un vistazo a ¿Por qué sigues usando C?

C ++ compensa algunos de los problemas que C no ayuda mucho con como:

  
• La encapsulación y ocultación de la información
  
• Programación de las interfaces
  
• objetos que pueden sustituirse
  
• inicialización Ad-hoc

C ++ se puede utilizar eficazmente para el desarrollo incrustado. Bueno sí es necesario un compilador de C ++, y el espacio para la cabeza. Tal vez eso no se POSSIble en su mundo, o tal vez es el costo de hacer negocios. Comience por el aprendizaje:

  
• clases - estos son estructuras con funciones miembro, así como datos de los miembros.
  
• constructores -. Esto hace que sea posible obtener la inicialización correcta, todo el tiempo
  
• destructores - si se entera de constructores, también debe aprender destructores para mantener el universo en equilibrio
.   
• herencia - utilizar esto principalmente para definir interfaces que contienen funciones virtuales puras única. Interfaces proporcionan importantes roturas de dependencia y puntos de flexibilidad. Estos suelen ser injustamente desanimados en incrustado. No debe haber ningún misterio o prejuicio aquí; funciones virtuales son los punteros de función bajo el capó. La alternativa a la utilización efectiva de las interfaces es lógica condicional compleja, algo que los programas en C integrados suelen tener demasiado de.

Si desarrolladores de sistemas integrados utilizan aquellas partes de C ++ se podría construir un diseño más flexible y no incurrir en un alto costo.

Test Driven Desarrollo

Esto podría ser el mayor cambio de juego. Estoy contento de ver otros mensajes mencionan también. TDD puede ayudar a prevenir defectos de ahora y en el futuro. Para ver por qué TDD podría ayudar a echar un vistazo a La Física de TDD .

Integrados presenta algunos desafíos únicos para TDD. Por ejemplo, TDD requiere una extremadamente rápido de edición incrementales / compile / link / Desarrollo del ciclo. Para muchos desarrolladores de sistemas integrados esto significa cuidado gestión de la dependencia y prueba unitaria salir el primero a la meta. Ver más sobre TDD se adapta por Embedded .

Con TDD, va a crear código que se prueba a fondo. La cobertura completa de los ensayos automatizado actúa como una red de seguridad, permitiendo que el código sea cambiado de manera segura a medida que cambian los requisitos. consecuencias no deseadas se detectan inmediatamente.

Además, tener las pruebas que que conseguir casi gratis , le permiten sin miedo refactorizar su código ...

continua Refactoring

El código se escribe una vez, pero leído muchas veces. A continuación, se cambió y ajustado, lo que lleva a los diseños que se degradan con el tiempo. Si los desarrolladores no refactorizarán continuamente para mantener el código limpio, se convierte en un desastre. Tal vez algunos de ustedes están tratando con ese lío. pruebas automatizadas de TDD permiten a bajo costo y refactorización de bajo riesgo.

integración continua

Automatice su proceso de construcción. Que se ejecute con cada registro del espacio de trabajo. Se trata de un reto con las herramientas heterogéneas establece a menudo necesaria para obtener el código compilado en el blanco, pero sigue siendo la meta correcta.

El desarrollador cuanto antes incrustado sabe que un cambio es de alguna manera incompatible con algún otro trabajo, más rápido se puede reparar y menos tiempo será gastar en fusiones dolorosas.

incremental de entrega

Encuentra maneras de dividir el trabajo para que las grandes integraciones dolorosas se pueden evitar, y las ideas de diseño pueden ser juzgados antes de tiempo. Evitar la división a lo largo de las líneas arquitectónicas, se centran en la entrega de rebanadas de funcionalidad visible.

Colaboración

desarrolladores incrustados! salir de allí cubos y trabajar juntos. ¿Cómo se puede mejorar cuando sólo se ve su propio código? ¿Cómo puede mejorar cuando usted es el experto en tecnología XXX, han dominado y no tener la oportunidad de trabajar en diferentes áreas.

Hay mucho que aprender que hay. Es usted responsable de todo lo que pueda estar

Answer 2

He trabajado tanto como ingeniero de software embebido y como desarrollador de software. Al estar allí en ambos mundos, he aprendido que no importa cómo los recursos poco su sistema tiene y en qué idioma se está programando, hay muchas cosas que pueden hacer su vida más fácil.

Lo primero es la herramienta que está utilizando. En el software incorporado sólo se ocupan con el compilador / enlazador mayor parte del tiempo. Hay más de estos. herramientas de diferenciación, las expresiones regulares un lenguaje de programación, herramientas de documentación que ahorran mucho tiempo.

Otra cosa es la calidad del código. Uno tiene que seguir las convenciones de estilo, pasar por ciclos regulares de refactorización y en general tener en cuenta que la lectura de códigos se realiza con más frecuencia que la escritura de código y lo que realmente vale la pena tener un código más legible.

Algunas veces en software embebido que se pierda la fase de diseño completo. proyectos incorporados por lo general no son tan grandes como los de sobremesa / servidor, pero eso no es excusa para no hacer un diseño adecuado.

Software tiene que ser probado por sí mismo y no sólo como parte del dispositivo. Realmente ahorra mucho tiempo para construir un simulador de software del sistema, sólo para probar que el software cumple con las especificaciones requeridas. Es mucho más caro que lo haga cuando la cosa entera, el hardware y el software está listo.

Answer 3

• Control de fuente
• Prueba de la unidad (TDD)
• integración continua (o versiones compiladas)
• El seguimiento de errores

Los ingenieros de firmware que he trabajado no hacen ninguna de estas.

Prueba de la unidad puede no aplicarse muy voluntad a todo tipo de firmware. imagen que es más difícil a la unidad de prueba de algo cuando se está ejecutando en hardware físico. Depende si tiene emuladores disponibles supongo.

Answer 4

Si se asume por "ingenieros de firmware" que quiere decir "ingenieros de software embebido", entonces mi respuesta sería: que son los ingenieros de software, por lo que deben - en lo posible - estar haciendo las mismas cosas que cualquier otro ingeniero de software.

Obviamente, la escritura de software para sistemas embebidos requiere algunas habilidades diferentes, tales como un conocimiento detallado del procesador objetivo, y ser capaz de hacer frente con recursos limitados (en comparación con un PC o similar).

Como otros han mencionado, la unidad de pruebas se complica por el hecho de que esto puede tener que ser hecho en un simulador se ejecuta en un PC, que si bien es muy útil, no puede ser nunca un sustituto para las pruebas a fondo del sistema real - especialmente teniendo en cuenta la naturaleza asíncrona de eventos que un sistema embebido está sujeto a.

Una de mis preocupaciones en cuanto a por qué el software embebido puede parecer que "detrás de la curva" se debe a que la ingeniería de software - y como parte de eso, el software integrado - no se enseña generalmente en cualquier profundidad de grados de ingeniería electrónica. Dada la cantidad de la carrera de un ingeniero electrónico es probable que gastar codificación de hoy en día, esto parece una supervisión masiva.

Afortunadamente, hay quienes están tratando de compensar esto. Me gustaría recomendar encarecidamente la lectura de los artículos de Jack Ganssle (en su página web , y en su columna regular en < a href = "http://www.embedded.com/columns/archive/?content_type=bp" rel = "nofollow noreferrer"> embedded.com ).

Además, Misra-C fue creado hace un tiempo para tratar de evitar las fuentes comunes de errores en el software C para la industria del automóvil, y su entonces ha sido adoptado por muchos en el mundo de software embebido. Añadir un comprobador de análisis estático como PC-Lint , y que ya ha ido de alguna manera de mejorar su código.

Las herramientas vendedores tampoco han ayudado, en muchos casos mediante la creación de sus propios entornos de desarrollo, cuando quizá hubiera sido mejor concentrarse en el compilador y depurador, y dejar el IDE a otros, por ejemplo, Eclipse.

A propósito, para más información sobre la no utilización de C ++ en sistemas embebidos ver esta pregunta .

Por último: porque los ingenieros de firmware son ingenieros de software, nos enfrentamos a muchos de los mismos temas, retos y preocupaciones, por lo que debemos utilizar los mismos recursos; después de todo, hay un montón de ellos alrededor, y estás leyendo uno de ellos!

Algunos de los otros sitios web que frecuentan son:

• desbordamiento de pila del blog y podcast de
• The Daily WTF
• hablar de calidad
• Coding Horror
• Secreto Geek
• Joel on Software
• desbordamiento de pila del blog ; Este es uno está dedicado a los sistemas embebidos.

EDIT: En respuesta al comentario de Gabe, "¿qué herramientas deberíamos buscar para adaptarse", un par de ejemplos vienen a la mente:

compilador independiente de entornos de desarrollo: IDE para C, pero por lo que puedo decir, pocos de ellos pueden ser utilizados a sus pocas potencial sin un compilador compatible. Me gustaría ver que tanto los desarrolladores de compiladores y los desarrolladores IDE convergen de manera that, idealmente, cualquier compilador se puede utilizar con cualquier IDE.

En ausencia de un compilador compatible, me gustaría ser capaz de utilizar PC-Lint (o equivalente) como mi compilador "oficial" con un IDE de mi elección.

Simulación y modelización: Las herramientas de simulación como Simulink permitir la simulación, modelado y prueba de software para el PC y algunos procesadores de gama alta incrustado. Herramientas como esta sería tan útil para los chips más pequeños, por lo que sería bonito verlas extenderse a esa zona del mercado.

PD: la columna de Jack Ganssle esta semana se titula " Lo que hace diferente incrustado ? ", y así es (ligeramente) en relación a la pregunta anterior.

Answer 5

No está seguro de qué grado de software se considera el firmware (BIOS, controladores o utilidades), pero el estándar de quejas que escucho es que la interfaz de usuario no es estándar. Al darse cuenta de que las cuestiones de la interfaz de usuario y que debe seguir algunas normas o la tradición sería algo bueno.

En lo que va de C ++, es comprensible que dude en entrar en ella, porque hay un montón de gastos generales en comparación con C. C es casi como un lenguaje ensamblador con libc, mientras que en C ++ incluso una simple llamada a la función puede ser virtual. La aplicación de la C ++ en tiempo de ejecución total no puede ser tan fácil, dada la complejidad de la lengua.

Hay demasiadas cosas para mostrar en términos de desarrollo de software "mejores prácticas" (odio esa palabra). ¿Por qué no comenzar con rel="nofollow El Test de Joel:. 12 Pasos para mejor código

  

El Test de Joel

     

  
1. ¿Utiliza control de código fuente?
  
2. ¿Se puede hacer una acumulación en un solo paso?
  
3. ¿Haces versiones diarias?
  
4. ¿Tiene una base de datos de errores?
  
5. Foro de corregir los errores antes de escribir nuevo código?
  
6. ¿Tiene un calendario de puesta al día?
  
7. ¿Tiene una especificación?
  
8. programadores tienen condiciones de trabajo silencioso?
  
9. ¿Utiliza las mejores herramientas de dinero puede comprar?
  
10. ¿Tiene probadores?
  
11. Haz nuevos candidatos escribir código durante su entrevista?
  
12. ¿Haces pruebas de usabilidad pasillo?
  

Answer 6

Firmware Ingeniería es bastante amplio. De PIC para DSP todos ellos tienen diferentes grados de recursos físicos. Estos DSP días son bastante potente (comparable con la CPU ~ 5 años de edad), pueden soportar gran cantidad de memoria, etc. Pero, de nuevo hay que PICS que operan con varios kilobytes. Más magros los recursos, el programador tiene que usar hacks ingeniosas para obtener el máximo rendimiento del dispositivo. Y la atención se centra en 'hacer que funcione' en lugar de 'escribir código elegante'.

Lo que me gustaría ver es buenas herramientas de gestión de proyectos que incorporan código, así como los documentos que hay que hacer referencia a un montón de hojas de datos, documentos de diseño que se encuentran dispersos por la red y en manchas de correo electrónico, etc ..

También me gustaría ver mejores herramientas dev para los DSP (TI: por favor entregue CCS a alguien bueno en la fabricación IDE), y más fabricantes de la biblioteca usando C ++ (estoy mirando a ti ATEME) para construir mejores bibliotecas.

Y también los ingenieros de hardware para tener una mejor apreciación de Orientación a objetos en lugar de dejar escapar 'si se trata de C ++ que va a ser lenta'.

Answer 7

Déjame primera dirección de un supuesto en su pregunta. La suposición es que los ingenieros de software embebido (ESE) no sabe o no son conscientes de las prácticas de ingeniería de software modernas y la necesidad de aprender nuevas prácticas. Este supuesto se debe sacudir a cabo de inmediato. Creo que puedes encontrar la misma distribución estadística de las ESEs que mantienen sus habilidades y técnicas en marcha hasta la fecha como las PE no incrustados.

Así que, tal vez su pregunta se convierte en una serie de preguntas como:

1. ¿Por qué ESEs usar un editor independiente de código y un compilador de línea de comandos y no un IDE?
2. ¿Por qué se prefiere a C C ++ en la mayoría de los proyectos incorporados?
3. ¿Por qué no está ahí tanto la experimentación en las prácticas de programación en el mundo incrustado?

Los siguientes párrafos responden a estas preguntas.

1. ESEs suelen utilizar un editor de código específico, ya que es una preferencia personal o que es lo que se utiliza por su / su empresa. IDE no son tan comunes porque ESEs trabajar muy de cerca con el silicio y no todos los fabricantes de chips desarrollar un IDE para su línea de chips. Sólo las fichas que logran mayor penetración en el mercado, tales como ARM, tienen suficiente impulso como para justificar el desarrollo de herramientas basadas en IDE. Por otra parte, un IDE no proporciona tanto de una ayuda al ESE como lo hace con, por ejemplo, un desarrollador de escritorio. IDEs proporcionan ayuda para hacer la cola a la interfaz gráfica de usuario o código de finalización para las API grandes; ninguno de los cuales se encuentra comúnmente como estándar o como en el mundo incrustado.

2. Estoy seguro de que hay mejores escribir-ups en cuanto a porqué se prefiere a C C ++ en sistemas embebidos de lo que puede hacer sobre la marcha. El corto de él es que se utiliza lo que funciona. C funciona y es más común (más programadores saben C que en C ++). La otra razón podría ser que la metodología OO fue ideado para ayudar a los programadores a resolver grandes problemas mediante la abstracción de la solución en objetos conceptuales manejables. En el mundo integrado, los problemas son por lo general redujo a un problema tan pequeño (y solución) como sea posible para que el sistema embebido se vuelve más confiable por tener una base de código más pequeño.

3. Hay menos experimentación por ESEs porque un producto incorporado, en general, debe ser mucho menos propenso a errores y tienen una mayor fiabilidad que un programa de escritorio. Esto significa que una aplicación rígida de las prácticas de probada eficacia y más tiempo en las pruebas. ¿Por qué? Porque a menudo no hay un camino viable para actualizar el firmware de un dispositivo integrado; que es ya sea imposible debido al sistema que está siendo desplegado fuera de alcance o inverosímil debido al costo de la actualización de millones de dispositivos.

En conclusión, Utilizar herramientas y prácticas ESEs que mejor se adapten a sus necesidades al igual que las PE no incrustados hacen. Como ESE practicar, creo que la disciplina de software embebido es mucho más diferente que mi no ESE amigos creen que es. Por lo que la aparente disparidad de prácticas de programación no es una cuestión de ESEs que necesitan para aprender las prácticas modernas, pero no ESEs necesidad de entender cómo los diferentes sistemas embebidos es.

Answer 8

automatizado de pruebas
No analizar visualmente los resultados de la simulación para comprobar es que todo está bien. Es necesario prueba automatizada completa, ya que siempre se va a perder algo en esa masa de formas de onda.

Control de versiones
Usted no se va a recordar lo que fue la versión de trabajo. Utilizar el software de control de versiones para que sepa lo que para programar tablero con.

seguimiento de fallos
Su va a olvidar pronto o más tarde. Un registro de error debe contener la versión (véase Control Version) en el que se detectó el problema primera y la versión en la que se fija.

¡Vaya pensé que quería decir firmware como en FPGA, pero lo mismo es cierto para el software embebido. Si ya dispone de estos procesos en marcha un gran también olvídate de unconventional approaches hasta obtener las bases justo.

Answer 9

Probablemente esto esté un poco fuera de contexto.
Una breve referencia a una columna de firmware en Incorporado,

• Estándares para eliminar errores en la codificación de firmware
• Algunas páginas avanzan en el artículo, Diez reglas para matar insectos

Siempre he encontrado buenos artículos sobre ingeniería de firmware en Embedded.
Lo que probablemente muchos interesados ​​en esta pregunta también tengan...