¿Cómo fue trabajar en su primer proyecto de sistema integrado?

Había estado esperando esta pregunta por mucho tiempo.

TLDR: impresionante

El primer proyecto que hice en Embedded Systems fue un mini proyecto: Seminar Hall Automation.

Los componentes utilizados fueron:

  1. Sensor de infrarrojos
  2. 2 – Pantallas de segmento BCD 7
  3. 4 módulos de relé
  4. Cables de conexión
  5. LEDs
  6. Cables de conexión
  7. Raspberry Pi3
  • El sensor IR detectaría la presencia de una persona y encendería un led y el recuento aumentaría y se mostraría en los BCD.
  • El proceso anterior sería iterativo.
  • Cuando el conteo excede el múltiplo más cercano de 5, el módulo de relé se encenderá y la bombilla se encenderá.
  • Y volviendo a uno.

Esto estimula una sala de seminarios donde una fila tiene 5 personas y un ventilador. Tan pronto como la primera persona ingrese, el ventilador (representado por una bombilla) se enciende. El ventilador de la fila siguiente se enciende cuando entra la sexta persona y así sucesivamente.

Esto puede sonar un poco estúpido para ti, pero fue el primer proyecto RTOS que hice.

Al interactuar con el hardware, ver que mi código produce una salida física realmente me hizo sentir enfático.

Recuerdo que me senté allí durante una hora viendo este pequeño proyecto.

La belleza de la codificación + circuitos siempre me había cautivado.

Todavía lo hace

_____________________________________________

SIEMPRE LO HARÁ

PD:

BCD: decimal codificado en binario

LED: diodo emisor de luz

RTOS: sistema operativo en tiempo real

TL; DR: Diversión, porque ni siquiera era mi trabajo.

=== advertencia, esto va a ser muy largo. Me dejé llevar un poco ===

Era el año 1985. Trabajaba como ingeniero electrónico con una responsabilidad especial para los diseños analógicos de RF (radiofrecuencia), lo más lejos posible de la informática. La compañía para la que trabajé estaba dando sus primeros pasos en el mundo del diseño embebido, y tenía un interés natural en esto, ya que parecía ser el camino hacia el futuro. Ya usaba un C64 en casa y me había enseñado a mí mismo ensamblador a programarlo, porque muy pronto me di cuenta de que BASIC era un factor limitante severo.

De todos modos, la compañía contrató a un par de nuevos graduados nuevos cuyo trabajo sería escribir el código para los futuros productos que usarían un microcontrolador incorporado. Los productos en cuestión estaban en el campo de la seguridad física. La decisión que tomaron fue utilizar el 8051 MCU. No sabía nada sobre ese chip, ya que el C64 usaba el 6502, y eso es todo lo que sabía, aunque otro producto no diseñado internamente usaba un Z80, y también tuve un poco de exposición a eso. .

Por el bien de mi propia carrera, así como por mi interés personal, decidí que me ‘acompañaría’ tanto como pudiera para no quedarme atrás. En ese momento ya tenía unos 7 años de experiencia diseñando hardware de producción en varias formas, aunque eso era casi todos los diseños digitales analógicos o discretos. Los nuevos graduados, siendo los sabelotodos típicos con títulos pero sin experiencia en absoluto, fueron muy condescendientes. (Más tarde también descubrí que les pagaban mucho más que a mí, lo cual era difícil de tragar). Es cierto que solo conocía el ensamblador C64, que consideraban un juguete y no tenía valor. Pero su actitud despectiva al hacer preguntas sobre la codificación del 8051 (que sin duda eran ingenuas, como era de esperar cuando eres nuevo en un tema) solo sirvió para hacerme más decidido a aprenderlo.

Así que estudié en casa, y me quedaba hasta tarde en la noche para usar el sistema de desarrollo que permitía escribir, ensamblar y probar el código en el circuito. En esto, fui apoyado por mi jefe inmediato que alentó cualquier cosa que aumentara el arsenal de un ingeniero, y otro ingeniero en una oficina diferente que había escrito un sistema anterior basado en la CPU 6800. (La compañía tenía una estructura complicada en ese momento, ya que acabábamos de fusionarnos con otra compañía, por lo que había una mezcla de productos que usaban diferentes tecnologías y entraron un grupo de ingenieros de la otra compañía). Fue este otro ingeniero el que me enseñó todo sobre las trampas del código de interrupción que necesita un mutex con código ‘normal’ para garantizar la integridad de los datos que se pasan entre ellos. En aquellos días teníamos que codificar esos mutexes nosotros mismos: no había soporte dentro del chip o del lenguaje en sí. Otra cosa que me mostró fue un buen truco para implementar una gran declaración de tipo de interruptor / caso en el ensamblador (no conocía C en ese momento, por lo que no lo habría reconocido así). Había una tabla de salto de direcciones de rutina, y una función de selector usaría el índice de función para empujar la entrada de la tabla a la pila, luego realizaría un ‘RTS’, que arrastraría esa dirección a la PC y, por lo tanto, saltaría a la dirección. Esto funcionó alrededor del 8051 al no tener forma de mover directamente un valor a la PC.

Capítulo 1: La Odisea y la Ilíada

Tenía dos proyectos no oficiales sobre la marcha en los que decidí que usaría el 8051. Uno era una alarma de automóvil, con un reloj digital / pantalla de estado y un teclado, y el otro era un amplificador / receptor de alta fidelidad controlado digitalmente, También con una pantalla para frecuencia sintonizada y muchas otras cosas. Ambos proyectos me interesaron personalmente y eran directamente análogos a los tipos de productos en los que la compañía estaba involucrada en la producción, por lo que todo lo que aprendí sobre ellos sería directamente transferible. (nota de la barra lateral: los proyectos personales no oficiales se conocían como ‘jonrones’, es decir, proyectos domésticos. El nombre en clave del amplificador era Odyssey y la alarma del automóvil era Iliad. Homer, geddit?)

Así que rápidamente descubrí cómo configurar el 8051 y ejecutar el código, estableciendo interrupciones para escanear el teclado, devolviendo el código clave (con mutex) al código principal, controlando la pantalla y, en el caso del receptor, cómo maneje un sintetizador de frecuencia con un código binario para establecer la frecuencia sintonizada, y a partir de eso calcule el valor decimal sintonizado equivalente para mostrar en la pantalla. ¡Ese código de conversión ocupó la mitad del programa almacenado! (Mirando hacia atrás, es probable que haya una solución mucho más eficiente allí, pero en ese momento fue lo mejor que pude hacer, al menos funcionó. Pero tenga en cuenta otra limitación del 8051: no hay instrucciones de multiplicar o dividir).

Hubo beneficios secundarios de esto, así como aprender a codificar el 8051: mezclar una CPU ruidosa con un sistema de alta fidelidad me enseñó mucho sobre cómo garantizar que el ruido digital no se filtre en las cosas analógicas, por ejemplo, o cómo hacer un microcontrolador no falla cuando funciona con el sistema eléctrico de un automóvil, incluso mientras arranca el motor.

De todos modos, todo eso fue divertido, y tenía dos proyectos de trabajo que mostrar por mis esfuerzos, y sentí que había comenzado a entender el 8051 razonablemente bien. Mientras tanto, los graduados no habían producido una sola cosa que hiciera otra cosa que ejecutar funciones de prueba ultra simples. Esto fue casi 2 años después. Se quejaban constantemente del sistema de desarrollo y de tener que codificar en ensamblador; querían obtener un compilador de C para él, que estaba disponible, pero era una opción extremadamente costosa para ese sistema en ese momento. Los jefes lo criticaron, ya que ya habían gastado decenas de miles en el sistema y no tenían nada que mostrar, aunque estaban al tanto de mis proyectos no oficiales, no eran secretos, y eso demostraba claramente que el sistema de desarrollo era útil. como lo fue para hacer cosas de trabajo.

Debido a que los graduados siempre estaban hablando de C, y cuando comencé a aprender a programar el Mac (en BASIC, como otro jonrón), un día me pregunté en voz alta si debía aprender C. No estaba satisfecho. con BASIC en Mac, al igual que con el C64 anterior, era muy limitante. Era C o Pascal. En su habitual forma condescendiente, dijeron que C sería “demasiado difícil” para que mi pequeño cerebro esponjoso lo entendiera, así que debería seguir con BASIC. Así las cosas, terminé yendo por Pascal en ese momento, lo cual fue una buena opción para el Mac de 1987, aunque finalmente fue un callejón sin salida. No me gustaba ser patrocinado de esa manera, pero no había mucho que pudiera hacer al respecto: tenían su trabajo y yo el mío, y había una clara demarcación entre ellos, oficialmente. Pero, como siempre, no me senté y me molesté, solo construí cosas. Supongo que pensé que al final, los hechos valen más que mil palabras, y hacer que las cosas reales y de trabajo siempre hablen más fuerte. No me daba cuenta del hecho de que debían sentirse amenazados por esto, de que un ‘simple’ ingeniero de RF podría dominar 8051 y Pascal en unos pocos meses y realmente usarlo para hacer cosas, mientras que simplemente hablaban y aparentemente lo encontraban demasiado difícil. .

Capítulo 2: Coulda debería haber sido.

En el ’87, nos embarcamos en un diseño completamente nuevo para un sistema de seguridad inalámbrico. Este sería el primer proyecto combinado para las empresas fusionadas, y estaba destinado a ser de vanguardia. El concepto era utilizar pequeños módulos de transmisor de radio para cada sensor en el sistema: contactos de puertas y ventanas, sensores infrarrojos pasivos, detectores de rotura de ventanas, teclados remotos, etc., y un receptor basado en microcontrolador. El sistema presentaba muchos desafíos: garantizar una vida útil de la batería extremadamente larga en los sensores, garantizar la integridad de los datos, la manipulación y la resistencia a los atascos, así como un panel de control mucho más fácil de usar en el receptor. Fui el desarrollador principal de este proyecto y, como tal, responsable de gran parte del diseño básico, incluidos todos los protocolos de transmisión utilizados entre los sensores y el receptor. El receptor usaría un MCU 8051, pero la tarea de codificarlo se delegó a los graduados. Ese era su trabajo después de todo.

Desarrollé un prototipo de transmisor utilizando lógica CMOS discreta, que requería entre 60 y 80 chips. La idea era que una vez que resolviéramos los problemas, transferiríamos ese diseño a un IC personalizado que se usaría en cada transmisor diferente. (Por razones de costo, el mismo chip tenía que usarse en cada variante TX, por lo que tenía bastante versatilidad incorporada). Mientras trabajaba en eso, se les pidió a los graduados que desarrollaran software para recibir el protocolo de transmisión y decodificarlo. En primera instancia, el código se usaría para controlar una pantalla de estado en un receptor de prueba, para que pudiéramos ver lo que se estaba recibiendo.

Terminé el hardware de mi transmisor y lo arreglé todo para transmitir códigos de prueba. Le había demostrado esto a varios jefes y hasta ahora estaban impresionados: uno de los logros clave fue reducir el tiempo de transmisión de un solo mensaje a algo muy breve, mientras transmitía muchos más bits (necesarios para la corrección de errores y tener un rango ampliado de direcciones del sistema). Un sistema de radio anterior (no desarrollado por mí) transmitió solo 11 bits de información, ¡y cada mensaje tardó 2 segundos en transmitirse! La razón de esto fue que utilizó la activación y desactivación de la codificación con una codificación NRZ, por lo que la velocidad de datos tenía que ser muy lenta para evitar interferencias de radio. Fue un diseño extremadamente tonto, y una gran razón por la que tuvimos que idear algo mucho mejor. Mi diseño envió alrededor de 204 bits de datos con corrección de errores en 170 ms utilizando la modulación GPSK de una subportadora que luego se transmitió mediante FM. Hizo una buena demostración para configurar el sistema antiguo y el nuevo lado a lado con la alimentación de datos a un altavoz. Cuando se activan juntos, el mío “chirria” y el otro “blip-blip-blip-blip-blip” … durante 2 segundos. Era fácil demostrar que cuando se golpeaban varios transmisores juntos o en una sucesión rápida, un escenario bastante realista, era mucho más probable que el chirrido pasara que los blips, dado que todos los blips se transmitían ciegamente uno encima del otro. ; Un sistema de autointerferencia.

De todos modos, los jefes necesitaban ver el sistema funcionando como un todo, porque todos sabían que esos chirridos eran solo un ruido. Necesitaba demostrar que el chirp podía decodificarse de manera confiable incluso cuando la señal se deterioraba o se interfería, o si se activaban dos transmisores a la vez. Aún quedaban muchos problemas por resolver. La presión estaba en los graduados para que algo funcionara. Día tras día no lo lograron. Las excusas abundaban. La falta de un compilador de C era una que seguía apareciendo. Finalmente, los jefes cedieron y les compraron el maldito compilador de C. Ahora tenían la excusa de que era nuevo para ellos y tenían que descubrir cómo usarlo, y comenzaron a reescribir las cosas en C. Me estaba frustrando mucho: el proyecto se estaba estancando debido a su incapacidad para hacer cosas.

Entonces hice lo que tenía que hacer. No era para probar un punto, era solo para que pudiera progresar en el proyecto. Teníamos un prototipo de hardware que tenía una pantalla de 2 líneas y un controlador 8051, y tenía un receptor de radio y un demodulador GPSK en hardware que demodulaba los bits de datos sin procesar y los alimentaba al 8051. Estaba todo allí, aparte del software. Por las noches, cuando los graduados se iban a casa y dejaban solo el sistema de desarrollo, escribí mi propio decodificador y controlador de pantalla. No tenía que ser de calidad final, solo tenía que funcionar para poder hacer una demostración del sistema y comenzar a analizarlo. Lo tuve trabajando en dos o tres noches. Creo que la primera vez que los graduados se dieron cuenta de que algo estaba pasando fue cuando dejé de molestarlos para que me dieran algo. Luego notaron que tenía una placa receptora que funcionaba y estaba probando cosas como tasas de error, resolución de conflictos y otras cosas. Uno de ellos me preguntó qué código estaba usando, y solo dije que lo había escrito después del trabajo para poder continuar. Realmente no me importaba si eso era vergonzoso para ellos, realmente se les había dado cada oportunidad.

Resultó que mi decodificador rápidamente amarrado no necesitó mucha revisión: funcionó bastante bien y cumplió con todas las especificaciones sin demasiados ajustes. También entregó sus datos decodificados de una manera muy limpia (una pequeña cola de registros de transmisores recibidos) que estaba completamente separada del código del controlador de pantalla. Entonces, después de mostrarlo a los jefes y presentar los resultados, me preguntaron cuál era el siguiente paso. Fui completamente honesto con ellos y dije que el decodificador del receptor era algo que había atacado como aficionado en mi propio tiempo, y que los graduados seguramente tendrían algo mejor “muy pronto”. Dios sabe por qué incluso intenté cubrir sus traseros: ¿conciencia culpable? Los jefes preguntaron qué harían los suyos que los míos no harían, dado que los míos cumplían con las especificaciones, y realmente no tenían una respuesta. Creo que hubo algunos murmullos acerca de que no estaba en C, por lo que sería más difícil de mantener, lo cual fue un punto justo, pero en 1987 esas cosas no fueron un problema tan grande y todas estas cosas de codificación todavía eran bastante nuevas para la compañía de todos modos. Entonces se les dijo que usaran mi código tal como estaba y que siguieran escribiendo las cosas de nivel superior que impulsaban la pantalla del usuario, etc.

Tal vez se sintieron aliviados de que el viejo y retorcido decodificador ya no estuviera en su plato, pero también estaban bastante molestos por haberlos tropezado y avergonzado. Si bien esa nunca fue mi intención, fue muy satisfactoria. Me gusta pensar que cuando realmente vieron el código que había escrito, el hecho de que usaba interrupciones con mutex adecuados, usaba tablas de salto ordenadas, se mantenía muy bien separado y les presentaba los datos en una forma directamente utilizable. seguramente me habría dado cuenta de que mis habilidades no debían subestimarse, como siempre lo habían hecho. Sin embargo, eso es probablemente una ilusión ya que nunca lo mencionaron; Es la manera británica.

Luego diseñé el chip real para el transmisor y una especie de ‘GUI’ para el receptor, del cual escribí una simulación en la Mac (en BASIC, no había llegado al Pascal para entonces) para mostrar cómo funcionaría y se vería. Todavía tengo una copia del código fuente para todos estos proyectos.

Captura de pantalla, impresa en papel, del simulador. Lo real no habría sido pixelly como este, pero en ese momento fue lo mejor que pude simular. El panel de la izquierda habría sido una pantalla LCD personalizada con todos estos símbolos prediseñados. En uso, no los verías todos encendidos a la vez de esa manera.

Mirando hacia atrás, ese período fue probablemente uno de los períodos más intensos de aprendizaje por los que pasé, igualado solo por mi posterior adopción de C y C ++. También fue cuando me expuse a la codificación del mundo real por primera vez, y resultó que era bastante bueno en eso. Ciertamente podría entregar, que al final es lo que le importa a un empleador que paga. Desafortunadamente, esa compañía nunca apreció realmente mis habilidades, aunque ciertas personas y mi jefe inmediato lo hicieron. Ese proyecto finalmente se canceló por razones que hasta el día de hoy son difíciles de entender: funcionó bien, cumplió con sus especificaciones y limitaciones presupuestarias, se completó en un 95% para el momento en que se desconectó el tapón (incluidas las molduras personalizadas, la producción personalizada TX IC) y se adelantó a su tiempo; Todavía creo que hubiera sido un ganador en el mercado. Años más tarde vi algo similar publicado por un competidor, pero no fue tan bueno. El motivo fue la política de la empresa posterior a la fusión en lugar de los problemas técnicos. Después de tanto trabajo, mi jefe inmediato y yo estábamos devastados por la decisión, y ambos nos fuimos en 1989. Pero todas las habilidades que había adquirido fueron útiles de muchas maneras en los años siguientes.

Gracias por leer. ¡Dudo que muchos hayan llegado tan lejos!

Fue lo más divertido que he tenido.

Era un sistema de automatización bancaria. Lo comenzamos con el procesador 8008, pero antes de construir un prototipo, Intel presentó el 8080. Nos entregaron numerosas muestras gratuitas, cada una de las cuales costaría un mes de mi salario en ese momento, y enviaron un par de ingenieros de aplicaciones de campo para sostener nuestra mano. Nos enseñaron todo lo que necesitábamos saber sobre la arquitectura y el lenguaje ensamblador.

El hardware consistía en un par de pies cuadrados de placa de circuito, con una fila de 1702 EPROM, las primeras EPROM, con una capacidad de solo 256 bytes cada una, y ocho chips 2102 que daban un total de 1k RAM.

El desarrollo del software se realizó mediante la creación de una cinta de papel con el código fuente del lenguaje ensamblador en un Teletipo, una impresora mecánica de 10 caracteres por segundo. Luego, el ensamblador se cargó en el sistema de desarrollo a través del lector de cinta en el teletipo, que tomó aproximadamente 20 minutos, y el programa se ensambló pasando su cinta de papel a través del lector de cinta, dos veces, para un ensamblador de 2 pasadas. Finalmente, el código de máquina ensamblado se envió al punzón de Teletype en formato Intel Hex. La cinta resultante podría enviarse para tener EPROM programadas. Tomó un par de días escribir y probar el cambio de programa más simple. No pasó mucho tiempo antes de adquirir un lector de cinta de alta velocidad y nuestro propio programador de EPROM, pero aún trabajamos con esa configuración primitiva durante un año o dos antes de utilizar un sistema con disquetes y un terminal de video.

Entonces, uno de los Intel FAE apareció con un disquete en su maletín. Era el juego de Star Trek, para ejecutar en nuestro sistema de desarrollo. De repente, se nos reveló el verdadero propósito de las computadoras.

Escribiré sobre mi primer proyecto real. Era un simulador de RADAR para un nuevo RADAR de avión de combate.

Era un sistema DSP de cuatro 500 MHz, con capacidades de generación de señal RADAR simulada en tiempo real para reflexiones de hasta 20 objetivos voladores, junto con reflexiones y ruidos no deseados, en diferentes modos RADAR. En resumen, un simulador para RADAR multimodo (MMR).

¿Cómo fue la experiencia de trabajar en ello?

  • Fue difícil, a veces ni siquiera sabía qué preguntas debería hacer,
  • Fue un desafío: tuve que respaldar cualquier reclamo que hice con datos,
  • Necesitaba todo mi conocimiento y más allá: requería aprender profundamente sobre arquitecturas de procesador, hardware, diseño de sistemas multiprocesador más allá de lo que esperaba,
  • Fue humillante: me di cuenta de que realmente no sé mucho sobre los sistemas del mundo real y el esfuerzo necesario para hacer que las cosas sean estables y confiables,
  • Exigía comprender los aspectos de firmware de las cosas, el hardware y el software de alto nivel, así como conocimientos generales,
  • Cubrió temas como: programación en lenguaje ensamblador y C, sincronización de tareas entre diferentes procesadores, uso de la pila de protocolos de comunicación, almacenamiento de datos, desarrollo de software basado en PC, procesamiento de señales y mucho más.

Éramos 4 en el equipo: 2 hardware (diseño esquemático y PCB), 1 tipo FPGA y yo en el desarrollo de firmware y software de PC incorporado.

Estaba bastante acostumbrado a proporcionar soporte y ayuda a los desarrolladores en mi trabajo como ingeniero de soporte técnico para Cypress Semiconductors. Ahora tenía que usar todas mis habilidades para aprender a encontrar la información que necesitaba para hacer lo que quería, pedir ayuda, y este proyecto estaba ampliando mis habilidades casi a diario.

Masivo esfuerzo de más de 2 años. Extremadamente satisfactorio.

A veces pienso en esos días y recuerdo a Shakespeare que dijo: “¡Cómo se burlan mis logros!”

Mi primer proyecto incrustado implicó no depurar, sino más bien depurar. El siguiente requería un tipo inusual de depuración aunque el sistema funcionaba perfectamente.

Llegué a la ingeniería como aficionado a la electrónica, construyendo Heathkits y fuzzboxes caseros para mi guitarra eléctrica. Después de graduarme de la universidad con un título de psicología inútil, conseguí un trabajo como ensamblador / cableado electrónico en equipos de comunicaciones para aviones de combate, y finalmente construí prototipos. Cuando me negaron un aumento, me transfirieron a un trabajo como técnico de prueba. Este fue un trabajo bastante aburrido, así que en los momentos de inactividad comencé a enseñarme lógica digital, molestando a los ingenieros con preguntas incesantes.

Cuando me inscribí en un programa de posgrado en psicología experimental, obtuve un puesto como técnico para los laboratorios de psicología humana y animal de la universidad. Supongo que podrías llamar a ese trabajo en el laboratorio de animales mi primer sistema incrustado.

En ese momento, si desea, por ejemplo, enseñarle a una rata a presionar un interruptor cuando se enciende una luz, y entregar un gránulo de comida cada cinco pulsaciones del interruptor, y contar el número de pulsaciones correctas e incorrectas del interruptor, conectaría el luz, el interruptor y el alimentador a una colección de puertas lógicas OR y AND, relés paso a paso (un divisor primitivo) y contadores. Estos artículos se montaron en piezas rectangulares de plástico que se engancharon a +28 voltios y barras de tierra, que a su vez se montaron en bastidores de equipos de 7 pies de altura. Interconectaría los módulos utilizando cables de conexión con enchufes banana en cada extremo.

¿Ves ese estante en el fondo detrás de BF Skinner? Algo como eso.

Mi trabajo consistía en descubrir cómo implementar esta presentación de estímulo, refuerzo intermitente y conteo de respuestas. El diseño lógico para algunos experimentos se volvió sofisticado, por lo que tuve que diseñar diagramas elaborados para hacer un seguimiento de qué cable de conexión iba a dónde. A menudo había docenas de cables de conexión para una sola caja Skinner.

Después de probar el aparato para verificar que funcionó según lo especificado, se lo entregaría al experimentador (y a sus ratas, palomas o pollos). Pero ocasionalmente recibía una llamada telefónica frenética rogándome que viniera a reparar un aparato que había dejado de funcionar. Por supuesto, primero busqué cables de conexión que se habían soltado. ¡Resultó que había ratas escapadas corriendo por el laboratorio, y que habían roído varios cables de conexión y los sacaron de sus enchufes! Esos diagramas me ahorraron una enorme cantidad de tiempo y me llevaron a casa sobre la importancia de documentar mi trabajo para poder reconstruirlo o modificarlo más tarde.

Fue mucho más fácil construir aparatos para el laboratorio de psicología humana. Las ratas allí no podían alcanzar los cables. Sin embargo, un incidente allí fue especialmente memorable. Una de las candidatas al doctorado estaba tratando de medir si su sujeto experimental podría volverse insensible a imágenes impactantes. Con ese fin, ella había obtenido fotos de la escena del crimen de la policía. Eran realmente, realmente inquietantes. Programé la lógica del controlador para controlar un proyector de diapositivas, que mostraría las imágenes durante un tiempo fijo con intervalos fijos entre diapositivas, mientras que el sujeto se sentaría en un sillón mirando las imágenes y conectado a electrodos galvánicos de resistencia de la piel y una grabadora de chat. El estudiante graduado se quejaba de que la grabadora se estaba volviendo loca incluso cuando no se mostraba ninguna diapositiva. Verifiqué que el equipo funcionaba correctamente y que sin nadie conectado a los electrodos, el registrador de gráficos estaba en silencio. Decidí sentarme en una sesión para ver qué estaba pasando. Efectivamente, el GSR del primer sujeto se volvió loco incluso antes de que se proyectara la primera diapositiva horrible.

Encendí las luces de la habitación y vimos las cucarachas que se arrastraban por su brazo.

Para resumir en una palabra: doloroso


Estaba construyendo un abrepuertas inalámbrico. Imagine que, en lugar de levantarse cada vez que alguien toca el timbre, podría presionar un botón en el Módulo A (por usted) que enviaría una señal al Módulo B (por el interruptor de la puerta), que luego pasaría por alto el módulo de seguridad Zumbido abre la puerta, dejando que la persona.

Tan vago, cierto.

Decidí ir con ambos módulos que se comunican a través de Bluetooth Low Energy (BLE). Después de analizar los diagramas de productos y conectar un osciloscopio, descubrí que el módulo de seguridad abrió la puerta con un zumbido enviando una señal de voltaje a través de un cable determinado.

Todo lo que tenía que hacer era …

  1. Enviar una señal de A a B a través de BLE
  2. Haga que B envíe la señal de voltaje a través del cable en lugar del módulo de seguridad

Simple derecho? Eso es lo que yo también pensaba …


Disparar la señal de voltaje del Módulo B fue bastante sencillo. Solo tuve que encender un pin GPIO momentáneamente y conectarlo al cable original.

Configurar la comunicación BLE estaba lejos de ser sencillo. Como mi primer proyecto incrustado, prácticamente no tenía experiencia en desarrollo de bajo nivel, y mucho menos protocolos de comunicación.

Ni siquiera sabía lo que no entendía.

Pasé aproximadamente un mes en llamadas telefónicas con varios ingenieros y buscando en varias guías en línea. Olvidé desarrollar mi propia aplicación, ¡tardé 2 semanas en ejecutar la muestra proporcionada!

Afortunadamente, mi aplicación era ~ bastante simple ~ donde podía modificar la muestra y desechar algo juntos. No era bonito, pero sorprendentemente de alguna manera hizo el trabajo.


Lección aprendida: no saltes al fondo de la piscina esperando pararte

En una palabra: cautivador.

Tuve la suerte de trabajar en un grupo de sistemas embebidos basados ​​en Motorola 6805 y 68HC11 desde principios hasta mediados de los 90, mientras estaba en la universidad a tiempo parcial.

Este primer proyecto completo fue para un sistema de reabastecimiento químico para nuestra empresa matriz, Filmlab Engineering, máquinas de procesamiento de película de 35 mm, y me refiero a las cosas realmente grandes, 10 pies de ancho, 70 pies de largo, 15 pies de alto en los extremos, algunos operando a cientos de pies por minuto.

Era esencialmente un diseño nuevo, pero replicaba un diseño anterior, porque mi jefe había perdido de alguna manera el código fuente y también se necesitaban actualizaciones para el PCB. Pensó que era una buena oportunidad para poner a prueba mis habilidades de diseño de PCB y luego escribir el nuevo firmware yo mismo, todo basado en la funcionalidad que se había establecido con la versión original del sistema.

Tener el antiguo diseño esquemático y la PCB disponibles fue un gran conjunto de ‘ruedas de entrenamiento’ para demostrarme lo que tenía que hacer, al tiempo que me daba la libertad de actualizar componentes, usar relés más baratos y mejores interruptores en el panel frontal, etc. Probablemente necesitó siempre para completarlo. Recuerdo que estaba totalmente paranoico por cometer un error. En aquellos días, obtener algunos prototipos de PCBs podría costar fácilmente casi $ 1000, nada de lo barato que es hoy.

Para mi gran alivio (y para ser justos, con mucha supervisión por parte de mi jefe), el PCB funcionó por primera vez, ¡no se necesitan modificaciones! Pero eso fue solo con un código de ensamblaje muy básico para ejercer cada función de E / S. Ahora comenzó la diversión, escribir el código para la aplicación real de reabastecimiento químico.

En 6805 Asamblea.

Había hecho un poco de codificación en C en la universidad en esa etapa, pero en ese momento no había un compilador de C disponible para ello o era demasiado caro.

Esto fue cuando entendí por primera vez el concepto de un ‘súper bucle’: ese nivel superior “¿Qué tengo que hacer ahora?” Del firmware, en este caso se ejecutó cuando un temporizador pasó un incremento establecido: escanee el teclado, actualizar el estado de encendido / apagado del LED, verificar los tiempos de espera de encendido / apagado de la bomba, etc.

También tuve que hacer un bit-bang a un periférico I2C, un pequeño NOVRAM / EEPROM que almacenaba las tasas de reaprovisionamiento programadas por los operadores humanos, porque el 6805 no tenía EEPROM / Flash en el chip, ¡ni siquiera un periférico I2C! Al principio me horrorizó tener que hacer tanto trabajo para algo tan básico, pero simplemente lo desglosas, sigues el protocolo y el diagrama de tiempo en la hoja de datos de la EEPROM, y finalmente funciona correctamente.

Este sistema tenía 3 modos de operación:

  • Automático, operando cualquiera de los 8 programas de tasa de reaprovisionamiento preprogramados;
  • Manual, donde el operador de la máquina podría seleccionar la tasa de reposición para cada bomba sobre la marcha;
  • Modo de programación, donde el operador puede ingresar la tasa de reabastecimiento para cada bomba, para cada uno de los 8 ‘programas’.

Seleccionó qué modo con un interruptor de llave real de 3 posiciones. Se sintió como algo que había visto en la icónica película War Games de principios de los 80 , donde primero tuvieron que girar las llaves para lanzar las armas nucleares, ¡qué genial fue eso!

Un día en el ciclo normal crash-n-burn (edite su código, ejecute el ensamblador y el enlazador en él, grábelo en una EPROM recién borrada de ultravioleta, póngalo con cuidado en el zócalo IC, encienda, pruebe), ¡Tuve una situación extraña en la que parecía que el sistema funcionaba en los 3 modos simultáneamente! En ese punto de mi carrera, probablemente fue lo más extraño que había visto en mi vida, y no tenía ni idea de lo que había hecho mal. Cuando comencé a depurar el problema, comencé a apreciar cómo el flujo del programa podría distorsionarse y, sin embargo, aparentemente “funcionar”, al menos hasta cierto punto.

No recuerdo cuál fue el error de codificación, pero probablemente me llevó toda la tarde solucionarlo. Ni siquiera teníamos un puerto serie para enviar ‘declaraciones de depuración’ en ese entonces, todo lo que podía hacer era usar un GPIO de repuesto para señalar ciertas cosas. Recuerde, cada ciclo crash-n-burn podría tomar 10 minutos, no como hoy, donde puede volver a compilar y actualizar el nuevo código en cuestión de segundos. Tampoco teníamos un emulador en circuito para este MCU; eso habría arreglado las cosas mucho más rápido. No fue hasta que comencé a trabajar con el 68HC11 que aprendí las alegrías de un emulador en circuito (que hoy ha sido reemplazado en gran medida por JTAG y una aplicación de depuración).

Al final de este proyecto, sabía lo que quería hacer por el resto de mi vida. Aunque no resultó de esa manera, tomé un desvío de 11 años en una carrera / industria diferente por un tiempo, pero ahora vuelvo a los sistemas integrados, y ‘cerdo en la mierda’ no comienza a describir cómo muy divertido todavía es 😀

Mucha diversión

En 1999, Motorola me contrató para desarrollar una interfaz de usuario para teléfonos móviles. Tuvimos algunos dibujos conceptuales de diseñadores en Libertyville IL, una especificación de hardware aproximada (diseños de botones, tamaño de pantalla, etc.) y un equipo de cinco ingenieros en Plantation FL. Tomamos eso y especificamos una API de servicios para que los desarrolladores de aplicaciones comiencen a usar. Después de dos años de trabajo constante, lanzamos nuestro primer producto: el teléfono celular V60.

Pequeña pantalla en blanco y negro, pero tremendo espacio para expandirse. Se agregó una pantalla a color más grande, se intercambiaron las posiciones clave de envío y finalización y se eliminó el botón del menú central. Aquí está mi diálogo de lista en un RAZR con 2 teclas programables.

Se mantuvo ocupado adaptando el software para diferentes mercados. Entrada de Hiragana a Kanji para Japón, texto de derecha a izquierda para Israel, efectos especiales para fotos, etc. La competencia no salió con un producto claramente superior hasta el iPhone 1 en 2007.

El primer proyecto de sistema integrado en el que trabajé se realizó durante un taller en nuestro clg y fue seguidor de línea, usando atmel uc (como hacen la mayoría de los ingenieros aquí: p). Cada pieza de código que hizo que algo funcionara dio una felicidad inexplicable. Algo tipo de magia. Me hizo explorar aún más los sensores IR y los motores. Estaba realmente feliz de haber podido jugar bien con la UC. Al final, nuestro equipo obtuvo el premio al mejor intérprete. Me dio la chispa y me hizo darme cuenta de que esta será mi pasión aquí después.

Esa pasión me llevó a asistir a hackatones nacionales e internacionales, concursos de proyectos, reuniones técnicas y muchos más. Después de cuatro años de experiencia técnica en la universidad, finalmente obtuve una oferta del trabajo de mis sueños en una empresa OEM de productos electrónicos.

El diseño y desarrollo de sistemas integrados es un océano con mucho que aprender y desarrollar. Parece magia al principio. Una vez que se sincroniza con él, ahí va, la forma en que el mundo comienza a cambiar.