Trabalhar com o complexo de pneus personalizados Redd

No último artigo, começamos a nos familiarizar com como você pode trabalhar com pneus conhecidos e comuns usando o complexo Redd, depois do qual prometi seguir em frente para obter acesso a pneus mais exóticos. Mas, depois de conversar com alguns conhecidos, repentinamente percebi que nem todo mundo lia o artigo que foi escrito sobre o complexo de Redd fora deste ciclo. E, consequentemente, nem todo mundo sabe por que esses pneus foram adicionados ao complexo. É claro que você pode apenas se referir a esse artigo , mas parece-me que será mais correto recontar sua parte correspondente com referência ao tema desse ciclo em particular. Portanto, hoje consideraremos não apenas questões práticas, mas também teóricas sobre pneus vendidos pelo complexo Redd.

Parte teórica chata

O que consideraremos

Vamos brevemente (na medida do possível) examinar algumas questões teóricas para entender claramente por que tudo é feito no complexo Redd, de uma maneira ou de outra. Primeiro de tudo, a principal tarefa do complexo ... Por incrível que pareça, como parte dessa série de artigos, nunca escrevi sobre isso. Sim, e não pretendo escrever. O fato é que a principal tarefa é um acesso remoto conjunto à depuração de determinado hardware (de microcontroladores a enormes sistemas de processadores com vários núcleos). Reserva de tempo de trabalho, proporcionando acesso físico através de canais de péssima qualidade (e não apenas ideal) e outras delícias. A depuração pode ser por meio do JTAG ou de outras ferramentas fornecidas pelos ambientes de desenvolvimento. Uma grande equipe está trabalhando nisso, tudo é muito interessante por lá, mas eu não gosto de nenhuma burocracia, então não quero escrever sobre esses tópicos. Talvez no futuro, alguém mais preencha essa lacuna ... Enquanto isso, estou escrevendo sobre as ferramentas auxiliares do complexo.

Sim, sim, tudo o que descrevo há mais de seis meses são apenas coisas que foram projetadas para ajudar os desenvolvedores.

Por que no complexo padrão Redd os pneus são implementados

Muitas vezes você precisa desenvolver um equipamento sem ter acesso a ele. Vejamos um exemplo específico de um projeto que possui bons links. Aqui, por exemplo, estão meus helicópteros favoritos. Estamos aqui e helicópteros estão na Suécia. Além disso, pedimos desenvolvimento no inverno, quando os helicópteros fisicamente não podiam desempenhar as funções que implementamos para eles (a saber, fertilizar o solo nas florestas: o solo naquela época estava sob nevascas). Acontece que os dispositivos instalados no helicóptero devem ser emulados durante a depuração e o voo - virtualmente.

Mas isso é depuração. Ao testar um projeto, a emulação é a única opção. O testador deve verificar tudo no número máximo de modos, classificando através de várias combinações. Além disso, ele deve criar situações com condições críticas e de emergência (um trabalho tão destrutivo para os testadores). Como fazer isso em equipamentos reais? Somente em emuladores.

Como está indo a comunicação com dispositivos modernos? Geralmente - através de barramentos padrão, porque os desenvolvedores de dispositivos tendem a se conectar através de algo já conhecido pelos consumidores. Isso é apenas Redd e atuará como um emulador de muitos dispositivos. Seus barramentos estão conectados ao bloco desenvolvido. E a unidade terá certeza de que trabalha com equipamentos reais, sem saber que na outra extremidade dos pneus não há um monte de ferro, mas o complexo Redd, no qual vários emuladores estão girando.

Ao trabalhar com equipamentos reais, os pneus podem atuar como analisadores, registrando o trabalho com hardware real para analisar voos em caso de problemas.

Em geral, deve haver o maior número possível de pneus, e sua configuração o mais variada possível. Embora, em tudo que você precisa saber a medida. Bem, apenas porque cada barramento custa algum dinheiro e ocupa espaço no gabinete e também no conector. Agora vamos considerar quais estratégias são melhor usadas para controlar esses barramentos programaticamente.

Quem liderará o desenvolvimento de código para Redd

Nas empresas modernas, Sua Majestade horas-homem está na vanguarda. O fato é que esse é um recurso muito caro em muitos aspectos (dinheiro, tempo de desenvolvimento, disponibilidade de um especialista neste momento específico para esta e outras tarefas da empresa etc.); portanto, se a gerência puder economizar horas, ela fará isso. Se for possível não adicionar desenvolvedores à equipe, eles não serão adicionados. Se for possível fazer tudo em menos tempo, eles nocautearão os desenvolvedores para que possam fazê-lo em menos tempo.

Daqui resulta que é improvável que eles forneçam especialistas individuais para escrever emuladores. E se o fizerem, serão programadores comuns que trabalham na mesma empresa.

Por que estou escrevendo isso? Em alguns artigos, é considerado chique quando alguns idiomas especializados são usados ​​para as tarefas de manutenção de pneus fora do padrão. Eu tive a chance de trabalhar com algo assim. Deixe-me descrever minhas impressões sobre o exemplo de coisas que já foram publicadas. Aqui, por exemplo, https://www.astrosoft.ru/about/clients/bvg-group/case-959/ . Além disso, a linguagem GOST saiu recentemente até GOST. Minha opinião é a seguinte: o que era necessário no final dos anos 70 - início dos anos 80, depois absolutamente não necessário no final do primeiro quartel do século XXI. Aqui está um maravilhoso artigo de Konstantin Chizhov, no qual a coisa mais importante dessa linguagem (grupos de contato) é perfeita e quase gratuita, implementada por metaprogramação em C ++ http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na- si.html . Este artigo verifica tudo quanto ao AVR. Fiz uma ótima verificação da opção da biblioteca para o Cortex M, os resultados também são surpreendentes. Os otimizadores empacotam tudo de tal maneira que o desenvolvimento direto no assembler não trará nenhum ganho. E isso se aplica não apenas aos grupos de contatos, mas em geral a todos os drivers do mcucpp. É uma pena que as autoridades não tenham permitido essa ideologia no MAX RTOS, portanto os resultados da pesquisa não foram publicados. Mas em casa eu uso apenas essa biblioteca.

Todas as outras coisas implementadas no YASTEK também são perfeitamente empacotadas na construção C ++. Mas a interatividade para o operador na junção dos anos setenta e oitenta não era. É verdade que não estava nos compiladores de Pascal, C e outros idiomas da época. Na maioria das vezes, os compiladores eram em lote e simplesmente geravam texto do assembler sem nenhuma ferramenta de depuração. Ao fazer o remake do YASTEC, adicionamos operadores para a saída de dados na tela e até mesmo um depurador interativo, mas, de qualquer maneira, essas são meias medidas no contexto do que está acontecendo em ambientes de desenvolvimento prontos para linguagens de programação comuns. Em suma, os tempos em que havia razões técnicas para tornar a linguagem especial do YASTEK há muito tempo. Hoje, em uma linguagem de programação comum, é possível obter o mesmo e muito mais.

Alguém pode dizer que não foram especialistas em C ++ que escreveram o código lá, mas personalizadores comuns ... É assim que é, mas eu já notei que programadores comuns escreverão o código para Redd. Não há sentido para a gerência manter um especialista restrito para tarefas ocasionais. E não faz sentido para um especialista comum aprender outro idioma.

E que outras características expressivas isso terá? Ao desenvolver emuladores, você pode precisar de coisas completamente exóticas. Por exemplo, para o emulador de GPS no modo interativo, controlamos o uso do joystick. Que linguagem orientada a problemas a suporta? E a flexibilidade desses idiomas ainda é. Por fim, a reutilização do código no YESTEK discutido não está à altura, mas a busca de soluções prontas na rede ... Mesmo em idiomas comuns, não é apenas um bom exemplo, mas também exótico.

O mesmo se aplica a esse caso , que suavemente se transformou em tal caso . No âmbito da automação empresarial, o SIMATIC, com seu sistema avançado de configuração e programação, é bom, mas, para um projeto pequeno, criou mais problemas do que resolveu, sendo substituído por uma solução mais universal.

No total, concluímos que o trabalho de programadores comuns em suas linguagens usuais é normal para Redd. Para outras tarefas - é discutido e, especificamente, para tarefas auxiliares resolvidas pelo complexo Redd, é normal.

Como implementar pneus

Mas se dissermos que programadores comuns usarão os pneus em suas linguagens habituais, as bibliotecas para trabalhar com esses barramentos deverão ser o mais típico possível. Em particular, a frase foi notada imediatamente: "E vamos colocar microcontroladores no complexo, e os programadores escreverão tudo sobre eles". Esta opção novamente requer especialistas nesses controladores. Além disso, requer sincronização séria entre subsistemas. Foi decidido que, se possível, o programador deve trabalhar no familiar processador central do PC. "Mas e os FPGAs?", Você pergunta. Bem, opa, provavelmente todo mundo percebeu que, para os FPGAs, escolhi a ideologia do "desenvolvimento mínimo no Verilog, o máximo familiar aos programadores". Lá você não pode fazer isso de forma mais conveniente. Mas estamos trabalhando duro.

Portanto, implementações típicas de pneus. Com o UART, tudo está claro. Com o SPI / I ² C, várias opções foram consideradas, uma vez que não existe um padrão de fato estabelecido para os PCs. Mas havia um desejo de fazer sem a opção de escrever um conjunto completo: "firmware" do controlador, driver e bibliotecas. Eu queria levar algo pronto. No entanto, até o final, consideramos a opção com microcontroladores que implementam no nível USB e no depurador Cypress. O ponto disso foi colocado pelas descobertas descritas no artigo sobre DMA . É impossível garantir a largura de banda solicitada no TOR se todos os barramentos com fluxos de dados anteriormente desconhecidos funcionarem simultaneamente. E se espalharmos por vários controladores - descansamos na largura de banda do USB 2.0 FS. Portanto, apenas pontes FTDI. Uma ponte é uma função e o USB 2.0 HS fornece largura de banda.

A propósito, na última seção, sempre me referi à linguagem C ++ comum. O fato é que, nesta fase da jornada da minha vida, essa é minha principal linguagem de programação (embora nem sempre fosse esse o caso). Mas soluções padrão, são padrão para funcionar perfeitamente em outras linguagens comuns hoje em dia, seja Python, Java ou outra coisa. Portanto, se um especialista nessas línguas for jogado em batalha, ele, usando essas línguas, fará tudo com menos facilidade. Essa é a beleza das soluções universais.

Mas existem alguns pneus que são bobos para colocar chips caros de FTDI. Falaremos sobre como eles são implementados no complexo.

Mil pequenas coisas

Por que o complexo Redd tem um cartão SD comutado

Vários dispositivos em desenvolvimento estão atualizando seu “firmware” usando um cartão SD. Na maioria das vezes, o “firmware” é derramado no cartão na forma de um arquivo, após o qual o dispositivo é desligado e, quando ligado, ele detecta o arquivo de atualização e o aplica. Recentemente, envolvi-me em uma nova placa para uma das minhas impressoras 3D. Lá, o "firmware" do Marlin 2.0, após alguns dos comandos M (não me lembro do código exato), abriu o conteúdo do SD através do barramento USB, para que eu pudesse injetar atualizações sem truques. Conectei via USB, após o que sabia que havia desligado / ligado (como fazê-lo com a ajuda do complexo Redd, examinamos no artigo anterior ), dei o comando para conectar o cartão SD ao USB, esperei o disco aparecer, preencheu o “firmware”, desligou / ligou novamente e esperou . O firmware foi atualizado. Mas nem tudo é tão bonito. Às vezes, um cartão SD precisa ser preparado com antecedência. A propósito, se você adicionar a curva “firmware” à impressora 3D, a opção ideal descrita acima também não funcionará, e você também precisará preparar o cartão com antecedência. E, ao desenvolver, crie um "firmware" que não funcione - algumas ninharias.

Nesse caso, o complexo Redd possui um cartão SD comutado. No diagrama do circuito elétrico, está incluído da seguinte forma:



Inicialmente, tentamos encontrar uma solução típica que permitisse alternar o barramento SDIO (não SPI, ou seja, SDIO, os dispositivos também podem funcionar por essa interface) via FPGA. Descobriu-se que uma solução bonita não existe. Mesmo as soluções dos fabricantes de FPGA são complexas e pouco credíveis. Portanto, foram fornecidas chaves analógicas que conectam fisicamente a placa a um conector externo ou a um leitor como parte do Redd. Portanto, o algoritmo de operação é o seguinte: conectado a um leitor, arquivos preparados usando o SO Linux, conectado ao dispositivo de destino. Nós usamos lá.

Como trabalhar com o sistema de arquivos não pertence a coisas críticas (estamos apenas preparando os dados, portanto não é necessária velocidade especial), foi decidido criar um leitor baseado no microcontrolador STM32F103. O suporte para SDIO completo está apenas na versão máxima deste chip. E como esse controlador possui muitos contatos gratuitos, foi decidido fazer outras funções de baixa velocidade neles. Considere um fragmento de um diagrama de circuito elétrico, a partir do qual sua lista será visível.



Na verdade, os sinais relacionados à troca de SDIO e cartão SD são destacados em vermelho. Passamos a considerar as cores de luz de fundo restantes.

Unidade flash SPI

A segunda técnica comum para atualizar o "firmware" dos dispositivos de destino é com uma unidade flash SPI. Atualmente, isso não é cada vez mais SPI, mas Quad-SPI. O princípio é o mesmo. Preencha os dados, conecte a unidade flash ao dispositivo e ligue-a. O mecanismo Bootstrap "sugará" o firmware para a RAM na inicialização.

O mesmo esquema é aplicado aqui - com comutadores analógicos:



Bem, as linhas relacionadas ao trabalho com uma unidade flash foram destacadas em verde.

Relés de estado sólido baixos

Periodicamente, surge a tarefa de simular o pressionamento de botões no dispositivo. Uma situação típica: os testadores precisam verificar a operação do menu do dispositivo de destino. Não, uma vez que você pode revisar todos os pontos, mas se os desenvolvedores fizerem alterações? Para automatizar o processo, é melhor que os botões para navegar no menu sejam feitos automaticamente (as capturas de tela podem ser feitas pelo sistema operacional no dispositivo de destino ou digitalizando o barramento que vai para a tela usando o sniffer para o FPGA). Bem, existem muitas outras tarefas nas quais você precisa simular programaticamente um pressionamento de botão. Para isso, relés de estado sólido são adicionados ao circuito:



... e suas linhas de controle foram destacadas em azul.

Configurando pontes USB-SPI / I ² C

Em um artigo anterior, observei que as pontes FTDI nas quais os barramentos SPI e I ² C são implementados possuem pernas de controle CFG0 e CFG1. Em geral, provavelmente, ninguém precisará alterar seus valores padrão (todos os zeros), mas, se necessário, as linhas que controlam esses sinais também deixam o controlador STM32 em questão e foram destacadas em roxo.

Redefinição do dispositivo USB

Durante o desenvolvimento do sistema, foi decidido que, puramente teoricamente, os dispositivos poderiam "congelar". Por exemplo, as pontes FTDI da primeira série tinham a propriedade de “congelar” com “terreno” instável. Sim, isso foi há mais de dez anos. Sim, dentro do complexo, a terra é extremamente estável, pois a ponte está no mesmo prédio que o computador. Mas de repente. Em geral, no ToR havia a possibilidade de redefinir qualquer um dos dispositivos. Os pedidos correspondentes são gerados pelo mesmo controlador STM32 e destacados em amarelo.

Acesso programático ao controlador STM32

Como você pode ver, a maioria dos dispositivos descritos acima não é padrão. Mais precisamente, a maioria deles pode ser classificada como GPIO, mas não existe um padrão de fato para ele. A parte mais difícil dos dispositivos é o leitor de cartão SD. Portanto, foi decidido implementar a funcionalidade SD Reader no controlador STM32 (felizmente, o ambiente STM Cube MX permite fazer isso escrevendo apenas algumas linhas do seu próprio código) e implementar o restante das funções conforme o fornecedor solicitar ao dispositivo de armazenamento em massa subjacente ao leitor. Mas, como foi decidido há vários artigos, as enormes narrativas são inconvenientes para a leitura. Portanto, os princípios de envio de comandos para o dispositivo de armazenamento em massa do Linux e exemplos de acesso programático ao dispositivo resultante serão examinados na próxima vez.