Experiência no uso de monitores LCD baseados em produtos MELT

Este artigo é dedicado a uma emocionante aventura de aventura pela qual tive que passar no processo de criação de um sensor externo atualizado para a estação meteorológica descrita aqui neste artigo há um ano e meio. De acordo com a experiência operacional da versão anterior, eu realmente queria criar um sensor com uma tela de controle para que fosse possível verificar periodicamente (e verificar) o componente mais caprichoso da estação - o sensor de velocidade do vento. As aventuras começaram quando comecei a selecionar uma exibição para esse fim e, por várias razões, sobre as quais me deparei com os produtos do meu MELT nativo. Mas antes de continuar descrevendo as técnicas de maneiras sexuais não tradicionais de lidar com os produtos dessa empresa que escolhi, vale a pena me concentrar brevemente na principal razão de toda essa grandiosa modernização que comecei.

Nos comentários a esse artigo, fui corretamente apontado sobre o design dos sensores que o eixo desse dispositivo deve ter uma ponta sólida e repousar em uma base igualmente sólida (lembre-se de um relógio de pulso “com tantas pedras”). Obviamente, eu sabia disso, mas não conseguia pensar em uma maneira de fornecer a um eixo de luz um ponto agudo de dureza suficiente; então, pelo contrário, tomei o caminho de minimizar o atrito imergindo uma ponta de latão (para cata-vento) ou dural (para sensor de velocidade) em um PTFE macio (consulte .Relator no artigo especificado). No total entendimento de que essa decisão é temporária e de curta duração, e em um futuro próximo será necessário apresentar algo mais substantivo.

O resultado das duas últimas temporadas de operação mostrou, no entanto, que essa solução é bastante adequada para um cata-vento, que, é claro, serrou a base fluoroplástica no metal com um eixo de latão, mas não o machucou - o atrito mínimo não é necessário lá, mesmo parcialmente vice-versa. Era pior com um sensor de velocidade, no qual não apenas o fluoroplástico era serrado na base, mas também a própria ponta de uma duralumínio macia, com dois milímetros de comprimento. Como resultado, em primeiro lugar, o limiar de partida foi inaceitavelmente aumentado e o sensor teve que ser modernizado. O próprio anemômetro também passou por modernização, uma vez que o disco laser com base no qual foi feito estratificado pelo sol e adquiriu uma aparência desarrumada (eu também não sabia anteriormente que os discos compactos consistem em duas camadas).

Espero contar mais sobre o novo sensor posteriormente, depois de pelo menos um pouco de operação, e você pode garantir que não precise modificar nada de uma vez (ou seja, não antes do início do verão). E agora apenas alguns detalhes sobre as alterações no circuito de medição, pois estão relacionadas ao tópico principal deste artigo.

Sobre o circuito de medição do sensor


Em conexão com a redução do limiar de partida, surgiu a questão do tempo considerável necessário para medir as baixas frequências provenientes do sensor de velocidade (para detalhes, consulte esta publicação sobre métodos para medir baixas frequências). Para não limitar o limiar de partida artificialmente, neste caso, devemos medir frequências a partir de 1-2 hertz: levando em consideração que o sensor possui 16 orifícios em um círculo (veja a foto do sensor no artigo original ), isso corresponde a aproximadamente uma rotação em 8-16 segundos, que é obviamente mais baixo do que qualquer limite para iniciar. Ou seja, o tempo limite para aguardar a chegada do próximo pulso de frequência deve ser de pelo menos 1 s (consulte o artigo indicado sobre métodos de medição), o que faz sentido para a história de economia de energia: para obter um tempo de atualização aceitável e ao mesmo tempo gerenciar a média dos dados para evitar vibrações na tela, temos que ativar o controlador a cada dois segundos. E se metade deles demorar algum tempo para aguardar os pulsos, não haverá economia de energia - levando em consideração o fato de que o LED emissor do sensor está funcionando o tempo todo, consumindo cerca de 20 mA.

Alguns detalhes entre parênteses
Observo entre parênteses que, em conexão com esse problema, lembrei-me imediatamente do medidor atual que foi projetado em nossa agência de design no início dos anos 80, mesmo antes do surgimento de todos os tipos de controladores. A verdadeira média dos vetores foi implementada: a gravação de todas as leituras foi registrada em clock pelo sinal da plataforma giratória do próprio sensor de velocidade - um análogo aproximado do despertar de uma interrupção externa. Em outras palavras, se não houver corrente, nenhuma gravação foi feita e o circuito não consumiu nada - apenas os relógios em tempo real funcionavam. O limiar para o início dessa plataforma giratória, feito na forma de um impulsor com flutuabilidade zero, era, para dizer a verdade, 2-3 cm / s, e o medidor indicava a direção girando o corpo inteiro. Então está na água, que é 700 vezes mais densa que o ar! Durante o tempo médio, que chegava a horas, esse cata-vento girava pelo menos uma vez, porque quase não havia medições vazias lá. E para uma estação meteorológica, como já mencionado , um método de média matematicamente correto não é adequado, pois, na ausência de vento, deve mostrar algo real. Portanto, aqui não podemos prescindir de um tempo limite artificialmente limitado para aguardar pulsos do sensor.

É possível equipar o controle complexo do despertar do controlador a partir de duas fontes: normalmente a partir de uma interrupção externa do sensor de velocidade (ou seja, enquanto aguarda pulsos do sensor, o controlador também entra no modo de economia de energia) e, na ausência de vento, ele é forçado pelo Watchdog. Isso faria sentido apenas ao alterar o princípio de ler o sensor de velocidade de circuitos ópticos para menos consumíveis de energia (que ainda precisam ser procurados - o sensor Hall, por exemplo, consome 5-10 mA, o que é fundamentalmente menor que o design óptico). Mas tudo foi simplificado devido ao fato de meu sensor agora ser alimentado por uma bateria solar, o que me permitiu simplesmente abandonar o modo de economia de energia.

Para registrar as leituras, não me incomodei com os temporizadores nem contei o Arduino millis (), mas simplesmente configurei um gerador de frequência externo primitivo com um período de cerca de 1,5 segundos no timer 555:


Como lembramos, o circuito do sensor usa o controlador Atmega328 “bare” no pacote DIP, programado via Uno e instalado no soquete; o Arduino em si é usado apenas para prototipagem. A saída do gerador foi conectada ao pino de interrupção INT0, pino 4 do microcircuito (pino D2 da placa Uno). A interrupção da diferença positiva (RISING) define um determinado sinalizador, segundo o qual a próxima leitura é feita no ciclo principal. A frequência do sensor também é medida pelo método de interrupção (a saída do sensor é conectada à entrada de interrupção INT1, pino 4 (D3), consulte o último método no mesmo artigo ), porque o tempo total total de espera é o dobro do período da frequência medida. Com um tempo limite de 1 segundo, portanto, a frequência mínima medida é de 2 Hz (uma rotação do anemômetro em 8 segundos). Em cada quarto ciclo, ocorre a média e os dados finalizados são enviados para o módulo principal, ou seja, as leituras são atualizadas aproximadamente a cada 6 segundos.

Toda a história com um sensor atualizado terá que ser calibrada e verificada periodicamente para ver se o atrito aumentou, comparando as leituras com um anemômetro manual. Portanto, é muito inconveniente quando as leituras são exibidas em um local (em casa) e o sensor externo é instalado em um local completamente diferente - no mirante do jardim. Surgiu a pergunta sobre a instalação de um LCD de controle na carcaça do sensor. Como a beleza não é necessária aqui, os requisitos de informação são mínimos: uma tela de 10 caracteres com uma única linha é suficiente. Mas os requisitos geométricos são bastante rigorosos: a tela deve caber no caso existente em largura, que é de 70 mm. Devo dizer que, devido à minha antipatia orgânica por telas de LCD (pouco brilho, baixo contraste, com letras pequenas, qualidade repugnante de luz de fundo e também consome muito, mais sobre isso mais tarde), quase não estou ciente da faixa disponível no varejo. E, portanto, ficou imediatamente claro que os monitores de que eu precisava eram muito procurados à venda: o monitor LCD padrão de 16x2, dominante nas lojas, possui uma placa de 80 mm e não pode caber no meu sensor, e todos os outros tipos são de tamanho ainda maior, independentemente da empresa. Na natureza, é claro, existem variedades menores, mas depois na natureza, e não no varejo doméstico.

Solução: oh MELT!


No final, descobri dois MELTs ao mesmo tempo que se encaixavam maravilhosamente na minha tarefa. O primeiro deles é um MT-10S1 de 10 caracteres de linha única com um controlador que, segundo os fabricantes, "é semelhante ao HD44780 da HITACHI e KS0066 da SAMSUNG ". Possui caracteres bastante grandes: mais de 8 mm de altura, o que é realmente característico de displays chineses de tamanhos muito maiores. A largura da placa é de 66 mm, as dimensões da tela saliente (externa) são 62x19,5. O consumo neste caso não me incomoda muito (porque o sensor externo é alimentado por uma bateria solar de potência obviamente maior que o necessário), mas por hábito, olhando para a linha da folha de dados, descobri que ele também é menor que o normal - 0,7 mA (todos os LCDs comuns exibições em análogos do HD44780 consomem de 1,2 mA e superior). Ainda há uma luz de fundo na pilha, como é habitual para todos esses tipos - bastante pobres e ao mesmo tempo consumindo muita energia.



A segunda tela do MT-10T7 é ainda mais surpreendente: exatamente nas mesmas dimensões cabem 10 dígitos de sete segmentos com uma altura de até 13 mm. Algumas suspeitas foram causadas por uma interface não padronizada e, aparentemente, criada por você (para a qual o exemplo de programação em pseudocódigo verbal é fornecido na folha de dados). O display não contém um controlador real: há um conjunto de gatilhos de trava estáticos controlados pela lógica combinacional. Mas, graças a essa simplicidade, todo esse design consome apenas 30 μA, ou seja, é realmente adequado para dispositivos que operam com bateria a qualquer hora (o consumo de 1,4 mA em monitores convencionais e até 0,7 mA no MT-10S1 é muito maior do que o permitido para esse aplicação do valor - calcule por quanto tempo esse monitor funcionará, mesmo sem levar em consideração os componentes restantes do dispositivo, por exemplo, de baterias AAA com capacidade de cerca de 1500 mAh)



Em suma, dê dois!

MT-10T7


Uma tentativa de reproduzir independentemente o algoritmo do MT-10T7, descrito na folha de dados (no Arduino e no assembler puro), não levou ao sucesso. O que foi feito de errado, eu não entendi, porque me deparei com esta publicação , onde o autor (eshkinkot) deu um exemplo muito bem escrito e bem executado de como lidar com o MT-10T7, após o qual tudo funcionou imediatamente. Se alguém estiver interessado, aqui está um exemplo modificado de eshkinkot, complementado por todos os símbolos significativos válidos em indicadores de sete dígitos, incluindo letras que não correspondem aos números:






Nestas fotos, o contraste da tela é ligeiramente distorcido, configurando o divisor para emitir Vo - 18 kOhm (potência): 10 kOhm (terra), embora sem ela o contraste "padrão" seja bastante aceitável.

Adicionei ao exemplo indicado uma função que reproduz um número arbitrário no visor com três a quatro casas decimais - positivo ou negativo, número inteiro ou ponto flutuante, ou seja, o número total de caracteres pode chegar a cinco: "-12,7", por exemplo. Como o ponto no código de sete segmentos não ocupa uma familiaridade separada, o número máximo de bits exibidos é 4. Os parâmetros de entrada para esta função são: a) uma matriz (char buf [5]) contendo uma representação ACSII do número, b) o número real de caracteres nele (ii de 1 a 5) e c) a posição (pos de 0 a 9) onde colocar o primeiro sinal (esquerdo) do número (para as funções e notações usadas ao longo do caminho, consulte a publicação indicada por eshkinkot ou no exemplo por referência):

Código de função
void writeASCIIdig_serial(char buf[5], byte ii, byte pos) //      { boolean dot; //     //  ,   pos: pos=pos+(4-ii); //  ,    : for (byte i=0; i <= ii; i++) if (buf[i]=='.') pos++; // : for (byte i=0; i <= ii; i++){ // .  ,    : if (buf[i+1]=='.') dot=true; else dot=false; switch (buf[i]) { //decoder ASCII -> 7-  case '0': writeSymbol(pos, DIGIT_ZERO, dot); break; case '1': writeSymbol(pos, DIGIT_ONE, dot); break; case '2': writeSymbol(pos, DIGIT_TWO, dot); break; case '3': writeSymbol(pos, DIGIT_THREE, dot); break; case '4': writeSymbol(pos, DIGIT_FOUR, dot); break; case '5': writeSymbol(pos, DIGIT_FIVE, dot); break; case '6': writeSymbol(pos, DIGIT_SIX, dot); break; case '7': writeSymbol(pos, DIGIT_SEVEN, dot); break; case '8': writeSymbol(pos, DIGIT_EIGHT, dot); break; case '9': writeSymbol(pos, DIGIT_NINE, dot); break; case '-': writeSymbol(pos, SYMBOL_MINUS, dot); break; } //end decoder if (buf[i]!='.') pos++; //  ,  +1  }//end for i } 


O módulo MT-10T7 para a saída de controle de valores numéricos é mais conveniente do que os displays de matriz de linhas comuns: possui números grandes e o ponto decimal não ocupa uma familiaridade separada e, portanto, pode-se ajustar mais um caractere nas mesmas posições. Mas, para meus propósitos, é mais conveniente se houver a possibilidade de emitir letras (caso contrário, a direção terá que ser exibida em graus de bússola, o que é um tanto incomum). Portanto, neste caso, voltei meus olhos para a matriz de linha única de tamanho idêntico MT-10S1, que, apesar de várias desvantagens, migrou para o design final. Ao mesmo tempo, ele já possui uma luz de fundo, que falta ao MT-10T7 (para isso era necessário comprar imediatamente o MT-10T8), e eu decidi que, nesse caso, sua presença não faria mal.

MT-10S1


O monitor MT-10S1 tem letras uma vez e meia menores, mas também um tamanho decente. Além disso, sua tela é embalada economicamente em dimensões gerais: não existem contrapartidas de importação de 10 dígitos, mas no Winstar WH1601L (onde os caracteres são ainda um pouco menores em altura), um sinal é mais que um milímetro a mais que o comprimento total da placa e da tela. Bem, o consumo do controlador está quase pela metade (comparado ao mesmo WH1601L). Na verdade, as vantagens terminam aí, e os "recursos" começam.

O módulo possui que, como já mencionado, possui um controlador compatível com o HD44780 da HITACHI. Ou seja, ele deve trabalhar com seu amado Liquid Crystal sem estresse excessivo. Além disso, a página de codificação “padrão” coincide com a página em inglês-cirílico da HD44780 e seus muitos análogos, ou seja, o MT-10S1 deve funcionar com o Crystal Crystal Rus sem problemas, não são necessárias páginas de código para que essa opção seja alterada. E ele realmente faz tudo isso, mas com nuances.

A primeira advertência - na versão de linha única, os desenvolvedores aparentemente salvam os registros e apenas 8 caracteres de uma sequência (endereços 00h - 07h) estão na memória por registro (e os dois caracteres restantes já estão em outro registro (40h-41h). Ou seja, a exibição de fato é de duas linhas, apenas as duas linhas estão localizadas fisicamente em uma linha. Após uma análise mais aprofundada, verificou-se que o mesmo se aplica ao WH1601 (somente lá o segundo registro leva oito dígitos completos). Por que isso é feito de maneira tão inconveniente, é totalmente incerto: em registros comuns de tela 16x2, são dezesseis bits, e esse truncamento dificilmente torna o produto mais barato, pelo contrário, devido à necessidade de produzir versões diferentes do controlador (se são diferentes, das quais não tenho certeza). Eu pensei que estava associado ao consumo menor que o habitual de MT-10S1, mas o mesmo WH1601 consome 1,2-1,4 mA, ou seja, não é diferente de seus equivalentes avançados.

Bem, ao que parece, tudo bem - em Liquid Crystal Rus, a função setDRAMModel () e a constante LCD_DRAM_WH1601 correspondente foram encontradas. Para este modo, a biblioteca possui uma tradução óbvia de endereço:

 if (ac>7 && ac<0x14) command(LCD_SETDDRAMADDR | (0x40+ac-8)); 

Mas não sei como ele funciona em outros monitores de linha única, e o MT-10S1 se recusa completamente a trabalhar nesse modo - a tela permanece simplesmente em branco. Como estamos falando de endereçamento, você não poderá consertar isso com uma função auto-escrita simples no topo da biblioteca, mas eu não fiquei na biblioteca e descobri qual é o problema - eu já tenho mais de meia dúzia de opções corrigidas pelo cristal líquido, não quero produzi-las e mais adiante.

O monitor MT-10S1 deve ser declarado como duas linhas: lcd.begin (16, 2); (em vez de 16, você pode substituir 10 ou 12, nada mudará, pois o número real de caracteres em uma linha ainda é 8). Uma tentativa de inicializá-lo como uma linha única (número 1 na segunda posição) levará a uma falha - o fundo ficará escuro. E os números de vários dígitos podem ser exibidos apenas com 8 caracteres. Para linhas mais longas, caracteres extremos além de 8 simplesmente desaparecem. Portanto, os 9 e 10 caracteres são adequados apenas para exibir quantidades auxiliares (unidades de medida, por exemplo), ou você precisa dividir o número da linha em dígitos separados e, quando ultrapassar o 8º caractere, altere a posição do cursor para o primeiro caractere da segunda linha.

Para os pacientes , aqui você pode fazer o download de um esboço de teste para esta tela (conexão de fios - no texto do esboço ou no diagrama abaixo). A propósito, o contraste (sobre o qual não há uma palavra no conjunto de dados de fábrica e a saída de Vo é designada como NC) é ajustado da maneira usual aqui, mas você realmente não precisa fazer isso: na ausência de luz de fundo, o fundo parece um pouco escuro, mas quando você tenta iluminá-lo, conectando o divisor à saída de Vo o contraste é visivelmente perdido quando a luz de fundo está ligada.

Interface com controlador


Depois de verificar se tudo funciona como deveria, surgiu a pergunta sobre como conectar tudo isso ao controlador do sensor. Obviamente, não havia conclusões gratuitas suficientes para o controlador do sensor fornecer controle a partir dele, mas eu realmente não queria cercar a cidade com controladores de tamanho grande - é mais conveniente quando a construção do sistema é modular e a tela não interfere no algoritmo básico que já havia sido depurado anteriormente. Restava usar qualquer uma das interfaces seriais.

Isso implora a solução I 2 C baseada em PCF8574 (ou seus muitos análogos), especialmente porque esse chip em si é apenas um registro de troca complicado e, portanto, consome várias dezenas de μA durante a operação e menos de 10 μA em repouso. Juntamente com o MT-10T7, eles formam um excelente par para a criação de dispositivos de baixa potência com indicadores, e o MELT ainda tem uma opção pronta para este caso: MT-10T11 com um consumo total de 30 μA.

Mas para o MT-10S1 não existe uma solução tão conveniente - por algum motivo, apenas as versões com uma configuração 20x4 são fornecidas com uma adição na forma de um análogo do PCF8574 entre os monitores da linha MELT ( UPD: nos comentários, eles sugeriram que também há uma configuração MT-16S2H de 16x4 com a mesma interface, embora , as dimensões dele estão além das dimensões que eu preciso). O módulo final do tipo descrito neste artigo é inconveniente para uso neste caso, pois o segundo recurso desagradável do monitor MT-10S1 é sua pinagem não padrão. As conclusões são as mesmas (HD44780, no entanto, mais precisamente, sua contraparte doméstica, KB1013VG6), mas elas estão localizadas em uma ordem completamente fora do padrão. Por uma questão de interesse, verifiquei os importados de 16x1 e MELT de duas linhas / quatro linhas - todos eles têm uma ordem de saída padrão e o MT-10S1 se destaca nesse cenário por algum motivo. Então você tem que tomar uma decisão por conta própria.

Como resultado, coloquei trivialmente o mesmo controlador ATmega328 no monitor, programado da mesma maneira - através do UNO e depois inserido no soquete em uma placa separada, equipada apenas com os acessórios necessários para a partida: quartzo com condutores, fonte de alimentação e circuito RC Redefina a saída (consulte o circuito do sensor no artigo original , onde o controlador está conectado de maneira semelhante).

Falando do Reset Encadeamento
A propósito, sobre o circuito Reset: Eu tenho um capacitor tão pequeno quanto 1 μF no resistor de vários kOhms, ou seja, o tempo de atraso ao ligar a alimentação é de alguns milissegundos. Quantos? O manual nos ensina que, como para toda a família Mega, uma corrente externa não é necessária, o início correto deve ser realizado pelo circuito interno e muito mais rápido. Mas o hábito de colocar uma corrente RC externa no pino 1 do controlador para uma inicialização atrasada quando liguei permaneceu comigo desde o momento da família AVR Classic já esquecida, onde o controlador pode não iniciar corretamente se a tensão de alimentação não for suficientemente rápida. E na família de detectores Mega Brown-out, pode não funcionar muito bem. Em casos críticos, ainda vale a pena instalar um monitor de energia externo, bem, mas aqui a corrente RC não prejudica nada, mas pode ajudar em casos com fontes de energia ruins. Os desenvolvedores de placas Arduino, a propósito, estão bem cientes disso, porque na placa Uno, por exemplo, existe a mesma cadeia de 10 kOhm / 100 nF.

E o próprio Deus ordenou que dois controladores AVR idênticos fossem encaixados na interface serial habitual, que de qualquer maneira, exceto o processo de programação, não é usada em nenhum outro lugar deste projeto e para a qual o uso já está disponível. A propósito, essa solução não difere em preço dos componentes baseados no PCF8574 e pode competir com ele em termos de economia de energia na variante com o MT-10T7 - caso o MT-10T11 mencionado acima não esteja disponível.

No total, o circuito do módulo MT-10S1 com o controlador é o seguinte (no diagrama, a designação das conclusões do ATmega328 é dada entre parênteses após as conclusões da placa Arduino):



No controlador, apliquei o modo de economia de energia (bem, sim, não é realmente necessário aqui, mas por que manter o chip desnecessariamente?). Além disso, a ativação ocorre de acordo com o sinal do mesmo gerador de ondas quadradas no chip 555 que o relógio do controlador principal, apenas desta vez ao longo da borda descendente (FALLING), a fim de separar ligeiramente as funções de medição e transferência de dados.

O mistério da natureza
Um mistério da natureza está relacionado a isso, que eu não consegui resolver. Sabe-se que o Mega só pode ser retirado do sono profundo por uma interrupção assíncrona externa, uma vez que o relógio está desligado e a interrupção síncrona simplesmente não pode acontecer. E toda a família de controladores AVR de 28 pinos, liderando sua árvore genealógica do ATmega8 (48/88/168/328), possui, como tal, apenas interrupções de baixo nível INT0 e INT1 (e interrupção PCINT, mas não é usada no Arduino). Todas as recomendações oficiais estão relacionadas a isso nos materiais Atmel e nos sites do Arduino. O exemplo no site arduino.cc diz explicitamente: " Em todos os modos, exceto nos modos de suspensão IDLE, apenas LOW pode ser usado ". E isso, por assim dizer, não está em dúvida, por exemplo, Monk repete a mesma coisa com mais detalhes em seu livro : “ Observe que o tipo de interrupção LOW está selecionado. Este é o único tipo de interrupção que pode ser usado neste exemplo. Os tipos RISING, FALLING e CHANGE não funcionarão . ”

A interrupção em um nível baixo é muito inconveniente de usar, pois, uma vez que ocorra, com esse nível mais baixo na saída, ocorrerá repetidas vezes, e medidas especiais devem ser tomadas para se livrar de gatilhos desnecessários. Então, dando uma olhada nos fóruns em busca de várias soluções para esse problema, de repente me deparei com alguns exemplos de código nos quais INT0 do tipo RISING ou FALLING é explicitamente usado para dormir. Certamente, eu atribuí isso ao analfabetismo dos autores. Mas quando tropecei na frase: “ Embora você possa usar qualquer outro tipo de interrupção (RISING, FALLING, CHANGE) - todos eles tiram o processador do sono ”, decidi, apesar dos inimigos, realizar um experimento ao vivo - foi bom para isso à mão.

E, para minha surpresa, tudo funcionou perfeitamente. Modo de economia de energia - SLEEP_MODE_PWR_DOWN; devido à inutilidade, aqui não tomei medidas para reduzir ainda mais o consumo desativando todas as outras funções, mas o gerador de clock ainda está obviamente desligado. No entanto, o controlador acorda regularmente na borda descendente, solicita dados, os exibe no visor e adormece novamente. Para a pureza do experimento, removi o MK da placa UNO e o inseri no meu soquete com o quartzo conectado, e ainda assim tudo continuou funcionando. Isso pode ser observado no consumo: quase 17 mA no modo normal e 0,9-1 mA com a economia de energia ligada (dos quais 0,7 mA devem ser atribuídos ao monitor).

Sem me surpreender, li as folhas de dados de Atmel, examinei o livro de Evstifeev (com a tradução deles), até olhei o antigo manual de Atmel sobre a família Classic e passei meio dia procurando pelo menos alguma explicação do que estava acontecendo (tanto em russo quanto em russo) em inglês) em dois mecanismos de pesquisa conhecidos, mas em nenhum lugar nem sequer encontramos uma dica. A menos que seja útil nas Notas de Aplicação da Atmel, porque é duvidoso que algo contrário às folhas de dados tenha sido publicado lá. Ficarei feliz se alguém que sabe o que entendi mal.
UPD: live assembler check (ATmega8) mostrou total conformidade com as planilhas de dados, ou seja, apenas trabalhos de interrupção de nível. A única explicação que vem à mente é que o Arduino de alguma forma conectou a interrupção PCINT a uma interrupção regular. Uma tentativa de esclarecer a situação estudando o texto das bibliotecas do sistema Arduino não resultou em nada - ali o diabo quebraria sua perna.

A transferência de dados do controlador do sensor para o controlador de exibição via UART é organizada na forma de um diálogo. Ao acordar, a cada quarta interrupção, o controlador de exibição solicita dados por sua vez:

 . . . . . if (flag==1) { //   4-  ~6  Serial.print('T'); //   while(!Serial.available()); //  T iit = Serial.readBytes(buft,5); //  5  , //  ii    Serial.print('H'); //   while(!Serial.available()); //  iihh=Serial.readBytes(bufhh,5); //  5  , //  ii    Serial.print('S'); //   while(!Serial.available()); //  iiss=Serial.readBytes(bufss,5); //  5  , //  ii    Serial.print('D'); //   while(!Serial.available()); //  iid=Serial.readBytes(bufd,5); //  5  , //  ii    flag=0; //   } . . . . . 

Aqui buft, bufhh, bufss e bufd são matrizes (não cadeias!) De cinco bytes, que contêm dados de temperatura, umidade, velocidade e direção na forma de uma decomposição ASCII dos números correspondentes. Para não aceitar muito, o setup'e especifica um tempo limite abreviado para recepção:

 . . . . . Serial.begin(9600); Serial.setTimeout(10); //   10  . . . . . 

É mais conveniente exibir: primeiro, você tem imediatamente o comprimento do número recebido e, em segundo lugar, a função Serial.print () envia uma sequência ASCII do lado do controlador do sensor, com pausas definidas nos mesmos 10 ms entre os envios :

 . . . . . //     : if (Serial.available()>0) //  { char ch=Serial.read(); if (ch=='T') { Serial.print(temperature,1); delay(10);} if (ch=='H') { Serial.print(humidity,0); delay(10);} if (ch=='S') { float wFrq=(3+0.8*f)/10; //   / if (wFrq>0.3) Serial.print(wFrq,1); else Serial.print(0.0,1); delay(10);} if (ch=='D') { // Serial.println(wind_G); Serial.println(wind_Avr); delay(10); }//end ch }//end serial . . . . . 

O cálculo da velocidade em m / s aqui é idêntico ao realizado no módulo principal da estação (o limite inicial é definido aleatoriamente em 0,3 m / s) e também terá que ser alterado de acordo com os resultados da calibração.

Se você tentar aceitar os dados com o Serial.read () usual e exibir o resultado da recepção em um display com uma função como lcd.print (t, 1), em que t é a temperatura em graus, igual, por exemplo, a 12,7, então MT-10S1 em resposta a isso o comando exibirá "49,5". Adivinhou, ou sugere? Esses são os três primeiros caracteres da sequência "49 50 46 55", ou seja, na expansão ASCII do número "12,7". Portanto, é mais fácil aceitar imediatamente uma matriz de caracteres e exibir diretamente quantos caracteres foram enviados (contagem é um contador que aumenta em um a cada interrupção):

 . . . . if (count%8==0){ // 8   lcd.clear(); if (buft[0]!='-') lcd.print("+"); for (byte i = 0; i < iit; i++) lcd.print(buft[i]); //  lcd.setCursor(6, 0); for (byte i = 0; i < iihh; i++) lcd.print(bufhh[i]); //  lcd.setCursor(0, 1); lcd.print("%"); } if ((count+4)%8==0){ //  4  lcd.clear(); lcd.setCursor(0, 0); for (byte i = 0; i < iiss; i++) lcd.print(bufss[i]); //  lcd.setCursor(5, 0); dir_dd(bufd); //  } . . . . . 

A última linha precisa ser descriptografada. O fato é que os dados de direção são enviados no código 0-15 (para o qual eles ainda são transferidos do código Gray ao implementar a média do vetor ). No caso do display de sete segmentos MT-10T7, eles foram traduzidos em graus de bússola:

 . . . . . dd=atoi(bufd); //   dd=dd*22.5; //   itoa(dd,bufd,10); //    . . . . . 

E aqui podemos escrever diretamente em letras russas, da mesma maneira que no módulo principal da estação meteorológica (pelo qual essa tela, de fato, foi escolhida):

 . . . . . void dir_dd(char dd[]) {switch(atoi(dd)) { case 0: {lcd.print(""); break;} case 1: {lcd.print("C"); break;} case 2: {lcd.print("C"); break;} case 3: {lcd.print("C"); break;} case 4: {lcd.print(""); break;} case 5: {lcd.print(""); break;} case 6: {lcd.print(""); break;} case 7: {lcd.print(""); break;} case 8: {lcd.print(""); break;} case 9: {lcd.print(""); break;} case 10: {lcd.print(""); break;} case 11: {lcd.print(""); break;} case 12: {lcd.print(""); break;} case 13: {lcd.print("C"); break;} case 14: {lcd.print("C"); break;} case 15: {lcd.print("C"); break;} }//end switch }//end dir . . . . . 

Aparência


A foto mostra a aparência da tela com o controlador conectado em condições de funcionamento:



É assim que o conjunto do sensor modificado se parece:



Os parâmetros da luz de fundo são aqueles indicados no diagrama acima. Como a queda de tensão na luz de fundo nos módulos MELT é de 4,5 V, com uma fonte de alimentação de 12 V, a corrente da luz de fundo é de 50 mA (no máximo para este módulo, 60 mA).

A caixa é selada no máximo para evitar a entrada de ar úmido (a moldura preta da tela é da bainha de borracha de um cabo fino). A placa branca à direita é o gabinete do sensor de temperatura e umidade SHT-75, retirado da caixa (o próprio sensor está localizado atrás dela). O fio amarelo acima é a antena do transmissor de 433 MHz. À esquerda, estão os conectores onde os sensores de velocidade e direção estão conectados.

E é assim que as leituras no visor do módulo principal da estação meteorológica se parecem (o módulo preto com a antena branca à direita é o receptor de 433 MHz):

Source: https://habr.com/ru/post/pt430828/


All Articles