ViniciusKruz

@aphawk Exatamente como eu pensei em fazer, o problema é que ainda assim seria um alto consumo de IO, se eu usar uns 20 CIs por exemplo, meu uC ta lascado rs. Para resolver este problema, caso ninguém tenha uma ideia melhor, vou fazer desta forma que sugeriu só que vou usar um 74LS138 pra fazer a multilpexação. Minha esperança seria que alguém tivesse uma saída melhor, tentando me enganar rerere. Não sei porque cargas criam um CI com i2c que não permite mudar o endereço!!! Grande abraço Paulo.

Amigo, na boa, ... cara não vou nem responder.

Aqui tem um exemplo para ligar na porta paralela do pc, mas para ligar em um uC o princípio é o mesmo: http://www.rogercom.com/pparalela/IntroMotorPasso.htm Abraço.

Pessoal, ha tempos atras eu lutei com um ci tda7319 e os resultados para aquela época foram satisfatórios: porém agora estou precisando de uma coisa que penso não ser possível porque não vi nada a respeito no datasheet. Preciso comunicar com vários deles por uma única via i2c, o problema é que eles têm endereço fixo 86h e não encontrei uma forma de mudar este endereço. Tentei desabilitar o DGND mas ele se comunica normalmente, se tivesse dado certo seria uma boa opção. Alguém teria uma ideia de como posso fazer esta comunicação em uma única via i2c? eu não estou querendo colocar uma via para cada ci, vai ser um desperdício de io. Desde já agradeço.

Amigo, tem uma forma bem simples de se fazer um debug, coloca em certos pontos do seu programa, um comando para piscar um led, assim você sabe realmente onde no seu código o sistema está rodando. Já no supervisório, coloca uma tela para monitorar os recebimentos e transmissões, assim tem como ver exatamente onde parou. Abraço.

Bom, vamos lá, lembrando que eu não programo em Mikro C, mas como em programação "todos os gatos são pardos", vamos tentar encontrar uma solução. Pelo que você mencionou, o supervisório envia para o mestre que por sua vez envia para o escravo e segundo informou o escravo fica ok mas o mestre fica travado juntamente com o supervisório. Assim podemos deduzir que o problema está entre o supervisório e o mestre. No seu programa, encontrei dois pontos que podem estar causando o travamento: 1º - quando o mestre envia para o escravo ele fica preso em um while: while (HidReadBuff[0] != 'S' && kp != 42) { } É preciso verificar com certeza se esta condição está realmente sendo desfeita ou então ficará travado aqui dentro 2º - Sua conexão com a porta USB está sendo reiniciada a cada vez que se pressiona determinada tecla: De repente por causa disso a configuração com o Host pode estar sendo perdida, tenta abrir a conexão uma vez só e deixa ela aberta o tempo todo pra ver. Bom, por hora é isto, checa aí e depois dá um feedback valeu.

No arduino tem dois exemplos que se você juntar os dois dá pra fazer o que está querendo: Blink e Button O Blink ensina a acender e apagar leds e o Button ensina a usar botões.

@aphawk beleza sem problemas, é uma boa ideia mesmo publicar alguma coisa a respeito deste CI porque não tem praticamente nada dele na internet, de repente depois eu publico o projeto depois. Já coloquei como resolvido, eu marquei sua resposta como a melhor, acho que pra ficar resolvido isto basta né? Se a moderação quiser pode dar por encerrado. Muito agradecido mesmo pela sua ajuda.

Pelo que você está dizendo, o problema está é no mestre, tem como você postar o trecho do código que envia os dados para o escravo?

@aphawk Amigo deu certinho, com o i2cScanner eu consegui identificar que o problema era o cabo que eu usava no i2c, com um cabo de 1/2 metro o scanner não encontrou nenhum dos 4 CIs que testei, daí desconfiei dele e troquei por um de 20cm, a comunicação ficou perfeita. Muuuiiitooo obrigado mesmo, sua ajuda foi muito grande. Deus o abençoe. Para quem quiser se comunicar com este CI(PT2322), fica aqui o programa que usei: #include <18F4550.h> #fuses MCLR,HS,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL2,CPUDIV1,VREGEN,NOPBADEN #use delay(clock=8000000) #use I2C(master, scl=PIN_B1, sda=PIN_B0) void main(){ i2c_start(); i2c_write(0x88); i2c_write(0xff); //resetar i2c_stop(); i2c_start(); i2c_write(0x88); i2c_write(0xc7); //ativar entradas i2c_stop(); i2c_start(); i2c_write(0x88); //volumes i2c_write(0x10); i2c_write(0x20); i2c_write(0x30); i2c_write(0x40); i2c_write(0x50); i2c_write(0x60); i2c_stop(); i2c_start(); i2c_write(0x88); i2c_write(0b11100100); //master -1db passo i2c_write(0b11010010); //master -10db passos i2c_stop(); i2c_start(); i2c_write(0x88); i2c_write(0x70 | 0x04); i2c_stop(); while(1) { } } Com o código acima, o PT2322 passa o áudio das entradas para as saídas a um volume baixo, isto é o suficiente para dar um sinal de vida, um hello world. Obrigado a todos pelas dicas. Vinícius Cruz.

Manda o print por favor, outra coisa, qual linguagem de programação esta usando nos microcontroladores?

@aphawk Nossa, isso vai ser uma mão na roda, muito obrigado por enquanto!!

@aphawk Paulo, desculpa a ignorância, mas de que programinha você está falando? Na verdade estou mesmo pensando em checar as respostas ACK, estou pensando em amanhã fazer alguma coisa pra ler a resposta do periférico. Tem razão, pode estar queimado mesmo. Veja só na simulação, a resposta no I2C Debugger está perfeita:

O 18f4550 deverá se comunicar com o computador por USB/RS485 ao mesmo tempo? seria isto?

Amigo, não entendi!! Creio que você conseguiu fazer o mais difícil que é a leitura de fluxo da água, calcular tudo e mostrar no display/leds, um timer de 60 segundos deveria ser o menor dos seus problemas. Desculpa, acho que não ajudei muito né rsrs. Conheço pouco e menos ainda de arduino, mas penso que você deva pesquisar por "timer" ou algo parecido, e no seu projeto você faz por exemplo um if(vazao<=0) {executa o timer} https://www.google.com.br/search?q=timer+60+segundos+arduino&o que=timer+60+segundos+arduino&aqs=chrome..69i57.8843j0j7&sourceid=chrome&ie=UTF-8

Minha nossa, como este ci é complicadinho, não comunica nem a pau, por último agora, estou tentando com o hardware I2C do 18f4550 a 100khz como manda o datasheet e nem assim não funciona. peguei a mesma sequencia de comandos usada naquela lib do arduino, que supostamente é funcional e nem assim não funciona. Com um outro ci de processamento de áudio funciona perfeito, mas esse é bem encrenqueiro rsrs. A sequencia de inicialização no arduino é assim: writeI2CChar(SYSTEM_RESET); writeI2CChar(INPUT_SW_ACTIVE); // required to activate // set the trim volumes to zero writeI2CChar(FL_VOLUME_CONTROL); //0db writeI2CChar(FR_VOLUME_CONTROL); //0db writeI2CChar(CENTER_VOLUME_CONTROL); //0db writeI2CChar(RL_VOLUME_CONTROL); //0db writeI2CChar(RR_VOLUME_CONTROL); //0db writeI2CChar(SUB_VOLUME_CONTROL); //0db // set the master voume Wire.beginTransmission(0x88 >> 1); // transmit to device 0x88, PT2322 Wire.write(MASTER_VOLUME_1STEP | (HEX2BCD(masterVolumeValue) & 0x0f)); Wire.write(MASTER_VOLUME_10STEP | ((HEX2BCD(masterVolumeValue) & 0xf0)>>4)); Wire.endTransmission(); // stop transmitting // set default function writeI2CChar(FUNCTION_SELECT | function); A minha sequencia (CCS C) ficou assim: #use I2C(master, scl=PIN_B1, sda=PIN_B0) void main() { i2c_start(); i2c_write(0x88 >> 1); i2c_write(0xff); //resetar i2c_stop(); i2c_start(); i2c_write(0x88 >> 1); i2c_write(0xc7); //ativar entradas i2c_stop(); i2c_start(); i2c_write(0x88 >> 1); i2c_write(0x10); i2c_write(0x20); i2c_write(0x30); i2c_write(0x40); i2c_write(0x50); i2c_write(0x60); i2c_stop(); i2c_start(); i2c_write(0x88 >> 1); i2c_write(0b11010010); //master 1 passo i2c_write(0b11100100); //master 10 passos i2c_stop(); i2c_start(); i2c_write(0x88 >> 1); i2c_write(0x70 | 0x04); i2c_stop(); while(1){} }

@aphawk Ok Paulo, vou fazer isto ainda hoje. Obrigado pelas dicas. @Bcpetronzio Obrigado, vou fazer isto.

entendi, acho que encontrei um erro no ACK, pelo que entendi ele tem que ser no 9º clock do scl e também me parece que o ACK não deve ser colocado em nível baixo e sim de alta impedância, será que tem mais alguma coisa?

Eu estava em um outro tópico com um assunto parecido onde eu tentava fazer a comunicação entre um arduíno e um tp2322. Sem muito sucesso com o arduíno resolvi voltar para o 18f4550 pois tenho mais afinidade. Bom vamos lá, antes de mais nada gostaria da opinião de vocês, vejam o gráfico que o 18f4550 está gerando(comunicação i2c), simulação feita no proteus e me digam se da forma como estão dispostos o scl e o sda está correto:

Não consegui marcar o tópico como resolvido. Muita coisa mudou por aqui rsrs.

@ljMonteiro Eu pensei que fosse ser mais fácil com o arduino por ter encontrado a lib correspondente mas já vi que me enganei. Meu foco na verdade é o CI PT2322, a programação em si neste momento não importa muito. O arduino parece ser fácil por conter quase tudo relativamente pronto porém eu percebi que se precisar alterar alguma coisa dá muito trabalho e como foi dito pelo amigo Paulo @aphawk: " Poucos possuem o conhecimento para fazer libraries" e isto pra mim é o calcanhar de Aquiles do arduíno. Faz o seguinte, vou abrir um novo tópico exclusivamente para análise dos gráficos gerados pelo 18f4550 pra não confundir as coisas, para fins de organização no forum. No 18f4550 estou fazendo na unha a comunicação, cada pulso de clock do scl e também do sda, creio que será mais produtivo. Agradeço a todos pelas dicas e peço encarecidamente que me assistam com seus comentários no outro tópico que vou abrir. Deus os abençoe.

Estou fazendo uns testes neste ci pt2322 também com um 18f4550 e não consigo comunicação de jeito nenhum, eu fiz na unha o driver mas não sei onde estou errando. Fiz uma simulação no osciloscópio do proteus para analisar o protocolo, aparentemente está certo, por favor, se puderem confiram minhas comparações entre os dados do osciloscópio e o datasheet na imagem em anexo.

@aphawk No PIC eu estou fazendo da forma sugerida por você, por não encontrar nada "pronto" ou que pelo menos dê um pontapé inicial, aliás, já fiz isto antes com um outro ci de áudio, um tda, e deu certo, mas como encontrei esta para o arduíno pensei que fosse me dar menos trabalho. @ljMonteiro Na verdade eu coloquei os arquivos na pasta libraries da mesma forma que já são dispostas as do sistema mas não deu certo, daí eu usei aquela opção de inserir libraries .zip e ele mesmo colocou as pastas nos locais corretos, porém ele não colocou os arquivos .h e o que eu fiz foi colocar eles manualmente só que o sistema não reconheceu eles aliás, passou a reconhecer quando eu mudei no código de #include<> para #include" " e desta forma passou a reconhecer, porém dá a mensagem de lib inválida. Ao invés de postar os códigos, vou postar a lib.zip tal qual foi baixada. PT2322.zip

Uma coisa interessante sobre a geração de hidrogênio é que as células atuais usam a eletrólise para quebrar as moléculas de água e geralmente o gás resultante não é H2 como deveria mas sim HO, até por este motivo ele não pode ser engarrafado pois devido a presença do oxigênio, haverá combustão espontânea. Até existe uma modificação nas células para que ela retire também o oxigênio mas geralmente poucos fazem desta forma. Agora, vejam o que me dizem desta nova forma de extração de hidrogênio: http://www.portal-energia.com/descoberta-forma-de-produzir-hidrogenio-sem-gasto-de-energia/ Agora uma dúvida sobre esses aglomerados de alumínio e esta técnica sugerido: esta é a mesma forma já utilizada ha tempos, onde se coloca um pedaço de alumínio em uma solução de soda caustica?

@FelipeZ. Então, obrigado pela bela explicação. É que como eu foquei no trecho que eu citei, pra mim havia ficado claro que quanto mais hidrogênio melhor, logo imaginei que se fosse H puro seria melhor ainda. Na verdade fiquei preso no átomo e não me atentei para a molécula. Certa vez fiz testes com hidrogênio, e eu até consegui funcionar um motor de 50cc de marcha lenta com apenas HO que minha célula gerava e eu acumulei em uma sacola plástica destas de supermercado, ai final coloquei fogo na sacola vazia e o resultado foi uma explosão parecida com o pneu de um carro explodindo, assustei a vizinhança inteira. Fiquei tão impressionado com o poder do hidrogênio que parei de brincar com ele.