Teste de Transmissão de um TX de 433MHz

rmlazzari58 · 13 de setembro de 2024

Em 12/09/2024 às 12:45, Renato.88 disse:

Esses são os TX/RX comerciais, que tinha para venda antigamente.

Eram usados em portão automático.

O cara do site levantou o esquema e colocou aí.

Eu tenho vários deles, que ganhei de um amigo meu que era serralheiro.

Lá embaixo, na página desse circuito, tem uma antena, que já vem até com o coaxial, que parece que pode atender ao amigo MOR...

Achei curioso, Mestre, que o cabo coaxial é bem fininho. Como o MOR falou em capacitância gerada no próprio cabo... quem sabe ajuda?

MOR_AL · 14 de setembro de 2024

21 horas atrás, rmlazzari58 disse:

Lá embaixo, na página desse circuito, tem uma antena, que já vem até com o coaxial, que parece que pode atender ao amigo MOR...

O cabo tem 3m. Não precisaria deste tamanho todo, pois o cabo introduz atenuação, que quero minimizar.

Vi em algum vídeo, que o sujeito simplesmente soldou o núcleo do cabo na ilha para a antena e a blindagem bem próxima ao terra.

Acho que não tem melhor opção de conexão do cabo coaxial, pelo menos eu não encontrei.

Com relação ao tamanho do cabo coaxial, algo me leva a usar um número inteiro de comprimentos de onda do Tx, mínimo, mas suficiente para chegar até onde eu precisaria.

Acredito que com um número inteiro de comprimentos de onda, fase do sinal na ponta do cabo coaxial, seria a mesma na ilha para a antena.

Em tempo:

Consegui apenas incluir o básico em meu PC. Então até que uma solução completa seja obtida, terei limitações com o CDH.

MOR_AL

rmlazzari58 · 14 de setembro de 2024

Meio off topic mas... usando uma calculadora de Internet - essa aqui - tentei calcular o comprimento da onda de 433MHz em metros e deu uns 70cm. No chute total, achei meio longa demais... a cada um segundo, precisa 70cm para a onda subir, descer e voltar ao zero? Será que tá certo isso?

MOR_AL · 15 de setembro de 2024

Em 14/09/2024 às 12:35, rmlazzari58 disse:

Meio off topic mas... usando uma calculadora de Internet - essa aqui - tentei calcular o comprimento da onda de 433MHz em metros e deu uns 70cm. No chute total, achei meio longa demais... a cada um segundo, precisa 70cm para a onda subir, descer e voltar ao zero? Será que tá certo isso?

A cada 1s vão ocorrer 433M ciclos dessa onda. E o comprimento de onda de todos esses ciclos com 70cm, juntarão 300.000Km.

MOR_AL

Renato.88 · 25 de setembro de 2024

Bom, entendo que o tópico está parado porque o colega @MOR_AL está com problemas em seu PC.

Faz um tempo que queria colaborar com o tópico, mas não tive tempo. Então como estou aqui a toa, achei interessante postar sobre o assunto.

Já tive algumas experiências com as ideias apresentadas, tanto da parte dos transmissores e receptores, quanto desse circuito de caixa d'água.

Inicialmente, sobre os transmissores. Nesse caso eu usaria soluções prontas, pois pelo que vi tem pra vender Circuitos integrados dedicados que atendem a proposta. Não sendo necessário programar um pic do zero.

Os CIs dedicados já tem toda uma informação gravada neles que permitem uma comunicação mais estável nos TX e RX. Mesmo que o sinal se deforma um pouco no caminho, o receptor consegue entender.

Um exemplo de CIs desses é o par da Motorola MC45026 (TX) e o MC45027(RX).

Também tem os da Holtek HT12E (TX) e o HT12D (RX).

Todos eles, permitem o controle de 4 canais independentes.

A informação pode ser enviada por um cabo coaxial ou então pelos transmissores de RF.

Sobre os sistemas de nível de água. O maior problema é que depois de um tempo, a água não deixa os fios conduzir energia. Mas creio que se usar alumínio, esse problema diminui.

Eu até tive essa ideia na época, mas desisti pelo motivo explicado abaixo.

Na época eu tinha desenvolvido um circuito análogico com 3 fios que iam pra caixa d'água. Positivo, negativo e a informação.

Era um jogo de transistor e diodos zener.

No receptor um circuito feito com o comparador LM339. Tudo isso funcionou muito bem, mas como é área rural outro problema foram os raios. Nada eletrônico se mantia ali.

Acabei abandonando toda a eletrônica nesse projeto e hoje é tudo mecânico, com relés e uma bóia elétrica comum.

MOR_AL · 25 de setembro de 2024

2 horas atrás, Renato.88 disse:

Bom, entendo que o tópico está parado porque o colega @MOR_AL está com problemas em seu PC.

Olá @Renato.88 !

Perdi todos os programas do PC anterior. Deveria ter uns 30 a 40 APPs. Estou instalando um por um, na medida da necessidade, mas estou avançando com o teste de comunicação entre Tx e Rx.

2 horas atrás, Renato.88 disse:

Inicialmente, sobre os transmissores. Nesse caso eu usaria soluções prontas, pois pelo que vi tem pra vender Circuitos integrados dedicados que atendem a proposta. Não sendo necessário programar um pic do zero.

Concordo, mas esta é a minha "cachaça". O desafio é justamente "tirar água de pedra".

2 horas atrás, Renato.88 disse:

Os CIs dedicados já tem toda uma informação gravada neles que permitem uma comunicação mais estável nos TX e RX. Mesmo que o sinal se deforma um pouco no caminho, o receptor consegue entender.

Eu tinha comprado há tempos uns 10 conjuntos TxRx em 433 e 3?? MHz. Daí pensei em usá-los. Tem os LoRa, que chegam a alguns Km. Assim eu não teria desafios.

2 horas atrás, Renato.88 disse:

Um exemplo de CIs desses é o par da Motorola MC45026 (TX) e o MC45027(RX).

Também tem os da Holtek HT12E (TX) e o HT12D (RX).

Todos eles, permitem o controle de 4 canais independentes.

A informação pode ser enviada por um cabo coaxial ou então pelos transmissores de RF.

Eu conhecia os da Holtek.

Estou tentando transmitir (e receber) um byte. Conseguindo isso, pode-se usá-lo para qualquer coisa, como endereço, ou dados. Basta estabelecer o protocolo de comunicação.

2 horas atrás, Renato.88 disse:

Sobre os sistemas de nível de água. O maior problema é que depois de um tempo, a água não deixa os fios conduzir energia. Mas creio que se usar alumínio, esse problema diminui.

Eu até tive essa ideia na época, mas desisti pelo motivo explicado abaixo.

Quando morava em outra casa, há dois anos, meu sistema (via dois fios entre a caixa e a cozinha), funcionou desde 2014 até 2022.

Os contatos eram de cobre, com cerca de 5 voltas em torno de um tubo com 1 cm de diâmetro.

Penso que de alumínio iriam formar uma pilha com o cobre e causar algum problema.

O cobre, mesmo oxidado, conduz. Os resistores usados em série com os contatos estão na casa das muitas centenas de k ohms. Alguns são de mega ohm.

Agora, os comerciais, estão usando aço inox. Eu comprei aqueles sensores magnéticos com reed. Eles não têm a parte elétrica em contato com a água.

2 horas atrás, Renato.88 disse:

Na época eu tinha desenvolvido um circuito análogico com 3 fios que iam pra caixa d'água. Positivo, negativo e a informação.

Era um jogo de transistor e diodos zener.

No receptor um circuito feito com o comparador LM339. Tudo isso funcionou muito bem, mas como é área rural outro problema foram os raios. Nada eletrônico se mantia ali.

Acabei abandonando toda a eletrônica nesse projeto e hoje é tudo mecânico, com relés e uma bóia elétrica comum

É! Cada um sabe onde aperta o calo.

Atualizando o meu projeto:

1 - Acredito ter terminado o fluxograma do Tx, com um PIC12F675. Quis generalizar tudo! Sem cristal. Poupo dois pinos. Nem precisava, pois só estou usando um pino como saída para o Tx. Devido a falta de precisão dos tempos, estou enviando a informação com o código Manchester, que transmite também o clock, junto com os dados. Isso reduz a taxa de transmissão à metade, mas posso alterar para UART à qualquer momento.

2 - O meu fluxograma é composto por blocos, que são quase as instruções em Assembler. Para pequenos projetos, uso o Assembler. A passagem dos meus fluxogramas para o assembler é quase que direta.

3 - Perdi a conta de quantas vezes instalei e desinstalei o MPLAB mais recente. Sempre pedia alguma coisa, que me consumia tempo. Descobri que a Microchip disponibiliza versões antigas do MPLAB. Então hoje instalei a que eu tinha no meu PC anterior e já comecei a fazer o firmware. Confesso que faz alguns anos que fiz o último projeto com PIC. Então comecei meio lento, mas estou retomando o jeito rapidamente.

4 - Pretendo verificar no osciloscópio, as ondas produzidas pelo PIC, para ver se estarão funcionando como deveriam.

MOR_AL

Sérgio Lembo · 26 de setembro de 2024

16 horas atrás, Renato.88 disse:

No receptor um circuito feito com o comparador LM339. Tudo isso funcionou muito bem, mas como é área rural outro problema foram os raios. Nada eletrônico se mantinha ali.

Tenho algumas ideias para área rural e seu comentário me incomodou. Fale com detalhes a questão dos raios.

rmlazzari58 · 26 de setembro de 2024

Em 25/09/2024 às 15:28, Renato.88 disse:

O maior problema é que depois de um tempo, a água não deixa os fios conduzir energia.

Aço inoxidável não é o melhor condutor elétrico que existe, mas que resistência elétrica pode ter num pino de inox de, digamos, 5mm de diâmetro x 10mm de comprimento? No "rabo" desse pino poderia ser soldado um fio de cobre. Esse fio correria por dentro de um tubo de PVC à prova d'água...

Bem... como 1 .jpg > 1k .txt, rs...

Corte longitudinal de um tubo de PVC fechado embaixo e com vários pinos de inox, um para cada altura da água dentro da caixa d'água.

Esses pinos poderiam ser feitos com pregos de inox, bem grossos... talvez, se os furos no pvc forem 0,01mm menores que o diâmetro dos pregos, nem precise massa para vedar o tubo, prá água não entrar nele... ou algo assim.

MOR_AL · 26 de setembro de 2024

1 hora atrás, rmlazzari58 disse:

orte longitudinal de um tubo de PVC fechado embaixo e com vários pinos de inox, um para cada altura da água dentro da caixa d'água.

Acho que vi esta solução em alguns fabricantes.

9 horas atrás, Sérgio Lembo disse:

Tenho algumas ideias para área rural e seu comentário me incomodou. Fale com detalhes a questão dos raios.

Quando morava em Angra dos Reis, RJ, próximo a montanha, tinha problemas na linha telefônica (celulares custavam uma pequena fortuna). Meus aparelhos telefônicos sem fio, porém conectados à linha, queimavam frequentemente. Até cheguei a receber um outro aparelho da companhia.

Não eram os raios que caiam diretamente na linha telefônica. O campo elétrico, formado pelo raio, induzia tensões muito altas na linha. Cheguei a colocar velas de automóvel como "spark gaps" da linha à terra em uma PCI. Não durou muito tempo. A PCI explodiu.

Campo aberto é um problema sério para fios longos.

Na década de 1970., trabalhava em uma empresa do grupo da Eletrobrás. O pessoal das subestações tinham conexões telefônicas no pátio, na região dos disjuntores e trafos de 13kV. Essas linhas eram frequentemente destruídas devido a manobras elétricas neste pátio.

Não tinham ainda MC disponíveis. Acabamos projetando uma solução para aquele problema, mas como tudo que é estatal, o aparelho nunca foi industrializado.

Hoje o problema poderia ser facilmente resolvido com dois pequenos MC e dois módulos Tx/Rx.

@Sérgio Lembo

Apresente suas sugestões, serão sempre bem-vindas.

MOR_AL

Sérgio Lembo · 26 de setembro de 2024

1 hora atrás, MOR_AL disse:

Não eram os raios que caiam diretamente na linha telefônica. O campo elétrico, formado pelo raio, induzia tensões muito altas na linha.

Caro Morris, não irei negar a sua experiência prática mas, os cabos trançados da telefonia não seriam um supressor natural de tais induções? Ou nas altas energias dos raios se tem algo a mais a ser considerado? Imagino também (e posso estar errado) que o solo, sempre considerado como o grande terra, possa apresentar diferença de potencial momentânea entre pontos distantes por conta de tais descargas.

MOR_AL · 27 de setembro de 2024

@Sérgio Lembo

11 horas atrás, Sérgio Lembo disse:

os cabos trançados da telefonia não seriam um supressor natural de tais induções? Ou nas altas energias dos raios se tem algo a mais a ser considerado?

Tinham alguma proteção, mas a intensidade, proximidade e grandeza dos raios eram fenomenais. Havia um trecho, o final, com cerca de 200m, no qual o fio era de par paralelo, isso poderia estar causando as altas tensões. Este cabo era da própria companhia e eu não podia trocar.

11 horas atrás, Sérgio Lembo disse:

Imagino também (e posso estar errado) que o solo, sempre considerado como o grande terra, possa apresentar diferença de potencial momentânea entre pontos distantes por conta de tais descargas.

Sim. A casa ficava em uma região de mata atlântica. A quantidade de chuva é grande e o solo sempre húmido. A diferença de potencial do solo era minimizada por este fator, porém os raios eram intensos.

Volta e meia desligávamos todas as tomadas da casa, quando podíamos.

MOR_AL

MOR_AL · 12 de outubro de 2024

Voltando à novela do "Teste de Transmissão de um Tx de 433MHz".

Há alguns dias, toda vez que abria o meu novo PC com o W11 no SSD, ele pedia para verificar o HD com restos do W10.

Cansado de ter que passar por essa etapa, apesar de poder pulá-la com um toque em qualquer letra do teclado, mas durante um pequeno intervalo, Resolvi agir.

O W11 criou uma partição com os restos do W10. Não aceitava deletar. Tive que formatar a partição. Ok.

Depois tive que unir a partição deletada com o restante do HD.

Fiz alguma M3rd@ e acabei apagando o HD todo..

Sorte que eu tinha todos (ou quase todos) os meu dados em backup.

O problema era que a data que fiz o backup já tinha cerca de uma semana.

Acabei perdendo alguns arquivos. Dente eles, justamente o arquivo.asm que fiz no MPLAB. Perdi também os arquivos que tinha baixado do programador K150 e o Word com as alterações e inclusões sobre o projeto.

O programador K150 tem entrada pela USB e cria uma porta serial virtual. O gabinete do W11 não tem um conector serial em sua parte traseira. Não tenho como usar os meus programadores que usam a porta serial. Não posso abrir o gabinete e colocar o conector, sem perder a garantia.

Estas semanas eu baixei uns 4 blocos de aplicativos, que tratam do K150.

Hoje terminei de refazer o arquivo.asm do transmissor. Tinha alguns bugs, que acabei tirando no debug do MPLAB. Refazer foi relativamente fácil, porque tinha o arquivo do programa em um fluxograma, com quase a linguagem Assembly.

Somando tudo, devo ter levado umas 10 a 15 horas de trabalho para encontrar e instalar o drive correto do K150, que funciona no meu W11. Nem acreditei, quando vi no "Gerenciador de Dispositivos", que tinha sido criada uma porta virtual, QUE FUNCIONASSE!!!

Abri o app do programador e finalmente consegui gravar o PIC12F675 com o .hex do Transmissor.

Passo seguinte:

Ver as formas de onda da transmissão na tela do osciloscópio, para conferir os tempos, se bem que a transmissão via protocolo Manchester já contém o clock.

MOR_AL

MOR_AL · 13 de outubro de 2024

Hoje:

1 - Liguei o PIC12F675 na placa do transmissor.

O led, informando que um ciclo (com cerca de 1s) termina e outro começa, Piscou como esperado.
Isso prova que o programador está funcionando.

2 - Liguei o receptor apenas com um led na saída de dados.

Durante o ciclo de transmissão, o led do receptor ficou acionado. Como a taxa dos de cada bit dura cerca de 2ms, não deu para perceber o piscar.
No intervalo de 1s entre o dado 255 e 0, o led do receptor apaga (sem transmissão) e o do transmissor acende como previsto.

3 - Conectei a saída do receptor no osciloscópio e obtive o início da transmissão. Vide foto a seguir.

O preâmbulo com 4 transmissões do bit 0 foi detectado como previsto. Ele serve para que o receptor se polarize corretamente e detecte os pulsos de clock a cada 1ms. Observar que não há garantia que o receptor detecte TODOS os 4 pulsos do preâmbulo. Para informar que os pulsos do preâmbulo terminaram, SEMPRE ocorrerá um período com 2ms. O nível deste período dependerá do nível do oitavo bit do byte seguinte. Como o primeiro byte após o preâmbulo é 0 (decimal), o oitavo bit é '0', consequentemente, o nível de 2ms será '1'.

4 - Observe, o conjunto de bits, que o período de 1ms não está calibrado. Está dando um pouco mais de 1ms. Isso não tem importância, pois o clock contém esta informação.

Em tempo:

Filmei o funcionamento do Tx e do Rx com os leds piscando como deveriam. Ele comporá o vídeo total.

Próximo passo:

Fazer o fluxograma do receptor.

MOR_AL

MOR_AL · 19 de outubro de 2024

Em 14 de agosto, eu abri este tópico e desde então estou tentando fazer um teste de comunicação para os módulos Tx e Rx (UHF) encontrados facilmente no mercado.

Sem conhecimento dos meandros destes módulos iniciei com o "TxRx_Teste1", com apenas um Tx controlado por um 555 e um Rx. Neste teste descobri as limitações para poder efetivar a comunicação.

Ciente das limitações, parti para o "TxRx_Teste2". Pensando na sua aplicação seguinte, decidi poupar duas portas do microcontrolador (MC), eliminando o cristal. Assim teria 4 portas para monitorar o nível d'água da caixa de minha casa, que corresponderiam a 25, 50, 75 e 100% de água. Ledo engano.

Precisei usar um código de comunicação, que enviasse os dados e o clock no mesmo pino.

O procedimento já se arrasta por alguns meses, então tomei a seguinte decisão.

Desisti de seguir o código Manchester.

Tentei fazer o fluxograma via código Mancheter. Cheguei a terminar o teste de transmissão (postagem anterior). Tentei incluir a presença de ruído em alguns trechos na recepção. Infelizmente o trabalho e a dificuldade superou as minhas expectativas.
No momento o fluxograma do receptor se encontra grande, porém incompleto.
O detalhe é que há mais de três décadas eu fiz com chips da série CD40xx com menos trabalho e ficou bem mais simples.
Acho que a idade também conta. Enfim é a vida.

Com esta decisão, serão feitas as seguintes alterações para o projeto "TxRx_Teste3".
1 - Será incluído um cristal.
2 - Será usado o código UART como meio de comunicação.

MOR_AL

MOR_AL · 20 de outubro de 2024

Em Tempo:

Agora observei que o PIC12F675, que eu quero usar, não tem a comunicação USART incluída.

Pretendo então usar o padrão de comunicação da USART na transmissão. Já na recepção, usarei o PIC16F628A, que tem a USART incluída.

MOR_AL

MOR_AL · 13 de janeiro

Olá pessoal (galera para os mais novos, heheheh)!

Em 20/10/2024 às 16:12, MOR_AL disse:

Agora observei que o PIC12F675, que eu quero usar, não tem a comunicação USART incluída.

Pretendo então usar o padrão de comunicação da USART na transmissão. Já na recepção,......

Pois é!

A cada avanço (ou retrocesso) deste projeto, muitas alterações ocorrem.

Vamos lá:

1 - Decidi usar o PIC12F675, tanto na transmissão, como na recepção.

2 - Havia desistido do protocolo de comunicação Manchester por começar a ficar muito grande. Optei pelo protocolo UART.

3 - Acontece que o PIC12F675 não possui hardware da UART, então tive que fazer na unha.

4 - Optei em usar cristal em ambos os PICs.

5 - Transmissão.

A transmissão é composta por um preâmbulo antes de enviar todos os bytes desde 0x00, até 0xFF. O preâmbulo consta de um tempo de 49ms em '1' e três bytes, 0xF8, 0xF8 e 0xFA.

Depois do byte 0xFF, há um período de 1s sem transmissão, até que tudo seja repetido.

Segue a PCI do transmissor (fora de escala):

6 - Terminei o firmware em Assembly do transmissor.

7- Receptor.

Acabei verificando que vou precisar de quase todas as artimanhas que usei com o protocolo Manchester. Mas, com o desenvolvimento do projeto, muita coisa foi simplificada e outras foram descartadas.

8 - Terminei o fluxograma do receptor. Não sei se está correto. Por isso é que ocupei os três pinos restantes do PIC12F675, para usá-los com leds. Até que o firmware fique ok. Os três leds poderão fornecer 8 estados, sete dos quais correspondem a problemas em grande parte do fluxograma. Alguns problemas correspondem a erros provocados no canal de comunicação (distância, lajes, paredes. ruídos etc). Caso sejam necessários mais pontos de verificação, já previ, mas não implementei, outros 8 estados com os leds pulsantes. Outros erros são detectados devido a falta de algumas ocorrências.

8.1 - O pulso inicial recebido do preâmbulo tem que possuir, pelo menos 5ms dos 49ms transmitidos.

8.2 - Em seguida tem que haver um stop bit com cerca de 1ms.

8.3 - Podem ser detectados dois bytes 0xF8, porém o segundo 0xF8 tem que ser detectado.

8.4 - O byte 0xFA tem que ser detectado.

8.5 - Ambos, start bit, como stop bit dos dados têm que ser detectados.

8.6 - Um ruído, ou um pequeno problema na detecção, que implique na NÃO recepção do byte esperado, faz o programa ser reinicializado. Como o transmissor não tem como identificar o erro no receptor, o receptor irá acusando erro, até que detecte o preâmbulo seguinte. Caso ele seja detectado, os três leds apagarão. Este foi um meio para saber até que distância o sistema vai funcionar.

9 - Terminei o firmware em Assembly do receptor. Ficou trabalhoso, mas pode até dar certo. Vamos ver e tentar corrigir os erros. Inicialmente pretendo testar a comunicação sem o Tx e o Rx (ou com o Tx e o Rx, a um metro entre eles), para saber como está se comportando os firmwares.

10 - Segue o layout do receptor:

11 - Hoje terminei de fazer as PCIs do transmissor e do receptor. Segue a foto: Com um cartucho novo, porém não original, o depósito de toner ficou muito bom. Já coloquei uma fina camada de verniz, para preservar o cobre.

MOR_AL

.if · 13 de janeiro

Em 20/10/2024 às 16:12, MOR_AL disse:

observei que o PIC12F675, que eu quero usar, não tem a comunicação USART incluída.

Queira googlar bit banging (clique).

25 minutos atrás, MOR_AL disse:

Terminei o firmware em Assembly do transmissor.

Ok... já entendi que já resolveu...

O que me fez lembrar uma loucura do passado... certa feita com hormônios à flor da pele... fiz um programa no 8049..

https://en-m-wikipedia-org.translate.goog/wiki/Intel_MCS-48?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt&_x_tr_pto=tc

o meu é com janela.. ainda tenho.

detalhes: sem datasheet, sem manual do compilador assembly, o que fiz foi abrir no pctools (lembra disso?) o .exe e .ovl do programa dele e procurar por mnemônicos meio que conhecidos tipo LDA, JMP, ADD, SUB e etc e fazer deduções de como se comportariam. E deu muito certo. Usei um display lcd que mostrava textos vindos de um terminal.

MOR_AL · 18 de janeiro

Rx e RX Montados.

Próximo passo:

Programar o PIC do Tx e do Rx.

MOR_AL

.if · 18 de janeiro

Desculpe.. esqueci de te falar... era pra você deixar uma barra de pinos de 5 terminais pra fazer gravação in circuit

Nem precisava do soquete. Detalhes: é bom que GP0 GP1 sejam saída ou entrada com resistor em série pra que a eventual (baixa) impedância do sinal não atrapalhe os de gravação. Ok.. entendi que gravar por fora não lhe é problema e que preferiste otimizar espaço. No entanto permito-me registrar a dica pois se algum dia migrares pra smd, o icsp é condição sine qua non.

MOR_AL · 19 de janeiro

Hoje fiquei cerca de 5 horas instalando o firmware no PIC12F675 do Tx.

Uma hora para botar funcionando o programador K150. Desta vez escrevi a "receita de bolo" para não ter que partir do zero.

Quatro horas para programar. Na simulação funcionava, mas na realidade não.

E o erro era simples, mas sutil. Errei em tornar o registro CMCON como saídas digitais. O detalhe foi que errei com uma instrução também aceita pelo MPLAM, não acusando o erro.

MOR_AL

.if · 20 de janeiro

12 horas atrás, MOR_AL disse:

Errei em tornar o registro CMCON como saídas digitais.

Comigo foi o contrário. Levei muitos minutos pra descobrir que após o reset os pinos nascem como entradas pro comparador. Pra torná-los digitais deve-se fazer

                           CMCON=0b00000111; //CM2=CM1=CM0=1;
                                      |
                                     \+/

MOR_AL · 20 de janeiro

3 horas atrás, .if disse:
Comigo foi o contrário. Levei muitos minutos pra descobrir que após o reset os pinos nascem como entradas pro comparador. Pra torná-los digitais deve-se fazer
                           CMCON=0b00000111; //CM2=CM1=CM0=1;

É!

Eu sabia disso, até cheguei a comentar em uma outra postagem.

O programa já tinha CMCON como 0x07 (movwf CMCON). Só que em vez de fazer antes movlw 0x07, eu usei outra instrução mov alguma coisa e o compilador aceitou. A entrada permanecia analógica. .

MOR_AL

MOR_AL · 26 de janeiro

Hoje tentei gravar o PIC12F675 com o firmware do receptor.

Como dizia o Paul McCartney. "Vida é o que acontece, quando ocupado, temos outros planos".

Pois é!

Casualmente tentei abrir o arquivo do fluxograma usado para fazer o assembler.

Xabu total!

O arquivo não abria de jeito nenhum.

Recebia a informação que "Não era um arquivo válido".

Para encurtar a história.... Fiquei cerca de 5 horas pesquisando porque não abria. Descobri que era um caso comum na comunidade Windows e ninguém conseguia resolver.

Tentei de tudo sem sucesso.

Aí pensei... Será que tenho esse arquivo em algum backup? Tenho várias mídias com backup.

Em uma delas estava o arquivo e outros que não abriam. Tentei e os arquivos abriram.

Rapidamente deletei os arquivos que não abriam e os troquei pelos que abriram.

Acontece que 5 horas tentando desgastam qualquer um.

Acabei resolvendo um problema, mas perdi o sac.... ehr, a paciência para gravar o firmware.

Outro dia eu gravo.

MOR_AL

.if · 27 de janeiro

18 horas atrás, MOR_AL disse:

arquivo do fluxograma usado para fazer o assembler

18 horas atrás, MOR_AL disse:

Não era um arquivo válido

Qual programa usaste pra criar e salvar o tal arquivo? Qual a extensão? Qual seu formato? Texto simples?

18 horas atrás, MOR_AL disse:

um caso comum na comunidade Windows e ninguém conseguia resolver.

Não faço parte de tal comunidade tampouco da linux ou de qualquer uma que seja ... no entanto possuo conhecimentos empíricos genéricos que eventualmente podem somar ligeiramente além do zero. P.ex. tal arquivo pode ter tido o cabeçalho danificado por isso o programa não consegue decifrar mas os dados ainda estão lá. Este era um caso na época do pctools, ndd, ncc (lembra disso?) onde se lia diretamente os dados de setores do HD e via-se os dados em texto, hexa, binário e afins. Um programa menos antigo que usei há anos (com não muito boas intenções mas com sucesso ) foi o hiew.

Aqui com a visualização de código de máquina

ok... entendi que já conseguiste resolver mas mesmo assim senti vontade registrar o feito pois eventualmente alguém pode não ter tido seu tino de fazer backup... ou melhor, não tem backup mas tem que ter sac...

18 horas atrás, MOR_AL disse:

várias mídias com backup.

18 horas atrás, MOR_AL disse:

e os arquivos abriram

18 horas atrás, MOR_AL disse:

Acabei resolvendo um problema

edit pra não virar muitas páginas...

1 hora atrás, MOR_AL disse:

arquivo.cpp. A mensagem de erro no RFFlow mencionava o arquivo e as linhas com problemas.

arquivo.cpp antigamente era texto simples em c++ (C Plus Plus). Parece que o tal rfflow sequestrou esta extensão pra ele e acrescentou complicadores além do texto em asc-ii. Enfim de fato parece não ser texto simples e preferiste abrir o de ontem.cpp e resolveu. O saco é quando há muitas alterações/revisões de ontem pra hoje, o backup ajuda pouco. Neste caso existe a opção de se avaliar melhor p.ex. suas linhas com problemas ou o método (arcaico) por mim supramencionado...

MOR_AL · 27 de janeiro

3 horas atrás, .if disse:

Qual programa usaste pra criar e salvar o tal arquivo? Qual a extensão? Qual seu formato? Texto simples?

O principal que não abria era o RFFlow.

Cada dia que trabalho nele, salvo com o nome do arquivo e a versão salva.

Tenho diversos arquivos (17) com o mesmo nome, porém com versões diferentes.

O detalhe é que os quatro últimos o; arquivo_16, arquivo 16_1, arquivo_17 e arquivo_17_1. (o complemento _1 é o backup. Útil, quando o arquivo principal dá problema), não abriam, mas os outros 16 anteriores, sim.

Já tinha aberto estes mesmos arquivos antes, sem problema.

Como alguns PDFs também não abriam com o XChange, tentei abrir com o PDFgear e abriu.

O problema não está nos arquivos e sim no arquivo.cpp. A mensagem de erro no RFFlow mencionava o arquivo e as linhas com problemas.

Acredito que tenha ocorrido em alguma atualização automática de algum arquivo do Windows.

MOR_AL