Guia CNC Brasil - Tudo sobre CNC, Router, Laser, Torno e 3D Print
ELETRÔNICA / ELÉTRICA => Eletrônica Básica => Microcontroladores => Tópico iniciado por: Smarley em 06 de Março de 2009, 19:21
-
Gostaria de saber se algum dos colegas ja utilizou transmissão RF para comunicação entre PIC's.
Eu vou utilizar aqui no apartamento, para controlar uns aparelhos eletrônicos.
Comprei no solda fria 2 Módulo Receptor de RF 315 MHz (RWS-371-3) e 2 Módulo Transmissor de RF 315 MHz.
Eu olhei que a taxa do transmissor é de 8Kbps, e do receptor de 4800bps.
Tem algum problema de eu trabalhar com uma taxa de 4000bps? eu queria trabalhar com uma mais baixa assim para dar uma folga pro receptor. No programa está em 9600bps ainda, mas vou baixa-la.
Eu não tenho necessidade de velocidade nos dados. O que o PIC mestre vai fazer é o seguinte.
Se alguem apertar o botão 1, ele vai mandar o valor 8 pela saída serial. Quando passar um tempo ele manda o valor 9. Com isso o outro PIC vai receber e interpretar este sinal. Cada vez que o escravo recebe ele manda o valor de volta para a confirmação do valor.
Para eu fazer isto basta ligar a saída do Tx e Rx no DATA no transmissor e receptor ou eu tenho que colocar algum resistor ou circuito entre eles?
O programa ja está pronto.
No meu circuito vou utilizar um DS1302 para marcar o horário, pois vou precisar dele para ligar um rele...
Só falta fazer a placa no Eagle, implementar mais umas funções no programa para ajuste do horário, e chegar os componentes.
Em anexo o datasheet do transmissor e receptor.
Abraço!
-
Tem algum problema de eu trabalhar com uma taxa de 4000bps?
Não há probs que eu saiba.
Para eu fazer isto basta ligar a saída do Tx e Rx no DATA no transmissor e receptor ou eu tenho que colocar algum resistor ou circuito entre eles?
Como vc pode ver no exemplo de aplicação na DS, não há necessidade de resistor.
Provavelmente vc terá de transmitir um preâmbulo para que o AGC do receptor se ajuste.
-
Provavelmente vc terá de transmitir um preâmbulo para que o AGC do receptor se ajuste.
Como assim? Para sincronizar o receptor e transmissor?
O que seria este preâmbulo?
Que tipo de sinal...
-
Provavelmente vc terá de transmitir um preâmbulo para que o AGC do receptor se ajuste.
Como assim? Para sincronizar o receptor e transmissor?
O que seria este preâmbulo?
Que tipo de sinal...
Quando não há transmissão o receptor abre o AGC, ou seja o ganho vai ao máximo e muito provavelmente os primeiros sinais recebidos serão severamente distorcidos, até que ocorra a acomodação do ganho, por isso é quase sempre necessário um preâmbulo, que pode ser uma simples sucessão de zeros e uns, o comprimento deverá ser determinado experimentalmente.
Eu tenho quase a certeza de que se não fizer isto terá probs.
-
Olá Smarley, caso vc não tenha experiencia em trabalhar com transmissao de dados via rf, sugiro utilizar os módulos XBee da MaxStream. Simpes, rápido, simples de ser configurado vc comunica com ele através de uma porta serial e vc nao irá precisar esquentar a cabeça com sincronismo, crc, sujeira, etc...
Uma alternativa mais barata, é o TRW-24G. Um pouco enjoado na hora de botar pra rodar, mas uma vez que vc acertar, não esquenta mais a cabeça.
Abraço
-
hmm..
Mas cara, eu acho que estou fazendo certo, da uma olhada.
No meu programa eu estou mandando o valor.
Recebendo ele de volta. Conferindo se é igual ao que foi mandado.
Se for diferente, ele manda denovo. Até que o valor correto volte do PIC escravo.
Isto não elimina estes problemas?
Eu até ia fazer um esquema para ele mandar, receber, conferir, e se estiver correto mandar outro sinal, liberando a acão do PIC escravo. Mas como ele só vai ter uma função por enquanto, eu não vou mandar este sinal de confirmação do mestre pro escravo. Até porque eu vou ter que conferir o valor de confirmação também.
-
Olá Smarley, caso vc não tenha experiencia em trabalhar com transmissao de dados via rf, sugiro utilizar os módulos XBee da MaxStream. Simpes, rápido, simples de ser configurado vc comunica com ele através de uma porta serial e vc nao irá precisar esquentar a cabeça com sincronismo, crc, sujeira, etc...
Uma alternativa mais barata, é o TRW-24G. Um pouco enjoado na hora de botar pra rodar, mas uma vez que vc acertar, não esquenta mais a cabeça.
Abraço
Vou pesquisar sobre estes módulos, mas eu acho que com o meu programa la, eu não vou ter problemas com sujeiras. Da uma lida no meu post anterior ali...
-
bao, fica a dica ai... caso tenha problema...
mas para completar a minha dica: esses módulos transceptores fazem o necessário para a comunicação seje feita sem erro, ou seja, se vc enviar um 'A', o receptor vai receber o 'A' e nada mais que isso. esse receptores eles ficam recebendo sujeiro o tempo todo.
para tentar resolver isso, eu te sugiro a criar pacotes de tamanho fixo (ex: 16 chars), com caracteres de inicio e fim (ex: SS: '@', FS: '#') e utilizar o oitavo bit para paridade. Resolveria 99% dos problemas.
-
Smarley, nao tinha lido o seu 1o post completamente e só agora vi q vc quer ligar/desligar algo remotamente.
Fica um pokim mais facil, agora pra facilitar de vez sua vida, bota uns ci da holtek especialmente feitos para essa função. não me lembro o modelo deles, mas no site vc acha facil.
-
tu se refere aqueles encoder e decoder?
Aqueles seriam para comunicação paralela--paralela.
Eu até poderia usar pois é somente 1 rele por enquanto.
Mas quando eu aumentar vou ter que disponibilizar mais portas do uC.
Vou tentar primeiro enviando um byte pelos 315Mhz mesmo.
-
Pelo que eu saiba, com esses módulos não tem problema usar uma taxa menor de transmissão.
Pra o que você quer fazer por enquanto, seu "protocolo" é razoavel.
Se quiser aumentar o número de funções aí eu sugiro que vc faça um protocolo de verdade como já foi sugerido, você pode ler um pouco sobre modbus pra entender como ele funciona e até implementar ele ou algo parecido.
Eu já implementei alguns protocolos mestre-escravo assim, geralmente usando alguns bytes por mensagem, por exemplo:
% O D FUNC ARG CRC #
onde
% - indica inicio do pacote
O - ID do emissor da mensagem
D - ID do Destinatario da mensagem
FUNC - função a ser executada
ARG - argumento da função, por exemplo, um número relacionado a função enviada
CRC - calculo do CRC
# - indica final da mensagem.
Usando pacotes com formatos parecidos com este se resolve muita coisa.
Abraço!
-
A função detes pacotes seriam para o receptor não pegar interferência? de portões eletrônicos ou qualquer outro aparelho se comunicando nesta faixa?
Para eu trabalhar com pacotes, eu tenho que largar a int e criar. Ai eu ja preciso de velocidade, pois antes era só um byte sendo enviado...
Eu não lembro, mas seria por ex.:
char %12liga1#
não entendi o que seria o CRC.
1 seria o transmissor e 2 o receptor.
liga, comando de ligar.
1, executa a função no rele 1.
Seria isto?
-
A primeira providência é fazer com que transmissor e receptor funcionem. Por incrível que pareça é aqui onde fracassa a maioria dos projetos desse tipo.
Minha sugestão é que teste e verifique este aspecto, qualquer outra sugestão cai no vazio se a transmissão / recepção não funciona ...
Pacotes e CRC não resolvem absolutamente nada se não forem corretamente recebidos ...
Não há coisa melhor que o esquema de handshake que se pretende implementar, é o ideal. Não faz sentido implementar outros algoritmos de redundância e verificação quando isto é possível.
-
A primeira providência é fazer com que transmissor e receptor funcionem. Por incrível que pareça é aqui onde fracassa a maioria dos projetos desse tipo.
...
Pacotes e CRC não resolvem absolutamente nada se não forem corretamente recebidos ...
Com certeza, tudo que eu falei é baseado nisso, acho que estamos falando de camadas diferentes =)
Não há coisa melhor que o esquema de handshake que se pretende implementar, é o ideal. Não faz sentido implementar outros algoritmos de redundância e verificação quando isto é possível.
Concordo de novo, só sugeri um pacote maior caso ele pretenda expandir o sistema dele, no final das contas fica mais "fácil" controlar tudo.
A função detes pacotes seriam para o receptor não pegar interferência? de portões eletrônicos ou qualquer outro aparelho se comunicando nesta faixa?
Se a interferencia for na camada do Hardware, nada vai funcionar, nao tem pacote que faça milagre. Isso serve para você endereçar e organizar o que cada "ponto de acesso" vai fazer. Se você nao pretende expandir o seu sistema, só ligar um equipamento remoto, tá razoavel o que vc quer fazer.
Para eu trabalhar com pacotes, eu tenho que largar a int e criar. Ai eu ja preciso de velocidade, pois antes era só um byte sendo enviado...
Eu não lembro, mas seria por ex.:
char %12liga1#
não entendi o que seria o CRC.
CRC de modo simples, é o resultado de uns calculos feitos com os bytes enviados ou recebidos, o transmisor e o receptor fazem o calculo dos bytes recebidos/enviados e esse valor CRC tem que bater nos dois pontos. Se bater o pacote ta integro, se não, aconteceu algum problema na transmissão/recepção.
1 seria o transmissor e 2 o receptor.
liga, comando de ligar.
1, executa a função no rele 1.
Seria isto?
Basicamente é isso aí.
Geralmente quando faço um esquema desse de pacote eu crio um array de char, coisa do tipo:
char PACOTE[16];
Aí em cada posição você coloca cada byte do seu protocolo.
-
Com certeza, tudo que eu falei é baseado nisso, acho que estamos falando de camadas diferentes =)
Nós estamos falando da mesma coisa, a diferença é que vc preconiza uma solução pouco adequada para o caso, mais complexa, sem que essa complexidade traga qualquer benefício, ao contrário, considerando as condições específicas da implementação, pode ser um tiro no pé.
Pacotes são utilizados e justificáveis onde há tráfego de grande volume de dados e num período considerável.
É o caso dos HDs, onde seria insano tentar tratar os dados a nível de byte e portanto adota-se maior granularidade, tratando-se setores ou mais realisticamente, clusters. É o caso tb em redes, onde se trata, por exemplo pacotes de 1.500 bytes. Obviamente o tratamento de pacotes da tal tamanho não só recomenda, mas obriga à utilização de algoritmos de verificação sofisticados e descarta a redundância.
O que discutimos aqui é coisa de natureza quantitativa e qualitativamente muito diferente. Trata-se de ambiente doméstico, tráfego ridiculamente modesto, meio nada confiável e redundância absoluta à mão e isto faz toda a diferença.
-
Jorge, acho que o que eu disse não é tão inviavel nem inadequado quanto parece.
Eu falei que pra o que ele quer tá razoavel a solução dele, se for só isso mesmo, deve ser até o melhor custo/beneficio.
O que tentei aconselhar, é que caso ele pretenda usar mais funções futuramente no sistema ou mais de um escravo, fica dificil fazer desse jeito.
Não me provoca não senão eu vou sugerir um algoritmo de correção de erros... he he he ;D
-
Eu não disse que sua proposta é inviável, nem inadequada, o que eu disse é que é pouco adequada, pq é mais complexa e não traz benefícios. :P
Considere-se provocado ! ;D
A solução proposta não apenas é "razoável", é a melhor possível, em qualquer circunstância. Se discorda, apresente coisa melhor. Isto tb é uma provocação. ;D
-
Pessoal, que bom que se interessaram por isso!
Eu gosto de fazer programas para microcontroladores e pensar em algorítmos para resolver soluções.
Eu vou fazer o seguinte.
Eu não vejo a necessidade de enviar mais de um byte para o escravo... A não ser que seja por causa da interferência.
Mas eu vou tentar resolver assim:
Vou mandar um byte para o escravo. No caso o valor 8.
O escravo recebe este byte, manda de volta, e grava numa variável "y".
O mestre verifica se o valor que voltou foi o mesmo enviado.
Caso positivo, o mestre manda um outro valor, 16 por exemplo.
O escravo recebe este valor, manda de volta e antes de gravar na variável y, ele verifica se o valor é 16.
Caso seja negativo, ele vai mandar de volta para o mestre outro valor, que não vai ser 16. Aí o mestre volta para o começo, mandando o valor 8, para que o escravo não grave um valor errado na variável "y".
Caso positivo, o escravo entra em um laço de menu(), que vai ser onde está os comandos dos reles.
No caso, o valor 16 seria para dar um comando "pode começar" e o valor 8 seria o comando do rele.
Vou implementar isto no programa hoje, e testar.
Se der certo deste jeito, eu posso colocar vários escravos, e continuar usando 1 byte. Porque eu colocaria o valor de "pode começar" diferente para cada escravo.
:)
Abraço!
-
Smarley,
imagine a possibilidade de vc receber do receptor continuamente isso: "DF13213D456S879S5S2 3SDASFDASFDSA89F56F D4H..." (ele vai estar sempre recebendo caracteres, exitem milhares de fontes de 315mhz ao nosso redor. nem vou considerar harmônicas)
será que vc vai conseguir indentificar um caractere enviado do mestre?
-
Me desculpe pelo post incompleto, comi bola aqui.
Mas continuando...
O jeito mais simplista de fazer isso na minha opnião, é filtrar na int da serial os caracteres de controle e enviar cada comando umas 10x num determinado período. no receptor vc contaria esses caracteres, confirmaria se esta dentro do tempo e dispensaria a necessidade do handshaking e consequentemente de mais um transceptor.
-
Acho que sim, pois só vai dar problema se o recepetor receber o valor.
8 e depois 16 na mesma seqüencia.
Caso ele receba um 8, e depois 9, ele não vai ser liberado para fazer nada.
Ou se ele receber um 9 e depois 16, ele vai entrar no menu, mas não vai ter esta opção la.
Para diminuir este problema eu posso enviar uma char então com mais bytes.
Mas não sei se isto será problema.
Uma dúvida besta aqui...
Como as letras e outros caracteres, como !&%@# são representados com os 8 bits de uma char?
Pode até parecer bobagem não lembrar disto, mas a ressaca não me deixa pensar agora... :P
-
Me desculpe pelo post incompleto, comi bola aqui.
Mas continuando...
O jeito mais simplista de fazer isso na minha opnião, é filtrar na int da serial os caracteres de controle e enviar cada comando umas 10x num determinado período. no receptor vc contaria esses caracteres, confirmaria se esta dentro do tempo e dispensaria a necessidade do handshaking e consequentemente de mais um transceptor.
Isto vai ser pensado futuramente!
para eliminar um receptor e transmissor.
Mas eu não sei se vou fazer isto, pois eu também quero informações do escravo.
Como controle do nível da água.
-
Smarley, vc esta falando da tabela ASCII?
http://pt.wikipedia.org/wiki/ASCII (http://pt.wikipedia.org/wiki/ASCII)
-
hmm
não lembrava mesmo...
Quando o uC receber este valor, o do caractere. Como ele faria para diferenciá-lo de valores comuns e mostrar o caracter no LCD?
-
Eu não disse que sua proposta é inviável, nem inadequada, o que eu disse é que é pouco adequada, pq é mais complexa e não traz benefícios. :P
Considere-se provocado ! ;D
A solução proposta não apenas é "razoável", é a melhor possível, em qualquer circunstância. Se discorda, apresente coisa melhor. Isto tb é uma provocação. ;D
Hehe, Eu acho razoavel porque não considero 100% seguro esse tipo de implementação. Num ambiente doméstico pode até funcionar, mas não é totalmente improvavel que algo estranho aconteça quando alguém começar a brincar com o alarme do carro, controle do portão e etc... Te garanto que esses controlezinhos não mandam um byte só, mandam uma cacetada de coisa que podem coincidir com os bytes solteiros que você esta usando.
Quando você manda um pacote, tem um sequência de dados nele, e o receptor só entende aquilo. Se chegar um monte de byte quebrado ou coisa fora do lugar ele vai simplesmente ignorar. Se tiver CRC ainda, só com interveção divina para seu receptor aceitar algo errado.
Já que é pra sugerir me ocorreu agora que você poderia mandar para o receptor dois bytes. um com o endereço do escravo e um outro número qualquer. vc faria uma multiplicação, um ou-exclusivo, ou qualquer algoritmo com esses dois bytes e devolveria esse valor ao mestre, se isso bater o mestre devolve uma confirmação com mais de um byte. Mesmo assim, ainda não é seguro... eu prefiro os pacotes... ;D
Mas repetindo... não discordo do que está sendo feito...
-
Eu tava tentando simular agora. O envio do byte de comando e do byte de liberação.
Mas está acontecendo algo estranho...
Tipo, quando o escravo recebe 8, e depois 32. Ele manda devolta 8+16+32 = 56.
Mas o mestre está mandando somente 32.
no escravo só tem isso de programa e ele mandar assim...
while(true)
{
x=getc();
putc(x);
y=getc();
putc(y);
if(y==16)
{
if(x==8)
{
output_high(PIN_B3);
}
else
{
output_low(PIN_B3);
}
}
}
o que pode estar errado?
quando eu mando 81 para escravo depois do 8. Ele manda 89.
Ele está sempre somando este valor, e as vezes imendando ele. dependendo do número que recebe.
-
o que a função xxxx faz? e a output_high?
em que lugar que é enviado de volta pro mestre?
-
Smarley,
liga esse receptor na serial do pc, abre o hyper terminal e da uma analisada no q vc recebe do mestre.
pelo q pude perceber, vc esta achando q vc só vai receber os dados q o seu transmissor enviar. e não é bem porai...
-
Smarley,
Não sei se é o caso, mas se seus módulos forem identicos (2 TX e 2 RX), com exatamente a mesma frequencia. Você tem que levar em consideração que tudo que vc envia por qualquer TX, chega nos 2 RX. e tem que ser previsto no seu algoritmo do mestre e do escravo.
E tem que ter algum controle pra o mestre e o escravo nunca falarem ao mesmo tempo, senão ninguem se entende.
-
bah cara, mas eu estava usando o simulador no pc. Proteus.
E nem estava usando módulos sem fio.
Tava no fio mesmo...
Não sei porque aconteceu isso.
Tem mais esse detalhe neh...
só que é assim cara.
Se eu tenho um "putc(x);" no mestre. Ele está só mandando.
E na próxima linha eu tenho um "getc();".
Ou seja. Ele vai mandar, e quando terminar, pular para o próximo comando e receber.
Tu acha que eu vou ter problemas assim?
Eu vou usar pacotes, de uns 10bytes ou mais, porque não me custa nada fazer isto...
abraço!
-
plancton81, ele nao recebe somente dos 2 tx nao veio...
ele fica recebendo dados a doidado...
os txs funcionando ou nao, ele ta recebendo dados...
Smarley, posta seu codigo inteiro ai q fica mais facil
-
Cfreund, é verdade, e já passei por isso fazendo um projetinho com um amigo meu, exatamente com módulos como estes.
Era um sistema de telemetria para enviar sinais biomédicos de um "paciente" para um PC, nada profissional, coisa da época de estudante mesmo.
Sem enviar nada, o receptor não parava de receber lixo. Na época, fizemos um esquema bem simples pra filtrar "tudo" isso.
Só aceitava o que fosse 0,1,2,3,...A,B,C,D,E, o resto todo descartava (mesmo assim não é muito seguro, sou chato!). Fora que pra enviar uma informação, antes era enviado um monte de lixo pra ele conseguir receber o resto, só me toquei o que eu estava fazendo quando li o que o jorge falou sobre o AGC.
Hoje em dia com certeza faria com pacotes. Alias, hoje em dia sou fã de pacotes! hehe ;D
-
Bem vindo ao mundo dos radios regenerativios, pega tudo que é porcaria, junto com o sinal que vc envia.
-
Não sei se vosmecês estão familiarizados com ZigBee, mas é o que eu pensaria em utilizar em projetos de automação doméstica mais sérios.
Os módulos da XBee custam entre US$ 20 e US$ 35, coisa de gente grande, vale a pena conhecer. Tem gente usando até pra controle de aeromodelos, com alcance de alguns quilômetros ...
Há um bom artigo sobre a coisa aqui:
http://www.rogercom.com/ZigBee/ZigBee.htm
-
Kms e força de expressão a não ser se voce usar configuração de rede com varios modulos em set reduzido.
Mas são muito bons para ambientes com interferencia principalmente se voce configurar para rede mesh.
A freescale manda amostras para o Brasil e tem um stack disponivel para brincar.
Edson
-
Kms e força de expressão ...
Obrigado por me fazer notar que grafei incorretamente a unidade, já corrigi.
Não é força de expressão e o que vc citou não é a única maneira de estender o alcance. Há outras soluções.
-
poisé plancton...
por essas e outras q hoje em dia, eu só uso esses receptores pra coisas bem simplistas mesmo e em pacotes + crc...hehehe (na minha visão nao tem nada mais eficiente).
pra assuntos profissionais, ja dou preferencia ao TRW-24G q utiliza o nRF2501A da nordic q é um excelente transceptor.
e quando preciso de potencia, mas sem preocupação com baterias, ja pulo pros xbee pro. que é uma delicia trabalhar com eles..., só configura ele uma vez só com canal, id, baudrate, potencia, etc... e ligar na uart.
pena q custa R$100,00 cada um desses bixo.
-
ali quando aparece xxxx(x); é p u t c (x);
eu acho que deve ter algum bloqueio aqui no fórum contra isso.
Agora eu vou entrar para um grupo de pesquisa na faculdade e vou trabalhar com zigbee e outros métodos de comunicação.
Mas para usar em casa eu vou testar o RF, se não funcionar bem eu compro o zigbee. Onde se encontra aqui no brasil?
É que era só para ligar uma cafeteira, não vale a pena eu investir tanto dinheiro nisso...
Seria só colocar um relogio de tempo, mas eu resolvi fazer sem fio para aprender mais.
Vou colocar o programa completo aki.
Vai ter que ser por download pois é meio extenso.
abraço!
-
Smarley,
faz +/- 2 anos q nao compro esses modulos
mas eu costumava comprar na vika controls que fica na av. paulista - centro de sao paulo.
http://vikacontrols.com.br/destaque_capamaxtream.htm (http://vikacontrols.com.br/destaque_capamaxtream.htm)
-
Aqui está o programa.
Fiz com um pacote de 16 bytes, com os valores de 0 a 15.
Só falta o cabeçalho que eu não coloquei aqui...
#include "C:\Program Files\PICC\PICC\comando.h"
#include <DS1302.C>
#define LCD_ENABLE_PIN PIN_B0
#define LCD_RS_PIN PIN_B1
#define LCD_RW_PIN PIN_B2
#define LCD_TYPE 2
#include <lcd.c>
int8 hr,min,sec,day,day1,mth,year,dow,x,y;
int32 val32,tempo,val1,val2,val3,val4,val5,valor; //variaveis para leitura da temperatura
static boolean ler_temp=0,z=0,a=0;
char pacote[16],pacote1[16];
void escreve_data()
{
printf(lcd_putc,"\f %i:%i:%i %luC",hr,min,sec,valor);
switch(dow)
{
case 1:printf(lcd_putc,"\nDomingo %i-%i-200%i",day,mth,year);
break;
case 2:printf(lcd_putc,"\nSegunda %i-%i-200%i",day,mth,year);
break;
case 3:printf(lcd_putc,"\nTerca %i-%i-200%i",day,mth,year);
break;
case 4:printf(lcd_putc,"\nQuarta %i-%i-200%i",day,mth,year);
break;
case 5:printf(lcd_putc,"\nQuinta %i-%i-200%i",day,mth,year);
break;
case 6:printf(lcd_putc,"\nSexta %i-%i-200%i",day,mth,year);
break;
case 7:printf(lcd_putc,"\nSabado %i-%i-200%i",day,mth,year);
break;
}
}
void ler_data()
{
hr = rm_bcd(read_ds1302(0x85));
min = rm_bcd(read_ds1302(0x83));
sec = rm_bcd(read_ds1302(0x81));
day = rm_bcd(read_ds1302(0x87));
mth = rm_bcd(read_ds1302(0x89));
year = rm_bcd(read_ds1302(0x8d));
dow = rm_bcd(read_ds1302(0x8b));
}
void envia_byte()
{
envia_denovo:
x=0;
while(x<16)
{
xxxx(pacote
);
delay_ms(50);
x++;
}
x=0;
while(x<16)
{
pacote1
=getc();
x++;
}
x=0;
while(x<16)
{
if(pacote
!=pacote1
)
{
goto envia_denovo;
}
x++;
}
}
void liga_cafe()
{
if(input(PIN_C3))
{
while(input(PIN_C3))
{
}
printf(lcd_putc,"\fLigando\na cafeteira...");
x=0;
y=0;
while(x<16)
{
pacote
=y;
x++;
y++;
}
envia_byte(); //Manda e verifica o pacote
delay_ms(500);
printf(lcd_putc,"\fCafeteira\nligada...");
delay_ms(500);
tempo=0;
a=1;
}
if((hr>6)&&(min>15)&&(z==0))
{
if((hr<7)&&(min<10))
{
printf(lcd_putc,"\fLigando\na cafeteira...");
x=0;
y=0;
while(x<16)
{
pacote
=y;
x++;
y++;
}
envia_byte(); //Manda e verifica o pacote
delay_ms(500);
printf(lcd_putc,"\fCafeteira\nligada...");
delay_ms(500);
z=1;
day1=day;
}
if((hr==8)&&(min==15))
{
x=15;
y=15;
while(x>=0)
{
pacote
=y;
x--;
y--;
}
envia_byte(); //Manda e verifica o pacote
delay_ms(500);
printf(lcd_putc,"\fCafeteira\nDesligada...");
delay_ms(500);
}
}
}
void atualiza_data()
{
write_ds1302(0x86,get_bcd(day));
write_ds1302(0x88,get_bcd(mth));
write_ds1302(0x8c,get_bcd(year));
write_ds1302(0x8a,get_bcd(dow));
write_ds1302(0x84,get_bcd(hr));
write_ds1302(0x82,get_bcd(min));
write_ds1302(0x80,get_bcd(0));
}
void ler_valor()
{
valor=read_adc();
if(valor) valor += 1;
val32=(valor*4+((int32)valor*113)/128);
val32=(val32)/30;
val1=val32;
valor=read_adc();
if(valor) valor += 1;
val32=(valor*4+((int32)valor*113)/128);
val32=(val32)/30;
val2=val32;
valor=read_adc();
if(valor) valor += 1;
val32=(valor*4+((int32)valor*113)/128);
val32=(val32)/30;
val3=val32;
valor=read_adc();
if(valor) valor += 1;
val32=(valor*4+((int32)valor*113)/128);
val32=(val32)/30;
val4=val32;
valor=read_adc();
if(valor) valor += 1;
val32=(valor*4+((int32)valor*113)/128);
val32=(val32)/30;
val5=val32;
valor=(val1+val2+val3+val4+val5)/5;
}
#int_timer0
void trata_t0()
{
int conta;
static boolean led;
set_timer0(131 + get_timer0());
conta++;
if(conta == 125)
{
conta=0;
output_bit(PIN_D6,led);
ler_temp=!ler_temp;
led=!led;
tempo++;
}
}
void desliga_cafe()
{
if(tempo==2400) //alterei o valor para 1 segundo só para testes.
{
x=0;
y=15;
while(x<16)
{
pacote
=y;
x++;
y--;
}
envia_byte(); //Manda e verifica o pacote
delay_ms(500);
printf(lcd_putc,"\fCafeteira\nDesligada...");
delay_ms(500);
a=0;
}
}
void verifica_var()
{
if(ler_temp==1)
{
ler_valor();
}
if(day1!=day)
{
z=0;
}
if(a==1)
{
desliga_cafe();
}
}
void menu()
{
if(input(PIN_D2))
{
hr++;
write_ds1302(0x84,get_bcd(hr));
while(input(PIN_D2))
{
}
}
if(input(PIN_D3))
{
min++;
write_ds1302(0x82,get_bcd(min));
while(input(PIN_D3))
{
}
}
if(input(PIN_D0))
{
mth++;
write_ds1302(0x88,get_bcd(mth));
while(input(PIN_D0))
{
}
}
if(input(PIN_D1))
{
day++;
dow++;
if(dow==7)
{
dow=0;
}
write_ds1302(0x86,get_bcd(day));
write_ds1302(0x8a,get_bcd(dow));
while(input(PIN_D1))
{
}
}
}
void main()
{
lcd_init();
setup_adc_ports(AN0_AN1_AN3);
setup_adc(ADC_CLOCK_INTERNAL);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_64);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
enable_interrupts(global|int_timer0);
set_adc_channel(0);
rtc_init();
delay_ms(100);
ler_valor();
ler_data();
while(true)
{
delay_ms(100);
verifica_var(); //verifica os timers e o acoinamento do café, 1 vez por dia.
ler_data(); //le a data e hora do DS1302.
escreve_data(); //identifica a data e hora, e mostra no LCD.
menu(); //correção nos minutos e horas.
liga_cafe(); //verifica o acionamento do café.
}
}
-
Onde se le
Este é o programa do escravo.
#include "C:\Program Files\PICC\PICC\receptor 16f628A.h"
#int_timer0
void trata_to()
{
int conta;
static boolean led;
set_timer0(131 + get_timer0());
conta++;
if(conta == 125)
{
conta=0;
output_bit(PIN_B0,led);
led=!led;
}
}
char pacote[16],pacote_liga[16],pacote_desliga[16];
int x,y;
void carrega_valores()
{
x=0;
y=15;
while(x<16)
{
pacote_desliga
x++;
y--;
}
x=0;
while(x<16)
{
pacote_liga
x++;
}
}
void main()
{
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_64);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
enable_interrupts(global|int_timer0);
carrega_valores();
while(true)
{
x=0;
while(x<16)
{
pacote
x++;
}
x=0;
while(x<16)
{
putc(pacote
delay_ms(50);
x++;
}
x=0;
while(x<16)
{
if(pacote
{
output_high(PIN_B3);
}
x++;
}
x=0;
while(x<16)
{
if(pacote
{
output_low(PIN_B3);
}
x++;
}
}
}
-
Smarley,
antes que eu seja mal compreendido ou falar besteira, eu nao trabalho com PIC e sim com AVR.
Nem imagino qual compilador vc esta usando.
mas partindo do ponto que c é c em qualquer lugar, vamos la...
dei uma olhada por cima e vi alguns problemas de conversao de tipos.
o mais engraçado é q o compilador deveria ter parado nesses pontos.
por ex:
char pacote[16],pacote_liga[16],pacote_desliga[16];
int x,y;
void carrega_valores(){
x=0;
y=15;
while(x<16){
pacote_desliga=y; // aqui vc esta convertendo int em char[16]. nao seria: pacote_desliga
x++;
y--;
}
x=0;
while(x<16){
pacote_liga=x; // aqui vc esta convertendo int em char[16]. nao seria: pacote_liga
x++;
}
}
Mais tarde eu vou dar uma sapiada melhor e se eu achar algum erro, vou te apontando.
Abs,
-
ops, complicou os comments.
deixa eu tentar corrigir:
"aqui vc esta convertendo int em char[16]. nao seria: pacote_desliga[ x ]= y; ?"
"aqui vc esta convertendo int em char[16]. nao seria: pacote_liga[ x ]= x; ?"
-
Mas é o que está escrito la.
É que o fórum apaga os [ x ].
Mas ta la, pacote_desliga[ x ]=y;
-
Fiz a placa agora a pouco...
Só que estou pensando ainda se vou usar ela ou não.
As trilhas ficaram finas, fiz com 50mil. Deveria ter feito com 70mil.
-
me desculpe Smarley, nao tinha percebido.
mas vc vai ter problemas nessa comunicacao ai.
o problema é q o receptor estara sempre recebendo dados, vc transmitindo ou nao. vc vai ter q montar um protocolo de comunicacao com caractere de inicio, de fim e arrumar um jeito pra vc confirmar se o caractere recebido é do mestre msm. um idéia é vc fazer um filtro para passar somente alguns caracteres, por ex: '!' para inicio de pacote; '#' para fim de pacote, e os digitos de 0 a 9. como esses caracteres usam somente 7 bits, vc poderá usar o oitavo bit para paridade (contaria os bits setados, se o resultado for impar, setaria o oitavo bit)
-
Pessoal só para tentar facilitar a compreensão dos códigos existe uma ferramenta "Inserir código" que preserva o código fonte original.
Exemplo:
include "C:\Program Files\PICC\PICC\receptor 16f628A.h"
#int_timer0
void trata_to()
{
int conta;
static boolean led;
set_timer0(131 + get_timer0());
conta++;
if(conta == 125)
{
conta=0;
output_bit(PIN_B0,led);
led=!led;
}
}
char pacote[16],pacote_liga[16],pacote_desliga[16];
int x,y;
void carrega_valores()
{
x=0;
y=15;
while(x<16)
{
pacote_desliga[x] =y;
x++;
y--;
}
x=0;
while(x<16)
{
pacote_liga[x] =x;
x++;
}
}
void main()
{
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_64);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
enable_interrupts(global|int_timer0);
carrega_valores();
while(true)
{
x=0;
while(x<16)
{
pacote[x] = getc();
x++;
}
x=0;
while(x<16)
{
xxxx(pacote[x]);
delay_ms(50);
x++;
}
x=0;
while(x<16)
{
if(pacote[x]==pacote_liga[x])
{
output_high(PIN_B3);
}
x++;
}
x=0;
while(x<16)
{
if(pacote[x] == pacote_desliga[x])
{
output_low(PIN_B3);
}
x++;
}
}
}
-
Smarley,
Um tempo atrás fiz um sistema de armário escuro que usa um protocolo parecido com esse que sugeri, tem o link do video dele funcionando na minha apresentação http://www.guiacnc.com.br/forum/index.php/topic,1952. (http://www.guiacnc.com.br/forum/index.php/topic,1952.)
Não achei aqui na máquina do trabalho a última versão do código, essa deve ter alguns bugs e burrices...
Vou passar o código integral pra vc dar uma olhada na parte do protocolo. Tem dois arquivos, um com exemplos de dados passados pra maquina pelo hyperterminal por exemplo e outro com o código fonte. a função que tem grande parte disso é a "__interrupt void usart0_rx (void)".
Abraço
-
Fiz um programa agora e botei no PIC e na placa.
Terminei de montar ela agora a pouco.
No programa mandei ele pegar o que tivesse no ar e mostrar no LCD.
Realmente a quantidade de informações é enorme.
Eu não sei o q aconteceu que ele só está recebendo 3 valores e parando.
Vou revisar o programa, mas acho que está tudo certo.
#include "C:\Program Files\PICC\PICC\receptor 16f877a.h"
#define LCD_ENABLE_PIN PIN_B0
#define LCD_RS_PIN PIN_B1
#define LCD_RW_PIN PIN_B2
#define LCD_TYPE 2
#include <lcd.c>
int x;
void main()
{
lcd_init();
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
while(true)
{
printf(lcd_putc,"\fRecebi=");
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"\n%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
x=getch();
printf(lcd_putc,"%i ",x);
delay_ms(100);
}
}
Esse é o programa.
Plancton, vou dar uma olhada nos seus arquivos.
Cfreund não entendo porque colocar um caracter no começo e outro no fim.
Se da no mesmo eu colocar números ou não.
-
Smarley,
vc pode sim colocar números, desde que no resto da mensagem nao os repita.
além de não permitir que isso aconteça, ficaria mais facil pra vc na hr de programar ou revisar o código.
vc precisa de um caracter fixo e único para que, na hora em que vc receber o pacote, vc saiba onde ele começa.
-
o programa do plancton é um excelente exemplo.
mas como vc terá um ingrediente a mais na seu projeto, o ruído, eu te aconselho a colocar a paridade para saber se o caractere recebido faz parte do pacote ou não. fazendo isso seu pacote terá mais chances de estar íntegro com os 16 caracteres.
-
Pois eh...
mas pelo que eu to vendo aqui, tem muita bobagem no ar.
Mas muita mesmo... ele não para de receber nunca.
Vai ser quase impossível os 16 bytes chegarem la sem nenhum byte estranho pelo meio.
Eu acho que vou ter que diminuir a quantidade de bytes do pacote.
1 só byte não tem como, pois assim ele iria ligar toda hora...
Tem que ser uns 5 bytes que dai ja elimina as chances de outros equipamentos ligarem ele.
-
Smarley,
se vc trabalhar a 4800bps (q é maximo segundo o datashit do receptor), quando vc estiver recebendo dados do transmissor, as chances de entrar um byte intrometido é mínima. e se você usar paridade, diminui ainda mais.
tava pensando aqui e bolei um jeito facil e eficiente para essa verificacao:
se vc trabalhar com números de 0 a 7, vc usaria somente 3 bits.
definiria o número 7 como inicio de pacote e o número 0 como fim e deixaria o resto para comandos.
sobrariam 5 bits, certo? entao vamos aproveita-los:
1' ao 3' - Utilizaria para os números de 0 a 7.
4' ao 7' - Utilizaria para enviar a posição do byte atual dentro do pacote.
8' - Paridade. Se a contagem dos bits '1' for par, setaria em '1'.
Ex.:
Pacote[00] = 0b1 0000 000; // bit8: P; bit7~4: Posição 0; bit3~0: Inicio de Pacote
Pacote[01] = 0b1 0001 001; // bit8: P; bit7~4: Posição 01; bit3~0: Número 1.
Pacote[02] = 0b1 0010 010; // bit8: P; bit7~4: Posição 02; bit3~0: Número 2.
Pacote[03] = 0b1 0011 011; // bit8: P; bit7~4: Posição 03; bit3~0: Número 3.
Pacote[04] = 0b1 0100 100; // bit8: P; bit7~4: Posição 04; bit3~0: Número 4.
Pacote[05] = 0b1 0101 101; // bit8: P; bit7~4: Posição 05; bit3~0: Número 5.
Pacote[06] = 0b1 0110 110; // bit8: P; bit7~4: Posição 06; bit3~0: Número 6.
Pacote[07] = 0b1 0111 111; // bit8: P; bit7~4: Posição 07; bit3~0: Número 7.
Pacote[08] = 0b1 1000 111; // bit8: P; bit7~4: Posição 08; bit3~0: Número 7.
Pacote[09] = 0b0 1001 111; // bit8: I; bit7~4: Posição 09; bit3~0: Número 7.
Pacote[10] = 0b0 1010 111; // bit8: I; bit7~4: Posição 10; bit3~0: Número 7.
Pacote[11] = 0b1 1011 111; // bit8: P; bit7~4: Posição 11; bit3~0: Número 7.
Pacote[12] = 0b0 1100 111; // bit8: I; bit7~4: Posição 12; bit3~0: Número 7.
Pacote[13] = 0b1 1101 111; // bit8: P; bit7~4: Posição 13; bit3~0: Número 7.
Pacote[14] = 0b0 1111 111; // bit8: I; bit7~4: Posição 14; bit3~0: Número 7.
Pacote[15] = 0b0 1111 111; // bit8: I; bit7~4: Posição 15; bit3~0: Fim de Pacote
da pra amadurecer a idéia, mas o propóstio principal é te dar uma luz das varias maneiras de que pode ser feito isso.
-
... aconselho a colocar a paridade para saber se o caractere recebido faz parte do pacote ou não.
Ô dureza ...
Paridade não serve para nada neste caso. Quem inventou tava de porre e quem usa não parou pra pensar ... ;D ;D ;D
-
Jorge, poderia me explicar o porque dessa sua afirmação?
-
Jorge, poderia me explicar o porque dessa sua afirmação?
Poderia. Mas antes reflita um pouco ... faça aí uma simulação, mesmo que com papel e lápis e vc vai perceber ...
-
Nem preciso, sei muito bem como funciona.
não somente eu como: fabricantes de memória ecc, usuários de varios protocolos como o f2f, e uma kctada de gente...
-
Cara, eu tava pensando aqui agora...
nunca isso vai funcionar!
eu fiz o seguinte, coloquei o transmissor e o receptor na placa.
Fiz um programa:
#include "C:\Program Files\PICC\PICC\receptor 16f877a.h"
#define LCD_ENABLE_PIN PIN_B0
#define LCD_RS_PIN PIN_B1
#define LCD_RW_PIN PIN_B2
#define LCD_TYPE 2
#include <lcd.c>
int y,x;
void main()
{
lcd_init();
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
x=0;
while(true)
{
if(x>100)
{
x=0;
}
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"\f%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"\n%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
x++;
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"%i ",y);
}
}
E sempre da erro.
Nunca ele lia o byte certo.
Ai eu pensei, como que ele vai ler, se o byte ja foi mandado? o.O
Com 1 só PIC eu não tenho como testar essa comunicação nunca, pois ele não tem como mandar e receber ao mesmo tempo...
Vou ter que fazer a outra placa, e usar ela para enviar os bytes pro receptor.
Assim eu posso saber se está tudo ok, e calibrar o receptor.
A taxa eu botei em 4000bps.
eu tinha botado um delay no código la, mas vou tirar ele. Para não ter problemas com bytes metidos durante esse tempo.
Eu estou certo quanto a não funcionar o meu esquema de mandar e enviar neh?
-
utilize interrupcoes e filtre logo no inicio para ser processados somente os caracteres q vc utilizar
-
Pra conferir os dados eu prefiro CRC.
Vou tentar fazer um resuminho de um método simples.
Se vc tiver memória livre pode usar um algoritmo baseado em tabelas e não em calculos.
Por exemplo:
declara como global:
unsigned int crc_tx;
unsigned int crc_rx;
const unsigned int tabela_crc[256] = {
0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, 0xC601, 0x06C0,
0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, 0xCC01, 0x0CC0, 0x0D80, 0xCD41,
0x0F00, 0xCFC1, 0xCE81, 0x0E40, 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0,
0x0880, 0xC841, 0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40,
0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41, 0x1400, 0xD4C1,
0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641, 0xD201, 0x12C0, 0x1380, 0xD341,
0x1100, 0xD1C1, 0xD081, 0x1040, 0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1,
0xF281, 0x3240, 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441,
0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41, 0xFA01, 0x3AC0,
0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840, 0x2800, 0xE8C1, 0xE981, 0x2940,
0xEB01, 0x2BC0, 0x2A80, 0xEA41, 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1,
0xEC81, 0x2C40, 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640,
0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041, 0xA001, 0x60C0,
0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240, 0x6600, 0xA6C1, 0xA781, 0x6740,
0xA501, 0x65C0, 0x6480, 0xA441, 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0,
0x6E80, 0xAE41, 0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840,
0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41, 0xBE01, 0x7EC0,
0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40, 0xB401, 0x74C0, 0x7580, 0xB541,
0x7700, 0xB7C1, 0xB681, 0x7640, 0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0,
0x7080, 0xB041, 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241,
0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440, 0x9C01, 0x5CC0,
0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40, 0x5A00, 0x9AC1, 0x9B81, 0x5B40,
0x9901, 0x59C0, 0x5880, 0x9841, 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1,
0x8A81, 0x4A40, 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41,
0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, 0x8201, 0x42C0,
0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040 };
usa essas funções:
void calculo_crc(unsigned int *crc, unsigned int byte_in) {
(*crc) = ((*crc) >> 8) ^ tabela_crc[((*crc) ^ byte_in) & 0x00FF];
}
unsigned char char_to_hex(unsigned char caracter, unsigned char H1L0) {
unsigned char saida;
saida = caracter;
if (H1L0) { saida >>=4; }
saida &= 0x0F;
if ((saida >= 10) && (saida <=15)) { saida += 7; }
saida += 48;
return saida;
}
unsigned int rx_hex_to_int(unsigned char b3, unsigned char b2, unsigned char b1, unsigned
char b0) {
unsigned int i;
i = hex_to_char(b3,b2);
i = i << 8;
i += hex_to_char(b1,b0);
return i;
}
na hora de enviar faz algo do tipo:
void serial_tx_pacote(char *pacote) {
unsigned int i=0;
crc_tx = 0xffff;
while(i < 11){
tx_byte(pacote[i]);
calculo_crc(&crc_tx,(unsigned int)pacote[i]);
i++;
}
tx_byte(char_to_hex((char)(crc_tx >> 8),1));
tx_byte(char_to_hex((char)(crc_tx >> 8),0));
tx_byte(char_to_hex((char)(crc_tx & 0x00ff),1));
tx_byte(char_to_hex((char)(crc_tx & 0x00ff),0));
tx_byte('%');
}
tx_byte é a função que vc usa pra enviar pela serial seu byte.
na hora de receber usa tipo isso:
crc_rx=0xffff;
for (i=0;i<11;i++) {
calculo_crc(&crc_rx,(unsigned int)rx_chegada[i]);
}
l=rx_hex_to_int(0,0,rx_chegada[11],rx_chegada[12]);
m=rx_hex_to_int(0,0,rx_chegada[13],rx_chegada[14]);
calculo_crc(&crc_rx,l);
calculo_crc(&crc_rx,m);
se o resultado for zero em crc_rx, o pacote tá ok.
Abraços!
-
Nem preciso, sei muito bem como funciona.
Sabe, né ? Que bom, assim vc não precisa se aborrecer com uma explicação ... he, he, he ... O bom de saber tudo é que a gente não tem que aprender mais nada, né ?
não somente eu como: fabricantes de memória ecc, usuários de varios protocolos como o f2f, e uma kctada de gente...
Ah, claro, o clamor da multidão faz qualquer coisa virar verdade ... e memórias, etc tem tudo a ver com esta discussão ... que asno que eu sou !
Desculpe qualquer coisa, hein ? Foi mal ...
-
Pessoal, vcs n sabem se pode ser este o meu problema de não receber os dados?
Tipo, enquanto eu mando, eu não posso receber pois esse é a próxima linha.
Só que eu acabei de constatar que isto não é verdade quando se trata de comunicação com fio.
Liguei a saída direto na entrada serial e ele recebe perfeitamento todos os bytes mandados por ele mesmo.
Por mais que os byte sejam mandado antes da função de pegar este byte.
Porque será que estou com esses problemas então?
Notei também que ele só funciona até o 4 erro. Após isso ele tranca...
-
Smarley, microcontroladores que possuem porta de comunicação serial tem um buffer na entrada que guarda o que recebe, mas pra isso funcionar você tem que programar o bichinho direito.
Quando receber alguma coisa, é bom que a interrupção esteja ligada e uma função seja chamada para tratar o que você esta recebendo pra nao perder nada.
Isso que eu falei é baseado em quase nada ;D, pq eu até agora não entendi se vc ta programando no PIC, simulando no PC e etc.
-
Eu to programando no PIC mesmo.
Mas cara, sobre este buffer.
Como ele funciona quando eu uso um receptor?
Ele esta sempre "lendo" as informações e deixando neste buffer ou é só quando eu ligo com fio a saída serial?
-
O que é ligar com fio? ligar a saida serial do pic com a entrada serial?
Se for isso a resposta é não, qualquer sinal que habilite uma comunicação serial, por exemplo, a descida de nivel alto pra nivel baixo já começa a receber a.
Se o seu receptor não para de receber coisas, com certeza seu buffer vai estar sempre cheio de coisas que vc não quer, se vc nao tratar isso pode dar algum problema. vc ta usando interrupção pra tratar o que chega?
-
O que é ligar com fio? ligar a saida serial do pic com a entrada serial?
Se for isso a resposta é não, qualquer sinal que habilite uma comunicação serial, por exemplo, a descida de nivel alto pra nivel baixo já começa a receber a.
Se o seu receptor não para de receber coisas, com certeza seu buffer vai estar sempre cheio de coisas que vc não quer, se vc nao tratar isso pode dar algum problema. vc ta usando interrupção pra tratar o que chega?
Apertei sei lá o que aqui que enviou a mensagem antes de eu terminar, ignora essa aí que eu vou reescrever
-
Ligar com fio que digo é ligar direto ali a saída com a entrada.
Eu não estou tratando nada com interrupções.
Eu só estou fazendo o seguinte:
p u t c(x); //mandando y
y=getc(); //guardando o valor em x
Eu teria que ter acesso a este buffer e verificar que valor está nele, e eliminar o valor caso seja diferente do que eu estou mandando.
Teria como fazer isso?
-
Oi Plancton
Apenas como lembrete, vc. no computador tem uma sequencia certa, mas no outro lado quando vc. manda o receptor pode não estar sincronizado e fica dificil de decodificar.
Sobre os espurior que aparecem, isso porque é um receptor superegenerativo, mas quando vc. tem um sinal forte ele supera os ruidos e interferencias.
Só pra lembrar procure radio pacote ou packet radio, que é um sistema um pouco superado de comunicação usado por radioamadores e são mandado pacotes de até 200 e poucos bytes, mas sempre necessitando de um protocolo (no caro AX25) e um circuito integrado para 1200 ou mais bauds.
Abraço Roberto
-
Eu achei na internet agora um cara que teve problemas com isso por que faltava um tal de INVERT na #use rs232...
Não entendi direito o porque mas vou tentar com ele la.
E vou baixar a taxa para uns 1200bps
-
Jorge, vc poderia tentar ser um pouco menos ignorante nas suas mensagens. isso não lhe faria mal nenhum.
É muito mais gostoso quando vc pode discutir idéias e conceitos quando não precisamos nos defender de ataques.
Ignorancia não leva a nada. se vc não concorda com um ponto de vista, ofereca o seu, argumente, faça valer a pena gastar tempo e teclado. Afinal de contas o propósito de foruns como esse, não é destilar veneno e sim nos ajudar-mos.
e quanto a paridade, é uma forma facil e eficiente de conferir dados, tanto q é mto usado em comunicações. ok, não é 100%. mas para o caso acredito q possa servir sem necessitar de muito sacrificio do colega. como é um hobby e não um projeto profissional onde melhor se encaixaria um receptor do tipo q eu ja mencionei, o TRW-24G(ok Jorge, eu sei q nao é o único e muito menos o melhor, mas pra um transceptor pequeno, que consome apenas 15mA e tem um alcance de centenas de metros, mas já o qualificaria com sobras para o projeto).
-
O que é ligar com fio? ligar a saida serial do pic com a entrada serial?
Se for isso a resposta é não, qualquer sinal que habilite uma comunicação serial, por exemplo, a descida de nivel alto pra nivel baixo já começa a receber aquele byte.
Se o seu receptor não para de receber coisas, com certeza seu buffer vai estar sempre cheio de coisas que vc não quer, se vc nao tratar isso pode dar algum problema. vc ta usando interrupção pra tratar o que chega?
Não programo muito em PIC, faz alguns anos que não mexo em um, então não sei qual seria a melhor técnica para isso nem o tamanho do buffer que eles usam. Eu desligaria a serial quando soubesse que não ia usar (se isso for possivel saber) e com certeza usaria interrupções pra processar o byte assim que chegasse. Tenho impressão que se vc não usou intrrupções pode ser o problema. Não to acostumado tambem a usar esse putc e getc, uso os registradores do próprio microcontrolador.
Pode ser que você tá mandando um byte, e na hora que ta recebendo é um outro que chegou ou antes ou depois ou a soma de todos eles, hehehe
Acho melhor alguem que programe bem em PIC te responda.
-
Acho que achei alguma coisa:
DISABLE_INTS
Will cause interrupts to be disabled when the routines get or put a character. This prevents character distortion for software implemented I/O and prevents interaction between I/O in interrupt handlers and the main program when using the UART.
-
opa, mandei sem querer.
Será que isto resolve?
Vou tentar...
-
Da um erro na compilar.
Ele compila mas deixa uma mensagem la:
"variable never used: rs232_errors"
-
Smarley,
e se vc esquecer comunicação serial e trabalhar com pulsos?
tipo vc gera uma freq de 1khz durante 1seg no master e faz uma rotina no receptor prele verificar isso?
-
Jorge, vc poderia tentar ser um pouco menos ignorante nas suas mensagens. isso não lhe faria mal nenhum.
Cláudio, receio que isto não seja possível ... apesar de todo meu esforço, tô cada vez mais ignorante, ainda tenho muito, mas muito mesmo a aprender, ao contrário de vc que já sabe tudo ... he, he, he ...
Falando sério: Onde é que está a ignorância ? Em mim ? Tem certeza ?
Releia, desta vez com atenção, o que escrevi acima. Apontei um fato, o de que paridade não serve para absolutamente nada no contexto desta discussão e o fiz em tom de brincadeira. A seguir convidei-o a fazer algum exercício, simular situações e verificar por si mesmo.
O que vossa sapiência respondeu ? Lembra-se ? Vc respondeu de maneira arrogante, dizendo que não precisa de explicações e que sabe muito bem. E não me poupou de mais uma de suas pérolas, citando aplicações que não guardam qualquer similaridade com o contexto desta discussão. E muito brilhantemente, insultando minha já tão escassa inteligência me diz que um montão de gente usa, como se isto provasse algum coisa além do fato que macaqueamos uns aos outros o tempo todo. Com isto vc fez jus e foi contemplado com algumas gotas de ironia, bem menos do que merecia, é bom que se diga.
É muito mais gostoso quando vc pode discutir idéias e conceitos quando não precisamos nos defender de ataques.
Pois é. E quem está atacando aqui é vc. Eu apontei um conceito equivocado e o fiz em tom de brincadeira e vc confunde contestação a um conceito como ataque pessoal.
Ignorancia não leva a nada. se vc não concorda com um ponto de vista, ofereca o seu, argumente, faça valer a pena gastar tempo e teclado. Afinal de contas o propósito de foruns como esse, não é destilar veneno e sim nos ajudar-mos.
Então não destile o seu veneno por aqui ... e trate de comer a sua fatia da torta da humildade ... ao contrário do que vc pensa e diz, tem muito o que aprender e muita gente por aqui, incluindo o ignaro que vos fala, é capaz de ensinar-lhe algo ... desde que esteja disposto a aprender ...
e quanto a paridade, é uma forma facil e eficiente de conferir dados, tanto q é mto usado em comunicações. ok, não é 100%. mas para o caso acredito q possa servir sem necessitar de muito sacrificio do colega. como é um hobby e não um projeto profissional onde melhor se encaixaria um receptor do tipo q eu ja mencionei, o TRW-24G(ok Jorge, eu sei q nao é o único e muito menos o melhor, mas pra um transceptor pequeno, que consome apenas 15mA e tem um alcance de centenas de metros, mas já o qualificaria com sobras para o projeto).
Vou repetir: vc está redonda e quadradamente equivocado, como milhares de outros que engolem sem mastigar. Se serve de consolo, já vi gente grande, com décadas de experiência no ramo cair na esparrela. Eu mesmo já fui vítima da falácia por anos.
Vou reiterar meu convite: procure simular algumas situações onde vc acha que a verificação da paridade seria algo benéfico ... e ao invés de procurar justificar suas crenças, faça como o advogado do diabo, procure pelas falhas ... acho que vc vai ter uma bela surpresa e vai se divertir com isso ...
-
ta certo Jorge.
Respeito muito seu conhecimento, pelo que eu vejo aqui no fórum vc sabe o que diz. Apesar de algumas vezes minimizar colegas desnecessáriamente.
Não vejo onde fui ignorante ou pelo menos arrogante com vc. vc falou q um conceito q foi muito utilizado e, que ainda se aplica em algumas ocasiões, não serve pra nada. e nao é bem assim.
bit de paridade é muito útil quando se sabe empregá-lo.
agora deixa eu te fazer uma pergunta, de que forma "simples" vc resolveria essa questao?
-
ta certo Jorge.
Respeito muito seu conhecimento, pelo que eu vejo aqui no fórum vc sabe o que diz. Apesar de algumas vezes minimizar colegas desnecessáriamente.
Cláudio, vamos deixar claro uma coisinha: eu não minimizo nínguém. Nunca. Já vivi o bastante pra saber que tenho algo a aprender com qualquer um, em qualquer lugar, a qualquer tempo. Além disso, preciso aprender e gosto.
Sei muito bem sabido que meu estilo seco não é do agrado de muitos, mas além de estilo pessoal a coisa tem alguns propósitos, um deles é o de evidenciar como ainda somos imaturos e belicosos, sempre dispostos a sacar as cimitarras ao menor arranhão que o ego sofra. Serve pra evidenciar tb a confusão entre discordância de idéias, conceitos, etc e ataques pessoais, coisa que não faço e abomino. Serve tb a muito outros propósitos, poucos confessados, mas nenhum inconfessável.
Não vejo onde fui ignorante ou pelo menos arrogante com vc.
Não tem importância, o importante é que vc demonstra que não está disposto a uma guerrinha sem sentido e privilegia o que interessa mais a todos nós, que é a informação, o conhecimento, etc ...
vc falou q um conceito q foi muito utilizado e, que ainda se aplica em algumas ocasiões, não serve pra nada. e nao é bem assim.
Vou repetir: no contexto desta discussão é bem assim.
bit de paridade é muito útil quando se sabe empregá-lo.
Não duvido, mas não neste contexto. Em muitos outros não sei como. Toda vez que alguém tentou demonstrar saí mais convencido do que tenho dito. Se vc quiser demonstrar eu agradeço muito, pela simplicidade da coisa eu ficaria muito contente por ser convencido do contrário.
agora deixa eu te fazer uma pergunta, de que forma "simples" vc resolveria essa questao?
Logo no início do tópico comentei que considerando a proposição inicial, que é a comunicação em duas vias, handshake* é imbatível, perfeitamente redundante, o que dispensa qualquer outro artifício de verificação / correção de erros. Se isto é simples, é questão de ponto de vista, mas é das coisas mais simples e eficazes que se pode fazer com o hardware proposto, um luxo.
Considerando implementação mais corriqueira, via de mão única, dá pra pensar em duas vertentes principais, uma solução mais assentada no hardware, pode-se usar, por exemplo, um desses pares codificadores / decodificadores da Holtek pra controle remoto de portões ou coisa que o valha. a coisa funfa muito bem considerando a aplicação discutida, é bem simples e barato e com alguma criatividade dá pra ampliar o escopo sem maiores dificuldades. Já vi coisas muito interessantes baseadas em DTMF tb, este troço é uma maravilha pra furar um paredão de ruído se a velocidade de comunicação puder ser (muito) baixa.
Na outra vertente, mais assentada no software, eu certamente partiria para o que já foi sugerido, pacotinhos + CRC. Aqui o céu é o limite, o pacotinho pode virar pacotão, o algoritmo CRC pode ser tão complicado que dá pra satisfazer os onanistas pelos séculos vindouros. Eu pensaria em pacotinho mesmo, uns poucos bytes: preâmbulo (só pra acertar o AGC), talvez um header, endereçamento, função, CRC, só isto ou algum pedacinho a mais.
-
Logo no início do tópico comentei que considerando a proposição inicial, que é a comunicação em duas vias, handshake* é imbatível, perfeitamente redundante, o que dispensa qualquer outro artifício de verificação / correção de erros. Se isto é simples, é questão de ponto de vista, mas é das coisas mais simples e eficazes que se pode fazer com o hardware proposto, um luxo.
Claro, eu também pensei nisto logo que começei o projeto.
Mas o problema é que eu não to conseguindo nem fazer ele receber o que envia.
Imagina se vai funcionar com o outro PIC junto...
Eu vou tentar agora habilitando aquela interrupção la.
Só que eu não sei pra que serve a variável rs232_error, eu dei uma lida la, mas não entendi bem a função dela...
Vou tentar depois posto aki.
E não entendi também porque ele só recebe 3 bytes com erro e tranca o programa no PIC.
Tipo, da erro no primeiro envio, no segundo, no terceiro, e ele trava por completo.
Isto acontecia também quando eu mandava só pegar os valores, tipo, ele pegava uns 6 valores e parava. as vezes pegava 8, as vezes 4. Eu acho que não é porque não tem bytes no ar que da isso, pois basta eu ligar ele denovo pra ele ja pegar mais 3 ou 4 valores do ar. sempre.
-
Fiz o programa rodar sem erro.
Com essas alterações e 1000bps ele consegue ler valores próximos.
Nunca da exato, na melhora das tentativas ele reconhece um valor 3 ou 4 unidades menor.
Tipo, ele pega uns 3 valores totalmente diferentes, e acerta um 2 números a menos...
É mais ou menos isso que ta acontecendo.
As vezes ele erra 1 ou 2 e chega perto no segundo ou terceiro.
Agora eu vou aumentar a taxa de 1000 para 4800, vamos ver se melhora isso.
-
Estou por desistir desta porcaria...
Ja tentei de tudo. E não adianta, ele não recebe o que manda nem a pau.
Ele estava recebendo muitos números negativos. Passei os valores para unsigned int e não adiantou em nada. Ele ficou recebendo mais 0 do que qualquer coisa.
Passei as variáveis para char e também não muda em nada.
Não sei como que fazem funcionar esta porcaria de transmissor.
O receptor tem um pot nele que eu ja coloquei ele de todas as maneiras várias vezes. E não muda em quase nada, as vezes melhora um pouco, mas melhora para o que eu relatei ali em cima.
Não adianta protocolo, CRC, qualquer outra coisa se ele não recebe o que está sendo enviado.
Vou tentar trocar de tranmissor e receptor pelo outro par que tenho aqui, mas acho que o problema não deve ser com eles.
-
Smarley,
Se você ta desconfiado do seu código e tiver paciencia, faz o seguinte:
Monta um esquema simples com o transmissor e um max232 e poe na serial do PC, abre o hyperterminal e vê o que chega.
Na placa do PIC deixa só o transmissor mandando uns bytes conhecidos, desliga o receptor, faz um código bem simples, um loop enviando um byte e dando um delay depois de enviar.
tipo isso:
while(1) {
envia_byte();
delay();
}
-
Cara, o meu código ta 100% porque quando eu ligo a saída Tx direto na entrada Rx do PIC ele le todos os números na ordem correte. Perfeitamente.
-
Verifica a alimentação deles, vc colocou antena?
-
ta 100% a alimentação, mas eu vou conferir.
A antena eu coloquei um fio de uns 25cm mais ou menos.
Mas ta um do lado do outro.
-
To alimentando com 5V o transmissor e receptor.
-
Smarley, vc esta considerando o preamble?
-
Não...
Eu estou mandando os números de 1 a 100, como está ali no programa.
Como eu poderia fazer este preamble?
Seria alguma coisa assim:
Mandar uns 100bytes com o mesmo valor?
abraço!
-
vc tem q mandar algun bytes pro receptor se calibrar. normalmente uns 2 bytes.
tenta fazer uma transmissao contínua, sem intervalos entre os caracteres.
e quanto a antena, comumente é utilizado 1/4 ou 1/2 de onda. procure deixar ela de pé, sem encostar em nada e sem barreiras metalicas entre o tx e o rx. com isso, as chances de vc receber 100% dos caracteres aumentam.
-
eu estou usando um fio para cada antena.
Eles tem uns 25cm.
Eu enrolo um no outro, acho que assim deve melhorar.
-
Vou fazer um programa para ficar mandando somente um valor então.
Assim que der eu gravo no PIC e posto os resultados aqui.
-
Smarley, experimenta utilizar um fio rigido com comprimento de 40cm. tanto no tx como no rx. sem enrolar uma na outra.
-
Eu to usando um fio 0,6mm esses mais comum em eletrônica.
Rígido eu só tenho de telefone, mas ai acho que é muito fino.
Vou ver se acho um pra vender...
-
Smarley, pra teste ja é o suficiente. um esta bem próxmio do outro.
-
procure respeitar o comprimento dela.
primeira vez q eu brinquei com essas encrencas ai, eu usei um pedaço de fio pequeno e o resultado foi q o alcance não passava de 10cm..rs
entao deixe sempre com 1/4, 1/2 ou 1/1 do comprimento de onda.
Para calcular o comprimento de onda:
Comprimento de Onda (em metros) = 300.000.000 (velocidade em m/s) / Frequencia (em Hertz).
-
Aham, vai tem que ser quase 1 metro de fio para dar 1/1 do comprimento de onda.
É possível de eu fazer pois tenho como esconder tudo isso, tem uma calha aki de metal, que não vai atrapalhar a tranmissão eu acho...
Eu deixo ela em contato com o fio para ajuda um pouco mais.
-
nao faz isso.
e quanto ao comprimento, se 1/1 ou 1/2 é muito, deixe com 1/4 ou 23,80cm.
nao saberia te explicar, mas nos testes q eu fazia, eu tinha uma melhor performance com uma antena de 1/2.
-
Fiz um novo programa, só com isso:
char y,x;
void main()
{
lcd_init();
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
x=10;
rs232_errors=0;
putc(x);
putc(x);
while(true)
{
putc(x);
y=getch();
if(x!=y)
{
printf(lcd_putc,"\fDeu erro no %i\nRecebi %i",x,y);
delay_ms(700);
}
printf(lcd_putc,"\f%i ",y);
}
}
E ficou pior que antes, olha só uns exemplos da coisas que ele le:
19,-37,-1,33,83,11,110,-128,3,33,-46,8,19,-33,-101-,109,0,-37,-27,45,-5,-45.
Nem um 10 ele le..
não entendo porque isso não funcoina.
A taxa está em 4000bps.
Uma coisa estranha é que se eu ficar espichando as antenas ele fica recebendo quase sempre 0.
Ou quando eu coloco o tranmissor muito perto do receptor, digamos que o pino da antena deles fique a 1cm um do outro.
-
Smarley, afaste o transmissor do receptor pelo menos um ou dois metros ou mais, se possível. O receptor muito provavelmente está saturando.
-
Eu cheguei a pensar nisto e afastei eles aqui ja.
Só que pouco... coisa de 30cm.
Vou refazer os fios e afastar mais ele.
-
Kms e força de expressão ...
Como diziamos acima, força de expressão pô nenhuma. Para os incréus:
XBee-PRO® XSC
Performance - Power output: 100 mW (20 dBm)
- Indoor/Urban range: Up to 1200 ft (370 m)
- Outdoor/RF line-of-sight range: up to 15 miles (24 km) <---
- Receiver sensitivity: -106 dBm
- RF data rate: 9.6 Kbps
- Interface data rate: Up to 57.6 Kbps
Tá bão assim ou quer mais ? ;D ;D ;D
Fonte: http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xscspecs.jsp (http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xscspecs.jsp)
-
Smarley,
e se vc fizer um programa simples para gerar 10Hz, enviar pelo tx e no rx colocar um led para ver como se comporta.
-
Oi
Desculpe se o comentario não tem nada a ver com o projeto.
Estou "brincando" com um transmissor e receptor desses de portão eletronico, e a ideia era de acionar dois reles acionados por dois botões no transmissor.
Uma coisa é o delay do receptor que para acordar leva uns 3ms,não sei se o receptor usado por vcs. tem esse delay. Consegui visualizar esses sinais gravando a saida do receptor na entrada de microfone do computador,e com o sinal gravado da para conferir se os pulsos são iguais aos que estão sendo mandados. TEM QUE TER UM DIVISOR DE SINAL, PARA NÃO PIFAR A ENTRADA DE AUDIO, pois a entrada de audio precisa uns 100mV e a saida do transmissor é quase a da alimentação, me parece que esta sendo usado 5v.
inclusive foi o modo de ajustar o receptor, colocando pulsos no transmissor e ajustando o pequeno potenciometro do receptor para ter o melhor sinal, inclusive ajustando antes de colocar no computador para gravar , jogando um sinal de 800hz no transmissor e recebendo no receptor e injetando num pequeno amplificador de audio, o sinal chegava limpo até uns 30metros de distancia ajustando o potenciometro do receptor.
No transmissor a antena tem que ter 1/4 de onda para "casar" com a saida e ter o maximo de potencia.
A intenção do comentario , foi apenas lembrar que seria interessante tentar "ver" ou "ouvir" o sinal que esta sendo enviado e recebido.Com osciloscopio daria para ver, mas como é uma sequencia de pulsos, o melhor é gravar e depois interpretar.
Roberto
-
Eu tenho como conseguir acesso a um osciloscópio digital...
Caso não funcione distanciando o receptor do transmissor acho que vou fazer um programa para ficar mandando 800hertz por ex. e comparar a transmissão com a recepção, ai ja aproveito para regular ele mesmo...
Vou pegar outro display para monitor a recepção e a transmissão...
E usar 2 16F877a.
-
Ou melhor, vou usar um gerador de funções digital.
Ai não preciso programar nada e tal...
Só vou setar a freqüência para 1K e a amplitude para 5V.
E as freqüência eu leio no oscilocópio mesmo...
Coloco as duas ondas para aparecerem na tela, dou um atraso na do tranmissor para enquandrar com a do receptor e deixo uma mais pra cima do que a outra.
Assim eu posso comparar as duas...
-
Coloquei o transmissor a 2 metros do receptor e fiz 2 antenas com 48cm(1/2 do comp. de onda) com fio de cobre, 1,5mm de diametro mais ou menos.
Coloquei as duas antenas para cima, e testei de outros modos também.
E ficou a mesma coisa...
Não funcionou nem um pouco...
Ele não recebe nada(0) ou fica recebendo uns valores bem loucos...
Não sei mais o que fazer. A última tentativa vai ser com o osciloscópio, para testar o que esta porcaria está mandando. Se é que está mandando alguma coisa...
O PIC eu sei que está funcionando bem, pois quando ligo sem os transmissor e receptor ele recebe normal o que deveria.
Eu acho que este transmissor não está funcionando direito...
-
Parece que vc. esta usando os modulos rws371 de 315mhz
Faça o teste usando apenas um receptor e um transmissor , pois não da para usar um transmissor e receptor na mesma frequencia.Para usar uma transmissão full duplex precisa ter diferença de frequencia de algums mhz, ou ter de habilitar e desabilitar os modulos.
O ideal no caso seria usar um transmissor em 315 e o receptor em 420 e o do outro lado o transmissor 420 e o receptor em 315.Senão um entope o outro e o outro entope o um.hi..
Nos transmissores de rf normalmente as antenas tem de ter 1/4 de onda para dar impedancia de 50 ohms. Se colocar 1/2 onda não vai haver transferencia de rf para a antena.Quanto a usar um osciloscopio duplo traço é beleza, ajuda no ajuste do receptor, que é o que tem alguma variavel.
-
1/4 de onda? 29cm apenas então...
Seria uma boa usar um conjunto de frequencia para cada lado da transmissão...
Mas agora eu ja tenho estes módulos aqui...
Agora eu ja troquei o programa do PIC e cansei de gravar e desgravar esta porcaria que não da certo...
Segunda eu vo testar o transmissor se ele manda legal os sinais com o osciloscópio.
Acho que o problema está mesmo na transmissão pois o receptor recebe várias porcarias...
Eu estou usando apenas 1 par de transmissor receptor. Pois estou mandando os sinais e recebendo eles com o mesmo PIC.
-
Opâ!! Mandar e receber pelo mesmo PIC
Ce ta chutando o escanteio e correndo para a área cabecear?
-
Mas os caras aki falaram que era possível...
Eu também ja pensei nisso. QUe quando ele manda ele não pode receber.
Mas me disseram que tem um buffer que armazena o q ele recebe enquanto ele manda.
Agora...
Quem está certo aqui?
-
Smarley.
Você mesmo disse que quando liga o Rx com o Tx da USART recebe os dados. isso demonstra a existência desse buffer.
-
Aproveitando, além dessa comprovação prática, recomendo um pouco de teoria:
No datasheet do PIC 18f628A (é o que eu acho que você ta usando), na página 83 fala isso.
Seção 12.2.2 USART ASYNCHRONOUS RECEIVER
Lá tem tudo explicado sobre o funcionamento da recepção, na primeira página já explica quase tudo.
-
Smarley, se vc quiser trabalhar com o mesmo pic, utilize interrupcoes.
nessa interrupcao vc filtra somente os caracteres q vc quer receber ('#', '@', 'A'). envie um pacote comecando com #, terminando com @ e uns 10 'A' dentro dele. nessa interrupcao vc bota ele pra detectar esse # e tudo o q receber dpois dele vc joga num buffer. se o buffer tiver mais de 12 caracteres e nao veio o @, apague o buffer e comece a esperar o # novamente. quando ele receber o @, joga no lcd o tamanho do buffer.
Mas isso nada adiantará se vc nao tiver resolvido o problema dos seus módulos. pelo que me parece, eles nao estao funcionando.
-
Oi Smarley
Uma coisa que lembrei, é que a entrada do pic deve copiar quando vai de 1 para 0 , mas no transmissor o pulso que vc. recebe é de 0 para 1. Tente colocar um transistor para inverter ou uma porta.
-
Ainda não deu para ir testar o transmissor e receptor la com o osciloscópio.
Eu peguei um serviço para fazer aqui, que esta me tomando um tempo...
Estou fazendo um projeto de um aparelho para controlar o tempo de dosagem de uns produtos químicos.
Ja está quase terminado... Estou montando os prototipos.
Vocês tem experiência em quanto se cobra para fazer um projeto desses?
Seria um controle com PIC, mostrar o tempo no LCD. Regular o tempo que um motor fica ligado e o tempo que fica desligado atraves de botões. Usar um rele para controlar o motor.
Não sei quantas horas levei até achar a solução para o programa.
Mas é o seguinte: software+hardware
Quanto vocês cobrariam para entregar o software, gerber e prototipo?
abraço!
-
Fiz o projeto pro cara ja e to mandando amanhã.
Coloquei no meu blog sobre ele, deem uma olhada la se der.
Tem 2 projetos que fiz.
Agora semana que vem volto com os transmissores de Rf...
Abraço!
-
Vou começar a trabalhanr neste área agora...
Desenvolvimento de projetos e programas
:)
não sabia que isto era tão valorizado quanto eu descobri agora.
abraço!