MONZEIROS.COM

Só de curiosidade, já que citei na postagem que ficou na página anterior o teste copiando o sinal de um sensor MAP, aqui está a imagem dele.

A forma de onda amarela é a original (para os que não entenderem o gráfico, de uma forma mais didática do que técnica, cada ondulação na tela corresponde a uma "aspiração" do motor, que cria um ligeiro vácuo no coletor, com o movimento de descida de cada pistão).

A azul é a minha cópia.

O arduino lia em tempo real (motor funcionando) cada pontinho da linha amarela na sua porta de entrada e soltava um pontinho azul na sua porta de saída. Notem que não há atraso nem perda de resolução significativos em relação ao sinal original.

Na verdade, mal dá para ver a forma de onda azul por baixo da amarela, de tão bem que ele copiou o sinal.

A aplicação deste teste era para outro caso, de outro carro (interferir no sinal de um carro turbo original para enganar a ECU, para ela subir a pressão). E eu só queria ver se seria possível dentro das limitações do hardware.

entendi, pra oque tu quer dessa forma funciona mesmo.

o calculo da distancia é simples, nao depende de tempo. isso te salva heheh pq se fosse depender de tempo da forma que tu fez nao teria como dessa maneira. qual foi a formula que usou, comprimento / 8 ? foi por 8 pulsos a cada 360º entao? se for responde minha duvida rsrsrsr.

Os 16 Mhz deste modelo de arduino, apesar de ser bem basicão, quebram o galho... Talvez não dê para ler muitos sensores e fazer muitos cálculos e atualizar muitas informações no display sem pagar o preço no processamento por isso. Mas também não é complicado dividir as tarefas entre dois ou mais arduinos também...

os MCU possuem varios clock, esse que tu se refere é a origem, porem nao quer dizer que ele trabalhe em 16Mhz talvez ele passe por um Prescale, PLL, dae clock real RTI na pratica mude, isso so pra quem for usar ele a modo de eng pesada mesmo, pra coisas simples da e sobra, oque nao da certo é usar 1 a 1ms é preciso usar Timer de hardware que é contador de estouro de variavel 16 bits(barramento cpu) no caso, cada numero equivale a 1 ciclo de clock oscilador oque é extremamente rapido. cada caso é um caso, no meu S12 Freescale é 8Mhz cristal vira 48Mhz PLL cai pra 24Mhz, depois tem o clock principal RTI de 8Mhz dando 128usec por tic, e depois o clock 1,5Mhz nos ISR 65535 * 666 Nanossegundos! = 43,3msec por overflow. todos oriundos do cristal de 8 Mhz porem com velocidades diferentes

imagine a precisao disso. cada 666 nsec 43,3ms dividido por 65535

os Atmel nao tem muita opçao disso, se tu ler, vai ver que nenhum eng ou tecnico recomenda seu uso em setor automotivo. é mais pra fim didatico como os PIC. funciona muito bem pra coisa simples o Arduino escolheu ele justamente por isso, eu mesmo uso e tenho no meu aquario Hitech, muito rapido fazer qualquer coisa nele, ta tudo mastigado. MCU nativos é muito complicado e demorados ate pra compilar e as vezes precisa de Debugs SCI etc...

Da parte do sinal, concordo que ali foi só para um teste e que para produçao mesmo, tenho que melhorar a forma de tratar... Os resistores 1k eram o que eu tinha facil na mao e montei com eles so para testar mesmo... Mas o certo é isolar os dois lados mesmo, como sugeriu com o optoacoplador. Boa dica..

esqueci de falar, na saida do opto nao precisa fazer c/pullup, ative o pullup do MCU, dae é so por no coletor do opto e aterrar o emissor e ta feito o chaveador

Rafaelo escreveu: ↑02 Mai 2017, 16:52 entendi, pra oque tu quer dessa forma funciona mesmo.

o calculo da distancia é simples, nao depende de tempo. isso te salva heheh pq se fosse depender de tempo da forma que tu fez nao teria como dessa maneira. qual foi a formula que usou, comprimento / 8 ? foi por 8 pulsos a cada 360º entao? se for responde minha duvida rsrsrsr.

Distância não depende do tempo mesmo. Apenas número de pulsos acumulados na variável x comprimento da roda.

Para velocidade, que é em função do tempo, basicamente é só dividir a distância pelo tempo (km/h).

E como eu disse, até 1Khz, na bancada, o erro máximo foi de 0,3%. Não testei com mais porque não tinha necessidade para esta aplicação.

Programando de outras maneiras, o resultado saia bem errado. Deixando o código dentro da função interrupt com apenas um "contador++" e o restante no loop, a precisão foi esta.

os MCU possuem varios clock, esse que tu se refere é a origem, porem nao quer dizer que ele trabalhe em 16Mhz talvez ele passe por um Prescale, PLL, dae clock real RTI na pratica mude, isso so pra quem for usar ele a modo de eng pesada mesmo, pra coisas simples da e sobra, oque nao da certo é usar 1 a 1ms é preciso usar Timer de hardware que é contador de estouro de variavel 16 bits(barramento cpu) no caso, cada numero equivale a 1 ciclo de clock oscilador oque é extremamente rapido. cada caso é um caso, no meu S12 Freescale é 8Mhz cristal vira 48Mhz PLL cai pra 24Mhz, depois tem o clock principal RTI de 8Mhz dando 128usec por tic, e depois o clock 1,5Mhz nos ISR 65535 * 666 Nanossegundos! = 43,3msec por overflow. todos oriundos do cristal de 8 Mhz porem com velocidades diferentes

imagine a precisao disso. cada 666 nsec 43,3ms dividido por 65535

os Atmel nao tem muita opçao disso, se tu ler, vai ver que nenhum eng ou tecnico recomenda seu uso em setor automotivo. é mais pra fim didatico como os PIC. funciona muito bem pra coisa simples o Arduino escolheu ele justamente por isso, eu mesmo uso e tenho no meu aquario Hitech, muito rapido fazer qualquer coisa nele, ta tudo mastigado. MCU nativos é muito complicado e demorados ate pra compilar e as vezes precisa de Debugs SCI etc...

Verdade... São tidos como ferramenta de desenvolvimento, não de produção. Mas quebram bem o galho para aplicações específicas e funções que não sejam de alto risco.

Eu não o usaria para ser uma ECU (acredite, tem projeto pronto assim na net, com vídeo e tudo... que coragem...rsrsrs). Mas para um odômetro, ou para mostrar a saída de algum sensor a cada 1 segundo (eternidade em termos eletrônicos)? Não vejo problema.

Estão prometendo uma versão com processador ARM bem mais rápida e com mais portas.

esqueci de falar, na saida do opto nao precisa fazer c/pullup, ative o pullup do MCU, dae é so por no coletor do opto e aterrar o emissor e ta feito o chaveador

Só de configurar a porta como input ele já faz isso, não é?

500EF escreveu: ↑03 Mai 2017, 08:33 E como eu disse, até 1Khz, na bancada, o erro máximo foi de 0,3%. Não testei com mais porque não tinha necessidade para esta aplicação.

sem duvida, a 200 km/h caso seja 8 pulsos por cada 360º nao passa de 250 hz.

500EF escreveu: ↑03 Mai 2017, 08:33 Verdade... São tidos como ferramenta de desenvolvimento, não de produção. Mas quebram bem o galho para aplicações específicas e funções que não sejam de alto risco.

Eu não o usaria para ser uma ECU (acredite, tem projeto pronto assim na net, com vídeo e tudo... que coragem...rsrsrs). Mas para um odômetro, ou para mostrar a saída de algum sensor a cada 1 segundo (eternidade em termos eletrônicos)? Não vejo problema.

Estão prometendo uma versão com processador ARM bem mais rápida e com mais portas.

tu usa um 328 correto ?
http://www.atmel.com/pt/br/Images/Atmel ... asheet.pdf

dei uma olhada por cima e so confirmou oque ja tinha lido a anos atras, tem aplicaçao limitada, alias, a Atmel ate tem MCU pra aplicaçao automotiva mas nao o arduino (Atmel328 ou Mega)

pois é, so ser for pra um cortador de grama, ate pra moto mono cilindro ate ae daria... mas pra carro ta bem longe seu uso.
varias coisa me chamaram atenção. para o lado da limitaçao tecnica da aplicaçao

* apenas 32k de ROM, so grava um motor monocilindro e olhe la, nada de mapas completos com varias celulas etc, 32k da pra fazer quase nada
* baixo numero de portas I/O
* barramento 8 Bits sao apenas 255, overflow ultra mente lento e curto, oque usaria-se muito contador de OF pra fazer algum calculo de tempo
* so tres ISR um de 8 bits oque limitaria a precisao de igniçao e injeçao em 255, ou seja o comprimento dos pulsos seria muito espaçados,, e dois de 16 bits.
* +105ºC nao é pra automotivos que exigem +125º
* ADC é bom 10 e 16 bits isso é oque se usa em qualquer aplicaçao precisa.

e como todo MCu é completo e complexo pra iniciantes como nós é uma boa fonte de literatura e aprendizado.

500EF escreveu: ↑03 Mai 2017, 08:33 Só de configurar a porta como input ele já faz isso, não é?

nao, tu precisa informa mais comandos.
deixando assim:
pinMode(pin, INPUT);
digitalWrite(pin, HIGH); // ativa o pull up

obs: esse pull usa um resistor de 20 a 50k dependendo do modelo, e como te sugeri um cap de 10nF talvez atenue muito a subida do sinal do sensor, bom como tu nao vai passar dos 250hz pelo visto entao nao seria um problema. mas testa! deixar o sinal muito curvado diminua pra 1nF

isso vai evitar ruidos.

Certo.

Deixa chegarem os itens comprados lá na turma dozóio puxados (displays oled e sensor "MAP") que eu volto ao projeto...

500EF escreveu: ↑03 Mai 2017, 13:56 Certo.

Deixa chegarem os itens comprados lá na turma dozóio puxados (displays oled e sensor "MAP") que eu volto ao projeto...

legal, novidades coloca ae.

acabei de receber da Fedex meu pedido comprado da Mouser la dos EUA, o negocio foi tao bom que vou fazer um video mostrando a diferença em comprar no brasil e la fora. o pessoal do brasil chega passar vergonha da diferença tanto de tratamento ao cliente como de produto.

ate certificaçao de origem recebi dos componentes criticos da ECU(MCU + USB)

comprei na sex passada recebi hoje, mesmo com feriado pessoal trabalha. mais rapido que sedex nacional, custo caro devido os impostos mas o tratamento e a segurança é outro nivel.

eu ja comprei muito componente chines ate tenho e uso, mas ja me derem dor de cabeça, ou vem estragado, ou nao funciona certo, ou funciona mas nao se sabe ate quando rsrsrsrs. infelizmente qualidade tem preço e os cliente terão que pagar por isso. mas vale apena, eu sei que saiu do vale do sicilio e nao de um amarelo com um maçarico derretendo o CI pra revender.

compre um jogo de IGBT chines, quando fui soldar caiu as perninhas, resultado, (usado + original + queimado ao fogo)

pedi pro amigo Luiz do SR contar quantos pulsos é emitidos a cada 360º. realmente era como eu ja tinha imaginado a cada volta é o numero total de pulsos do sensor. 8,13,16P/360º

https://www.youtube.com/watch?v=DzxOIusHHbo


obs: voltando ao teu caso, se tu quer ter precisao ou seja fazer um hodometro profissional nao tem como tu nao usar tempo, eu fiz no meu o algortimo completo e tem que ter tempo, e tempo muito preciso senao nao funciona

o maximo que tu vai conseguir fazer nesses moldes é a cada 360º = 8 pulsos = comprimento da roda entao atualizaçao a cada 100m jamais vai conseguir. so com tempo. contagem de pulso vai funcionar porem nao por metro e sim pelo total da volta.

praticamente terminei o meu, so aguardava a confirmaçao dos pulsos a cada 360º

Mas é isso mesmo...

A forma mais precisa que eu achei de fazer foi por tempo também.

A cada período constante (500ms, por exemplo), eu pego o valor acumulado no contador e calculo a distância percorrida, através do número de pulsos que aconteceram neste período.

Aí zero o contador e faço novamente.

E o contador é incrementado sempre que uma interrupção acontece na porta onde liguei o sinal dos pulsos do sensor de velocidade. Como lá dentro da rotina da interrupção só tenho um comando "contador++", a interferência disso no tempo de processamento é desprezível e a precisão é bem aceitável.

E só atualizando o tópico, os displays já estão em terras brasileiras. Agora é só esperar a PF liberar e o correio não sumir com a minha encomenda... rsrsrs