Construyendo OBD Fast Pressure: aquí está el ICE

Soy un codificador de software desagradable cuando se trata de eso. No presté atención cuando todo estaba dirigido a un objetivo y mis raíces siempre fueron el lenguaje ensamblador y los sistemas operativos en tiempo real (RTOS) de todos modos.

Así que es natural que recurra a un emulador de circuito real (ICE) para terminar mi pequeño bus OBDII para acelerar un generador de pulsos. ICE es un hardware que se utiliza para depurar sistemas integrados. Se comunica con el microcontrolador en su placa, lo que le permite ver lo que está sucediendo al pausar la ejecución e inspeccionar o cambiar valores en los registros del dispositivo. Si desea ser excelente en el desarrollo integrado, debe usar la emulación en circuito excelente.

No solo veo mis errores casi en tiempo real, también hago un video al respecto.

Obtener datos del vehículo

Estaba trabajando en una pequeña placa que se deslizará en mi automóvil y dará acceso directo a una velocidad informada en la Red de área regulada (bus CAN).

Para respaldarlo un poco, mi última publicación de video fue sobre mi inepto deseo de hacer un montaje pequeño que pudiera deslizarse en el puerto OBDII de mi camión y crear una serie de pulsos que representan la velocidad del vehículo para hacer que mi GPS funcione con mucha más precisión. Mientras un cable estaba enterrado profundamente en los muchos haces de cables conectados al módulo de control del motor del vehículo, decidí por muchas razones crear mi propia fuente de señal.

En el centro de mi proyecto está la necesidad de convertir el puerto OBDII y el protocolo CAN subyacente en una variable simple que represente la velocidad, y luego ocultar ese valor al flujo de pulsos, donde la frecuencia varía con la velocidad. El protocolo OBDII / CAN es manejado por el chip STN1110 y convertido a ASCII, y yo uso ATmega328 como se encuentra en un montón de placas Arduino'ish para la conversión de ASCII a pulsos. Utilizo interrupciones de dispositivo para controlar la salida de señal de forma sólida como una roca, sin tiempo de estrés.

Siga el proceso de uso de un emulador en circuito en el video a continuación y únase a mí después del descanso para obtener más detalles sobre el proceso.

El hardware

He estado revisando la placa desde el último video y eliminé el soporte para varios protocolos excepto CAN, que es el protocolo desactualizado del grupo. Al quitar un conjunto de piezas, pude cambiar el estilo de empaque a un perforador, que es más fácil para muchos aficionados domésticos, por lo que puede dejar la soldadura en el refrigerador.

Rvdo. 2

Rvdo. 1

El "otro conector" de su Arduino

A diferencia del Arduino, que está listo para hablar con su puerto USB cuando lo saca de la caja, los chips ATmega llegan sin ningún conocimiento de cómo descargar el código, en otras palabras, no tiene un gestor de arranque. En consecuencia, tengo los pines de programación en serie en circuito (ICSP) apuntando a un encabezado de pines en mi placa para poder programar la pieza directamente.

En este conector encontrarás la línea Reset, lo que significa que con este título puedo usar true ICE usando el protocolo debugWIRE. Dado que la gran mayoría de los diseños que usan un chip AVR no reutilizan el pin de reinicio para GPIO, es un pin perfecto para usar ICE. Todas las comunicaciones durante el proceso de depuración se llevarán a cabo en el pin de reinicio.

Entra el ICE

Cuando proyecta una computadora desde cero, siempre existe el escenario en el que nada funciona todavía. En pocas palabras, un circuito de microprocesador no puede funcionar hasta que casi todas las partes del diseño funcionen; La RAM, la ROM y los buses subyacentes deben funcionar (principalmente) antes de que se hagan cosas simples. Como ingeniero de hardware de profesión, siempre me gustaría que ICE pusiera en marcha la implementación; solo después del lanzamiento Beta, el ICE comenzaría a acumular polvo en la esquina.

En el caso del ATmega, las capacidades de purificación están incorporadas en el propio microcontrolador. Esta es una implementación mucho más simple que en los primeros días cuando teníamos que tener un segundo procesador aislado que se agotaba con su propia RAM / ROM local.

Una nota que se menciona en el video es que una placa Arduino'ish estándar necesita quitar los condensadores de filtro de la línea RESET para permitir los datos de alta velocidad en la línea para su uso de debugWIRE.

El ICE que uso aquí es el fabricado por Atmel, y compatible con Atmel Studio, también hay otros modelos disponibles como el AVR Dragon.

Hielo

El ICE nos permite descargar y una vez pasar nuestro código mientras podemos observar y reemplazar la RAM y los Registros de E / S del teclado. Podemos ver el programa paso a paso o mirar debajo del código ensamblador real generado por el compilador. Podemos ver variables y ubicaciones directamente en la RAM o ver equivalentes en el mismo idioma. También es posible omitir una llamada de subrutina en el caso de solo querer ver el resultado sin todo el procesamiento.

Vale la pena dedicar su tiempo a ver siquiera un vistazo de las capacidades de ICE en acción. Te recomiendo que veas el video donde comienza la depuración.

Ultimas palabras

Este video trataba sobre terminar el circuito OBDII, así que realmente no tuve tiempo para analizar todo lo que ICE puede hacer, tal vez haga una publicación dedicada solo al ICE y al entorno de desarrollo la próxima vez.

  • Miroslav dice:

    No estas solo. A veces pienso que la programación OO fue inventada por profesionales de la programación solo para confundir a la gente y crear arte oscuro a partir de un tema a priori bastante fácil 🙂 Yo, por mi parte, me quedaré con la programación procedimental (?) De la vieja escuela, hasta el amargo final. GOSUB o muerte 🙂

    • Nathan dice:

      Curiosamente, me entrevistaron la semana pasada para un firmware, y me hicieron preguntas objetivas que me sentí incapaz fuera del campo izquierdo ... Sé que OO C ++ funciona para sistemas integrados, pero nunca he tenido una gran razón para utilizar muchos de ellos los conceptos fuera de las razones organizativas.

      • Nathan dice:

        Salir del campo izquierdo *

      • Miroslav dice:

        Hago muchos sistemas de control simples. Ni una sola vez he usado o sentido la necesidad de PO. Yo uso / he usado arado, Arduino C, Python, C y BASIC.

        • wren6991 dice:

          "Un buen programador puede escribir un ensamblado en cualquier lenguaje";)

          • ESTOLA dice:

            INC (: ME GUSTA)

      • Caballero oscuro 512 dice:

        Ciertamente, no hay nada malo en aplicar conceptos de OO al software integrado, en un sistema con memoria limitada, debe preocuparse por asignar demasiada memoria dinámicamente, pero se encontraría con el mismo problema si solo asignara memoria en C de todos modos. Es bueno poder crear 2 ejemplos de clases para verificar dos ADC idénticos. Mucho más limpio, luego crea un conjunto completo de variables y las pasa manualmente por referencia.

        Recientemente creé un proyecto con un prefijo de aplicación muy OO escrito en C ++ con firmware basado en Qt y C para MCU, por lo que a veces escribo firmware en C de todos modos. Al final del proyecto, sentí que C ++ tendría más sentido sobre el firmware.

        • tekkieneet dice:

          ¿Qué tiene de malo usar una matriz para la estructura de datos? Todos los casos se pueden tratar mediante un índice y se combinan maravillosamente dentro de un bucle.

    • lupo02 dice:

      Apuesto a que el javascript asincrónico ES6 debería hacer clic en usted hasta su núcleo.

      • Nitori dice:

        JavaScript golpea a cualquiera hasta la médula.

        • Miroslav dice:

          +1 🙂

        • ESTOLA dice:

          Solo si desea que funcione también con un explorador de Internet.

      • ESTOLA dice:

        Si alguna vez ha escrito un RTOS básico en un ensamblado, JavaScript es más fácil.

    • BobH dice:

      Lo que está sucediendo ahora es que los lenguajes orientados a objetos se han enseñado el tiempo suficiente para que las personas que solo han aprendido lenguajes orientados a objetos puedan ser administrados ahora. Como resultado, los trabajos más firmes requieren el diseño de objetos, para bien o para mal. Perdí algo que parecía un buen trabajo porque no tenía habilidades en C ++. Es hora de desempolvar los libros y aprenderlo.

      • xerootg dice:

        +1 perdió uno sobre TDD C ++ en sistemas integrados. El tiempo me asume hasta la actualidad, supongo ...

        • xerootg dice:

          * incrustado. aparentemente todavía no hay suficiente café esta mañana.

      • Steven Gann dice:

        > personas que aprendieron solo lenguajes orientados a objetos

        Esperaría que fueran pocos. En Florida Atlantic University, donde era estudiante y miembro del personal, todos los estudiantes de CompSci, CompEng o EE tenían que tomar un curso sobre microprocesadores, que comenzaba con Assembly, luego C, además de otro curso que requería C ++. A partir de ahí, había muchas opciones que usaban lenguajes de programación orientada a objetos, pero cada estudiante tenía que al menos aprender los conceptos básicos.

        Fue divertido ver a los estudiantes de primer año que tenían que escribir C para MSP-430 cuando hace solo unos años tomé el mismo curso, pero solo con Assembly y en los viejos tableros de entrenamiento de 68k donados por Motorola en los años 80.

        • Quinto dice:

          Virginia Tech solía requerir C ++ tanto en Windows como en * nix; cambiaron a Java durante los dos primeros años después de pasar CS del departamento de Matemáticas a Ingeniería. El primer año se le “animó” a evitar la OO innecesaria, pero se centró en las sugerencias, las referencias, la copia de paso, etc. El segundo año introdujo un fuerte OO con plantillas, ya que podría diseñar su propia lista de enlaces o árbol de CD pero nunca ver el tipo de datos que almacenará. Otros requisitos eran un conjunto de MIPS, un nivel C bajo para escribir un sistema operativo, probablemente más que no recuerdo. Los únicos codificadores que aprendieron solo OO fueron los que se fueron a la carrera de Negocios después de los cursos de segundo año de OO.

    • Sweeney dice:

      Entonces tienes que hacer algo mal. Todo en OO es simplificar y abstraer lo que sucede debajo del capó.
      Hay muchas bibliotecas de clases malas (¿es MFC?), Pero bien hechas, te permiten armar código como Lego y probar elementos de forma aislada.
      Esto de alguien que comenzó a programar de acuerdo con BASIC y ensamblador obsoletos, pasó a bloquear la codificación estructurada y luego OOP. Cada paso requiere un cambio de pensamiento, pero tiene una clara ventaja sobre su predecesor.

      • Tim Kyle dice:

        “Simplificar y abstraer” es bueno en una computadora, donde los procesadores son casi idénticos al programador. Para utilizar de manera significativa una herramienta de depuración en el sistema integrado y garantizar el máximo rendimiento del procesador, es una necesidad tener una correspondencia simple entre el código avanzado y las instrucciones de montaje subyacentes.

    • Nitori dice:

      También puede agradecer a Xerox por ello.

      • Steven Gann dice:

        Estoy seguro de que Microsoft lo inventó.

  • Bytie dice:

    OFFTOPIC: ¿Sabes si es posible configurar de alguna manera el sistema responsable del consumo de combustible?
    Me gustaría contactarte y charlar sobre este tema.

    Saludos

    • John dice:

      Ese es principalmente tu pie derecho.

    • Ren dice:

      ¿Quieres ajustarlo como lo hizo Volkswagen?
      Hace una docena de años, había algunos lugares donde podía reemplazar los chips de la ECU de su automóvil o incluso establecer los parámetros para un mayor rendimiento.
      Eche un vistazo a MegaSquirt, que producen ECU para bares promocionales, y sus propietarios pueden llamarlos.

    • Con griego dice:

      Hay productos de terceros que están conectados a su puerto OBDII, pero tienen investigación y desde entonces han sido certificados por CARB, etc. (creo). No es fácil hacerlo, comprende completamente los sistemas de circuito cerrado dentro del vehículo, incluida la configuración de la transmisión, y luego el mfg ya lo tiene marcado bastante de cerca. Muchos de los terceros en realidad marcan más rendimiento que consumo.

      Lo que John dijo a continuación es correcto en realidad se trata de los hábitos del conductor, de hecho, algunas ventanas de terceros pueden emitir un pitido mientras gastan gasolina (básicamente, observando mucha presión y algunos de los sensores de O2)

      • piotrsko dice:

        La mayoría de los "desarrolladores" cambian alguna parte del rendimiento de la unidad o del motor que los usuarios no aceptarán para aumentar ninguna otra opción. La mayoría tampoco están aprobados por CARB. Se acabaron los días de verter más combustible.

      • darkspr1te dice:

        Pero ese no es el hacker, ¿verdad, Bill ?, sí jugaremos con 'sastres', podemos, mira un dispositivo ultraligero, atmega y canbus, algunos recortes de firmware y puedes ENCENDER a 'cualquier cosa', bluetooth o pi elige tu poisen

      • Martín dice:

        También hay productos de terceros que no hacen más que parpadear el LED para fingir que están haciendo algo. Hay videos destructivos de estos dispositivos falsos en YouTube, creo que de bigclivedotcom.

    • Martín dice:

      Puede optimizar el consumo de combustible, la energía y la contaminación, pero no todos a la vez. El valor de contaminación aceptable no es su elección, por lo que solo quedan dos para un compromiso que normalmente el fabricante del automóvil hace aceptable. Por tanto, no se puede mejorar mucho cuando no se permite aumentar la contaminación.

    • Luke A. dice:

      Lee este libro. También consulte Moates.net para conocer algunas cosas buenas que deben cumplir con la gestión del motor.

  • hackadave dice:

    Estaba convencido de que la programación orientada a objetos estaba diseñada para ser complicada para que los nerds pudieran ganar más dinero. Lo más probable es que las personas que inventaron los lenguajes estuvieran demasiado cerca del hardware para tener buenos conceptos de programación del "mundo real". No los principios de OO son fundamentalmente malos, pero en muchos sentidos los lenguajes OO no están realmente orientados a objetos. Un mejor término sería programación "orientada a clases". Antes de mayo, dediqué un tiempo a tratar de convencer a la gente de Sun Labs de que Java debe estar verdaderamente orientado a objetos, donde el comportamiento se asocia con objetos identificables del mundo real (podría llamarlos "ejemplos"). Está bien tener el comportamiento y la herencia de clases, pero es mucho mejor si puede asignar dinámicamente un objeto a las clases y hacer que esa tarea sea persistente implícitamente sin la necesidad de persistirla explícitamente utilizando, por ejemplo, llamadas a la base de datos. Además, con la herencia, es muy importante establecer una estructura de clases que se corresponda estrechamente con la clasificación de objetos del mundo real. Estas asociaciones del "mundo real" suelen formar una red, por lo que las estructuras jerárquicas de clases suelen ser artificiales y restrictivas. Hay mucho más que eso, pero esto debería dar una idea de algunos de los problemas con la programación OO. Mientras tanto, mientras espero un entorno de programación OO real (el lenguaje de programación limita demasiado la expresión), programo usando lo que está disponible.

    • ESTOLA dice:

      Estoy de acuerdo, muchos lenguajes originalmente procedimentales como PHP agregan lo que se llama OOP al crear las primitivas de clase, pero aunque eso se parece a OOP, crea más problemas de los que resuelve. PHP solo tiene un nivel de alcance además del alcance global, por lo que OOP no funciona como se esperaba a menos que también aprenda los controles integrales necesarios para que lo haga y, en este sentido, NO es un lenguaje iniciado como OOP.

      JavaScript es un buen ejemplo de OOP porque está vinculado a un módulo de objeto de documento (la página web) y básicamente funciona mejor como OOP.

      Para mí, los estilos de programación por procedimientos y OOP tienen su lugar, pero en todos los lenguajes que implementan OOP con estructuras de clases como LUA, por ejemplo, simplemente uso el procedimiento de todos modos.

      Creo que la conclusión es que con los lenguajes de procedimiento necesitas saber lo que está sucediendo bajo el capó con cosas como el alcance, mientras que con el punto de vista solo esperas lo mejor.

      La programación orientada a objetos es probablemente la mejor opción para un entorno cerrado, como el código de un microcontrolador, donde no existen vectores de ataque de seguridad o son limitados. En entornos abiertos como servidores web, la programación orientada a objetos crea muchos problemas de seguridad para la plataforma de escritura principiante.

      Es triste que la gente ya no esté aprendiendo programación procedimental. La programación orientada a objetos es mejor cuando hay muchos duplicados funcionales, pero casi cualquier otro caso, menos procesal se refiere.

  • Nitori dice:

    Me pregunto qué tan difícil sería crear una herramienta que pueda cumplir con los protocolos bidireccionales de GM, aunque apuesto a que mucho de eso está oculto detrás de los NDA y otras pantallas BS.

  • nezoika dice:

    Tienes unas uñas bonitas.

  • Peter Dokter dice:

    Buen video, y puedo relacionarme completamente. Me refiero mucho más al hardware que al código. Y mientras sigo envolviendo mi cabeza alrededor de él, principalmente me hace gemir y hacer otros "ruidos de ritmo".

Alberto Gimenez
Alberto Gimenez

Deja una respuesta

Tu dirección de correo electrónico no será publicada.