Emular por software el protocolo I2C

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, 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
 
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...
 
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
 
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 :)
 
leo_programer dijo:
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 :)
 
PHLAKO dijo:
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. :D
 
maunix dijo:
PHLAKO dijo:
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. :D

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 :rolleyes:

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 :eek:
Ojala ubiese mas gente haciendo esto, para avanzar mas rapido :)


salu2 :)

chaos :)
 
PHLAKO dijo:
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.

PHLAKO dijo:
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 :eek:
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.

PHLAKO dijo:
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
 
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 :)
 
PHLAKO dijo:
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
 
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 :)
 
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....
 
Atrás
Arriba