limitador de RPM com arduino

mlegnari · 28 de maio de 2021

@Sérgio Lembo Eu ia fazer ele quebrar a cabeça pra fazer isso kkk essa validação, e outra coisa: se o rpm for maior que 5000 (sendo o corte 4000) com certeza é ruido! então faça x...

@ComandateGustavo não é que a função é mais suscetível a ruídos, ela ta ali na escuta toda hora, o digitalRead tem um espaçamento maior entre as leituras.

Posta o esquema do hardware completo, podemos trabalhar no código como o amigo @Sérgio Lembo sugeriu, mas vamos dar uma melhorada no hardware pra aliviar um pouco na programação também.

Não desista das interrupções, eu as uso em varios produtos sem problemas, mas com hardware ruim não faz mlagres

aphawk · 28 de maio de 2021

@mlegnari ,

E se isso virar um produto, lembro aqui que todo microcontrolador usado nos Arduínos tem um único numero de série embutido no hardware, mesmo que o datasheet informe o contrário ( gostaram da dica ? )

Paulo

Sérgio Lembo · 29 de maio de 2021

24 minutos atrás, mlegnari disse:

@Sérgio Lembo Eu ia fazer ele quebrar a cabeça pra fazer isso kkk essa validação, e outra coisa: se o rpm for maior que 5000 (sendo o corte 4000) com certeza é ruido! então faça x...

E a minha proposta de validação contém um erro. Se no período de 1 pulso verdadeiro há um falso então teremos 2 medições falsas consecutivas. A validação para ser correta tem que considerar no mínimo 3 valores consecutivos. Outra possível invalidação de resultados é se a leitura nova for maior que a anterior em 500RPM, isto é, qualquer aceleração inconsistente mesmo que o motor esteja a vazio e pedal seja socado.

aphawk · 29 de maio de 2021

2 minutos atrás, Sérgio Lembo disse:

Outra possível invalidação de resultados é se a leitura nova for maior que a anterior em 500RPM, isto é, qualquer aceleração inconsistente mesmo que o motor esteja a vazio e pedal seja socado.

Eu uso isto também na validação do giro dos rotores de antena : sei que a velocidade angular sempre é inferior a 7 graus por segundo ( definido pelo sistema de redução e a rpm máxima do motor ). Se alguma coisa der resultado maior do que este, eu invalido a leitura atual (N) , e mantenho a anterior acrescida da variação da leitura N-1 para a N-2 . O resultado é muito bom.

Precisamos de uma estimativa do aumento da RPM por segundo ( ou nesse caso, eu acho bem melhor usar períodos bem menores, tipo 2 décimos de segundo, para validação ... ).

Paulo

Sérgio Lembo · 29 de maio de 2021

31 minutos atrás, aphawk disse:

@mlegnari ,

E se isso virar um produto, lembro aqui que todo microcontrolador usado nos Arduínos tem um único numero de série embutido no hardware, mesmo que o datasheet informe o contrário ( gostaram da dica ? )

Paulo

Prefiro os timers da ST. A Série STM8 e STM32 possuem basicamente o mesmo custo, diferença irrisória. O legal do STM32 é a operação com 32 bits e mais registradores. O bom da STM8 é o endereçamento linear e as 20 formas de manipulação da memória. As 2 séries possuem pipeline, apenas 1 clock por instrução. Sobre o comentário seu teria que montar um programa que lesse a ID e a incorporasse de forma automática no programa. Já vi em muitos processadores a possibilidade de bloquear o programa para leitura. Sabe se isso funciona bem ou já conseguiram quebrar esse bloqueio?

aphawk · 29 de maio de 2021

@Sérgio Lembo ,

Os ST são mais poderosos, e tem custo menor, mas para pequenas produções, como as que eu faço, não ter em DIP complica bastante, e se comparar a base de usuários que conseguem hoje programar para os Avr's é muito maior do que as que conseguem fazer algo com os ST.

Claro que estou falando para quem quer produzir em pequena quantidade.

Esse bloqueio de leitura funciona muito bem, protege de qualquer um que tente ler o código ( qualquer usuário comum, exceto empresas chinesas dedicadas a isto... ).

MAS ...

Sobre os bloqueios, qualquer microcontrolador pode ser aberto e o código copiado por empresas chinesas. E por menos de US 500 ... então tá bem mais fácil de termos um projeto copiado por quase qualquer um...

Para evitar isso, os novos microcontroladores possuem internamente um número serial único, que dificulta bastante a simples cópia do firmware, pois precisaria desassemblar o programa todo e alterar o código que compara esse ID. Mas como eu disse antes, vários microcontroladores Atmega e Attiny antigos também possuem isso, embora o datasheet não mencione.

Eu procuro dificultar ao máximo, escondendo o trecho de código que pega o ID do Atmega , eu monto o código na memória RAM numa sequencia de variáveis do programa, e chamo esse código de maneiras diferentes, através de Pushs e Ret direto do Stack Pointer... quem tentar desassemblar vai perder muiiiito tempo tentando entender o processo pois são truques da velha guarda, em Assembly puro. Naquele meu tópico sobre programação de Avrs em Básico e Assembler eu usei esse truque num dos projetos para retomar o controle de um loop infinito numa interrupção.

Se copiarem o meu código para um outro Atmega, eu deixo o programa funcionar de maneira errática, para dar mais trabalho ao coitado kkkkk !

Dá mais trabalho para a gravação, pois eu tenho de gravar um programa que vai me fornecer via serial o ID do hardware do Atmega, e uso esse Id no programa fonte e gero o firmware dedicado para esse microcontrolador. E faço uma nova gravação, agora protegendo contra leitura.

De tudo o que eu lí sobre isso, me parece que é a única maneira mais segura de tentar impedir a cópia de um projeto.

Paulo

mlegnari · 7 de junho de 2021

Em 28/05/2021 às 20:42, aphawk disse:

E se isso virar um produto, lembro aqui que todo microcontrolador usado nos Arduínos tem um único numero de série embutido no hardware, mesmo que o datasheet informe o contrário ( gostaram da dica ? )

@aphawk muito interessante!! posso ler o numero e amarrar o firmware a rodar somente com aquele serial correto? isso iria proteger mesmo que conseguissem extrair a flash (fuse bits descuidados!) muito obrigado!!!!

@Sérgio Lembo as validações são fantásticas!! nesse mundo lúdico e incrível da programação existem N possibilidades , eu costumo utilizar mais de 3 ou 4 filtros obvios, como rpm maximo, minimo, a variação como você citou (se esta a 2000rpm constante de repente varia mais de 500rpm de uma volta pra outra ai tem algo bem estranho!)

Em 28/05/2021 às 21:08, Sérgio Lembo disse:

Prefiro os timers da ST. A Série STM8 e STM32 possuem basicamente o mesmo custo, diferença irrisória. O legal do STM32 é a operação com 32 bits e mais registradores. O bom da STM8 é o endereçamento linear e as 20 formas de manipulação da memória. As 2 séries possuem pipeline, apenas 1 clock por instrução. Sobre o comentário seu teria que montar um programa que lesse a ID e a incorporasse de forma automática no programa. Já vi em muitos processadores a possibilidade de bloquear o programa para leitura. Sabe se isso funciona bem ou já conseguiram quebrar esse bloqueio?

@Sérgio Lembo existe os fuse bits que são gravados em eeprom , com muita paciencia remove-se o epoxy do microcontrolador até chegar nessa regiao dos lock bits e usa luz ultra violeta apagando os fuse bits retornando ao padrão, então lê-se o conteúdo. Mas existe CI's que os fusebits são fisicos mesmo! quando se queimam para proteção, literalmente queimam e rompem-se, protegendo totalmente!! (ou um robô ultra avançado pode operar???)

A questão de amarrar o ID do micro controlador é uma segunda camada! caso se extraia a flash, ainda sim teria que fazer engenharia reversa para modificar o hexa do código extraído e mudar esse serial!

Em 29/05/2021 às 10:57, aphawk disse:

Se copiarem o meu código para um outro Atmega, eu deixo o programa funcionar de maneira errática, para dar mais trabalho ao coitado kkkkk !

@aphawk que tal mudar os pinos que estão aterrados para high? rsrsrs Teve um virus (malware) para radios wireless em 2012 terrível da ubiquiti, ele se espalhava pela rede em busca de falhas conhecidas, tentava se replicar ao máximo e depois de concluído fazia o update do firmware do radio, e mudava alguns parâmetros que queimava o hardware!