rodrigocirilo

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....

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..

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)

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...

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. 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.

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..

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

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)