I2C PIC Slave ACK

test man*~ · 8 de maio de 2015

Boa note pessoal,

Estou fazendo uma comunicação I2C entre dois PICs e estou com um problema, Tudo está ocorrendo de forma correta exceto o fato do PIC slave não pegar corretamente o ACK enviado pelo mestre após ele (o escravo) ter transmitido um byte.

Pedaço do código, parte onde o slave envia o dado para o mestre:

Uso o CCS

ack=i2c_write(buffer[endereco]);//buffer[4]

endereco++;//Endereco de 0 a 3

Após todas as escritas o ACK sempre é 1 (NO ACK), mesmo o mestre enviando o 0 (ACK). O mestre recebe os dados e envia o ACK corretamente o problema é o slave.

Minha dúvida é a seguinte, como estou somente na simulação isso pode ser um erro do Proteus? Usei o I2C debbuger e simulei passo a passo (com o .cof) antes do mestre enviar o ACK o slave termina a instrução "i2c_write(buffer[endereco])" e atribui o valor 1 para a variável ACK e depois disso o mestre envia o ACK...

alguém já teve este problema?

Muito obrigado aos que responderem!

MOR_AL · 8 de maio de 2015

Bem-vindo Darui!

Fiz as rotinas I2C em asm. Tentei simular no proteus e aconteceu algo estranho com o ACK. Não aparece o pulso de ack = 0 por parte da memória

Aí decidi montar e funcionou.

Bom.

Tenho um projeto completo em asm. Lá pode ser observados todos os passos para o uso do I2C.

Como você usa a linguagem C, tudo ficaria mais fácil.

Agora. Se você quiser entender o funcionamento detalhadamente, uma lida no meu trabalho vai facilitar para o seu projeto em C, pois não há necessidade de entender as rotinas em asm. Basta entender o que elas fazem.

Meu trabalho possui 24 páginas. Caso realmente deseje ler o trabalho, me informe.

MOR_AL

test man*~ · 8 de maio de 2015

Muito obrigado cara...

Mande-me por favor! Vou ler ele ... Eu decidi montar, debugar com o Pickit2, colocar um breakpoint no lugar onde o primeiro ack é recebido e ver o que acontece...

Eu comecei fazendo uma comunicação com o DS1307 daí achei o I2C muito interessante e adicionei uma memória EEPROM ao barramento, pretendo adicionar um PIC slave e depois mais 2 mestres... Tudo ocorreu bem na simulação até ocorrer esse problema no ACK...

Mas enfim, obrigado pela resposta e aguardo o seu trabalho!

MOR_AL · 9 de maio de 2015

Segue o endereço.

Você deve se registrar e fazer o login para baixar, caso contrário o sítio abre um monte de páginas e você vai ter dificuldades de achar o arquivo.

http://www.4shared.com/zip/eGukOaZ2ce/i2c_MOR_AL__1_.html

Leia e comente, ok?

MOR_AL

test man*~ · 9 de maio de 2015

Muito obrigado... Vou ler antes de dormir hehe!!!!

Hoje eu testei o código na prática, descobri que não é possível colocar breakpoint dentro de interrupção (pelo menos eu não consegui, provavelmente há como ) então fiz o PIC slave mandar todos os ACKS recebidos durante a transmissão para a serial e para a minha surpresa o slave funcionou exatamente como o proteus simulou , a função "i2c_write" sempre retorna o valor 1 (com o PIC no slave mode) independente de qual foi o ACk enviado pelo master...

Dei uma pesquisada e descobri que outros tiveram esse problema:

http://www.ccsinfo.com/forum/viewtopic.php?p=93584

http://www.ccsinfo.com/forum/viewtopic.php?p=60862

havia pesquisado antes e não encontrei coisa alguma mas agora encontrei .

No segundo link o Ttelmah diz para usar o bit R/W do registrador SSPSTAT que é zerado quando a condição NACK é detectada... Isso resolve o problema . Vou ler a parte do MSSP do datasheet e depois vou testar o código novamente...

Muito obrigado pelo link do trabalho mais tarde vou lê-lo.

Após testar o código usando o R/W do SSPASTAT eu posto o resultado aqui para concluir o tópico!

test man*~ · 10 de maio de 2015

Li o seu trabalho, queria ter lido antes de começar a fazer o programa para o DS1307 ...

Uma dúvida; vamos supor um caso de multimestre (M1 e M2) se o M1 está transmitindo o M2 espera uma condição de stop no barramento para assim tentar iniciar uma comunicação, nos casos das figuras 9 e 10 se após a introdução do endereço da palavra (e a condição de stop) o M2 também iniciar uma comunicação pode ser que o M1 perca a arbitrariedade e assim ele não conseguirá ler os dados devendo esperar uma condição de stop (do M2) para reiniciar o procedimento, podendo perder a arbitrariedade novamente (na próxima tentativa) após o envio do endereço (endereço da palavra) e assim por diante...

Por isso não seria melhor ter usado o repeated start? Pois daquela forma o M1 deve (caso haja outros mestres aguardando para se comunicar) ganhar a arbitrariedade 2 vezes consecutivas.

Se for pensar bem você fez apenas para um único mestre então isso não importa né? Sou eu quem está viajando

Gostei bastante da parte IV...

MOR_AL · 11 de maio de 2015

Olha.

Realmente fiz apenas para um mestre.

Não saberia informar com relação a mais de um mestre.

Fiz o trabalho há alguns anos e também não estou mais familiarizado com detalhes.

O capítulo IV contem detalhes importantes sobre como proceder na gravação da EEPROM.

Depois apresento exemplo prático com diversas situações diferentes de gravação. Depois eu leio os dados gravados e comparo com os valores esperados e ao final o LCD mostra o resultado. Se confere aparece no LCD "Teste OK!".

MOR_AL

test man*~ · 11 de maio de 2015

Entendo, obrigado MOR_AL!

Para concluir o tópico. Parece que no modo slave a função "i2c_write" não retorna o valor corretamente, assim deve ser usado o bit R/W do registrador SSPSTAT, esse bit é setado quando o endereço é recebido com o R/W (endereço + R/W) bit 1 e é zerado por uma condição de stop, start OU NACK DO MESTRE (que é o que eu estava querendo).

Essa informação está na Application Note 734 da Microchip.

Com isso agora consigo fazer o slave perceber que o mestre não quer ler mais bytes e ele está funcionando igual ao DS1307 (em termos de sequencia de comunicação).

A função "i2c_isr_state" também parece não funcionar perfeitamente para todos os casos o Ttelmah postou um código mais eficiente (parece ser, não testei... Mas ele faz o que a Application note 734 sugere)... É isso, valeu!