Pensei em comprar um fabricante de iogurte de alguma forma. Sim, para que o iogurte seja bom e sempre da mesma qualidade. O que é necessário para isso? Em primeiro lugar, matérias-primas, em segundo lugar, temperatura precisa e estável, em terceiro lugar, definindo o tempo de cozimento. Comecei a escolher e enfrentei a seguinte emboscada: fabricantes de iogurte baratos não eram regulamentados. Ou seja, dentro do fio de aquecimento, e esse fio, de fato, está conectado à rede. Qual a temperatura dentro do fabricante de iogurte ao mesmo tempo depende das mãos do coletor, da temperatura ambiente, das fases da lua e da profundidade do sono de Cthulhu (a propósito, Cthulhu fhtagn).Claro, essa situação não me agradou. E mais ainda fiquei incomodado com a situação dos fabricantes de iogurtes, que, por suas funções e parâmetros, me convinham. Por alguma razão, os fabricantes desses fabricantes de iogurtes acreditam que estão fornecendo produtos espaciais ao mercado e os preços desses produtos devem ser adequados. A forte angústia mental no processo de seleção levou-me ao ponto de expressar minha indignação à minha amada esposa sobre a política desumana de preços dos fabricantes de iogurtes e no processo de derramamentos verbais expressei a frase "farei melhor por quinhentos rublos", após o que depois clicou ...Era a história de fundo. E agora a história.No processo de construção de um dispositivo maravilhoso, encontrei um bug. Quando a temperatura atual era exibida, o controlador periodicamente reiniciava. Ou seja, às vezes funcionava normalmente por horas, e às vezes era redefinido a cada poucos segundos. Desde que isso começou a acontecer depois que a função de sondagem do sensor ds18b20 foi introduzida no firmware, é natural que eu tenha recorrido a ela para uma busca de bugs. E não encontrou nada. A pilha não quebrou, a função não gravou nada em suas áreas de memória. Em geral, funcionou como deveria ser. Além disso, a desativação dessa função removeu o bug, que indicava claramente (como me parecia naquele momento) o herói da ocasião. Eu pensei que tudo era o culpado pelo sistema de sincronização.Como tenho uma pedra pequena (attiny2313a) e não há temporizadores suficientes para todas as loções, saí da situação escrevendo um gerenciador de tarefas que recebe tarefas e o tempo de atraso necessário das funções, coloca-as na fila. Depois de contar o tempo necessário, ele transfere o controle para eles. Defino o tempo de atraso mínimo como 1 milissegundo. O que me permitiu definir atrasos de milissegundos para um minuto. Mas se você olhar a folha de dados do sensor ds18b20, verá que a comunicação com o sensor de temperatura às vezes dura mais de 500 microssegundos (redefinir e aguardar presença).
Mas e se, no processo, uma interrupção interferir na função de comunicação? Haverá um deslocamento de intervalo de tempo, devido ao qual o controlador não poderá ler o bit ou reconhecer corretamente a presença. Encontrei uma maneira de usar a sincronização. O processo é simples. Quando a função de polling do sensor vê que ele terá uma comunicação de longo prazo com o sensor, ela configura uma interrupção no registro B do timer 1 ao mesmo tempo que a interrupção do "gerenciador de tempo", localizada no registro A do timer 1. E como as interrupções são processadas em estrita conformidade com o endereço do vetor de interrupção em tabela de interrupção, verifica-se que, após o processo de sincronização, a função de polling do sensor receberá o controle imediatamente após a interrupção do "gerenciador de tempo".Bem, onde pode haver um bug? Sim em todo lugar. Mas, pessoalmente, pensei que o problema poderia estar no cruzamento de interrupções. Ou seja, no caso em que outro entra durante a execução de uma interrupção. A limpeza do código para resolver esse problema continuou até que eu descobri que minhas ações levaram ao fato de que o problema começou a ocorrer mesmo com o sensor não conectado. Tendo desativado a função de polling do sensor, eu estava convencido de que agora as redefinições do controlador não dependem de sua operação. E então um palpite brilhante me atingiu. Precisa medir a tensão! O multímetro informou alegremente que existem 4,2 volts no controlador. “Bem, é claro, BOD, pensei. E conectei energia externa à placa (antes eu estava satisfeito com a energia USB). O multímetro resmungou bastante, que é de 4,98 volts na placa. Com um sentimento de vitória, liguei o quadro para ver o incrível. Um bug estava presente!E ficou ainda mais vigoroso. Agora, o controlador era redefinido a cada par de segundos e às vezes em uma fração de segundo. As pesquisas continuaram com uma vingança e levaram a uma função que exibe informações na tela.Como você provavelmente adivinhou, tudo estava bem com ela, especialmente porque depois de escrevê-la, ela foi devidamente testada. E, no entanto, tudo dizia que meu bug esquivo está nele. Descobriu-se que o erro ocorre apenas ao exibir a página de temperatura atual. Páginas exibindo poder, início, hora do bug não causaram. Não encontrando nada que pudesse causar esse comportamento, decidi aproveitar a comida. Ou seja, o fato de que sob tensão normal um bug ocorria com mais frequência. Ao diminuir a tensão, descobri que, a 3,8 volts no controlador, o último funciona de forma estável. A situação rasgou todos os padrões. E então me lembrei da lei de Ohm. A corrente é proporcional à tensão. É sempre? Não. Nos LEDs, essa lei não funciona. Funciona com mais precisão, mas com seus gadgets.A proporcionalidade da corrente através do diodo não é a mesma que em um resistor convencional, porque os dispositivos semicondutores são principalmente não lineares. Lembre-se de pelo menos um tiristor ou um diodo zener (diodo zener). Aqui está uma comparação da característica de tensão de corrente do LED da folha de dados (linha preta) e a característica de tensão de corrente da carga resistiva (linha vermelha)
É visto que, para o carregamento resistivo, a lei de Ohm é deus e mestre. Se a tensão aumentar em 10%, a corrente aumentará nos mesmos 10%. Mas ninguém é um decreto para o LED. Se você aumentar a tensão no LED em apenas 10% (de 2 para 2,2 volts), sua corrente aumentará 100%, ou seja, duas vezes! Mas, no meu caso, o principal era que um aumento na tensão também aumentava sua diminuição no momento em que o diodo era ligado. E eu tinha 32 diodos! Quatro indicadores de sete segmentos com oito LEDs em cada (sete segmentos e um ponto). Eles estão conectados a mim não através da multiplexação, mas através dos registros de turno porque:1. As conclusões do controlador attiny2313 estavam extremamente ausentes.2. Fico aborrecido com o tremor deles quando conectado por multiplexação (número de perfeccionismo vezes)3. O multiplexador consome muitos recursos do controlador para saída (perfeccionismo número dois)Além disso, conectei os registros de turnos com a função de desligar a tela durante a atualização do visor (perfeccionismo número três). Por que desisti desse recurso - não sei. Afinal, a lógica que escolhi pode funcionar até uma frequência de 100 MHz. Consequentemente, os dados podem ser inseridos na freqüência total do controlador, que eu tenho é de 10 MHz. Bem, quem tem tempo para notar o movimento de bits nos bits do indicador em tal frequência?Ir em frente. A potência do meu circuito é fornecida pelo regulador L7805, aqui está o diagrama de conexão.
O regulador fornece uma corrente de 1A sem problemas. Na saída do regulador, há um capacitor de microfarad de 0,1, que, em teoria, deve suavizar as flutuações de corrente. Sua carga a 5 volts é de 0,5 microcoulomb. A 3,8 volts, a carga é respectivamente 0,38 microcoulomb. A 3,8 volts, os LEDs consomem cerca de 288 mA e a 5 volts, cerca de 416 mA. Assim, quando a tensão é aumentada de 3,8 volts para 5 volts, a carga armazenada pelo capacitor aumentará 24%, mas o consumo de corrente aumentará mais de 30% ao mesmo tempo. Os cálculos são obviamente exemplares, mas mostram que a queda de tensão em um circuito é quanto maior, maior a tensão de alimentação. A 3,8 volts, o rebaixamento não foi crítico para o controlador. Mas a 5 volts, o rebaixamento aumentou e começou a reiniciar o controlador. E o controlador foi redefinido precisamente na página de exibição da temperatura, porqueexatamente nesta página estavam todos os indicadores de exibição envolvidos.A solução foi simples. No código, basta comentar as linhas para ativar e desativar os indicadores sbi displayPort, offDispWire e cbi displayPort, offDispWire. ldi XL, videoMem
cbi displayPort, shiftWire
cbi displayPort, storageWire
;sbi displayPort, offDispWire
ZpushToDisplay:
ldi temp2, 8
ld temp, X+
ZnextbitToDisplay:
cbi displayPort, dataWire
sbrc temp, 7
sbi displayPort, dataWire
sbi displayPort, shiftWire
cbi displayPort, shiftWire
lsl temp
dec temp2
cpi temp2, 0
brne ZnextbitToDisplay
cpi XL, videoMem+sizeVideoMem
brne ZpushToDisplay
sbi displayPort, storageWire
cbi displayPort, storageWire
;cbi displayPort, offDispWire
As descargas foram interrompidas. E o controlador viveu feliz para sempre.Z.Y. o processo indescritível de busca de bugs apontou para outro problema no esquema. O fato é que a dissipação máxima de energia dos registros de deslocamento é de cerca de 0,5 watts, e a corrente através da saída ou do solo é de cerca de 70 miliamperes. Se a figura oito com um ponto for exibida, a corrente no registro de deslocamento deve ser de cerca de 104 miliamperes, o que, como você sabe, é um excesso. Não é que eu não tenha levado esse momento em consideração. Eu levei em conta. Mas, no processo de calcular o resistor para o LED, ele sucumbiu à fraqueza minuciosa e esqueceu que o LED é um elemento não linear e, para reduzir a corrente através dele duas vezes, não basta dobrar a resistência do resistor limitador de corrente. Em geral, em qualquer situação incompreensível, consulte o CVC!