Emular por software el protocolo I2C

[PHLAKO]

Quien ha hecho una aplicacion de protocolo I2C, necesito una mano, ya que no he podido hacerlo, necesito implementarlo en una 16F84, el porque no uso una 16F873 u otra que lo tenga por hardware, es porque cuando use una PIC mas grande, tendré que usar el protocolo SPI con otro dispositivo ademas del I2C y como sabrán, ocupan los mismos pines, tengo problemas en cuanto al envío y recepción de los AKCNOWLEDGE y la puesta en I/O del pic ops:
programo en ASM, cualquier ayuda la agradecería mucho.

 

[leo_programer]

En este enlace https://www.forosdeelectronica.com/f24/pic-16f84-memorias-24lcxx-i2c-2835/, yo ya había posteado algo que de pronto le sirva, en este mismo foro, mas sin embargo no lo he probado, mira a ver si le sirve, es lo mas que puedo hacer, cualquier cosa me avisa, cuídese...

 

[PHLAKO]

Leo, te agradezco la ayuda, pero el programa al que estas vinculando, es para escribir en la eeprom interna del micro, los 64bytes de memo interna me queda muy pequeño, lo que necesito es realizar el programa que pueda "EMULAR" el puerto I2C, ya que no esta implementado y poder agregar una eeprom de 16KBytes, ayer estuve trabajando en ello y, hoy o mañana, le doy el toque final, gracias de todas maneras

chaos

 

[leo_programer]

phlako, en el fig2-24.asm hay algunas subrutinas de i2c por software, esta el bit de start, el de stop, la recepcion y la transmision de datos, el resto si son de ejemplo de eeprom interna del micro, revisa bien y vera que si esta, me avisa si sirve para yo probarlo, ya que me gusta mas por hardware, cuidese...

 

[PHLAKO]

OK, le echare una mirada, gracias

ahí te cuento como me fue

chaos

 

[maunix]

Yo que tu comienzo por leer bien la especificación de Phillips acerca del i2c.

En su página, tienes acceso gratuito a ella.

Es imprescindible, a mi modo de ver , el leer eso antes de querer implementar el i2c por software.

Saludos

 

[PHLAKO]

mira ya da muestras de estar vivo, se me corre un bit, me he cabezeado harto y no encuentro el problem, la especoficacion tecnica esta en el PDF del micro y en el PDF del 24LCxx, nada del otro mundo, pero algo estoy haciendo mal....aver si mañana lo saco

chaos

 

[PHLAKO]

phlako, en el fig2-24.asm hay algunas subrutinas de i2c por software, esta el bit de start, el de stop, la recepcion y la transmision de datos, el resto si son de ejemplo de eeprom interna del micro, revisa bien y vera que si esta, me avisa si sirve para yo probarlo, ya que me gusta mas por hardware, cuidese...

Hola, Leo, mira respecto al programa que binculaste, no lo pase al micro porque creo que hay cosas en el que me hacen dudar del funcionamiento, entonces para estar modificando ese programa, mejor gasto las energias en el mio, me explico:

veo que realizan el cambio del puerto como entrada o salida en los TRIS y luego cambian niveles de modo BSF PORT, esto es redundante, al poner el pin como ENTRADA, dejas en alta impedancia dicho pin, como existe una resistencia PULL-UP, automaticamente la logica en ese pin es "1", al configurar el pin como salida, este estado pasa de "1" a "0", por lo tanto no es necesario y ala vez incorrecto el seteo del pin como I/O y despues escribirlo, ya que si quieres sacar un cero y seteas el pin como salida y despues escribirlo con un "0" tendras una transicion de "1" a "0"...........estas transiciones pueden provocar errores al ser detectadas por el esclavo

eso, en este momento recibo 7 bits bien, osea me desplazo un bit.........la idea de hacerlo por software es liberar los pines que estan destibnados para I2C y utilizarlos pra la comunicacion SPI

chaos

 

[maunix]

la idea de hacerlo por software es liberar los pines que estan destibnados para I2C y utilizarlos pra la comunicacion SPI

PHLAKO, no es que me quiera meter ni decirte qué hacer pero, ¿has considerado hacer al revés?

Es decir usar el I2C por hardware y ¿el SPI hacerlo por software?

El SPI es muchísimo más facil de implementar por software.

Como te dije hace unos días, el i2c no es tan simple como parece. El SPI sí es tan simple como parece.

 

[PHLAKO]

la idea de hacerlo por software es liberar los pines que estan destibnados para I2C y utilizarlos pra la comunicacion SPI

PHLAKO, no es que me quiera meter ni decirte qué hacer pero, ¿has considerado hacer al revés?

Es decir usar el I2C por hardware y ¿el SPI hacerlo por software?

El SPI es muchísimo más facil de implementar por software.

Como te dije hace unos días, el i2c no es tan simple como parece. El SPI sí es tan simple como parece.

Cumpa, todas las opiniones, aportes y criticas constructivas, siempre seran bien recibidas.....y SI he considerado hacerlo al reves, pero me parece un buen desafio hacer el I2C por soft, como primera instancia ya que al hacerlo andar por el puerto destinado a I2C (hardware)me adentre en el protocolo, entonces como ya estaba entendiendo bien el tema, quiero hacer la libreria por software, antes de que se me olvide el funcionamiento , terminado este proyecto(CNC)en el que estoy trabajando, quiero subir un peldaño o dos, migrando a la familia 18Fxxxx y a programacion de alto nivel como lo es "C", antes de eso, deseo tener las librerias claritas y archivaditas

volviendo al tema del I2C por soft, la gran razon, ademas de lo anterior, es que tengo un proyecto en mente que me obliga a comunicarme a traves de uan 16F84 con una EEPROM, por eso lo porfiado en cuanto a no emular el SPI
Ojala ubiese mas gente haciendo esto, para avanzar mas rapido


salu2

chaos

 

[maunix]

antes de eso, deseo tener las librerias claritas y archivaditas

Je, si las quieres archivar para luego usarlas en los 18F , te tengo malas noticias. Deberas cambiar unas cuantas cosas. Un i2c por software requiere un control interesante con timers o con bucles de demora por instrucciones los cuales deberás modificar al pasarte de familia.

Si lo quieres, lo puedes pensar desde otro punto de vista. Que lo quieres hacer porque quieres aprender a hacerlo, pero la reutilización (sin cambios) es casi un "no" en los 18F. A lo que voy es que eso de "libreria clara y archivada" es un concepto muy aplicable en las PC pero en los microcontroladores, lamentablemente cuesta elaborar.

volviendo al tema del I2C por soft, la gran razon, ademas de lo anterior, es que tengo un proyecto en mente que me obliga a comunicarme a traves de uan 16F84 con una EEPROM, por eso lo porfiado en cuanto a no emular el SPI

Sí, cada cual tiene sus razones. Otra razón podría ser incluso que lo haces porque te gusta.

Tampoco veo otras razones para las cuales hacer un i2c por soft. No veo lo que tu ves, tampoco estoy en tu pellejo jeje ni se que PICs puedes conseguir, pero el 16F84 le queda chico a un 16F72 y éste último no solo que vale casi la mitad sino que tiene i2c por hardware.

Ojala ubiese mas gente haciendo esto, para avanzar mas rapido

La razón es que en los compiladores en C del mercado ya vienen estas rutinas hechas por software.

Pocos programamos en ensamblador (de hecho en los 18F yo casi que programo todo en C aunque en los 16F si lo hago) y es una tendencia en aumento.

Esta y lo que te expuse en el primer párrafo , son en mi opinión , la principal causa por la cual te encuentras "solo" o "casi solo" en tu proyecto

Saludos

 

[PHLAKO]

Cumpa, tengo muy claro que no es compatible la libreria del 16 con la 18, aparte teniendo mas instrucciones, se ahorraria espacio. Me referia mas bien al hecho de conocer casi en su totalidad los recursos de las 16F antes de pasar a la 18, en el fondo tener bajo la manga la posibilidad de sacar un proyecto rapido con 16, si por tiempo no es posible implementarlo en la 18 ya que tengo que tener un training para ser tan agudo como lo soy con la serie 16.......ahora la mayor razon del cambio es la posibiliad de debugger existente en los 18, que a la hora de analizar problemas ahorra 2 semanas de tiempo, las cuales he estado "perdiendo" con el 16
creo saber cual es el problema de mi codigo, espero mañana contarte que ya lo solucione

salu2
chaos

 

[maunix]

ahora la mayor razon del cambio es la posibiliad de debugger existente en los 18, que a la hora de analizar problemas ahorra 2 semanas de tiempo, las cuales he estado "perdiendo" con el 16

Muchos 16F también tienen posibilidad de debugging... con un ICD o compatible.

Saludos

 

[PHLAKO]

list, programa funcionando y pasando pruebas de rigor

chaos

 

[maunix]

list, programa funcionando y pasando pruebas de rigor

chaos

Enhorabuena!!!

Me alegro que lo estes haciendo funcionar

Saludos

 

[PHLAKO]

me di cuenta del error que estaba cometiendo(mi ingles no es muy bueno) al ver las notas de aplicacion de microchip, donde muestra claramente los flancos de subida y bajada del reloj y de la data. Mi problema era en la recepción y no en el envio, puesto que lograba direccionar bien el dispositivo, por lo tanto el problema era muy puntual.

chaos

 

[nutriax]

puedes postear el codigo asi todos los que tengan inconvenientes pueden sortear ese obstaculo? ami me esta pasando lo mismo necesito el spi y el i2c...

 

[nutriax]

estas funciones no las trae el ccs? (digo el i2c por soft)

 

[zagoaristides]

que petes!!! no postean lo que logran solucionar!

 

[lubeck]

que petes!!! no postean lo que logran solucionar!

normalmente nadie lo hace, y si lo solucionas tu probablemente tampoco lo hagas..


no se realemte cual sea el problema o el tema de este tema (valga la redundancia) pero en proteus hay una herramienta que se llama SPYi2C y SPI no se que para ver lo que sucede con esos protocolos espero te sirva....