Congratulo-me com todos.
Seguindo os traços dos artigos anteriores sobre analisadores lógicos em Habré, decidi terminar meu trabalho "fundamental".
Vou começar um pouco de longe.
Tudo começou no início dos anos 10, quando descobri sobre a Saleae Logic (a seguir denominada Saleae, quero dizer um analisador de 8 canais sem controle deslizante) em algum fórum de rádio amador.
Tomou nota. Mas já com 13 anos no processo de implementação de outro projeto, me deparei com o fato de que realmente precisava de um analisador lógico com um buffer grande. O osciloscópio e o hanteck la-5034 disponíveis na época não resolveram o problema.
A principal característica do Saleae e seus clones é a falta de um buffer embutido - todo o fluxo é imediatamente perseguido para o PC e salvo lá. Em seguida, pode ser analisado, decodificado e exportado. Por um lado, somos praticamente ilimitados em profundidade de visualização (os dados podem ser armazenados por horas); por outro lado, a frequência máxima de amostragem é de 24 MHz. Na maioria dos casos, porém, devido à natureza programática da amostragem, as amostras têm um "tremor" perceptível.
Como resultado, muito rapidamente, em cerca de um dia, de Kharkov, do 6 laboratório (agora falecido), eles me enviaram via clones seu clone de saleae com dois eeproms já incorporados para alternar os tipos de saleae e xbee (o hardware desses dispositivos é o mesmo vid difere: pid que são mostrados em eeprom).
Consequentemente, você pode usar software de ambos os fabricantes.
Foi quando me interessei por algo como Y7C68013A, bem ou mais curto que o FX2 (embora seja mais correto que o FX2LP).
Este é um microcontrolador compatível com o 8051, com uma porta USB2.0 de hardware e 480Mb / s honestos.
Os recursos incluem: 16KB de RAM e a capacidade de baixar firmware de um I2C EEPROM conectado e via USB (não há flash embutido).
E este MK pode fingir ser qualquer dispositivo no barramento USB (no sentido de responder a qualquer VID: PID).
Alguns detalhes da folha de dados sobre o procedimento de carregamento
Considere o caso quando um I2C EEPROM está conectado ao MK.
Nesse caso, os primeiros 8 bytes são analisados a partir dele:
Se o primeiro byte for 0xC0 (como no firmware do clone Saleae), o MK configurará a porta USB com o VID: PID especificado em 1 a 4 bytes e aguarda o download do firmware via USB. Dependendo do VID piscado: o PID MK pode "ser" um dispositivo diferente, pelo menos uma área pelo menos Xbee pelo menos por alguém. Muito confortável Você pode soldar as EEPROMs em uma pilha e selecionar com um jumper.
Mas se o primeiro byte for 0xC2, começando com 9 bytes, o firmware do MK deve ser armazenado na EEPROM, que será carregado na RAM e começará a ser executado.
O formato de armazenamento é semelhante ao HEX da Intel:
Ou seja, o firmware é dividido em blocos carregados individualmente em diferentes seções da memória. E, portanto, não faz sentido armazenar áreas vazias.
E agora estamos nos aproximando do personagem principal do nosso artigo DreamSourseLab.
Não vou recontar toda a história (não a conheço realmente e não vejo nenhum significado mais profundo). São três engenheiros que, através do crowdfunding, viram o projeto do analisador lógico dos sonhos (quase).
O que eles fizeram?
Eles adicionaram ao FX2 uma plisina barata - Spartan 6 (talvez espionado em Saleae).
E são 16 canais ao mesmo tempo, são pontos de amostragem claros, é a capacidade de empacotar bits individuais (duas linhas podem ser amostradas 4 vezes mais que 8, o principal é manter a largura de banda USB). Esta é uma oportunidade para salvar no buffer em alta frequência (400 MHz / 4 canais, 200 MHz / 8 canais, 100 MHz / 16 canais) e depois transferi-lo lentamente para um PC. E se você estragar o sigrok com sua base mais poderosa de protocolos decodificados. Em geral, o projeto foi demitido - todos estão felizes. E levando em conta o fato de que os autores salvaram o modo de fluxo (sem salvar no buffer interno), obtivemos um analisador lógico dos sonhos (bem, quase porque eu queria imediatamente 32 canais e FX3).
Assim apareceu DSLogicPro. Caixa de alumínio preta estrita com conector USB-C.
E então os engenheiros chegaram ao negócio. E eles lançaram caixas com o nome DSLogicBase e DSLogicPlus (como eu entendo conquistar o mundo através de sites chineses), assim como o DSCope (penduramos alguns ADCs de 8 bits e agora temos um osciloscópio de dois canais).
Bem, para manter esse processo sob controle rigoroso, alteramos um pouco o layout da placa. Ou seja, o DSLogicPlus e o DSLogicPro são eletricamente e funcionalmente idênticos, mas a SRAM fica pendurada no plugue dos outros pinos (isso é claramente visto na imagem das faixas). Eu suspeito que melhorias foram feitas em outros lugares.
A propósito, uma revisão muito valiosa foi feita em termos do cabo para conectar os sinais estudados. Se no Pro todas as 16 linhas estiverem conectadas ao mesmo tempo com um conector largo, no Plus, todos os cabos foram divididos em grupos de 4 canais que podem ser conectados separadamente. Bem, os cabos em si são curtos, coaxiais e no local do corte (onde o coaxial é dividido em um sinal separado e em fios comuns), há um pequeno cachecol com filtro.
E assim, na primavera de 17, pedi o DSLogicBase na China (infelizmente, não sabia tudo o que escrevi sobre então). Eles me enviaram tudo, mas, aguardando ansiosamente pelo buffer de 64 mega amostras, eu torci o quadro e vi um lugar vazio. Aumentar rapidamente o butchu retornou 50% do custo. E então ele começou a estudar a questão de transformar minha Base em Plus. Essa é precisamente a diferença entre Base e Plus - a presença de um buffer separado. A base usa memória incorporada no FPGA.
No verão de 17, a caminho do trabalho e de volta por meia hora no trem da MCC, estudei essa questão. E rapidamente ficou claro que as diferenças estavam apenas na SRAM selada e em um par de bytes do firmware da EEPROM.
Um pouco sobre o que está no diretório DSView / res
Lá, temos um conjunto de arquivos com extensões bin e fw.
bin - estes são firmware para plisina. Eles são carregados no momento do início do programa via fx2.
fw são arquivos de firmware binários para FX2.
Se você comparar todos os arquivos fw, todos diferem apenas no byte PID no endereço próximo ao final.
Ou seja, as diferenças entre todos os dispositivos são exatamente isso e o firmware do plugue (que, como eu disse, é carregado no momento da inicialização).
A comparação de fw com o que está escrito na EEPROM (é claro, eu imediatamente joguei o despejo no analisador) mostrou que o firmware implantado está aqui.
Se você implantar o firmware a partir da EEPROM, (pelo que me lembro), eles corresponderão (para a versão de software 0.96).
Assim, como já foi escrito no Habr, você só precisa soldar a memória e alterar os 2 bytes no firmware (no cabeçalho e depois no firmware).
De maneira semelhante, o DSCope é finalizado, dobramos a memória e alteramos o PID na EEPROM.
Há mais uma nuance.
Quando novas versões de software foram lançadas (0,96-0,99), os modelos de hardware suportados foram adicionados e o PID desses modelos foi alterado.
Então, eu tenho um tablet assim:
Além disso, algumas indicações apareceram no firmware no endereço 0x20 para a versão Pro, há 5, para Base e Plus, há 6. Provavelmente, essa é apenas a versão da placa de circuito impresso.
A propósito, há outra maneira de refinar. Não é necessária reprogramação da EEPROM. Basta soldar a SRAM e, ao compilar o libsigrok4DSL, faça uma correção no arquivo libsigrok4DSL / hardware / DSL / dsl.h:
Na estrutura que descreve a const estática do equipamento DSL_profile supported_DSLogic [],
no local em que DSLogic PLus e Base são descritos, altere os campos PID para que o programa pense que possui o PID Base 20 e o PID Plus 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 },
E a sua versão do analisador com esta versão do DSView funcionará como se você tivesse um Plus real.
Enquanto isso, vou sonhar com um monte de Spartan6 + FX3 + DSView.