embedded - tipos - Diferencia de mentalidad entre la estación de trabajo y los programadores incrustados
que hace un programador trainee (5)
2 cosas, como ya mencionó Suroot, una vez que lanzas una aplicación de escritorio, no tiene que ser "para siempre", especialmente hoy en día.
Pero, una vez que lo "envías", está encajado, está en camino hacia Marte, por lo que no podrás tirar de él.
También una de las principales diferencias es que los programadores integrados suelen ser MUCHO más conscientes acerca de la administración eficiente de códigos y memorias: los equipos de sobremesa ejecutan código horrible muy rápido, y los integrados no.
¿Cuál crees que es la diferencia de mentalidad entre un programador que trabaja para un entorno de escritorio (Windows, Linux, lo que sea ...) y alguien que trabaja en un sistema integrado?
Un ejemplo simple que puedo pensar es que en un entorno incrustado, siempre compruebo que un malloc no es NULL. La mayoría del código que he visto es que los escritorios de destino no son diligentes para verificar el valor de retorno de malloc.
¿Algún otro ejemplo de diferencias de mentalidad?
En el entorno de escritorio existe la idea de que "oye, siempre puedo lanzar una actualización o parche para arreglar esto más tarde". En el diseño integrado, obtienes más "esto tiene que funcionar porque no queremos recuperar el dispositivo o lanzar un programa de reparación aún más largo".
Es curioso que menciones malloc () específicamente en tu ejemplo.
En cada sistema duro y en tiempo real en el que he trabajado, la asignación de memoria se gestiona especialmente (normalmente no el montón, sino grupos de memoria fija o algo similar) ... y también, siempre que sea posible, toda la asignación de memoria es hecho por adelantado durante la inicialización. Esto es sorprendentemente más fácil de lo que la mayoría de la gente creería.
malloc () es vulnerable a la fragmentación, no es determinista y no se divide entre los tipos de memoria. Con pools de memoria, puede tener pools que están ubicados / tirando de SRAM superrápido, DRAM rápido, RAM con respaldo de batería (lo he visto), etc.
Hay un centenar de otros problemas (en respuesta a su pregunta original), pero la asignación de memoria es muy importante.
También:
- Respeto / conocimiento de la plataforma de hardware
- No asume automáticamente que el hardware es perfecto o incluso funcional
- Conocimiento de ciertos aspectos y características del lenguaje (por ejemplo, excepciones en C ++) que pueden hacer que las cosas se vuelvan hacia los lados rápidamente
- Conciencia de la carga de la CPU y la utilización de la memoria
- Conciencia de interrupciones, prevención y las implicaciones en los datos compartidos (cuando sea absolutamente necesario, cuanto menos compartan datos, mejor)
- La mayoría de los sistemas integrados son impulsados por datos / eventos, en oposición a sondeados; Hay excepciones, por supuesto
- La mayoría de los desarrolladores integrados se sienten muy cómodos con el concepto de máquinas de estado y comportamiento / modelado con estado.
Los programadores de escritorio ven los recursos como prácticamente ilimitados. Memoria, potencia de cálculo, espacio de disco. Esos nunca se agotan. Los programadores integrados se enfocan intensamente en todos esos.
Ah, y los programadores embebidos también a menudo tienen que preocuparse por problemas de alineación de memoria. Los codificadores de escritorio no. El brazo frota cuidado. los chips x86 no.
el tamaño importa