embedded - industria - ¿La programación de sistemas embebidos/de bajo nivel es difícil para los desarrolladores de software?
sistemas embebidos hardware (17)
"Difícil" es un término extremadamente relativo. Si está acostumbrado a pensar de la manera estrecha, a veces enrevesada, que necesita para un pequeño código incrustado (por ejemplo, usted es un desarrollador de controladores), entonces ciertamente no es "difícil".
No para "bash" (sin juego de palabras) scripts de shell, pero si escribe perl y scripts de shell todo el día, entonces bien podría ser "difícil".
Del mismo modo si eres un tipo UI para Windows. Es un tipo diferente de pensamiento.
Dado mi historial como generalista, puedo abarcar gran parte del área, desde electrónica analógica hasta escribir aplicaciones simples que se conectan a un back-end RDBMS.
Actualmente trabajo en una empresa que desarrolla hardware para resolver problemas específicos de la industria. Tenemos un programador experimentado que ha escrito aplicaciones de negocios, videojuegos y un montón de otras cosas para PC. Pero cuando hablo con él sobre la programación de bajo nivel, al mismo tiempo expresa interés y también duda / incertidumbre acerca de unirse al proyecto.
Incluso cuando se habla de PC, parece estar más cómodo trabajando en el nivel del lenguaje que en el nivel inferior (conjuntos de instrucciones, ISR). Aún así, es un tipo inteligente, y creo que disfrutaría el trabajo una vez que haya superado la etapa inicial de aprendizaje. Pero tal vez ese es mi propio entusiasmo por las cosas de bajo nivel hablando ... Si estuviera realmente interesado, ¿tal vez ya habría comenzado a aprender cosas en esa dirección?
¿Tiene experiencia en hacer esa transición de software a hardware (o software de bajo nivel)? O, mejor aún, de tomar un tipo de software único, y la transición a las cosas de bajo nivel?
Editar:
PD: Me encantaría saber de los encuestados cuáles son sus antecedentes: EE, CS, ¿ambos?
Al final del día, todo es una API.
¿Necesita escribir código para un periférico SPI dentro de un microcontrolador? Bueno, obtenga la hoja de datos o el manual del hardware, y observe el periférico SPI. Es una API grande y compleja.
El problema es que debes entender el hardware y algunos fundamentos básicos de EE para comprender lo que significa la API. La hoja de datos no está escrita por y para desarrolladores SW, fue escrita para ingenieros de hardware y quizás ingenieros de software.
Así que todo es desde la perspectiva del hardware (enfrentémoslo: la compañía de microcontroladores es una compañía de hardware llena de ingenieros de hardware / asic).
Lo que significa que la transición no es simple y directa.
Pero no es difícil, es solo un dominio ligeramente diferente. Si puede implementar un programa de estudio, comience con los kits de Rabbit Semiconductor . Hay suficiente software allí para que un SW pueda cavar realmente con poco esfuerzo, y el HW es fácil de tratar porque todo está envuelto en lindas bibliotecas pequeñas. Cuando quieren hacer algo complejo, pueden profundizar en el acceso directo al hardware y tocar el violín en el nivel inferior, pero al mismo tiempo pueden hacer cosas geniales como construir servidores web pequeños o cámaras de red pan / tilt . Hay otras compañías con ofertas similares, pero Rabbit está realmente enfocado en facilitar el hardware para los ingenieros de software.
Alternativamente, introdúcelos en la plataforma Android. Se ve como un sistema Unix para ellos, hasta que quieran hacer algo interesante, y luego tendrán el deseo de atacar ese pequeño problema y aprenderán sobre el hardware.
Si realmente quieres saltar al fondo, ve con un kit arduino : compiladores y librerías baratos y gratuitos, bastante fáciles de usar, pero tienes que conectar cables para hacer algo interesante, que podría ser demasiado grande. obstáculo para un ingeniero de software reacio. Pero un poco de ayuda y unos cuantos empujones en la dirección correcta y estarán absolutamente encantados de tener una pequeña pantalla LED que se mueva * como las luces nocturnas ...
-Adán
* Sí, ese es un término de ingeniería técnica.
Creo que depende de la forma en que programan en su entorno elegido y del tipo de trabajo integrado del que están hablando.
Trabajar en una plataforma embebida de Linux, por ejemplo, es un salto mucho más pequeño que tratar de escribir código en una plataforma de 8 bits sin ningún sistema operativo.
Si son el tipo de persona que tiene una comprensión de lo que está sucediendo debajo de la API y el entorno al que están acostumbrados, entonces no será demasiado difícil avanzar hacia el desarrollo integrado.
Sin embargo, si su visión del mundo se detiene en el API de alto nivel que han estado utilizando, y no tienen ningún concepto de nada por debajo de eso, van a tener un momento realmente difícil.
Como una declaración (muy) general, si se sienten cómodos trabajando en aplicaciones multiproceso, probablemente estén bien, ya que comparte algunos de los mismos problemas de volatilidad de datos que usted tiene cuando trabaja en proyectos integrados.
Con todo esto dicho, he visto a más programadores incrustados trabajando con éxito en el desarrollo de PC que a la inversa. (por supuesto, es posible que no haya visto una buena sección)
De acuerdo en el término "difícil" es bastante relativo.
Diría que es diferente, ya que necesitaría emplear diferentes patrones de desarrollo que no usará en otro tipo de entorno. La restricción de tiempo, por ejemplo, podría requerir una curva de aprendizaje. Sin embargo, ser curioso, ¿sería una cualidad para un desarrollador, no lo sería?
Esto es muy subjetivo, supongo, sus razones podrían ser muchas. Pero si él es como yo, sé de dónde viene. Dejame explicar.
En mi carrera, he dedicado 6 años a la industria de las telecomunicaciones, trabajando mucho para integrar el middleware SDK en teléfonos móviles de gama baja, etc.
La mayoría de los entornos integrados que he experimentado son como un clima duro para un programador, tienes que superar constantemente las limitaciones de recursos, etc. Algunos pueden encontrarlo como un desafío y disfrutarlo por el desafío en sí, algunos podrían sentirse cerca de "lo real": el hardware, algunos pueden sentir que limita su creatividad.
Soy del tipo que siente que limita mi creatividad.
Disfruto de estar de vuelta en el entorno de escritorio de Windows y batir mis alas con elaborados diseños de clase, estirar mis piernas unos cuantos ciclos de reloj extra, usar cantidades innecesarias de memoria para diagnósticos, etc.
En ciertas unidades integradas en el pasado, apenas tenía soporte para fseek () (una función de archivo estándar ANSI C). Si tiene suerte, un "perro guardián" podría dar pistas sobre dónde se estrelló algo. Sin mencionar el dolor de comunicarse con el usuario en pantanos preventivos de un solo subproceso.
Bueno, ya sabes a lo que me refiero. En mi opinión, no es necesariamente difícil, pero es un gran salto, con una reutilización potencialmente pequeña de su experiencia actual.
Saludos
Robert
Existe una diferencia muy real en la mentalidad, desde el desarrollo de aplicaciones a nivel de usuario (es decir, PC o aplicaciones web de propósito general) hasta el desarrollo de aplicaciones de respuesta en tiempo real y en plazos difíciles (es decir, la interfaz de hardware / software).
Las interrupciones, los conjuntos de instrucciones, el cambio de contexto y las restricciones de recursos duros son relativamente desconocidas para el desarrollador promedio. Supongo que su "desarrollador promedio" no es un Ingeniero Eléctrico / Electrónico u otro Ingeniero por capacitación.
La transición para este desarrollador que mencionas puede estar fuera de su zona de confort. A algunos de nosotros nos gusta estirarnos así. Otros de nosotros podemos haber decidido que la vista no vale la pena subir.
Del mismo modo, las personas que han estado en el área de hardware (es decir, Ingenieros) a menudo tienen dificultades con las suposiciones y el lenguaje de desarrollo de software.
Estas son generalidades burdas, por supuesto, pero espero dar alguna idea.
Me gustan ambos. Embedded me desafía y realmente me pone en marcha de una manera visceral. Hacer algo que afecte el mundo macro físico es muy satisfactorio. Pero he tenido que ponerme al día en el extremo de la electricidad / electrónica, ya que mi licenciatura es en informática. Tengo una formación bastante generalista, donde estudié ai, gráficos, compiladores, lenguaje natural, etc. Ahora estoy haciendo un trabajo de posgrado en sistemas integrados. La parte realmente difícil es ajustarse a la falta de instalaciones de tiempo de ejecución como un sistema operativo.
Tienes razón en que cualquiera que tenga el suficiente conocimiento como para no sentirse completamente perdido en un área (¡al límite!) Disfrutará los desafíos de aprender algo nuevo.
Yo mismo me sentiría bastante nervioso al pasar al nivel de los conjuntos de instrucciones, ya que hay una gran cantidad de conocimientos básicos necesarios para sentirse cómodo en el entorno.
Puede marcar la diferencia si puede ayudar al desarrollador a aprender cómo hacer esto. Tener a alguien allí puede preguntar y hablar sobre el problema es una gran ayuda en ese tipo de cambio de dominio.
Puede valer la pena asignar el desarrollador a un proyecto más pequeño con otros como primer paso y ver cómo funciona. Si él expresa entusiasmo para probar otro proyecto, las cosas deberían fluir desde allí.
Yo diría que no es más difícil, solo requiere un conjunto diferente de conocimientos, diferentes consideraciones.
"Pero cuando hablo con él acerca de hacer programación de bajo nivel, simultáneamente expresa interés y también duda / incertidumbre sobre la posibilidad de unirse al proyecto". - Eso significa que lo dejas intentar y te preparas para contratar a otra persona en caso de que no pase la curva de aprendizaje.
Los mejores programadores integrados con los que he trabajado son EE capacitados y aprendieron SW en el trabajo. Los peores desarrolladores integrados son los recién graduados de CS que piensan que SW es la única forma de resolver un problema. Me gusta pensar en la programación integrada como la parte inferior de la pirámide SW. Es una capa / base de abstracción estable que hace la vida más fácil para los desarrolladores de aplicaciones.
Necesita sentirse cómodo con las cosas de bajo nivel, pero principalmente para la depuración y problemas de campo. Existe una curva de aprendizaje seria que depende de la arquitectura, pero no es imposible. Por otro lado, el código de bajo nivel toma (en general) más tiempo y depuración que el código de nivel superior. Entonces, si necesita volver al nivel bajo todo el tiempo, quizás algo no esté bien en el diseño. Incluso para los controles integrados que he construido, paso la gran mayoría de tiempo en el código de alto nivel. Aunque cuando tienes problemas, es extremadamente ventajoso tener un muy buen conocimiento de bajo nivel.
Bien, me corté los dientes con el hardware cuando comencé a leer Popular Electronics a los 14 años: esto era ANTES de las computadoras personales, en caso de que te lo estuvieras preguntando y si no estuvieras bien, de todos modos lo sabes. lol
He hecho las cosas de bajo nivel de bit-bang en el microprocesador 8048/51, hice PIC y algunas otras variaciones de un solo chip y, por supuesto, Rabbit Semiconductor. (genial si te gusta C). Eso es genial (y divertido) cosas; Sí, hay una forma diferente de ver las cosas, no más difícil, pero parte de esa información es un poco más difícil de encontrar, ya que no está tan discutida como los problemas de software. (Por supuesto, esto depende del círculo de amigos con el que se asocia, eh).
Pero, después de haber dicho todo esto, quiero recordarles una tecnología que comenzó a cerrar la brecha para los programadores en el mundo del hardware y desde entonces se ha convertido en un jugador muy importante y ese es el .NET micro framework. Puede encontrar información sobre esta tecnología en lo siguiente;
http://msdn.microsoft.com/en-us/embedded/bb267253.aspx
Aborda algunos de los mismos problemas que el desarrollo web de .NET abordó en el sentido de que puede usar algunos (bastante, en realidad) de su conocimiento existente basado en PC en los nuevos entornos. Por supuesto, hay que tener precaución, ya que su máquina objetivo no tener 4 GIG de RAM - solo puede tener 64K (o menos)
A partir de la versión 2.5 de .NET micro framework, tiene acceso a redes y servicios web - way kewl, eh? No se detiene allí ... ¿Quieres controlar las luces de tu casa? ¿Qué tal una estación de grabación temporal? Todo con las habilidades que ya tienes. Bueno, en su mayoría, echa un vistazo al enlace.
El SDK se conecta a su IDE de VisualStudio. Hay una cantidad de "Kits de desarrollo" disponibles por una cantidad de dinero muy razonable. Ahora, lo que normalmente requeriría una gran curva de aprendizaje en los componentes, construir una placa de circuito y cablear "cosas" puede hacerse razonablemente fácil con un kit de desarrollo. y un código bastante simple: por supuesto, es posible que tenga que realizar la operación ocasional de bit-bit, pero cada vez más gente de sensores está proporcionando controladores de .NET micro framework, por lo que el desarrollo del hardware puede estar más cerca de lo que cree ...
Espero eso ayude...
Soy un Ingeniero de Software convertido en EE. Prefiero programar bajo nivel. La mayoría de los desarrolladores de software entrenados de forma clásica saben que no quiero operar en este nivel al que quieren que apis llamen. Entonces para mí es una victoria ganadora, creo el controlador de bajo nivel y la API para que lo usen. Hay un "nuevo" grado, al menos nuevo desde que fui a la universidad, llamado Ingeniero en Computación. Hmm, podría ser un grado en ingeniería eléctrica no informática, pero es una buena combinación de software y fundamentos de hardware digital. Las personas con las que he trabajado en este campo son mucho más cómodas con bajo nivel.
Si la persona no está cómoda o dispuesta, colóquela en un lugar donde se sienta cómodo. Déjalos hacer documentación o trabajar en la interfaz de usuario. Si todo el trabajo en la empresa requiere un trabajo de bajo nivel, entonces esta persona debe hacerlo o buscar otro trabajo. No lo recubra con azúcar.
También creo que disfrutarán una vez que superen la joroba, la libertad que tienen en ese nivel, no obstaculizada por los sistemas operativos, etc. Hace poco presencié la experiencia de algunos compañeros de trabajo viendo por primera vez la ejecución de su software en simulación. Cada red dentro del procesador y otros periféricos de chip. No, no tienes una tabla en un gui (depurador) que muestre el estado actual de la memoria, tienes que mirar el bus de memoria, buscar la dirección que te interesa, buscar una señal de lectura o escritura y el bus de datos. Me preocupa el día en que llega el silicio y ya no tienen este nivel de visibilidad. Será como un adicto en la desintoxicación.
¡Empecé como ingeniero SW ahora soy HW uno! ¡lo importante es entender cómo funciona y estar motivado!
La programación integrada de bajo nivel también tiende a incluir la depuración de bajo nivel. Lo cual (en mi experiencia) usualmente involucra (al menos) el uso de un osciloscopio. A menos que su colega se sienta feliz pasando al menos parte del tiempo en contacto físico con el hardware y pensando en términos de microsegundos y voltios, me sentiría tentado de dejarlos.
Por qué el desarrollo integrado es "difícil":
1) El contexto puede cambiar a una interrupción entre cada instrucción de la máquina. Dado que las construcciones de lenguaje de alto nivel pueden asignarse a instrucciones de ensamblaje múltiples, esto incluso podría estar dentro de una línea de código, por ejemplo, var largo = 0xAAAA5555. Si se accede a ella en una rutina de servicio de interrupción, en un procesador de 16 bits, var podría estar solo a la mitad.
2) La visibilidad en el sistema es limitada. Es posible que ni siquiera tenga salida a Hyperterm a menos que lo escriba usted mismo. Los emuladores no siempre funcionan bien o de manera consistente (aunque son mucho mejores de lo que solían ser). Deberá saber cómo usar los osciloscopios y los analizadores lógicos.
3) Las operaciones toman tiempo. Por ejemplo, supongamos que su transmisor en serie utiliza una interrupción para indicar cuándo es el momento de enviar otro byte. Puede escribir 16 bytes en un búfer de transmisión, luego borrar las interrupciones y preguntarse por qué su mensaje nunca se envía. El tiempo en general es una parte difícil de la programación integrada.
4) Estás sujeto a condiciones de carrera sutiles que ocurren muy raramente y son muy difíciles de depurar.
5) Tienes que leer el manual. Mucho. No puedes hacer que funcione engañando. A veces se deben configurar 20 cosas correctamente para obtener lo que buscas.
6) El hardware no siempre funciona o es fácil de dañar, y lleva un tiempo descubrir que lo rompiste.
7) Las reparaciones de software en sistemas integrados generalmente son muy costosas. No puedes simplemente actualizar una página web. Un retiro puede borrar cualquier ganancia que haya realizado en el dispositivo.
Probablemente haya más, pero tengo esta condición de carrera para resolver ...