isto não é assim tão dificil.

coloca aqui o codigo que tens para vermos o que se passa.

Pwm, wave ou mp3 shield.

Não fazes... para capturares um som e aumentares o seu valor, usas um amplificador.
É extremamente mais simples e extremamente mais eficiente e eficaz que usar um Arduino. Isto porque o Arduino não amplifica nada... logo mesmo que fosse possível fazer algo decente com um Arduino terias na mesma de arranjar um amplificador.

Com o perdão do termo, o Atmel Studio é um puta de um software, que te dá absolutamente tudo que você precisa para desenvolver (em termos de IDE). Sua IDE é baseada no Microsoft Visual Studio, portanto é algo de primeiríssima linha. Ele usa, no entanto, C e C++ em um nível de abstração bem mais baixo que o Arduino.

LOL, estás perdoado. LOLOL

Eu achei-o bastante complicado de usar... mas deu para ver que tem imensos recursos, bem como bibliotecas incluídas para imensas coisas e verdade seja dita, não me dediquei a fundo.

Quando referes baixo nível queres dizer aprender a programar em Assembly (ou código máquina) ou que queres ver-te livre de tudo o que tem a ver com o Arduino?

Os chips ARM não são muito simples de usar. Principalmente por todo o hardware que traz dentro e, excepto a ATMEL, arranjar uma IDE que funcione de borla. Eu tenho usado umas placas da leaflabs.com com uma IDE similar à do Arduino e tenho de admitir que um chip ARM dá imensas opções que os AVR não podem fazer.

Gravar no chip directamente não será algo muito difícil para ti e certamente que existem tutoriais na internet. Já procuraste?

Outra coisa apesar de dar um trabalho homérico e reescrever a lib sem o uso de delays.

No mundo do arduino em que a papa está toda feita, isso até pode ser verdade...

Ok... já que é assim, porque não teres ADs externos?
Estou farto de colocar esta questão e tu continuas sem responder...

Como calculaste o tempo que demora o envio das tramas?

E julgas que o ATMEGA tem 5 ADCs?

Não. Tem um ADC e um mux analógico, logo não vais ler 5 canais ao mesmo tempo a não ser que invistas em hardwar especifico.

Se preferes hardware complicado, porque é que não contemplas ADCs externos?

Nunca vais conseguir fazer aquisição de 44 canais ao mesmo tempo, logo acho melhor começares a pensar nas tolerâncias que são aceitáveis.

Os potenciómetros serão usados por humanos?

o mux que o hugo referiu é analógico. escolhres um canal com pinos digitais, mas o valor passado é analógico.

não percebi isso da entrada analógica e 8 saídas...

isto é para um trabalho de escola?

identifgicar os dados é feito vcom um protocolo.

como garantes que as medidas entre atmegas são simultaneas?

O que ainda ninguém referiu é que os pinos I2C no ATmega 8, 168 e 328 ficam no porto A... que coincidentemente é o porto do ADC.

Então vais ter 44/4 = 11 chips ATmega.

Isto é, a meu ver, um pouco ridículo. Importas-te de explicar a aplicação que pretendes fazer para darmos uma ideia sobre como melhor resolver isto?

A ideia do Hugo com um MUX parece-me a melhor. E ainda melhor seria um AD externo com vários muxes. Meia dúzia de chips e ficava tudo medido. Mas tu é que sabes.

Que precisão pretendes? 10? 8? 12? bits.  

4 chips destes:

http://www.ti.com/lit/ds/symlink/tlc2543.pdf

E tinhas a festa feita. O problema seria mesmo o facto de ser SPI e não I2C, ou seja, ocupar-te-ia 7 pinos em vez dos 2 que o I2C ocupa. No entanto, teria a vantagem de ser mais rápido.

Acho que a tua dúvida se prende com algo chamado de protocolo de comunicação. Basicamente tens de definir um protocolo para passar os dados dum lado para o outro. Isso é o que não falta neste fórum. Tudo o que envolve comunicação entre ambas as partes envolve um protocolo.

e algumas outras coisas que não recordo agora

Isto normalmente é o mais importante.

Precisão não significa que ele consegue ler 3mm... apenas que o erro duma medida será de 3mm. No entanto, tendo em conta que é o Arduino que mede o tempo, diria que o maior erro é mesmo vindo do Arduino e não do sensor ultrasónico.

Porque não fazes assim... pegas na biblioteca que tinhas inicialmente com os tais 29... e fazes várias medições. Vê os resultados que obténs e não faças medições de cms certos. Ou seja, coloca o teu objecto a 12,4 ou 5,6 cm do sensor. Vê os resultados e se variam.

Depois faz a alteração que eu postei aqui e repete as medidas. Tira umas dez medidas para cada um dos casos.
Mete aqui as medidas para darmos uma vista de olhos.

Já experimentaste isto:
http://arduino.cc/en/Tutorial/Ping?from=Tutorial.UltrasoundSensor ?
É um pouco diferente do código que tens no post em baixo.

Coloca aqui os resultados e talvez consigamos chegar ao problema.

Ahh, que objecto estás a tentar medir? Uma parede ou uma lata de coca-cola?

Viva,

Acho que o problema está em não usares o lcd.clear() sempre que queres colocar dados novos no LCD ou fazer mudança de menú e também não fazeres uso da função setCursor() para posicionar o cursor.

Code:

void trata_lcd(){
 
 
  switch(estado_menu) {
  case MENU_HOME: {
    lcd.print("Gota 1");
    lcd.setCursor(0,1);   <----------------ADICIONADO
    lcd.print("Gota 2");
    if (BUTTON_UP == HIGH) {
      temp = (temp+1)%3;
      }
      lcd.clear(); <-----------------------ADICIONADO
      lcd.print("menu");
      lcd.print(temp);
      if (BUTTON_RIGHT == HIGH) {
        estado_menu = temp;
      }
      break;

Que corrente é que esse motor consome?

E como vais ligá-lo ao microcontrolador?

Ok...

Porque é que não funcionou?

O código não compilou?
Não te deu a medida correcta?
Que troubleshooting fizeste?
Que distância estavas a tentar medir e como?

Após dar uma vista pelo código acho que tens de ver as coisas de forma diferente...
Comparar cada caracter da password sempre que é digitado não é boa ideia e provavelmente é isso que te está a prender...

Porque é que não fazes algo assim:

Code:

char input[6]; //isto é para testar.
char key = keypad.getKey();
if(key != NO_KEY) {
   
   if (key == '#') { //sequência para meter pass...
      imprime_coisas_no_lcd();
      while (contador <6) {
           key = keypad.getkey(); //vamos assumir que a pass pode ter todos os caracteres...
           if (key != NO_KEY) {
              input[contador++] = key;
           }
      } //end while.
      if (strncmp(input, senha, 6) == 0) {
           Abre_a_porta;
      } else{
           Mensagem_de_erro
      }
   }//end if
}

Agora a mecânica seria a mesma para guardar a pass... para mexeres na EEPROM fazes assim.

Code:

#include <avr/eeprom.h>
//imagina que tinhas a pass no vector input

for (int i=0; i<6; i++) {
   eeprom_write_byte(i, input[i]); //escreve nos endereços 0 a 5 da EEPROM.
}

No início do programa terias de ir buscar a pass à eeprom...

Code:

#include <avr/eeprom.h>


for (int i=0; i<6; i++) {
   senha[i] = eeprom_read_byte(i); //escreve nos endereços 0 a 5 da EEPROM.
}

Agora um aviso...

A tua sorte é que eu vi a mensagem pessoal após ter colocado isto aqui. Tivesse eu visto a tua mensagem primeiro e não teria escrito nada aqui. E a razão para isso é que:

Eu não sou o teu criado. Se respondo no fórum é para ajudar todos mediante a minha disponibilidade e disposição. Responder por mensagem pessoal iria contra o propósito do fórum e por isso evito-o.
Se realmente pretendes que eu te ajude por mensagem pessoal, então podemos chegar a um acordo e contrato onde me pagas pela ajuda que eu fornecer e poderás então definir os termos de confidencialidade do meu serviço. De forma contrária toda e qualquer ajuda que eu der tem de ser visível a todos os participantes do fórum (será boa ideia, veres o significado da palavra fórum).
Nota também que eu não me responsabilizo por parvoíces escritas neste espaço pelo que se vais seguir algo dito por mim, entende que o farás por tua conta e risco.

Dito isto, mensagens pessoais só se forem pessoais, ou seja, se já interagimos de alguma forma no passado ou se me pretendes convidar para uma churrascada com cerveja (paga por ti, obviamente).

Esta passa a ser a minha assinatura para que todos percebam... e aproveito para te avisar que o teu nome está boqueado de me enviar mensagens pessoais novamente.

Passa bem.

Vá... estamos a desviar-nos da thread e da pessoa com a dúvida.

Olhando para o código e como fiz a ressalva no início, ao multiplicares por 10 vês o valor em milimetros, mas efectivamente não mediste em milimetros. Como estás a usar um int, ao multiplicares por 10, ficas apenas com um zero no final do numero. Se tinhas 12cm, ficas com 120 mm. Se a variável fosse um float, terias casas decimais e então isso faria diferença.

Olhando para a tua biblioteca, se a função timing te devolve o tempo que demorou a onda a ir e o eco a vir em microsegundos, então o cálculo seria:

// The speed of sound is 340 m/s or 29 microseconds per centimeter.

Ou seja, 2,9 microsegundos por milimetro.

Code:

double microsecondsToCentimeters(long microseconds)
{
  // The speed of sound is 340 m/s or 2,9 microseconds per milimeter.
  // The ping travels out and back, so to find the distance of the
  // object we take half of the distance travelled.
  return (double) microseconds / 2.9 / 2.0;
}

Experimenta assim e vê que resultados obténs. Algo que também seria interessante ver era o numero de microsegundos que leva a enviar e receber o eco.

Desculpa o comentário sem grande ajuda (apesar deste não ser muito diferente do original), mas não estava nos meus melhores dias.