i2c multitarefa + interrupçao

[Djalma Toledo Rodrigues]

Todo o processamento deverá estar concluido antes de imprimir.
.

[ze]

deixe eu exercitar minha especialidade em Conclusões Hipotéticas Universais Técnicas ExplicativaS
Que tal...
Pra não piscar o display na hora da comunicação i2c:
Verifique se é possível gravar apenas 1 byte (talvez +) por vez e só comunique “fora” da interrupt. Vai ter o resto do tempo todo pra gravar 1 (ou +) byte antes da próxima interr. Tipo assim:
static bit f; //global
__irq interr() //sua interrupção
{
...
f=1;// “sete” um flag na int
...
}
na func i2c:
i2c_com()
{
...
f=0;
while(!f); //pra garantir que a interr. terminou
...//aqui a func i2c
...//que sua função seja rápida e não encontre a próxima interrupt!!!
}
fica meio que sincronizado a int e a func
abç

[andre_luis]

andre_teprom

qual seria uma soluçao viavel ???
fazer i2c por software para separar os dispositivos

São 2 problemas distintos.

1) No meu caso, não encontrei razão lógica para que o uC não funcionasse com I2C por HW ( pelo menos na versão do CCS que usei ).

2) O caso da separação dos sinais ( que necessariamente deve ser feita ), uma vez que voce pode implementar o I2C por SW, voce pode facilmente criar suas funções de manipulação do protocolo, sem utilizar as funções nativas da API do CCS. Voce teria 2 alternativas :
a ) Dentro de cada I2CStart(), I2CStop(), etc..., adicionei if's que escolheriam o pino adequado a ser usado.
b ) Colocar diretivas de compilação no programa que mudassem a pinagem, dependendo de que dispositivo fosse acessado. O código ficaria mais limpo nesse caso.


De qualquer modo, voce poderia testar os dispositivos isoladamente, retirando o RTC ( mantendo a MEM ), e depois o contrário; retirando a MEM ( mantendo o RTC ). Já fiz isso, e comprovou que dispositivos com protocolos de comunicação diferentes não podem estar no mesmo barramento físico.

+++

[cristian]

vou fazer estes testes aqui

[Djalma Toledo Rodrigues]

... Já fiz isso, e comprovou que dispositivos com protocolos de comunicação diferentes não podem estar no mesmo barramento físico. +++

Mesmo quando possuem endereço ?

No Presente caso, MEM e RTC não possuem endereço ?
.

[cristian]

acho tb que deveria viver em paz pois cada um teria seu endereço

ex se mando o endereço da memoria tipo 0x01 o rtc nao se manisfesta ate acaba a comunicaçaõ com a memoria e depois esperar q seu endereço seja enviado

[andre_luis]

No Presente caso, MEM e RTC não possuem endereço ?
.

Sim...só que como mencionei antes, o endereçamento de ambos é diferente. Veja um trecho do programa que voce postou :

Código: Selecionar todos

BYTE read_ext_eeprom(long int address) {
{
i2c_start();
i2c_write(0xa0);
i2c_write(address>>Cool;
i2c_write(address);
i2c_start();
...
}

void ds1307_get_time(BYTE &hr, BYTE &min, BYTE &sec)
{
i2c_start();
i2c_write(0xD0);
i2c_write(0x00); 
i2c_start();
...
}

Repare que para acessar a MEM, voce precisa enviar um byte de endereço a mais que para o RTC.
Esse detalhe é suficiente para avacalhar com a comunicação.

Voce fez o teste que sugeri ?
( testar isoladamente o acesso a cada dispositivo )

+++

[cristian]

fiz e ficou bom


mas o problema tb é intermitente com os 2 no circuito entao nao tenho certeza se ficou bom com 1 dispositivo apenas ou se deu sorte

[cristian]

resolvir trocar o DS1307 por 1302 pois este é serial

vamos ver se acaba com o problema de gravaçao

agora sacanagem isso

entao teria q ter um micro com 2 i2c

e toda esta propaganda q I2C pode ligar varios disposistivos e pode ter 2 masters ...bla bla bla ...nao suporta 2 dispositivos um de 8 e 16 bits

[vtrx]

Cristian,não sei no seu caso,mas tenho um 16F628A usando na mesma linha I2C um DS1307,DS1620 e uma Eeprom normalmente.
Sobre o 'byte a mais' não atrapalha em nada,pois o outro dispositivo conectado na mesma linha esta em alta impedancia pois ele precisa de um bit de start para processar o proximo byte,enquanto não tiver o stop bit ou a comunicação for interrompida ele não processa os bytes na linha.
Alem do mais,dependendo da aplicação,pode-se ler os endereços da Eeprom sequencialmente apenas enviando 'ack' seguido.

[cristian]

teve 2 vezes q a hora foi alterada depois de salvar na eeprom


como nao possa arriscar agora vou trocar mas seria bom uma solução pra isso

[andre_luis]

Cristian,

Voce teria de fazer poucas modificações no seu código, e precisaria de apenas mais um pino, se seguisse as sugestoes da dica 2) que postei anteriormente.

+++

[vtrx]

Cristian,tem como vc postar o esquema do Hardware?

[cristian]

so hoje consegui o DS1302

mas em 40 relatorios 3 sairam errados justamente na data e hora

mas um deles foi gravado o erro depois tipo assim

no ticket 6 a hora foi mudada bem depois do ticket 10

o interessante é que no ticket a data e hora sai normal mas no relatorio nao e as vezes este erro é na hora da gravaçao

alguma sugestao

[cristian]

galera troquei o ds1307 por ds1302 assim a comunicação i2C fica so com a memoria mas ainda assim tenho erros na impressao do relatorio

ja nao sei o que fazer o cliente esta furiioso

qual um forma de descobrir o erro

fiz um teste para que depois da gravaçao ele ler a memoria e enviasse pele serial mas assim sai certo mas o relatorio nao

estou desconficando que algo esta alterando a memroia