Dexter, você deve ligar os pinos IN e OUT a dois I/Os do Arduino, o pino IN controla a leitura e o pino OUT gera um pulso proporcional à distância lida pelo sensor.

Por exemplo, ligando o pino IN ao pino 4 do Arduino e o pino OUT ao pino 5 do Arduino, seu código deve ficar mais ou menos assim:

Code:

//codigo baseado em um projeto do fundo do bau
//do tempo que eu usava os BS1 da Tato...

//inicializa I/Os
byte pinoInSensor = 4; //pino 4, IN do sensor
byte pinoOutSensor = 5; //pino5, OUT do sensor

//variaveis globais
byte distanciaEmCm = 0; //usa variavel byte por 2 motivos, o sensor nao le direito acima de +-220cm, e fica mais facil mandar pela serial
unsigned long duracaoDoPulso = 0;

void setup()
{
    pinMode(pinoInSensor, OUTPUT); //seta pino como saida
    digitalWrite(pinoInSensor, HIGH); //seta nivel alto na saida, estado de repouso do sensor
    pinMode(pinoOutSensor, INPUT); //seta pino como entrada
    digitalWrite(pinoOutSensor, HIGH); //habilita pull-up interno, so pra garantir...
    Serial.begin(9600);
}

//programa princpal
void loop()
{
    //gera pulso de 50uS no pino IN do sensor para iniciar uma leitura
    digitalWrite(pinoInSensor, LOW);
    delayMicroseconds(50);
    digitalWrite(pinoInSensor, HIGH);

    //deixa pino 5 esperando o pulso de leitura do sensor, que ocorre em nivel alto
    duracaoDoPulso = pulseIn(pinoOutSensor, HIGH);

    //converte a leitura de microsegundos para centimetros
    duracaoDoPulso *= 34; //multiplica pela velocidade do som
    duracaoDoPulso /= 2; //divide por 2, pois a leitura = tempo de ida + volta
    duracaoDoPulso /= 1000; //acerta a escala para centimetros
    if(duracaoDoPulso > 220) //overflow, erro na leitura do sensor...
    {
        duracaoDoPulso = 255; //valor 255 indica overflow, use como referencia no processing...
    }

    //passa valor para variavel byte e manda pela serial
    distanciaEmCm = duracaoDoPulso;
    Serial.print(distanciaEmCm, BYTE);

    //espera 1 segundo até a próxima leitura
    delay(1000);
}

Pra mim o grande problema é justamente o upload de sketches via serial, pois a grande maioria dos projetos que faço usa a serial para comunicação com outros equipamentos, são projetos stand-alone, não pra ficar mandando debug pela serial/usb... aí é um saco ter que ficar conectando e desconectando tudo pra atualizar o sketch, pois não dá pra ter um periférico E fazer upload pela serial ao mesmo tempo... o único porém é justamente a perda da interrupção externa, que pra mim é importante na leitura de cartões wiegand, que pela largura dos pulsos não podem ser lidos por pooling.

Já usei o AVR-CDC, funcionou 100%, só que usei a alimentação do M8 em 5 volts, com aquele arranjo dos zeners de 3v3 para as linhas de dados da USB, conforme visto em outros projetos de exemplo no site.

Uma alternativa que achei interessante foi aquela em que o bootloader emula um gravador/ISP USBASP... perde-se uma interrupção externa, mas ganha-se a gravação dos sketches via USB...

http://www.obdev.at/products/vusb/usbasploader.html

dentro da pasta "applet", dentro da pasta da sua sketch...

(sketch folder)\(sua sketch)\applet

Solução nacional para desenvolvimento com o Arduino, o ProtoShieldBR facilita a integração com os mais diversos componentes eletrônicos, fornecendo um layout semelhante às protoboards/breadboards, e abrindo as portas para sua criatividade transformar idéias em projetos reais.

Fornecido em forma de kit, o ProtoShieldBR traz, além da própria placa, componentes básicos para que você já possa começar a desenvolver seu próprio hardware.

Além disso, o ProtoShieldBR possui uma característica exclusiva: possui todas as legendas dos pinos do Arduino, facilitando e agilizando o processo de montagem.


Itens inclusos no Kit ProtoShieldBR.


Seu design permite que sejam "empilhadas" (stacking) várias unidades do ProtoSieldBR.
Invertendo a posição dos conectores macho/fêmea você pode empilhar vários ProtoShieldsBR, mantendo o equilíbrio e evitando quedas.


Exemplo de uso do ProtoShieldBR.

Mais informações no site ArduinoRS: http://www.arduinors.net/blog/protoshieldbr/
Adquira já o seu: http://produto.mercadolivre.com.br/MLB-88566938-protoshieldbr-kit-protoshield-para-arduino-_JM

Acho meio complicado fazer algo assim com o Arduino justamente pela falta de uma interface USB "de verdade"... Claro, dá pra enviar via serial e ter um driver que crie uma porta midi virtual... mas é muita gambi pro meu gosto... e por experiência própria, não funcina direito... Prefiro (e estou de olho pra fazer... só faltou tempo) algo assim: http://cryptomys.de/horo/AVR-MIDI/... Opensource, class driver, etc, etc, etc...

Erick, recomendo não usar os pinos RX/TX (0/1) do Arduino, pois um trem de pulsos chegando na serial pode disparar interrupções indesejadas.

Outra coisa, não precisa incluir a biblioteca software serial, e olhando rapidamente seu código, nem a stdio. A própria VirtualWire faz as devidas "configurações" dos pinos.

Se continuar tendo problemas, manda o seu novo código que a gente dá uma olhada.

Uma coisa que achei estranha... Você está tentando comunicar os 2 módulos com 1 só Arduino? Com certeza isso não vai funcionar, pois enquanto você estiver transmitindo, não poderá receber nada... Apenas a serial "de verdade" (pinos 0/1) consegue receber dados enquanto o processador estiver fazendo outra coisa, pois é um módulo assíncrono independente no hardware, com seu próprio buffer...

Detalhe... essa lib já implementa as sugestões que o Jeronimo indicou (header/sincronização e verificação de integridade por checksum).

Boa noite, Erick.

Eu e o Rafael já tivemos esse problema em um dos nosso projetos, realmente o problema é o formato dos dados que você deve usar com esses rádios.

Com o protocolo serial você dificilmente vai conseguir fazer eles conversarem, recomendo que você use a lib VirtualWire (http://www.open.com.au/mikem/arduino/VirtualWire.pdf, http://www.open.com.au/mikem/arduino/VirtualWire-1.1.zip), que implementa o procolo Manchester, o correto para uso com esse tipo de rádio.

Uma dica: não deixe o conjunto TX/RX tão próximo, pois pode haver sobremodulação no receptor, o que impossibilita a comunicação, mesmo usando o protocolo correto.

Eu usaria as duas INTs... tipo, usaria a MsTimer2 pra gerar uma interrupção a cada 1 segundo (ou meio segundo, depende de quanto em quanto tempo vc quer atualizar a leitura), cada vez que esse cara desse overflow, começa a contar quantas INTs os pinos vão gerar... no próximo overflow do timer, lê os contadores, multiplica pela base de tempo (x60 pra 1 segundo, x120 pra 1/2 segundo), mostra no display (imagino que terá um), e recomeça... zera os contadores, etc, etc, etc...

Why don't just use the good old RS-485? I've been sucessfully using that... Easy and cheap...

hum... I think i've readed sometime ago that burn bootloader don't works with usb/serial adapters... maybe you can search for it in forum...

I always have used the bootcloner for programming new mega8's, and after started using m168, the programmer2... they both are in the playground, and work like a charm... I've even made an shield to use with them...

The NM probably means Not Mounted... Junt under the link of the schematic there's an tip about R2 and R3...

"Note that R2 is not mounted and that R3 has been replaced by a 100 nano-farad capacitor."

or just use one of those smd2dip adapters...

Who says this chip is SPI?

It uses a simple data/clock serial bus, like many other shift registers do.

I suggest you to use any other two pins and shiftOut(), then you'll get the results you want.