pic16f877a

[tiagobarbosa94]

boas, isto é assim, fiz um codigo em assembly para trabalhar com o I2C e o que se passa é o seguinte, o meu codigo é para trabalhar com uma memoria i2c (24c02c), e 1º fiz um codigo para escrever numa posição da memoria e escrevi 0x0f. Depois fiz um codigo para ler a posição onde escrevi e mandei o resultado da leitura para o portd e no portd estava 0x0f o que é bom.

so que depois fiz o seguinte: escrevi um dado diferente tipo 0x20, 0x01 e logo de seguida lei-o a memoria e ele encrava numa rotina. fiz a seguinte experiencia: 1º fiz um program para  so escrever 0x30 numa dada posição de memoria, depois so fiz um program que le-se nessa posição de memoria e manda-se o resultado p/portd e la apareceu 0x30.

conclusao se trabalho com as rotinas de escrita e depois leitura separadamente ele funcioona bem, mas se utilizo a rotina de escrever e logo de seguida utilizo a rotina de leitura ele encrava na rotina de leitura, mais precisamente logo depois de eu dar o startbit, e quando mando o bit de controle da 24c02c ele encrava nessa rotina porque a memoria está sempre a mandar um ack (ack este que me diz para repetir , porque ouve problemas no ultimo byte enviado) e entao ele reenvia o ultimo byte e a memoria torna a mandar um ack que me manda repetir o ultimo byte e nao sai disto.

alguem tem ideia do que possa causar isto? alguem ja trabalhou com esta pic e com esta memoria? slguem tem codigo (c ou assembly) ou um tuturial para isto para que eu possa comparar com o codigo que fiz e tirar conclusões?

agradeço ajuda urgente!

[Singularity]

Boas

Não sei se vai a tempo mas...
Faz algum tempo que trabalhei com memorias 24LC512. Se não me engano é exactamente o mesmo que as que estás a usar só que com 64Kbytes de espaço. Infelizmente não posso enviar o código uma vez que a aplicação em questão foi desenvolvida a nível profissional e o código pertence à empresa onde trabalho.

De qualquer modo verifica se estás a terminar bem a sequência de escrita. Nomeadamente porque existe um modo de escrever um unico byte e um modo de escrever uma sequencia de byte (até no maximo o tamanho da pagina da memória ou até ao fim da página actual).

Provavelmente a eEprom está a espera de mais bytes por algum motivo.
Eu utilizei na altura o MCC18 (uma vez que era um pic18f) e usei a biblioteca I2C da microchip. Tudo funcionou bem.
De qualquer forma por vezes algo acontecia no arranque do sistema e a eEprom não comunicava correctamente (era um efeito raro que nunca consegui realmente entender porque acontecia, cheguei a pensar que era problema relacionado com o slew rate da alimentação - Feito um reset ao sistema tudo voltava a funcionar de novo - , mas mais tarde associei a problemas na soldadura do smd da eEprom (excesso de calor) uma vez que isto só acontecia em algumas placas - foi feita montagem em série de mais de uma centena desses dispositivos.
Como o teu problema se repete sempre presumo que não seja o mesmo que tive (alias o problema que tinha era aleatório (aparentemente) e relativamente raro 1 a 2% dos arranques a frio)

Se ainda valer a pena diz qualquer coisa que posso ir confirmar ao código que usei (apesar de não to poder passar como já expliquei por motivos de licenciamento uma vez que era e é uma aplicação comercial).

[Njay]

Também já trabalhei com uns quantos dispositivos I2C e já fiz drivers, mas já lá vai e às vezes cada dispositivo tem as suas pequenas esquisitices. A única coisa que me lembro é que nem todos os dispositivos I2C suportam transações read-after-write. Verifica a datasheet do teu dispositivo. Também há tempos de reacção que é preciso respeitar e variam consoante a situação. Mas de certeza que encontras código I2C na net para PICs...

[asena]

conclusao se trabalho com as rotinas de escrita e depois leitura separadamente ele funcioona bem, mas se utilizo a rotina de escrever e logo de seguida utilizo a rotina de leitura ele encrava na rotina de leitura, mais precisamente logo depois de eu dar o startbit, e quando mando o bit de controle da 24c02c ele encrava nessa rotina porque a memoria está sempre a mandar um ack (ack este que me diz para repetir , porque ouve problemas no ultimo byte enviado) e entao ele reenvia o ultimo byte e a memoria torna a mandar um ack que me manda repetir o ultimo byte e nao sai disto.

Já resolveste esta questão ?


Essas já me aconteceram.

Resolvi tratando das comunicações separadamente. Sempre que faço uma leitura, gero logo um NOT-ACK e um STOP. Assim, posso recomeçar a síncronização.

O chip ESCRAVO tem que detectar que o MESTRE já não quer falar com ele. É muito importante. Se não for assim, o ESCRAVO vai estar constantemente a deitar a linha abaixo com envios de dados.


Pode atrasar em milisegundos as comunicações, mas eu descobri que é sempre vantajoso comunicar por blocos: START-DADOS-NOTACK-STOP, START-DADOS-NOTACK-STOP.

Isto quando se trata de um só byte a ler. Se forem varios a ler ou escrever, faço: START-DADOS x N (com ACK em todos) -NOTACK no ultimo - STOP.


Fiz-me entender? às vezes é dificil explicar isto por escrito 

[tiagobarbosa94]

Também já trabalhei com uns quantos dispositivos I2C e já fiz drivers, mas já lá vai e às vezes cada dispositivo tem as suas pequenas esquisitices. A única coisa que me lembro é que nem todos os dispositivos I2C suportam transações read-after-write. Verifica a datasheet do teu dispositivo. Também há tempos de reacção que é preciso respeitar e variam consoante a situação. Mas de certeza que encontras código I2C na net para PICs...

nao leves a mal mas eu gosto de fazer os meus software, porque so assim é que realmente eu consigo aprender como tudo funciona, ma obrigado pela ajuda...

[tiagobarbosa94]

conclusao se trabalho com as rotinas de escrita e depois leitura separadamente ele funcioona bem, mas se utilizo a rotina de escrever e logo de seguida utilizo a rotina de leitura ele encrava na rotina de leitura, mais precisamente logo depois de eu dar o startbit, e quando mando o bit de controle da 24c02c ele encrava nessa rotina porque a memoria está sempre a mandar um ack (ack este que me diz para repetir , porque ouve problemas no ultimo byte enviado) e entao ele reenvia o ultimo byte e a memoria torna a mandar um ack que me manda repetir o ultimo byte e nao sai disto.

sim sim é explicito no que diz, por uns tempos deixei isto de lado, mas agora vou pegar nisto outra vez e vou ver se consigo trabalhar com estas memorias, dá muito gweito, acho que vou começar por fazer um coigo novo tudo de raiz, por vezes é um registo mal inicilaizado o ualterado individamente e causa coisas que ninguem imagina, ........   depois quando conseguir trabalhar com este tipo de memorias posto aqui o meu codigo para quem queira aprender posa trar ideias.....  obrigaod pelas dicas.

Já resolveste esta questão ?


Essas já me aconteceram.

Resolvi tratando das comunicações separadamente. Sempre que faço uma leitura, gero logo um NOT-ACK e um STOP. Assim, posso recomeçar a síncronização.

O chip ESCRAVO tem que detectar que o MESTRE já não quer falar com ele. É muito importante. Se não for assim, o ESCRAVO vai estar constantemente a deitar a linha abaixo com envios de dados.


Pode atrasar em milisegundos as comunicações, mas eu descobri que é sempre vantajoso comunicar por blocos: START-DADOS-NOTACK-STOP, START-DADOS-NOTACK-STOP.

Isto quando se trata de um só byte a ler. Se forem varios a ler ou escrever, faço: START-DADOS x N (com ACK em todos) -NOTACK no ultimo - STOP.


Fiz-me entender? às vezes é dificil explicar isto por escrito 

[Njay]

nao leves a mal mas eu gosto de fazer os meus software, porque so assim é que realmente eu consigo aprender como tudo funciona, ma obrigado pela ajuda...

Sim, mas não quer dizer que vás usar o driver feito. Pode servir apenas para dares uma olhadela e ver como é que outros fizeram, comparar o que já tens.

[Singularity]

Já resolveste esta questão ?


Essas já me aconteceram.

Resolvi tratando das comunicações separadamente. Sempre que faço uma leitura, gero logo um NOT-ACK e um STOP. Assim, posso recomeçar a síncronização.

O chip ESCRAVO tem que detectar que o MESTRE já não quer falar com ele. É muito importante. Se não for assim, o ESCRAVO vai estar constantemente a deitar a linha abaixo com envios de dados.


Pode atrasar em milisegundos as comunicações, mas eu descobri que é sempre vantajoso comunicar por blocos: START-DADOS-NOTACK-STOP, START-DADOS-NOTACK-STOP.

Isto quando se trata de um só byte a ler. Se forem varios a ler ou escrever, faço: START-DADOS x N (com ACK em todos) -NOTACK no ultimo - STOP.


Fiz-me entender? às vezes é dificil explicar isto por escrito 

Isso aconteceu-te com uns PLL de uns modulos para TV-A (Televisão de radio-amador).

quanto à ideia que sugeriram de ires confirmar com as bibliotecas da propria microchip, essas bibliotecas são em C (pelo menos as q usei) uma vez que o teu programa é em assembler terias q escrever tu o código...

De qualquer modo eu sou da opinião que não vale a pena re-inventar a roda... o teu programa terá de certeza mtas coisas unicas de tua auturia mesmo que retires ideias do q outros fizeram. E não seria uma cópia uma vez que até a linguagem é diferente...

[tiagobarbosa94]

Já resolveste esta questão ?


Essas já me aconteceram.

Resolvi tratando das comunicações separadamente. Sempre que faço uma leitura, gero logo um NOT-ACK e um STOP. Assim, posso recomeçar a síncronização.

O chip ESCRAVO tem que detectar que o MESTRE já não quer falar com ele. É muito importante. Se não for assim, o ESCRAVO vai estar constantemente a deitar a linha abaixo com envios de dados.


Pode atrasar em milisegundos as comunicações, mas eu descobri que é sempre vantajoso comunicar por blocos: START-DADOS-NOTACK-STOP, START-DADOS-NOTACK-STOP.

Isto quando se trata de um só byte a ler. Se forem varios a ler ou escrever, faço: START-DADOS x N (com ACK em todos) -NOTACK no ultimo - STOP.


Fiz-me entender? às vezes é dificil explicar isto por escrito 

Isso aconteceu-te com uns PLL de uns modulos para TV-A (Televisão de radio-amador).

quanto à ideia que sugeriram de ires confirmar com as bibliotecas da propria microchip, essas bibliotecas são em C (pelo menos as q usei) uma vez que o teu programa é em assembler terias q escrever tu o código...

De qualquer modo eu sou da opinião que não vale a pena re-inventar a roda... o teu programa terá de certeza mtas coisas unicas de tua auturia mesmo que retires ideias do q outros fizeram. E não seria uma cópia uma vez que até a linguagem é diferente...

nao, a minha ideia de fazer tudo é apenas compreender como tudo funciona, eu gosto de saber os pormenores todos.......................

[asena]

Isso aconteceu-te com uns PLL de uns modulos para TV-A (Televisão de radio-amador).

... "estes" radioamadores tresandam à distância........ hihiih 

73 !