¿Cómo depurar programas de microcontroladores? Se toma el JTAG, el osciloscopio dura un par de días / semanas y se depura el programa. Esta será una respuesta típica, y en la mayoría de los casos será correcta ... Pero no siempre. Los microcontroladores resuelven problemas muy diferentes, y en este artículo consideraremos qué hacer si necesita desarrollar un engorroso software de bajo nivel para controlar cualquier equipo eléctrico de potencia, por ejemplo, convertidores de frecuencia para motores eléctricos, convertidores de carga de batería CC / CC para trenes, correctores de potencia, servos y etc. Equipo, donde fluyen los kiloamperios y kilovoltios PWM, donde se cuenta cada conmutación de las teclas del inversor IGBT, donde el tiempo de respuesta del microcontrolador a una situación anormal se mide en microsegundos, y el propio equipo en cajas selladas se instala y opera en algún lugar de las fábricas de Yakutia.Si desea saber qué características impone esto a los métodos de depuración, bienvenido a cat.

Características de los sistemas de control de depuración.

¿Cuáles son las características de los microcontroladores de depuración (MK) que realizan tales tareas? En primer lugar, cuando MK funciona con equipos de potencia, no se puede detener.MK con la ayuda de PWM controla las teclas de encendido, regula muchos valores en sus corredores: corrientes de las fases del motor, voltaje de enlace de CC, velocidad, posición del cuerpo de trabajo, etc. Si detiene el MK mientras trabaja en el punto de interrupción, en el mejor de los casos, el equipo se apagará debido a la protección del hardware y, en el peor de los casos, todo simplemente explotará (si los interruptores de alimentación permanecen encendidos en la posición "uno" o con un ciclo de trabajo). Por lo tanto, la forma clásica de depuración es "recorrer los pasos con el depurador" en tales tareas. Por lo tanto, solo puede ejecutar en la tabla "módulos de software completamente en bruto antes de su primera inclusión en equipos reales.

En segundo lugar, esta es la complejidad del software de bajo nivel. El tamaño de la sección del código del programa .text es de 50-200 Kbytes para el código del programa que controla exclusivamente el hardware (sin controladores de comunicación de alto nivel, etc.); esta es una situación típica para un microcontrolador de algún servocontrolador industrial. Por lo tanto, los microcontroladores de la serie motorcontrol se utilizan para tales tareas, que combinan al mismo tiempo periféricos muy desarrollados, alto rendimiento y un tamaño de memoria relativamente grande (para MK). Como ejemplo de MK importados, se pueden citar MK Instruments de 32 bits de la serie C2000 de Texas Instruments, del chip K1921VK01T nacional de NIIET OJSC. El software para tal MK generalmente contiene decenas o cientos de miles de líneascódigo C / C ++ optimizado perfecto, que simplemente no se puede depurar "parpadeando un LED", "printfom en UART" u observando el funcionamiento de las patas de un osciloscopio externo.

En tercer lugar, el controlador del sistema de control de accionamiento eléctrico se encuentra con mayor frecuencia dentro del convertidor de potencia, cuya carcasa está cerrada y, a veces, incluso sellada. Por lo tanto, el acceso a través de JTAG ya es un gran problema, aunque solo sea para firmware (con apagado). Y un problema aún más grave es la depuración de JTAG con el sistema encendido. Aquí, se debe usar el JTAG necesariamente aislado galvánicamente y a prueba de ruido (lo usamos para MK TI JTAG SAURIS con aislamiento galvánico incorporado - costoso, pero funciona).

Cuarto, no hay sistemas operativos!Podemos prever cómo algunas personas tienen la idea "bueno, ya que tiene una tarea tan difícil, coloque un microcontrolador normal con Linux y escriba aplicaciones regulares para él, actualizando el software desde una unidad flash". Los sistemas de control de equipos de potencia son sistemas en tiempo real muy difíciles. No es que Linux, ni siquiera todos los sistemas operativos especializados en tiempo real sean adecuados para tales tareas. Por ejemplo, la interrupción del ADC al leer y promediar datos analógicos puede ser causada con una frecuencia de hasta 100 kHz. Al mismo tiempo, contendrá solo una docena o dos líneas de código: recopilación de datos de canales analógicos, un par de comprobaciones de protecciones de alta velocidad y salida, todo, nada más que hacer. Si le indica una interrupción a algún programador de tareas del sistema operativo, simplemente su propia ejecución requerirá más recursos. Sin mencionar que, en particular,para Linux, en lugar de un chip MK, debe colocar dos más en la placa: memoria RAM externa y memoria flash, asignarles un montón de patas de cristal preciosas, usar una placa de seis capas para un cableado adecuado, obtener un gran tiempo de arranque MK (a veces cuando hay una falla de energía o un temporizador de vigilancia ¡comience a trabajar antes de que el motor se haya detenido!), tenga problemas con la integridad del sistema de archivos y más.

Bueno, la quinta característica: los sistemas de control de bajo nivel para accionamientos eléctricos y otros equipos de potencia (en contraste con las tareas de comunicación en diferentes interfaces, PLC, controladores de todo tipo de alarmas, controles remotos, etc.) implementan principalmente algoritmos de sistemas de control automático. A saber: la mitad del software consta de varios tipos de estructuras cerradas con controladores PID, bloques de saturación, zonas muertas, tablas de dependencia de uno sobre el otro, filtros, observadores, ajustadores de intensidad, planificadores de movimiento y otros. Los cálculos en dicho software se realizan con una frecuencia determinada; por ejemplo, a una frecuencia de 10 kHz, se dispara una interrupción y se calculan todos los bloques enumerados, que en conjunto forman la estructura de control del equipo necesaria. En tales algoritmos, la depuración paso a paso no ayuda: la mayoría de las veces, en cada paso, cada módulo genera lo quelo que se espera de él: de hecho, todos estos filtros, reguladores, etc. ya se han depurado durante años y hay pocas sorpresas allí.Surgen problemas durante el funcionamiento de toda la estructura como un todo: cada unidad funciona individualmente y el proceso regulatorio deseado no ocurre como se esperaba . Y los problemas resultan estar en el ajuste de cientos de parámetros y coeficientes de estos bloques, así como en la estructura ensamblada a partir de ellos; puede resultar que necesite agregar un nuevo circuito de estabilización en algún lugar, agregar un bloque de predicción, restricciones, etc. Por lo tanto, esta es otra "piedra en el jardín" de la depuración paso a paso y mensajes de depuración printf: necesita depurar más a menudo que no el código del programa en sí, sino la estructura de control automática ensamblada. Si alguien tiene poca idea de qué es (estructura), entonces aquí está la estructura más simple de un control vectorial sin sensor de un motor síncrono:

Cada cuadro tiene algunas fórmulas y, a veces, un módulo en una docena o dos páginas de código. El módulo tiene entradas / salidas, así como algunas variables de estado (por ejemplo, la parte integral del controlador PI, etc.). Aquellos que lo deseen también pueden ver una estructura similar en la página de Wikipedia . Dado que el sistema de control está cerrado, el funcionamiento incorrecto de una unidad (o su configuración incorrecta) conduce a la inoperancia de toda la estructura. Y encontrar exactamente dónde está el problema, esa es otra tarea.

¿Cómo depurarlo?

Entonces, ¿qué hacer, cómo depurarlo? ¿Un osciloscopio externo? No va a ayudar El osciloscopio, por supuesto, es necesario para depurar algunos problemas puramente de hardware, pero solo pueden ver los valores de entrada y salida del microcontrolador, y cientos de variables dentro de la estructura permanecerán detrás de escena. Bueno, verá que la corriente de fase del motor se dispara extrañamente, y el voltaje de salida del inversor se dispara extrañamente. Y por qué, qué bloque dentro del software MK conduce a esto (o un motor o sensor de posición u otra cosa conduce a esta curva), sigue sin estar claro.

Modelo? Sí, esta es una buena ayuda.Muy a menudo, el desarrollo de estructuras de gestión complejas comienza con el modelado. En términos de TAU y en forma de ecuaciones diferenciales, se describe el objeto de control, se construye el sistema de control propuesto (como en la figura anterior, por ejemplo), y luego todo esto se realiza ... bueno, quién ama qué, pero el estándar de facto es Simulink Matlab. En él, puede "dibujar" una estructura junto con un modelo del objeto de control, utilizando "suelto" en forma de integradores, sumadores, funciones de transición, etc. Puede usar su paquete para modelar circuitos eléctricos, donde hay llaves IGBT listas para usar, motores eléctricos, resistencias, condensadores y más, dando a merced de los programadores de matlab la implementación del trazado en forma de ecuaciones diferenciales y dibujando la estructura de control en forma de "hoja suelta".Y puede escribir todos los bloques necesarios en matlab en C. Este método es conveniente porque el código del programa depurado en el matlab puede simplemente copiarse al microcontrolador. Por lo general, esta etapa siempre sigue al "dibujo", cuando la estructura del sistema de control después de un trabajo de investigación aproximado sobre modelado está más o menos formada. Pero a menudo los parámetros del objeto son desconocidos a priori, o se conocen de manera muy inexacta; nunca antes el software que funcionaba en el modelo comenzó a funcionar bien en el objeto. También es imposible poner "todo" en el modelo: transistores de conmutación transitorios, saturación del circuito magnético, corrientes parásitas, acoplamiento capacitivo, parámetros flotantes de temperatura y de instancia a instancia, interferencia aquí y allá ... Y a veces el objeto de regulación es tan complicado,que es más fácil desarrollar una estructura de control directamente en la instalación.

, , () - . , , «» – , , - ? ( – , « », ).

También hay una serie de productos que le permiten "dibujar" programas directamente para microcontroladores. Incluyendo el mismo Matlab es capaz de generar código C para marcas famosas de MK basadas en el modelo de Simulink. Supuestamente, puede dibujar y depurar la estructura dibujada del sistema de control en la computadora en el modelo, y luego subirlo a MK, y listo, ¡vamos! E incluso dichos entornos le permiten depurar estructuras de control dibujadas dentro del MK, ver variables, etc., y en los sitios de dichos productos hay un montón de proyectos de demostración para los sistemas más complejos que están "programados" de esta manera. Pero dado que todos los proyectos reales todavía se están programando con "manos" por alguna razón, podemos adivinar que algo está mal con "dibujar". Pero aquí es incluso difícil describir exactamente qué, cuando no es así, eso es todo. El argumento principal contra– . Presiona un botón en un entorno de "hacerlo bien" y espera que el generador de código haga el resto por usted. Para algunos sistemas simples, donde el rendimiento de MK está "detrás de los ojos", el cronograma de desarrollo es muy ajustado, y nadie sabe cómo programar en la empresa que inició el proyecto ... entonces sí, probablemente pueda intentar "dibujar" el programa. Pero si no funciona como debería, o tendrá algún problema técnico muy específico, entonces ya no habrá ninguna posibilidad de depurarlo. Y para una tarea compleja, donde incluso cuando la programación con manos con rendimiento MK siempre es un problema, el dibujo no es adecuado simplemente por falta de recursos: cualquier lenguaje de programación que sea de nivel superior (mucho más alto que el dibujo) genera un código de máquina menos óptimo. Y las optimizaciones de bajo nivel que haría un programador en Cdicho sistema no podrá hacerlo (cálculo de bloques de la misma estructura con diferente sincronización, uso de valores en caché de seno y coseno, reemplazo de funciones de división por multiplicación por un valor previamente preparado, o cosas absolutamente difíciles comotal , etc.).

Por lo tanto, debe escribir su software y escribir en C. Y de una forma u otra, necesita depurar su software, y es necesario en el objeto. Probablemente, todos en este punto del artículo ya entendieron que la estructura de control solo se puede depurar viendo los oscilogramas de las variables internas , es decir. al ver los gráficos a tiempo, cómo cambia esta o aquella variable en C, por ejemplo, "la salida de ese bloque, el quinto desde la izquierda, simultáneamente con las entradas del tercero desde la derecha". Obteniendo fotos como esta:

Y esto solo se puede hacer por medio del microcontrolador. No puede simplemente tomar y poner la interfaz de comunicación rápida externa y enviar "arriba" el valor de alguna variable, lo más rápido posible, y construir un gráfico en el sistema de nivel superior. Debido a que ninguna interfaz de comunicación MK tendrá tiempo para hacer esto con la frecuencia con la que ocurren los transitorios regulados. Y si tiene éxito, todos los recursos de MK se destinarán al mantenimiento de esta interfaz de comunicación. Por lo tanto, hacen esto: registran la forma de onda en la RAM de MKsolo en una matriz. Por lo general, no se necesitan muchos puntos: simplemente tome el momento correcto para escribir exactamente los datos: coloque el disparador correcto al comienzo de la grabación. Y luego puede ver qué estaban dando estos o esos bloques del sistema de control en el momento de la falla, cómo se estaba desarrollando, qué estaba tratando de hacer MK. Por supuesto, todas las variables no pueden oscilar inmediatamente de una vez, pero en la práctica, en nuestra experiencia, hay suficientes, por ejemplo, cuatro conjuntos de 256 puntos cada uno, una especie de osciloscopio de cuatro canales que utiliza herramientas MK. Si el equipo funciona mal más de una vez por semana, entonces la depuración no es un problema: en un experimento observamos estas 4 variables, en el siguiente reemplazamos la mitad con las otras, volvemos a mirar ... hasta que se encuentra una unidad que funciona mal, o hasta que eliminamos todo lo que sucede en todos los bloques y no te vayas a mirar el "metraje", rascando el lugar quién piensa qué ...

¿Cómo disparar tales oscilogramas? ¿Qué software puede hacer esto? ¿Qué interfaz de comunicación reenvía esto? En realidad, Texas Instruments es, por lo tanto, el líder en la producción de microcontroladores de control de motores, ya que hizo todo por esto: Code Composer Studio (su entorno de desarrollo) más MK en tiempo real. El modo en tiempo real es cuando a través de JTAG el entorno de desarrollo puede solicitar y escribir datos en la memoria RAM del MK sin detenerlo. Incluso no solo sin detenerse, sino sin la menor interrupción de su trabajo. Este modo está disponible en todos los MK de la serie C2000, pero requiere el costoso y rápido JTAG para usarlo, lo que lo admite. Pero además del modo en sí, el MK debería tener algo correspondiente en la parte posterior del cable: el entorno de desarrollo de Code Composer Studio puede construir formas de onda de fábrica.Además, tanto en el modo más simple, cuando el usuario establece el nombre de la variable C y ve su cambio en el tiempo en el gráfico, y el entorno solicita datos con la frecuencia que puede (generalmente buena, si Hertz 10), y en el modo de mostrar la matriz en la memoria en forma de onda, es decir justo lo que se describe arriba. , , , Code Composer Studio JTAG .Al mismo tiempo, el dispositivo puede continuar funcionando como si nada hubiera pasado. Esta herramienta se ha utilizado con éxito durante más de diez años, y, de hecho, esa ideología de depuración (parece, pero puedo estar equivocado) fue propuesta por Texas. En todos sus proyectos de demostración hay un módulo de registro de datos (que registra conjuntos de formas de onda) y los manuales describen cómo usarlo. Por cierto, aquí debes tirar una piedra al jardín ARM. También tienen un modo en tiempo real, y en esta arquitectura hay MK que pueden controlar motores eléctricos. Sin embargo, en ningún entorno de desarrollo me he encontrado con una función gráfica, incluso si se admite el modo en tiempo real. Por ejemplo, en Keil's amado por todos, incluso es imposible cambiar normalmente el valor de una variable en un MK en ejecución: se actualiza constantemente,y el nuevo valor ingresado por el usuario en la ventana se borra ... Sin mencionar los gráficos allí. ¿Quizás alguien en los comentarios sugiera una opción de trabajo? ¿O es "nadie lo necesita" y, por lo tanto, no funciona?

Pero hay un problema con este método de depuración, incluso a través de Code Composer Studio. Y este problema es JTAG. Como se dijo, su conector no siempre está disponible, y con mayor frecuencia en equipos en funcionamiento y no está disponible en absoluto. Y, francamente, no es muy cómodo sentarse a un par de metros del convertidor de megavatios, observar sus oscilogramas de trabajo, y muy concentrado y concentrado para rodear el botón de "parada" del microcontrolador con el mouse, ¿qué pasa si un dedo tiembla en el camino? ¿Sabes cómo el panel táctil tiene errores cuando se usa un PWM potente? ¿Y si el entorno falla? ¿Qué hay de JTAG? ¿Todo, chicas?

Babakh ordinario

Además, los oscilogramas en el entorno de desarrollo se muestran en los valores "tal cual" en C, sin ninguna escala, en diferentes ventanas de los gráficos, sin unidades de medida personalizadas (recuerde que en este gráfico 0.342 son voltios, deben multiplicarse en la mente por 540 para obtener unidades físicas, y aquí 1.2 son amperios con una escala de 800A). E incómodo y aterrador. Y, sin embargo, ¡no todos los entornos MK y de desarrollo pueden ver oscilogramas! ¿De repente el tuyo no es Texas? Por lo tanto, decidimos inventar otra forma.

Nuestra decision

En realidad, si no necesitamos una depuración paso a paso, ¿cuál es el problema? Reemplazamos todo lo que hacemos a través de JTAG con cualquier otra interfaz de comunicación y creamos nuestro propio shell de nivel superior, que construye los gráficos de la manera que queremos. Beneficio!

Entonces lo hicimos. Interfaz de comunicación que elegimos CAN, protocolo - CANopen. Por qué CAN es una interfaz de comunicación industrial muy buena, resistente al ruido, tiene arbitraje de hardware, acceso no destructivo al bus, confirmación de hardware de los paquetes y, al mismo tiempo, solo dos cables y tierra. Esto es mejor que todos los RS, y menos monstruoso que Ethernet (que es bastante exótico en el motorcontrol MK). ¿Por qué canopen? En realidad, hay dos protocolos comunes para CAN, estos son J1939 ("automotriz") y CANopen (máquinas herramienta, automatización, sensores, etc.). No hay mucha diferencia entre ellos, pero CANopen nos pareció más flexible, por lo que lo implementamos en nuestra propia pila (controlador). Quién no sabe nada sobre CANopen: su función principal, como muchos protocolos para MK, es proporcionar acceso al diccionario de objetos (lista de variables en C MK) en una dirección específica. Esto se puede hacer de dos maneras principales:Mensajes SDO de tipo solicitud-respuesta, así como mensajes PDO en forma de valores de envío constantes por temporizador o por evento (establece el nivel superior de qué enviar y cuándo). También hay varios servicios de servicio, como mensajes de emergencia, mensajes sobre la presencia de dispositivos en la red (latidos), etc. No se requiere un asistente en la red: quien quiera, envía, a quien quiera, acepta.

Creamos la pila CANopen no solo para MK, sino también para la computadora en forma de biblioteca. Y ya sobre su base, Windows escribió su propio entorno de nivel superior. Primero, simplemente hicieron acceso a las variables del diccionario de objetos para que fuera posible ver y cambiar la configuración del sistema de control (¡y hay cientos de ellas, por cierto!), Luego hicieron gráficos al consultar periódicamente el parámetro del diccionario de objetos a través de la red, y luego agregaron la carga de formas de onda de los arreglos MK (Además, la elección de qué oscilógrafo también se realiza a partir de objetos variables del diccionario). Conseguimos todo lo mismo que proporciona depuración a través de JTAG. O no? No, porque también necesitaba la función de actualizar el software a través de CAN. A pesar de la presencia de un cargador de arranque CAN en Texas MK, decidimos hacer el nuestro, ya que el estándar no era CANopen y podía interferir con el funcionamiento de otros dispositivos en la red mientras cosíamos uno, así como los dispositivos podrían interferir con el firmware. Además, hubo problemas con la corrección de errores y la pérdida de mensajes (aunque CAN es muy bueno, a veces se bloquea y el firmware es algo muy importante para no hacer una verificación o volver a intentar enviar una pieza rota). Por lo tanto, implementamos nuestro "programador" a través de la red CAN , pero dentro del marco del protocolo CANOpen. Ahora ya está todo. Ahora pudimos abandonar completamente JTAG, usándolo solo una vez, para programar un nuevo MK.

Al mismo tiempo, este enfoque abrió nuevos horizontes de depuración que no habíamos visto antes. Dado que creamos el entorno de nivel superior con un ojo puesto no solo en los programadores, sino también en las "personas comunes", creamos todos los parámetros de los nombres en idioma ruso e hicimos documentación para el instalador para cada parámetro (la documentación no es el entorno, sino el dispositivo, por supuesto). Y fue beneficioso: ahora si hay algún problema con la unidad, no tiene que "tirar" del desarrollador- El personal de servicio al cliente en algunos casos puede diagnosticar problemas de forma independiente. Ahora podemos recibir un correo electrónico como “Nuestro disco comenzó a emitir sonidos extraños a veces, miré el oscilograma del sensor de posición, eso es lo que vi (imagen). ¡Verifiqué la conexión a tierra de la pantalla, se cayó, solde y todo funcionó como debería! ¡Y absolutamente no hay necesidad de ir a ningún lado o volar! El segundo "descubrimiento": si hay un problema, le pedimos al cliente que conecte la computadora al equipo y le dé control remoto de escritorio a través de Internet: lanzamos nuestro entorno de nivel superior, oscilaremos todo nosotros mismos, corregiremos los parámetros / firmware / decimos que rompió, ¡ganancias! Una vez más, no tiene que ir a ninguna parte (lo principal es que Internet debe estar en las instalaciones, al menos a través de una red celular).

Con los años, este programa de nivel superior ha adquirido pequeñas funciones, como los hongos (un proceso natural para el software que utilizan). Esto incluye trabajar con el registro de fallas del dispositivo y guardar / cargar un nugget de todos los parámetros en un archivo en la computadora, y configurar el panel de control del dispositivo a la "panel de control", y mantener registros de red en un archivo y devolver el tráfico de red CAN a través de TCP / IP, y firmware / parametrización automática múltiple de dispositivos similares en la red (si hay docenas de dispositivos, entonces flashear todo con las manos es vago, necesita un script), etc.

Bueno, ahora algo de publicidad. Ahora ya es una herramienta muy poderosa (la llamamos tanto como UniCON), que en algunas tareas parece más funcional que un software similar de marcas famosas para configurar sus unidades y dispositivos. Además, no está vinculado a un dispositivo específico: puede configurar al menos una unidad eléctrica, al menos una estufa, al menos un cargador, solo cambia el diccionario de objetos. Ahora en nuestra empresa no vemos la oportunidad de completar con éxito un nuevo proyecto complejo sin nuestras herramientas de depuración CANopen. Para trabajar con UniCON, solo necesita incrustar nuestra pila CANopen en MK, después de lo cual MK se convierte en un laboratorio digital. Estamos seguros de que todas las empresas que crean sistemas de control serios en MK tienen herramientas de depuración similares. Pero ofrecemos nuestra solución CANopen en forma de un producto de software independiente, ya que se implementa universalmente en términos de independencia de las funciones del dispositivo. Actualmente, hemos implementado la pila CANopen con las funciones avanzadas descritas para el Texas Instruments C2000 MK, sus microcontroladores ARM (por ejemplo, la familia Concerto) y para el K1921VK01T del NIIET OJSC. Por lo tanto, si necesita desarrollar un sistema de control para un accionamiento eléctrico u otro objeto de control complejo, lo invitamos a cooperar.

PD:
En los comentarios, esperamos con ansias las críticas a la forma "Así que hay ***, hace lo mismo y de forma gratuita". Dado que hemos estado buscando herramientas de depuración similares para ARM para la funcionalidad durante mucho tiempo, incluso nos topamos con entornos de desarrollo famosos.

UPD: Gracias a los comentarios de Indemsys , olekl y LeonidLeninEncontramos funciones de gráficos en entornos de desarrollo para ARM Keil y STMStudio cuando trabajamos a través de SWD. Sin embargo, no saben cómo mostrar una matriz de datos de la memoria MK en forma de gráfico, que es justo lo que se necesita para observar los procesos rápidos de los sistemas de control (pero STMStudio puede mostrar gráficos con un tiempo de muestreo de aproximadamente 1 ms usando el almacenamiento en caché de datos). También es interesante la herramienta NXP FreeMaster: en descripción y propósito, es muy similar a nuestro desarrollo UniCON, pero con sus propias características. Además, el Segger J-Link tiene su propia herramienta de visualización de forma de onda .

Métodos para depurar el software del microcontrolador en una unidad eléctrica

Características de los sistemas de control de depuración.

¿Cómo depurarlo?

Nuestra decision

More articles: