Doy la bienvenida a todos.
Siguiendo las huellas de los artículos anteriores sobre analizadores lógicos sobre Habré, decidí terminar mi trabajo "fundamental".
Comenzaré un poco desde lejos.
Todo comenzó a principios de los años 10, cuando descubrí por primera vez sobre Saleae Logic (en adelante, Saleae, me refiero a un analizador de 8 canales sin control deslizante) en algún foro de radioaficionados.
Tomó nota. Pero ya a los 13 años, en el proceso de implementación de otro proyecto, me encontré con el hecho de que realmente necesitaba un analizador lógico con un gran búfer. El osciloscopio y el hanteck la-5034 disponibles en ese momento no resolvieron el problema.
La característica principal de Saleae y sus clones es la falta de un búfer incorporado: toda la transmisión se persigue de inmediato en la PC y se guarda allí. Luego se puede analizar, decodificar y exportar. Por un lado, tenemos una profundidad de visualización prácticamente ilimitada (los datos pueden almacenarse durante horas), por otro lado, la frecuencia de muestreo máxima es de 24 MHz. Sin embargo, en la mayoría de los casos, debido a la naturaleza programática del muestreo, las muestras tienen un "jitter" notable.
Como resultado, muy rápidamente, en aproximadamente un día, desde Jarkov, desde el laboratorio 6 (ahora fallecido), me enviaron a través de clones su clon saleae con dos eeproms ya incorporados para cambiar los tipos de saleae y xbee (el hardware de estos dispositivos es el mismo, solo difiere: pid que se muestran en eeprom).
En consecuencia, puede usar software de ambos fabricantes.
Fue entonces cuando me interesé en algo como Y7C68013A, bueno, o más corto que FX2 (aunque es más correcto que FX2LP).
Este es un microcontrolador compatible con 8051 con un puerto USB2.0 de hardware y 480Mb / s honesto.
Las características incluyen: 16 KB de RAM y la capacidad de descargar firmware tanto desde una EEPROM I2C conectada como a través de USB (no hay flash incorporado allí).
Y este MK puede pretender ser cualquier dispositivo en el bus USB (en el sentido de responder a cualquier VID: PID).
Algunos detalles de la hoja de datos sobre el procedimiento de carga
Considere el caso cuando una EEPROM I2C está conectada al MK.
En este caso, los primeros 8 bytes se analizan a partir de él:
Si el primer byte es 0xC0 (como en el firmware del clon Saleae), el MK configura el puerto USB con el VID: PID especificado en 1-4 bytes y espera a que el firmware se descargue a través de USB. Dependiendo del VID flasheado: PID MK puede "ser" un dispositivo diferente, al menos Saleae al menos Xbee al menos por alguien. Muy comodo Puede soldar las EEPROM en una pila y seleccionar con un puente.
Pero si el primer byte es 0xC2, comenzando con 9 bytes, el firmware para MK debe almacenarse en EEPROM, que se cargará en la RAM y comenzará a ejecutarse.
El formato de almacenamiento es similar al HEX de Intel:
Es decir, el firmware se divide en bloques que se cargan individualmente en diferentes secciones de la memoria. Y en consecuencia, no tiene sentido almacenar áreas vacías.
Y ahora nos estamos acercando sin problemas al personaje principal de nuestro artículo DreamSourseLab.
No volveré a contar toda la historia (realmente no lo sé y no veo ningún significado más profundo). Estos son tres ingenieros que, a través del crowdfunding, vieron el proyecto del analizador lógico de sueños (casi).
¿Qué hicieron ellos?
Agregaron al FX2 una plisina barata: Spartan 6 (tal vez espió a Saleae).
Y estos son 16 canales a la vez, estos son puntos de muestreo claros, esta es la capacidad de empaquetar bits individuales (se pueden muestrear dos líneas 4 veces más que 8, lo principal es mantenerse dentro del ancho de banda USB). Esta es una oportunidad para guardar en el búfer a alta frecuencia (400 MHz / 4 canales, 200 MHz / 8 canales, 100 MHz / 16 canales), y luego transferirlo lentamente a una PC. Y si atornillas sigrok con su base más poderosa de protocolos decodificados. En general, el proyecto se disparó: todos están contentos. Y teniendo en cuenta el hecho de que los autores guardaron el modo de transmisión (sin guardar en el búfer interno), obtuvimos un analizador lógico de sueños (bueno, casi porque inmediatamente quería 32 canales y FX3).
Así apareció DSLogicPro. Caja de aluminio negra estricta con conector USB-C.
Y luego los ingenieros llegaron al negocio. Y lanzaron cajas con los nombres DSLogicBase y DSLogicPlus (tal como lo entiendo por conquistar el mundo a través de sitios chinos), así como DSCope (colgamos un par de ADC de 8 bits y ahora tenemos un osciloscopio de dos canales).
Bueno, para mantener este proceso bajo estricto control, cambiamos un poco el diseño de la placa. Es decir, el DSLogicPlus y el DSLogicPro son idénticos eléctrica y funcionalmente, pero la SRAM se cuelga del enchufe en los otros pines (esto se ve claramente en la imagen de las pistas). Sospecho que se han realizado mejoras en otros lugares.
Por cierto, se realizó una revisión muy valiosa en términos del cable para conectar las señales estudiadas. Si en Pro las 16 líneas están conectadas a la vez con un conector ancho, en Plus, todos los cables se dividieron en grupos de 4 canales que se pueden conectar por separado. Bueno, los cables en sí son cortos, coaxiales y en el lugar de corte (donde el coaxial se divide en una señal separada y cables comunes) hay una pequeña bufanda con un filtro.
Y así, en la primavera del 17, pedí DSLogicBase en China (desafortunadamente, no sabía todo sobre lo que escribí entonces). Me enviaron todo, pero esperando el búfer de 64 megamuestras, desenrosqué el tablero y vi un lugar vacío. Subir rápidamente el butchu devolvió el 50% del costo. Y luego comenzó a estudiar la cuestión de convertir mi Base en Plus. Esta es precisamente la diferencia entre Base y Plus: la presencia de un búfer separado. Base utiliza memoria integrada en el FPGA.
En el verano del 17, de camino al trabajo y de regreso durante media hora en el tren de MCC, estudié este tema. Y rápidamente se hizo evidente que las diferencias solo estaban en la SRAM sellada y un par de bytes de firmware EEPROM.
Un poco sobre lo que hay en el directorio DSView / res
Allí tenemos un conjunto de archivos con extensiones bin y fw.
bin: estos son firmware para plisina. Se cargan al momento de iniciar el programa a través de fx2.
fw son archivos de firmware binarios para FX2.
Si compara todos los archivos fw, resulta que todos difieren solo en el byte PID en la dirección cerca del final.
Es decir, las diferencias entre todos los dispositivos son solo esto y el firmware del enchufe (que, como dije, se carga en el momento de la inicialización).
La comparación de fw con lo que está escrito en la EEPROM (por supuesto, inmediatamente descargué el volcado de mi analizador) mostró que el firmware implementado está aquí.
Si implementa el firmware desde EEPROM, entonces (hasta donde recuerdo) coincidirán (para la versión de software 0.96).
Por lo tanto, como ya está escrito en el concentrador, solo necesita soldar la memoria y cambiar 2 bytes en el firmware (en el encabezado y luego en el firmware).
De manera similar, DSCope está finalizado, duplicamos la memoria y cambiamos el PID en la EEPROM.
Hay un matiz más.
A medida que se lanzaron nuevas versiones de software (0.96-0.99), se agregaron los modelos de hardware compatibles y se modificó el PID de estos modelos.
Entonces obtuve una tableta así:
Además, apareció alguna indicación en el firmware en la dirección 0x20 para la versión Pro hay 5, para Base y Plus hay 6. Lo más probable es que esta sea solo la versión de la placa de circuito impreso.
Por cierto, hay otra forma de refinar. No se requiere reprogramación EEPROM. Es suficiente para soldar SRAM, y luego, al compilar libsigrok4DSL, corrija el archivo libsigrok4DSL / hardware / DSL / dsl.h:
En la estructura que describe la estructura estática del equipo DSL_profile support_DSLogic [],
en el lugar donde se describen DSLogic PLus y Base, cambie los campos PID para que el programa piense que tiene Base PID 20 y Plus PID 21.
319 {0x2A0E, 0x0020, "DreamSourceLab", "DSLogic PLus", NULL, 320 "DSLogicPlus.fw", 321 "DSLogicPlus.bin", 322 "DSLogicPlus.bin", 323 {CAPS_MODE_LOGIC, 324 CAPS_FEATURE_VTH | CAPS_FEATURE_BUF, 325 (1 << DSL_STREAM20x16) | (1 << DSL_STREAM25x12) | (1 << DSL_STREAM50x6) | (1 << DSL_STREAM100x3) | 326 (1 << DSL_BUFFER100x16) | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4), 327 SR_MB(256), 328 0, 329 DSL_BUFFER100x16, 330 0, 331 0, 332 DSL_STREAM20x16, 333 SR_MHZ(1), 334 SR_Mn(1), 335 0, 336 0} 337 }, 338 339 {0x2A0E, 0x0021, "DreamSourceLab", "DSLogic Basic", NULL, 340 "DSLogicBasic.fw", 341 "DSLogicBasic.bin", 342 "DSLogicBasic.bin", 343 {CAPS_MODE_LOGIC, 344 CAPS_FEATURE_VTH, 345 (1 << DSL_STREAM20x16) | (1 << DSL_STREAM25x12) | (1 << DSL_STREAM50x6) | (1 << DSL_STREAM100x3) | 346 (1 << DSL_BUFFER100x16) | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4), 347 SR_KB(256), 348 0, 349 DSL_STREAM20x16, 350 0, 351 0, 352 DSL_STREAM20x16, 353 SR_MHZ(1), 354 SR_Mn(1), 355 0, 356 0} 357 },
Y la versión de su analizador con esta versión de DSView funcionará como si tuviera un Plus real.
Mientras tanto, soñaré con un montón de Spartan6 + FX3 + DSView.