Revisão da unidade TC420
Como não houve necessidade da devolução da unidade, decidi analisá-la por dentro. Depois de abrir, descobri que a unidade é controlada pela MCU Nuvoton NUC120LE3AN. Na internet achei a informação que se trata de um componente com o núcleo ARM Cortex M0. Infelizmente, núcleos da ARM fazem hoje em dia parte de muitos processadores. O conjunto de instruções do ARM Cortex M0 não é nada revolucionário.
Minha expectativa foi que a MCU tomasse conta das funções seguintes: geração de 5 PWMs, controle da tela, leitura dos botões, comunicação com o PC através do USB e manutenção da data e hora. O NUC120LE3AN está no pacote LQFP48 que tem só quatro canais da PWM. Para o quinto canal é possível usar o timer. O controle da tela precisa por volta de 10 pinos e para ler o estado dos botões é preciso de 4 pinos. Para manter a hora é possível usar o módulo RTC (real-time clock). O pequeno reprodutor me parece redundante.
De qualquer forma o autor da unidade teve uma opinião diferente. Quando estava analisando a unidade, não deixava de perguntar. O primeiro mistério foi como se geram as PWMs. Achei só o sinal do quarto canal (pino 25) que é gerado pelo PWM 3. Nos pinos das saídas da PWM 0, 1, 2 não havia nenhum sinal da PWM. Depois achei o sinal do quinto canal PWM (pin 48), que é gerado pelo timer (TM0). Contudo, nos MOSFETs estavam presentes todos os 5 sinais da PWM. Continuei procurando e descobri que do pino 9 (TXD1), que funciona como uma porta serial com a velocidade de 9600 baud, estão sendo ciclicamente enviados 6 bytes para um chip na placa. Esse chip tem seu próprio cristal que tem por volta de 11 MHz. Dos 6 bytes o primeiro é sempre o zero seguido com 5 valores da PWM que a unidade está enviando ao chip. O chip gera 5 sinais da PWM. Em outras palavras, em vez de usar os periféricos da NUC120LE3AN para gerar 5 PWMs, o autor está enviando através da comunicação serial 5 bytes com o valores das PWM para outro chip que gera a PWM.
Os valores são enviados para o outro chip da seguinte maneira: 0 % corresponde com 0, 100 % se envia como 250. Com este valor podemos medir na saída a PWM por volta de 98 %. Então, 100 % não é 100 %. Por quê? O chip gerando a PWM está provavelmente programado para gerar a PWM de 100 % com o valor 255 (o valor máximo de um número de 8 bits). Prova: 250 / 255 x 100 = 98. A pergunta é: Por que o autor não usou 255 como o máximo? Provavelmente usou um valor da tabela, fez 1 shift à esquerda. Depois pegou o mesmo valor e fez um shift à direita. No final somou esses dois resultados. Quer dizer multiplicou por 2,5. A linha de código na linguagem C poderia ser:
u8PWM = (u8TableValue << 1) + (u8TableValue >> 1);
onde u8PWM é o valor da PWM resultante (0 – 250, typo uint8_t) e u8TableValue é o valor de entrada da tabela (0 – 100, typo uint8_t).
Enquanto era suficiente usar a multiplicação por 2,55, onde o número 2,55 seria deslocado para os 8 bits de cima dentro de uma variável de 16 bits. Poderia parecer desse jeito:
u8PWM = (uint8_t)(((uint16_t)u8TableValue * (uint16_t)655) >> 8);
A constante 655 é derivada do número máximo de 16 bits (65535) dividido por 100 (máximo da PWM). Simplesmente podemos verificá-lo para o valor 100: 100 x 655 = 65500. Esse número é deslocado 8 vezes à direita, quer dizer divido por 256 (ou seja 28): 65500 / 256 =255. É fato que dois shifts e uma adição pode ser muito mais rápido em alguns processadores do que a multiplicação, mas não é o caso do Cortex M0. Principalmente quando a PWM é atualizada ao máximo um vez por minuto. O Cortex M0 usará uma instrução para a multiplicação MULS e uma, para o shift ASRS. Enquanto no primeiro caso serão usadas duas instruções para o shift ASRS e uma, para a adição ADDS.
Contudo, a solução atual (com o uso de 8 bits para o valor da PWM) seria capaz da resolução de 0,5 %, não 1 %. Mas isso significaría uma pequena modificação na aplicação no lado do PC para isso.
Se o autor tivesse usado os periféricos da NUC120LE3AN: PWM ou timer, teria conseguido uma resolução da PWM muito mais alta. Para isso precisaria o conhecimento da aritmética fracionária: a frequência da PWM da unidade TC420 é 540 Hz. Se a frequência da entrada do periférico for 22,1184 MHz (o que indica o NUC100/120 Technical Reference Manual), o período da PWM resultante será 22118400 / 540 = 40960 incrementos. O periférico tem o contador de 16 bits, quer dizer que conta a 65535. Então, um período assim é realizável. Se dividirmos a base de 100 % por esse período, obteremos a resolução da PWM, quer dizer 100 % / 40960 = 0,0024 %. Diria que isso fica bem longe da resolução de 1 %, não fica?
Outra coisa que me surpreendeu é a existência do componente Maxim DS1302Z. Sua tarefa é manter a data e hora. Como mencionei acima, a NUC120LE3AN tem o módulo RTC que pode ser utilizado para a data e hora. Também é possível mandar a MCU dormir, para reduzir o consumo, e acordar através do RTC por um instante, fazer a operação e mandar novamente dormir. Por que o autor usou o DS1302Z que exige a comunicação serial com a NUC120LE3AN? Demais precisa outro cristal.
Medi a comunicação entre a MCU e o DS1302Z. Mas confesso que não conseguia acreditar no que vi. O autor queria provavelmente usar o periférico I2C porque a MCU usa justamente os pinos do periférico I2C para a comunicação com o DS1302Z. Porém, a comunicação que o DS1302Z usa, só faz lembrar da I2C. De fato, não é a I2C. O autor pôde usar o periférico SPI com os pinos MOSI (master out, slave in) e MISO (master in, slave out) em curto. No caso da leitura do DS1302Z o pino MOSI se colocaria no estado de alta impedância após enviar 8 bits (comando) para que o pino MISO pudesse ler a informação.
O autor, porém, escolheu a maneira do controle dos pinos do clock e dados pelo software controlando-os como os pinos GPIO (general purpose input output). Na imagem dá para observar uma frequência mais alta do sinal clock com flutuação durante os primeiros 8 bits. Nesse ponto se tratou do comando 0x81 – leitura dos segundos. Segue uma frequência do clock completamente diferente com flutuação. Nesse instante o DS1302Z responde enviando os segundos no sistema BCD. O autor não foi nem capaz de criar uma malha com o período constante para uma comunicação tão primitiva.
As saídas da PWM estão conectadas aos MOSFETs no pacote DPAK. Não vi nenhum filtro. Então as fitas de LED podem ter interferências. Não testei. O USB usa a classe HID (human interface device) para a comunicação com o PC, por isso não é preciso instalar nenhum driver no Windows. A HID é uma classe básica que já existe no sistema Windows. Isso provavelmente copiou de um exemplo sobre o uso do USB HID device.
A unidade poderia ser menor, mais barata, com o consumo mais baixo e principalmente a resolução da PWM teria sido muito mais alta. Em outras palavras, se a resolução da PWM estendesse, as transições entre as intensidades de LED seriam muito mais finas. Para melhorar a unidade não seria suficiente reprogramá-la, e sim significaria alterações na placa. Acho que o autor deveria considerar uma carreira na política.
