rodrigocirilo

2 horas atrás, .if disse:

Eu sei mas não posso contar ... Caso o autor revisite sua publicação, penso que lhe pode enviar mp.

Off... apesar de sinistro, respeito a decisão do velho amigo autor - ocupado com outras atividades - de não responder email... apesar que sinto que flui certa 'ignorância' - no sentido de ignorar - o que tem certa relevância. Curiosamente convivo com isso na vida real  kk

Minha curiosidade serviu pra desativar o modo off do autor hehe e lhe responder... no fim fiquei na curiosidade ainda..

Ja usei pic 10F em uns projetos, e impressionante como uma coisa daquele tamanho consegue ser programada e rodar um firmware...

Fiquei curioso pra saber o uso desse motorzinho vibrante  hehe....

44 minutos atrás, .if disse:

É quase a lesma lerda ... não sai do reset o que não deixa a cpu nascer.

Eu (eu) já acho o brownout bem útil: não deixa funcionar com bateria baixa o que poderia causar instabilidades algo como deixar as variáveis ter vida própria e começar a tomar decisões por si .

O wdog pra ficar achando pontos onde resetá-lo manualmente é 1 pns. Mas claro, tem sua missão estilo 'cada caso é um caso'.

 verdade...

No meu caso, ao ligar o wifi drena bem as pilhas se ja estiverem velhas e isso estava deixando variaves e I/O´s ter vida propria, mas o bronwout sozinho nao resolveu...parece que ficava um pouco acima do limite minimo pro Brown atuar, não resetava e zoava tudo....

o bronwout deveria atuar apos o codigo começar a rodar...

No caso do problema que relatei, eu mantive ativado, pois meu problema é unica e exclusivamente com bateria baixa, então se, ao ser ligado pelo usuario detectar a tensãi baixa, ele nao inicia (a popósito o bronwout fica resetanto o uC infinitamente ou somente nao deixa startar??

Falando de display 16x2 ou 20x4, em um passado nao muito distante, eu travei uma batalha com uns, era ambiente semi-industrial, uma vacilada imprimia lixo na tela...

Criei um topico aqui, acho que foi 2014, tive bastante ajuda e dicas, o Paulo me ajudou bastante via mp..

a interface entre placa e display era feito atraves de cabo manga etc... blindamos os display e nada... perdi a batalha, então, a cada 5 seg eu mandava um clear pro display pra limpar caso houvesse lixo impresso, era tão rápido que só dava ujm piscadinha, o cliente nem percebeu praticamente hehehe..e venci a guerra 

depois fiz outra placa com tudo onboard e acabou-se os problemas referente a isso, mas mesmo assim mantive o clear hehe..

1 minuto atrás, .if disse:

O que te levou a não usar um relógio de verdade tipo aqueles módulos ds1302 que já vem até com bateria? Não precisa mencionar que ele é caro mas a ideia seria usar apenas o ds1302+bat incorporado no seu sistema.

 

Sério que o esp precisava de ajuda pra isso?

 

Pra uma ajuda mais efetiva, considere publicar os desenhos/esquemas/etc... +1: 1.jpg>1k.txt

Sei que o esp da conta tranquilo de fazer tudo, mas ele com o modem desligado consome na faixa de 15mAh, e isso é muito para o meu sistema que vai ficar muitos dias ligado e alimentado por pilhas e a melhor opção que encontrei foi usar um pic para contar o tempo e controlar tudo, pois consome somente 0.5mAh.

o esp foi usado, pois a configuração precisa ser feita via app (acertar o relogio, inserir tempos etc)

4 minutos atrás, vtrx disse:

Ainda não sei a razão,mas tenho um circuito que usa um PIC com USB e utiliza alimentação do PC(USB).

Com um capacitor paralelo na alimentação com valor acima de 22µ,ele não inicia a cada 10 conectadas.

Só solucionei com um capacitor de menor valor.

Outro detalhe é que com capacitor maior,quando faço a gravação utilizando ICSP,as vezes da erro.

beleza, bom saber disso, assim que tiver com cap aqui eu vou testar sim..

@aphawk Bem, eu acabei usando um 1n4007, procurei o 4148 e estou sem nenhum hehe, no entanto, assim funcionou, vou explicar como ficou.

peguei a alimentação do pic, no output do regulador de 3v3, levei para o pic através do diodo, no pic junto do vcc e gnd ja tinha um 100nf e um 100uf, então mantive o de 100uf mesmo por uma questão de espaço(visto o tamanho do 470 e 1000uf que tenho aqui)

agora, quando as pilhas estão boas, tudo funciona normal, como antes, mas quando coloco pilhas ruins cerca de 1,1v em cada, a tensão cai demais e o pic nem liga (acho que o brownout atua) e ele nao trava nem da pau nas saidas. então neste ponto deverá ocorrer a troca das pilhas.

Ainda está testando aqui, qualquer novidade eu retorno aqui.

@vtrxprocurei aqui e tambem estou sem nenhum cap de 10uF, vou providenciar junto com os 4148 e vou testar isso tambem, mas me diga, porque abaixar o valor do capacitor?

E obrigado pela ajuda dos colegas...

1 hora atrás, aphawk disse:

@rodrigocirilo ,

 

Esse Pic deve funcionar tranquilamente com até 2V de alimentação. O seu ESP01 deve estar puxando um pico alto de corrente quando liga, e esse pico deve estar fazendo seu Pic travar.

Uma ideia seria isolar a alimentação do Pic da bateria via um diodo de baixa queda de tensão, um schotky de até uns 100 mA, e colocar um eletrolítico de uns 470 uF em paralelo com o Pic além de um cerãmico de 100nF, assim ele segura a tensão durante essa queda momentânea devido à partida do Esp01, ok ?

Talvez tenha de ajustar o valor do capacitor eletrolitico.

 

Vou te contar o que aconteceu comigo, eu usava um Nodemcu, que é um ESP14, e quando ligava ele dava um baita pico de corrente na bateria, eu tive de fazer esse isolamento tanto no meu Attiny como também no Nodemcu, usando diodos schotky de 1A e baixa queda de tensão, no Nodemcu usei eletrolítico de 1000 uF, no Attiny usei 220 uF,  e resolveu todos os problemas de uma vez. Mas peguei isso ainda na fase do projeto, e já fiz a PCB com essas correções.

 

Paulo

 

 

Ok, Paulo, imaginei mesmo que fosse o pico do esp01 causando isso.

como eu havia dito, a alimentação das pilhas vai direto para o pic ( 2v ~ 5v) então estara sempre dentro da faixa, e para o esp01 eu passo por um regulador 3v3.

Enquanto aguardava a ajuda de vocês, eu fiz um teste aqui, peguei a alimentação do pic, tambem do reg 3V3, e aparentemente o problema sumiu, penso que como a queda de tensão seja alta o pic nem consegue startar.

O que você sugeriu seria: O capacitor "cheio" seguraria a tensão para o pic startar, e essa tensão nao seria puxada pelo esp01 por causa do diodo, é isso? qual diodo sugere, pois acho que nao tenho nenhum diodo schotky  aqui.

1 hora atrás, vtrx disse:

Vou sugerir que teste duas coisas e poste o resultado.

A primeira que troque o capacitor de 100µ por um de 10µ(isso mesmo reduzir).e a outra é que experimente ativar no PIC o brownout.

vou abaixar o capacitor daqui a pouco para testar..há um fundamento nessa logica?

o bronwout ja esta ativo...

Bom dia pessoal.

Estou pedindo ajuda em um problema que está meio complicado de resolver.

Basicamente, tenho um esp01 interligado via serial com um pic.

O pic com um 32768khz conta um tempo preciso para ligar uma saida em tempos determinados previamente.

 O esp01 serve somente para acertar o relogio do pic e inserir os tempos em que a saida devera ser acionada.

 Apos configurar o pic (via celular) o esp01 entra em deepsleep, para  praticamente zerar o ser consumo, ficando só o pic contando o tempo.

Como o sistema é alimentado por 3 x AA (4,5v) ha um regulador LDK715M33R (3v3) para  o esp01, no pic vai direto das baterias.

Tenho capacitores de 100uf e 100nf proximo da alimentação do pic e do esp01.

Quando preciso altrar alguma configuração, devo desligar e ligar o sistema todo, para o wifi retornar ligado e é ai que o problema ocorre.

No caso o problema ocorre, somente quando as pilhas ja estão fracas, pois ao ligar, o esp01 "puxa" de 80 a 90mAh, deixando uma tensão muito baixa para o pic, o pic por sua vez, nao consegue "startar" e aciona as saidas aleatoriamente, fazendo a carga que está a saida ligar (obs a carga está em uma bateria 9v e é chaveada por um mosfet de nivel logico).

então quando as baterias enfraquecem, ao desligar e ligar, o pic enlouquece e ferra tudo.

Ja tentei algumas coisas via software, brownout reset , delays e nada, parece que quando isso ocorre, o programa nem passa pelo setup para dar tempo de configurar tudo, ela ja bug antes disso.

Ja tenho 100 pcbs montadas, porém nao previ o problema com bateria baixa.

ha algum recurso no pic (16F688) que eu possa usar para contornar isso, sera que o wdt inicia mesmo quando bug, pois ele ficaria causando reset, e nao deixaria ligar as saidas.

obrigado.

28 minutos atrás, Isadora Ferraz disse:

O certo era no eletrônica mesmo. Peça pra moderador mover pra você ou aguarde ele decidir.

 

O transistor bjt mesmo saturado guarda em si alguma tensão por isso há perda. Ela se destaca ainda mais em forma de calor no corpitcho dele ao trabalhar com baixa tensão e alta corrente. Tenta aumentar a corrente na base mas já vou adiantando que é 1/2 paliativo.

Pra otimizar o sistema, pesquise por mosfet que tenha baixo RDSon em baixo Vgs. Vá p.ex. no site digikey.com e digite mosfet n channel e faça busca paramétrica.

Obrigado.

Ja usei mosfet em outras aplicações, vou testar e retorno.

No Arduino IDE eu faria assim

String recebe_x  = String(x); // converte int em string

String recebe_y  = String(y); // converte int em string

String z = recebe_x + recebe_y; //concatena aqui

ou

x = x*100; //45*100 = 4500

x = x+y; // 4500 + 54 = 4554

z = String(x);// int para string

Bom dia pessoal, iria postar na parte de eletronica do forum por não ter muito a ver com programação, mas sei que o pessoal aqui é capacitado pra me ajudar a entender o meu problema.

Tenho um simples motor DC de 3~4,5V ligo ele direto em uma bateria (18650) atraves do amperímetro e leio 420mAh de consumo e uma certa velocidade no motor. então eu faço a acionamento através de um TIP122 ou bc337 e leio somente 330mAh no amperímetro e uma velocidade mais baixa no motor. aciono a base do transistor com resistor de 470 Ohms  e tambem 1K (não percebo diferença no consumo).

O que quero é que ao acionar a base do transistor eu tenha 100% de aproveitamento da potencia do motor. o que estou fazendo errado.

PS: vou acionar a base do transistor através de um uC.

@Isadora Ferraz Isadora, obrigado pela resposta e desculpe pela demora em dar um parecer por aqui.

Bem, no caso o 12F675 não tem serial de hardware, então o que tentei usar foi a softserial que o CCS possibilita. entretanto algo não estava dando certo, tentei de todas as maneiras que voce citou e mais algumas e não conseguia achar um padrão na comunicação. dai resolvi trocar o pic pelo 16F688 que tem hardware serial e no primeiro teste tudo funcionou perfeitamente.

Então resolvi optar por esse pic mesmo por não ter tido nenhum problema.

Futuramente pretendo testar a softserial do 675 novamente.

Pessoal boa tarde.

Estou tendo o seguinte problema:

Estou tentando uma simples comunicação entre um esp01 e um pic via serial, o pic em questão usa software serial ok.

Bem eu faço o ESP enviar um simples carácter ou int para o pic e o pic não consegue "decodificar" o que chega.

Eu tento enviar do ESP das seguintes formas:

Serial.print('1');
delay(1000);
serial.write('1');
delay...
serial.print(1);
delay...
serial write(1);
delay...

Do lado do pic tento ler assim:

char buffer;
if(kbhit())
  {
    buffer = getc();
  
  if(buffer == 1)//tenta ler como decimal int
    pisca uma vez...
  else if(buffer == '1')//tenta ler como caracter
    pisca duas vezes..
    else
    buffer = 0;
 
  }
  
 

Mesmo eu sabendo que o ESP está enviando, o pic não consegue identificar o que chega.

Alguém tem uma dica pra me dar..

2 horas atrás, Isadora Ferraz disse:

relé: filtro passa baixa RC: frequencia alta do buzzer não aciona o relé

O buzzer é ativo não passivo, aciona somente com alto/baixo.

30 minutos atrás, Isadora Ferraz disse:

Você (o pic) está no controle. Defina prioridades. Aguarde terminar a comunicação antes de buzinar.

Mas algo me diz que você é inteligente o suficiente pra compartilhar o inócuo buzzer com outro sinal menos crítico

Tentei no Protheus e funciona em partes, o pic envia o sinal, o buzzer toca normal, porém o pic não recebe do PC, acho que tem algo haver com isso.

Os outros pinos que eu poderia compartilhar um é um relé, não dá, pois praticar o buzzer o relé irá acionar, o outro é um pino de entrada que lê um sensor NA/NF, lendo nível lógico 0.

Acho que não vai rolar viu.

Fala pessoal, seguinte, tenho um pic  comunicando por rs485 com um PC, bem ocorre que o pic que uso (não há possibilidade de mudar pois é um pic smd 16f688 e os outros com mesma pinagem não tem memoria suficiente, então tem de ser este) antes eu comunicava por rs232 e não necessitava do pino Driver Enable do MAX485, agora (usando RS485) preciso desse pino, mas o pino em questão ja estava sendo usado por um buzzer ativo, então está me faltando um pino.

Então pensei se seria possivel compartilhar esse pino entre o D.E. e o buzzer, como o pino enable vai a high por um tempo muito curto durante a transmissão não me importaria que o buzzer apitasse ligeiramente (seria até bom, seria um indicativo de transmissão) no caso quando preciso sinalizar algo pelo buzzer (apitadas rapidas) o enable iria a HIGH tambem, mas não haveria comunicação no TX/RX isso não causaria problemas para o CI certo? penso que o problema que poderia gerar é: se o PC quiser enviar alguma informação, e o buzzer tocar, ambos D.E. estarão habilitados ao mesmo tempo, é ai que penso que poderia causar um defeito fisico ou somente a impossibilidade de comunicação momentânea? pois tudo ocorre tão rápido que acho que será difícil essa "colisão" 

Os dados que envio de cada vez não passam de 10 ou 15 bytes de cada vez, uso baud a 1200.

Na base do transistor do buzzdr tem um resistor de 10K.

Obrigado.

Ok, eu agradeço.

Caso puder me citar um exemplo ficarei grato.

vtrx eu descobri o problema. Na verdade um problema besta hehe, a variavel do laço for era int então ela incrementava somente até 255 e parava a gravação neste endereço, então eu tornei-a int16 e ele gravou até o endereço 2048 da eeprom ext.

Comi bronha nisso, e quebrei a cabeça, pois eu estava procurando o defeito em um local e estava em outro

opa, desculpe, o compilador é o CCS.

Olá pessoal do CDH.

Seguinte, estou quebrando a cabeça aqui, pois preciso usar uma eeprom externa com 16Kb de espaço, bem eu uso o comando a seguir para gravar nela:

I2C_start(); //start barramento
I2C_Write(0xA0); //identifica disp.
I2C_Write(end);  //Endereço
I2C_Write(dado); //dado
I2C_Stop();      //stop barramento
delay_ms(5);     //atraso

A questão é que se eu uso um for com a variavel de controle sendo o end, ele chega no endereço  0xFF ou 255 e para. Sei que  preciso ir para o proximo bloco para começar gravar a partir do 0 novamente, mas não sei qual comando adicionar ali ↑↑ para mudar o bloco que preciso gravar.

para ler uso esse ↓↓ que tambem vai requerer algo a mais para indicar o bloco, no ds da memo só fala algo B2 B1 e B0 nao entendi.

I2C_Start();     //start barramento
I2C_Write(0xA0); //dentifica dispos.
I2C_Write(end);  //Endereço
I2C_Start();     //Restart
I2C_Write(0xA1); //Identifica dispositivo para leitura
lido = I2C_Read(0); //Faz a leitura do dado
I2C_Stop(); //stop barramento
delay_ms(5); //Atraso

alguem?

Envia o valor como String 

Serial.print("30000");

Na recepção use o toint para volta a ser valor inteiro.

byte recebe = recebido.toInt();

Vixi, agora a coisa complicou para mim kkkkk.

Conversei com um amigo que mexe com tratamento de imagem, ele disse que é possivel decodificar a imagem através de uma camera IP, mas necessitaria de um pc para fazer isso e eu nao queria ter que ter um pc para fazer isso.

Bom, assim que der vou tentar a sugestão de ler os segmentos do display, se nao der certo ai que vejo se aceito esse desafio de ler o barramento i2c. 

Preciso abrir a balança pra ver onde está o barramento.

Talvez haja um motivo para as balanças que tem saida serial serem tão caras.

@Isadora Ferraz Obrigado pelas dicas. vou testar com os fotodiodo pra ver se detecta. quanto a "pegar" o sinal da celula de carga, assim que possivel vou abri-la pra dar uma olhada.

@Eder Neumann Não vou abri-la, quero ler de alguma forma a tela da balança, a mudança de estado dos segmentos do display. 0 ou 1 (acesso/apagado)