problemillas con la 24c16 y el i2c ( i2c pic16f876 pic16f877 )

es una eprom por i2c, de 2k.

ya me voy enterando con el i2c, pero si la direccion posible es de 8 bites puede aceder a 256 bytes, ¿como se puede aceder a toda la memoria?.

la escritura creo que la domino, pero solo de 0 a ff, (compruebo leyendo memoria con programador t20).

la lectura es mas dudosa. los tests no funcionan en todas las casillas de la eprom,

otra pregunta, leo una posicion, sumo, y vuelvo a escribir en ella, retardo de 10ms, y bucle en sigiente. cuando retarda ¿como debe estar la linea de datos?, entiendo que alta, pero esto solo pasa si uso direcion de dos bytes, si uso una simple (datasek de la 24c16) a veces queda en alto, otras en bajo, y normalmente alternan.

la idea de usar una direcion de 2 bytes la saque de aqui, que es lo que use de guia, parece que esto se usa para una 24c256.

formatting link

formatting link

Reply to
baldo
Loading thread data ...
¿Has leído el data sheet de la 24C16? Lo explica bastante bien. Los bits 3 a 1 del control byte, que Microchip llama B2, B1 y B0, definen en qué bloque de 256 bytes quieres leer o escribir. Así, la dirección queda formada por 11 bits, siendo B2, B1 y B0 los de mayor peso, con lo que puedes acceder a 2k direcciones.
--
Saludos de Jose Manuel Garcia
jose.mgg@terra.es
 Click to see the full signature
Reply to
Pepitof

que astucia, me lei el datase, ya me extraño que pusiese que A1,A2, A3 no se usan, estaba empecinao en que lo que tu llamas Bs eran para distinguir una entre 8 posibles eprom conectadas al bus,

gracias, hizo falta una buena sacudida para que cayese del arbol.

"Pepitof" escribió en el mensaje news: snipped-for-privacy@individual.net...

a
11
Reply to
baldo

Así es como funciona en las de más capacidad, A2, A1 y A0 forman parte de la identificación del chip, y para definir una dirección, después del control byte se envían dos bytes con la dirección a la que quieres acceder.

--
Saludos de Jose Manuel Garcia
jose.mgg@terra.es
 Click to see the full signature
Reply to
Pepitof

otras preguntitas tontas, vamos ver, a un bus i2c le puedes colgar muchos esclavos (incluso muchos maestros), cada esclavo tiene su maricula (direcion), p.e. la 24c16 es 1010xxxñ, pero ¿y si cuelgo varios pic?, como se define la direcion de cada uno, he mirao y no haye registro pa esto,

haber si adivino, esto se hace por sof, despues del start llega un dato, que provoca interrupcion en esclavo, este dato puede y debe interpretarse como direcion del esclavo, la compara por soft, y si no va con el paso de todo y return, si va con el maniobra en consecuencia, ¿es asi?,

en esta direcion ¿el bit 0 tambien ha de significar lectura / escritura?.

tengo claro que el start ystop lo emite el maestro ¿el famoso ackles o como se diga lo emite el esclavo o el maestro?.

¿y si el esclavo no existe o no funciona?, no se cuelga el maestro esperando su respuesta?.

¿ y si le pido que me de el analogico de cierto PORTA,?,, ¿como espera el maestro a completar la lectura?

Reply to
baldo

"baldo" escribió en el mensaje news:ct4jlv$ snipped-for-privacy@cesio.mundo-r.com...

muchos

esto,

Pues no has mirado muy bien. En modo esclavo, la id address del PIC es la que hayas puesto en SSPAD.

Lo puedes hacer por soft activando la interrupción en el stop, o dejar que lo haga el hard, que es lo más lógico, creo yo. No he usado nunca un PIC como esclavo, pero según el data-sheet, si lo hace el hard, y si lo has configurado correctamente (los bits BF y SSPOV deben estar a 0), la secuencia es:

1º. Cuando recibe una secuencia start - control byte - stop, el hard compara el dato con SSPAD. Si no coincide, no hace nada más. 2º. Si el dato recibido coincide con SSPAD, lo pone en SSPBUF. 3º. Activa el bit BF (buffer full). 4º. Envía ACK al I2C. 5º. Activa la bandera SSPIF, y si está habilitada la interrupción del MSSP genera una interrupción.

Si no lo he entendido mal, el bit R/W del control byte recibido es copiado en el bit R/W de SSPSTAT. En esa situación, el hard va leyendo cada dato que recibe, repitiendo los pasos 3º a 5º, hasta recibir un stop, siempre y cuando te encargues de ir leyendo cada nuevo dato y desactivando el bit BF.

El bit R/W no forma parte de la dirección, aunque sí forma parte del control byte. El control byte siempre lo envía el master, y es él quien dice si es una operación de lectura o escritura. El esclavo debe actuar en consecuencia.

Te aconsejo que estudies un poco cómo funciona el protocolo I2C antes de tratar de implementarlo con PICs. Puede ser muy instructivo estudiar el data-sheet de algún dispositivo I2C, como una EEPROM (por ejemplo las

24Cxxx).

como

El ACK lo pone el que está recibiendo datos, independientemente de que sea el maestro o el esclavo.

No, si está bien implementado. Un dispositivo (sea esclavo o maestro) que recibe un dato dirigido a él, debe responder con un ACK inmediatamente. El que envió el dato no espera más que el tiempo correspondiente a un clock, y si no recibe el ACK, considera que hay un time-out, es decir, que el receptor no existe.

el

Es que eso no se hace así. El maestro no puede pedir milagros. En el sistema que te inventes, el maestro debe tener en cuenta cómo funciona el esclavo, y saber cuanto tardará en responder. Pero eso no tiene nada que ver con el ACK. El esclavo tiene que devolver el ACK inmediatamente después de cada byte recibido, aunque luego tarde un rato en enviar los datos de respuesta.

En el ejemplo que pones, lo normal es que el esclavo haga las conversiones periódicamente, y almacene el resultado en su memoria, de forma que cuando el master le pide esos datos, no tiene que ponerse ha hacer una conversión, sino sólo enviar el resultado de la última conversión que hizo.

Otra posibilidad es que el master utilice un comando para decirle al esclavo que haga una conversión, y un tiempo después envíe otro comando para decirle al esclavo que le envíe el resultado de esa conversión.

En fin, te puedes inventar el sistema que quieras.

--
Saludos de Jose Manuel Garcia
jose.mgg@terra.es
 Click to see the full signature
Reply to
Pepitof

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.