Trabaja con llantas personalizadas complejas Redd

En el último artículo, comenzamos a familiarizarnos con cómo trabajar con neumáticos estándar y bien conocidos utilizando el complejo Redd, después de lo cual prometí pasar a cómo obtener acceso a neumáticos más exóticos. Pero después de hablar con un par de conocidos, de repente me di cuenta de que no todos leían el artículo escrito sobre el complejo Redd fuera de este ciclo. Y, en consecuencia, no todos saben por qué estos neumáticos se agregaron al complejo en absoluto. Por supuesto, puede referirse a ese artículo , pero me parece que será más correcto volver a contar su parte correspondiente con referencia al tema de este ciclo en particular. Por lo tanto, hoy consideraremos no solo cuestiones prácticas, sino también teóricas con respecto a los neumáticos vendidos por el complejo Redd.

Parte teórica aburrida

Lo que consideraremos

Repasemos brevemente (en la medida de lo posible) algunas cuestiones teóricas para comprender claramente por qué todo se hace en el complejo Redd de una forma u otra. Primero que nada, la tarea principal del complejo ... Curiosamente, como parte de esta serie de artículos, nunca he escrito sobre eso. Sí, y no planeo escribir. El hecho es que la tarea principal es un acceso remoto conjunto para la depuración de cierto hardware (desde microcontroladores hasta enormes sistemas de procesador multinúcleo). Reserva de tiempo de trabajo, proporcionando acceso físico a través de canales de pésima media (y no solo ideal) y otras delicias. La depuración puede realizarse mediante JTAG o mediante otras herramientas proporcionadas por entornos de desarrollo. Un gran equipo está trabajando en esto, todo es muy interesante allí, pero no me gusta ninguna burocracia, por lo que no quiero escribir sobre esos temas. Quizás en el futuro, alguien más llene este vacío ... Mientras tanto, estoy escribiendo sobre las herramientas auxiliares del complejo.

Sí, sí, todo lo que he estado describiendo durante más de seis meses son solo cosas diseñadas para ayudar a los desarrolladores.

¿Por qué en Redd se implementan neumáticos estándar complejos?

Muy a menudo tiene que desarrollar equipos sin tener acceso a ellos usted mismo. Veamos un ejemplo específico de un proyecto que tiene buenos enlaces. Aquí, por ejemplo, están mis helicópteros favoritos. Estamos aquí, y los helicópteros están en Suecia. Además, ordenamos el desarrollo en el invierno, cuando los helicópteros físicamente no podían realizar las funciones que implementamos para ellos (a saber, fertilizar el suelo en los bosques: el suelo en ese momento estaba bajo ventisqueros). Resulta que los dispositivos instalados en el helicóptero deben emularse durante la depuración y volar, virtualmente.

Pero eso es depurar. Al probar un proyecto, la emulación es la única opción. El probador debe verificar todo en el número máximo de modos, clasificando varias combinaciones. Además, debe crear situaciones con condiciones críticas y de emergencia (un trabajo tan destructivo para los probadores). ¿Cómo hacerlo en equipos reales? Solo en emuladores.

¿Cómo va la comunicación con los dispositivos modernos? Por lo general, a través de buses estándar, porque los desarrolladores de dispositivos tienden a conectarse a través de algo que los consumidores ya conocen. Eso es solo Redd y actuará como un emulador de muchos dispositivos. Sus autobuses están conectados al bloque desarrollado. Y la unidad se asegurará de que funciona con equipos reales, sin saber que en el otro extremo de los neumáticos no hay un montón de hierro, sino el complejo Redd, en el que giran varios emuladores.

Al trabajar con equipos reales, los neumáticos pueden actuar como analizadores, registrando el trabajo con hardware real para analizar vuelos en caso de problemas.

En general, debe haber tantos neumáticos como sea posible, y su juego lo más variado posible. Aunque, en todo lo que necesita saber la medida. Bueno, aunque solo sea porque cada autobús cuesta algo de dinero y ocupa espacio en el estuche, y también en el conector. Ahora consideremos qué estrategias se utilizan mejor para controlar estos autobuses mediante programación.

¿Quién liderará el desarrollo del código para Redd?

En las empresas modernas, la hora de Su Majestad está a la vanguardia. El hecho es que este es un recurso muy costoso en muchos aspectos (dinero, tiempo de desarrollo, disponibilidad de un especialista en este momento particular para esta y otras tareas de la empresa, etc.), por lo que si la administración puede ahorrar horas, lo hará. Si es posible no agregar desarrolladores al equipo, no se agregarán. Si es posible hacer todo en menos tiempo, eliminarán a los desarrolladores para que puedan hacerlo en menos tiempo.

De esto se deduce que es poco probable que den especialistas individuales para escribir emuladores. Y si lo hacen, serán programadores comunes que trabajan en la misma compañía.

¿Por qué estoy escribiendo esto? En algunos artículos, se considera elegante cuando se utilizan algunos idiomas especializados para las tareas de servicio de neumáticos no estándar. Tuve la oportunidad de trabajar con algo como esto. Permítanme describir mis impresiones sobre el ejemplo de cosas que alguna vez se han publicado. Aquí, por ejemplo, https://www.astrosoft.ru/about/clients/bvg-group/case-959/ . Además, el lenguaje GOST recientemente salió incluso GOST. Mi opinión es la siguiente: lo que era necesario a fines de los años 70 - principios de los 80, luego absolutamente innecesario a fines del primer cuarto del siglo XXI. Aquí hay un maravilloso artículo de Konstantin Chizhov, en el que lo más importante de ese lenguaje (grupos de contacto) se implementa de manera perfecta y casi gratuita a través de la metaprogramación en C ++ http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na- si.html . Este artículo verifica todo para AVR. Hice una gran comprobación de la opción de biblioteca para Cortex M, los resultados también son increíbles. Los optimizadores empaquetan todo de tal manera que el desarrollo directo en ensamblador no dará ninguna ganancia. Y esto se aplica no solo a los grupos de contacto, sino en general a todos los controladores de mcucpp. Es una pena que las autoridades no permitieron esta ideología en el MAX RTOS, por lo que los resultados de la investigación no aparecieron en la publicación. Pero en casa solo uso esta biblioteca.

Todas las demás cosas que se implementan en YASTEK también están perfectamente empaquetadas en la construcción C ++. Pero la interactividad para el operador en la unión de los años setenta y ochenta no lo era. Es cierto que no estaba en los compiladores de Pascal, C y otros lenguajes. La mayoría de las veces, los compiladores eran lotes y simplemente generaban texto de ensamblador sin ninguna herramienta de depuración. Al hacer la nueva versión de YASTEC, agregamos operadores para enviar datos a la pantalla e incluso un depurador interactivo, pero de todos modos, estas son medias medidas en el contexto de lo que está sucediendo en entornos de desarrollo listos para los lenguajes de programación ordinarios. En resumen, los tiempos en que había razones técnicas para hacer que el lenguaje especial de YASTEK desapareciera hace mucho tiempo. Hoy, en un lenguaje de programación común, uno puede lograr lo mismo y mucho más.

Alguien puede decir que no fueron expertos en C ++ los que escribieron el código allí, sino personalizadores comunes ... Así es como es, pero ya he notado que los programadores comunes escribirán el código para Redd. No tiene sentido que la gerencia mantenga un especialista limitado para las tareas ocasionales. Y no tiene sentido para un especialista común aprender otro idioma.

¿Y qué otras características expresivas tendrá esto? Al desarrollar emuladores, es posible que necesite cosas completamente exóticas. Por ejemplo, para el emulador GPS en modo interactivo, controlamos el uso del joystick. ¿Qué lenguaje orientado a problemas lo admite? Y la flexibilidad de estos idiomas es todavía. Finalmente, la reutilización del código en el discutido YESTEK no está a la altura, pero la búsqueda de soluciones preparadas en la red ... Incluso en idiomas comunes, no es solo para encontrar un buen ejemplo, sino también exótico.

Lo mismo se aplica a tal caso , que se convirtió sin problemas en tal caso . En el marco de la automatización empresarial, SIMATIC con su avanzado sistema de configuración y programación es bueno, pero para un proyecto pequeño creó más problemas de los que resolvió, por lo tanto, fue reemplazado por una solución más universal.

En total, concluimos que el trabajo de los programadores ordinarios en sus lenguajes habituales es normal para Redd. Para otras tareas, se discute, y específicamente para tareas auxiliares resueltas por el complejo Redd, es normal.

Cómo implementar neumáticos

Pero si decimos que los programadores comunes usarán los neumáticos en sus idiomas habituales, entonces las bibliotecas para trabajar con estos autobuses deberían ser lo más típicas posible. En particular, la oración se observó de inmediato: "Y vamos a poner microcontroladores en el complejo, y los programadores escribirán todo en ellos". Esta opción nuevamente requiere especialistas en estos controladores. Además, requiere una sincronización seria entre subsistemas. Se decidió que, si es posible, el programador debería trabajar en el procesador central de PC familiar. "¿Pero qué pasa con los FPGA?", Preguntas. Bueno, vaya, probablemente todos notaron que para los FPGA elegí la ideología de "desarrollo mínimo en Verilog, máximo familiar para los programadores". Allí no puedes hacerlo más convenientemente. Pero estamos trabajando duro.

Entonces, implementaciones típicas de neumáticos. Con UART, todo está claro. Con SPI / I ² C, se consideraron varias opciones, ya que no existe un estándar de facto establecido para PC. Pero había un deseo de prescindir de la opción de escribir un conjunto completo: "firmware" del controlador, controlador y bibliotecas. Quería tener algo listo. Sin embargo, hasta el último momento consideramos la opción con microcontroladores que implementan a nivel USB un depurador a la la de Cypress. El punto en esto fue puesto por los hallazgos descritos en el artículo sobre DMA . Es imposible garantizar el ancho de banda solicitado en los TOR si todos los buses con flujos de datos previamente desconocidos funcionan simultáneamente. Y si se extiende sobre varios controladores, descansamos en el ancho de banda de USB 2.0 FS. Por lo tanto, solo puentes FTDI. Un puente es una función, y USB 2.0 HS proporciona ancho de banda.

Por cierto, en la última sección, siempre me referí al lenguaje común de C ++. El hecho es que en esta etapa del viaje de mi vida este es mi lenguaje de programación principal (aunque este no fue siempre el caso). Pero las soluciones estándar son estándares para funcionar perfectamente en otros lenguajes comunes hoy en día, ya sea Python, Java u otra cosa. Por lo tanto, si un especialista en esos idiomas es arrojado a la batalla, él, usando estos idiomas, hará todo no menos fácilmente. Esa es la belleza de las soluciones universales.

Pero hay algunos neumáticos que son tontos para colocar chips FTDI caros. Hablaremos sobre cómo se implementan en el complejo.

Mil pequeñas cosas

¿Por qué el complejo Redd tiene una tarjeta SD conmutada?

Varios dispositivos en desarrollo están actualizando su "firmware" utilizando una tarjeta SD. Muy a menudo, el "firmware" se vierte en la tarjeta en forma de archivo, después de lo cual el dispositivo se apaga y, cuando se enciende, detecta el archivo de actualización y lo aplica. Recientemente incursioné en una nueva placa para una de mis impresoras 3D. Allí, el "firmware" de Marlin 2.0, después de algunos de los comandos M (no recuerdo el código exacto), abrió el contenido de la SD a través del bus USB, por lo que pude inyectar actualizaciones sin ningún truco. Me conecté a través de USB, después de lo cual supe que apagué / encendí la alimentación (cómo hacerlo con la ayuda del complejo Redd, examinamos en el artículo anterior ), di la orden de conectar la tarjeta SD a USB, esperé a que apareciera el disco, completé el "firmware", apagué / volví a encenderlo y esperé . El firmware ha sido actualizado. Pero no todo es tan hermoso. A veces, una tarjeta SD debe prepararse con anticipación. Por cierto, si agrega la curva de "firmware" a la impresora 3D, la opción ideal descrita anteriormente tampoco funcionará, y también tendrá que preparar la tarjeta con anticipación. Y cuando desarrolle, cree un "firmware" que no funcione, un par de cosas insignificantes.

Para este caso, el complejo Redd tiene una tarjeta SD conmutada. En el diagrama del circuito eléctrico, se incluye de la siguiente manera:



Al principio, intentamos encontrar una solución típica que permitiera cambiar el bus SDIO (no SPI, es decir, SDIO, los dispositivos también pueden funcionar a través de esta interfaz) a través de FPGA. Resultó que no existe una solución hermosa. Incluso las soluciones de los fabricantes de FPGA son complejas y poco creíbles. Por lo tanto, se suministraron claves analógicas que conectan físicamente la tarjeta a un conector externo o a un lector como parte de Redd. Por lo tanto, el algoritmo de operación es el siguiente: conectado a un lector, archivos preparados utilizando el sistema operativo Linux, conectado al dispositivo de destino. Usamos allí.

Dado que trabajar con el sistema de archivos no pertenece a cosas críticas (solo estamos preparando los datos, para que no se requiera una velocidad especial), se decidió hacer un lector basado en el microcontrolador STM32F103. El soporte para SDIO completo solo está en la versión máxima de este chip. Y dado que este controlador tiene muchos contactos libres, se decidió realizar otras funciones de baja velocidad en ellos. Considere un fragmento de un diagrama de circuito eléctrico, desde el cual su lista será visible.



En realidad, las señales relacionadas con SDIO y el cambio de tarjeta SD se resaltan en rojo. Procedemos a considerar los colores restantes de la luz de fondo.

Unidad flash SPI

La segunda técnica común para actualizar el "firmware" de los dispositivos de destino es con una unidad flash SPI. Hoy en día, esto no es cada vez más SPI, sino Quad-SPI. El principio es el mismo. Rellenó los datos, luego conectó la unidad flash al dispositivo y la encendió. El mecanismo Bootstrap "absorberá" el firmware en la RAM al inicio.

Aquí se aplica el mismo esquema, con interruptores analógicos:



Bueno, las líneas relacionadas con el trabajo con una unidad flash se resaltaron en verde.

Relés de estado sólido bajo

Periódicamente, surge la tarea de simular la presión de botones en el dispositivo. Una situación típica: los probadores deben verificar el funcionamiento del menú del dispositivo de destino. No, una vez que puedas repasar todos los puntos, ¿pero si los desarrolladores hacen cambios? Para automatizar el proceso, es mejor si los botones para navegar por el menú se realizarán automáticamente (el sistema operativo en el dispositivo de destino puede tomar capturas de pantalla o escaneando el bus que va a la pantalla usando el sniffer al FPGA). Bueno, hay muchas otras tareas en las que necesita simular mediante programación presionar un botón. Para esto, se agregan relés de estado sólido al circuito:



... y sus líneas de control se resaltaron en azul.

Configuración de puentes USB-SPI / I ² C

En un artículo anterior, noté que los puentes FTDI en los que se implementan los autobuses SPI e I ² C tienen patas de control CFG0 y CFG1. En general, lo más probable es que nadie necesite cambiar sus valores predeterminados (todos ceros), pero si es necesario, las líneas que controlan estas señales también salen del controlador STM32 en cuestión y se resaltan en púrpura.

Reinicio del dispositivo USB

Durante el desarrollo del sistema, se decidió que, teóricamente, los dispositivos podrían "congelarse". Por ejemplo, los puentes FTDI de la primera serie tenían la propiedad de "congelarse" con "terreno" inestable. Sí, eso fue hace más de diez años. Sí, dentro del complejo, la tierra es extremadamente estable, ya que el puente está en el mismo edificio que la computadora. Pero de repente. En general, en el ToR se estableció la posibilidad de restablecer cualquiera de los dispositivos. Las solicitudes correspondientes son generadas por el mismo controlador STM32 y resaltadas en amarillo.

Acceso programático al controlador STM32

Como puede ver, la mayoría de los dispositivos descritos anteriormente no son estándar. Más precisamente, la mayoría de ellos se pueden clasificar como GPIO, pero no hay un estándar de facto para ello. La parte más difícil de los dispositivos es el lector de tarjetas SD. Por lo tanto, se decidió implementar la funcionalidad del lector SD en el controlador STM32 (afortunadamente, el entorno STM Cube MX le permite hacer esto escribiendo solo unas pocas líneas de su propio código) e implementar el resto de las funciones que el proveedor solicita al dispositivo de almacenamiento masivo subyacente al lector. Pero como se decidió hace varios artículos, las grandes narrativas son inconvenientes para la lectura. Por lo tanto, los principios de envío de comandos al Dispositivo de almacenamiento masivo desde Linux y ejemplos de acceso programático al dispositivo resultante se examinarán la próxima vez.