Ethernet+Can bus

[habasconpan]

Hola, antes de nada quiero decir que no soy muy experto en el tema de microcontroladores y quiz�s no me explique bien.

Mi problema es que tengo una placa para la conexi�n a ethernet PICDEM.NET de microchip, y mi intenci�n es utilizar las caracter�sticas de la placa (ethernet, http, etc) junto con el protocolo CAN.

Estoy utilizando el c�digo de www.iosoft.co.uk y yo hab�a pensado en comunicar el PICDEM con un controlador para el bus CAN como el MCP2515. El MCP2515 se comunica con los PICs a trav�s del protocolo SPI, pero el PICDEM utiliza el protocolo I2C para comunicarse con la memoria e2rom que contiene la p�gina web del servidor.

Y claro, yo no soy muy experto en el tema, pero supongo que no se "llevar�an bien" los protocolos trabajando simultaneamente. Supongo que, en principio, el microcontrolador (tengo el PIC18F452) va bastante justo con el protocolo TCP/IP para que encima le meta un dispositivo SPI adicional.

Mi pregunta es si podr�a hacer esta comunicaci�n conjunta utilizando el SPI para el controlador CAN y el I2C para la memoria E2ROM.

Si no fuera posible, hab�a pensado en comunicar el controlador CAN con un PIC a trav�s de SPI y, �ste PIC comunicarlo con el de la placa PICDEM sin inferir en la comunicaci�n con la E2ROM. Me he fijado en que hay varias patillas libres que podr�a utilizar para comunicar los dos PICs. Yo no entiendo de comunicaciones entre PICs, hasta ahora hab�a utilizado el RS232 o el SPI, as� que me gustar�a saber como comunicar dos PICs mediante varias patillas sin esta funci�n y de la forma m�s eficiente posible.

Despu�s de este rollo seguro que mas de uno se ha quedao , bueno, haber si me podeis hechar una mano. Un saludo.  

[fenix_jn]

La solucion q t keda es implementar las rutinas SPI e I2C de forma q una de ellas use el SSP (no se si estas usando un PIC con capacidades d transmision serial autonoma) y el otro protocolo q t keda por fuera implementarlo via soft, en el foro hay una buena coleccion de rutinas en ASM. C y PBP poseen funciones ya integradas q NO usan el modulo SSP del PIC (es decir son rutinas ya escritas, tu solo pasas parametros como datos, puertos y configuracion, este establece de q forma se comportara la funcion) y q t permiten canalizar por cualkiera de sus patillas las funciones I2C y SPI (configuradas apropiadamente)

[habasconpan]

No sabia que había código de emulación del SPI, eso me vendría bien, voy a buscar por el foro. Muchas gracias, de verdad, te debo una cerveza bien fria.

[riouga]

No ontendí nada de lo que esplicaste que querías hacer, pero creo que podrías utilizar el USART del pic en modo sincrono para la comunicación i2c.

No se si antniof estará muy de acuerdo, no se, tampoco estoy muy seguro pq el USART solo lo utilizo para comunicarme con elpc en modo asincrono, asi que no me hagas mucho caso.

Saludos.

[riouga]

Fenix_in que me equivoque de nombre al decir si iba a estar de acuerdo.

[habasconpan]

Sabía que no se me entendería bien. Me explicaré las veces que haga falta, gracias por vuestra ayuda

Me preguntas porqué no utilizo el i2c... pues el i2c ya se utiliza para comunicarse con una memoria externa. Sé que se pueden colocar unas resistencias para colocar mas dispositivos junto a la memoria, pero en este caso no es exactamente una comunicación i2c... lo que quiero hacer es una comunicación SPI con un dispositivo externo.

Es decir, el microcontrolador que estoy programando se comunica con una memoria externa por i2c y además necesito comunicarlo por SPI a otro dispositivo. El SPI utiliza las mismas patillas (y alguna mas...) que el i2c y de forma distinta.

Aún así, puede que puedan estar conjuntamente ambos protocolos (SPI e i2c) pero las pocas pruebas que he hecho (sin las resistencias mencionadas) no me han dejado hacer nada y lo he dado por perdido puesto necesito terminar esto lo antes posible.

Al final, voy a optar por utilizar dos microcontroladores: uno para comunicarse con el dispositivo externo por SPI y el microcontrolador principal (el que tengo conectado a la memoria externa y a la red ethernet).

Así pues, voy a pasar de comunicarme al dispositivo directamente, a comunicarme poniendo como interlocutor otro microcontrolador. Esto quizás no sea muy adecuado, pero es lo mas rápido y en mi caso lo mas importante es el tiempo, mas que el numero de pics utilizados. la comunicación entre PICs la haré por RS232, que sí que lo puedo utilizar en el microcontrolador principal.

Ahora me hace falta un buen código que utilice comunicación serie entre ambos pics para recibir y enviar datos con interrupciones, etc...


PD:
La mejor solución es la que me propone fenix_jn, la de emular con las patillas que tenga libres el protocolo SPI, pero no he encontrado nada por el foro... no me sale nada en la búsqueda, tampoco he encontrado nada por internet... no se me da bien esto de buscar y lo he dao por perdido. Si tuviérais algo relacionado con la emulacion SPI os agradecería que me lo dijérais, mientras tanto lo haré con el rs232 y un pic adicional.

Gracias. Un saludo.

[fenix_jn]

OK tengo una aplicacion q usa el I2C emulado, es decir, t kedaria hacer lo contrario, pasar el SPI al USART y emular el I2C. Tb lo he estado buscando pero parece q ya nadie programa para emular protocolos, ahora se usan los modulos USART/MSSP.

[habasconpan]

Escrito originalmente por fenix_jnOK tengo una aplicacion q usa el I2C emulado, es decir, t kedaria hacer lo contrario, pasar el SPI al USART y emular el I2C. Tb lo he estado buscando pero parece q ya nadie programa para emular protocolos, ahora se usan los modulos USART/MSSP.

Gracias por tu ayuda. No podría emular el I2C porque la memoria externa viene implementada ya en la placa, es una placa de pruebas de microchip, para el SPI si puedo utilizar los pines que haya libres y emular el protocolo, pero para I2c no, tendría que hacer la placa por mi cuenta. De todas formas, a lo mejor me ayudaría ese protocolo I2c para crear el de SPI.

Ahora mismo estoy pensando en utilizar la comunicación serie para comunicar ambos PICs y estoy viendo varios ejemplos como el de la web de palaconcurso y el ejemplo EX_CRC del compilador CCS, y estoy cojiendo ideas de ambos. Aun así, si tuvierais alguna libreria para esta comunicación os agradecería toda la información posible ya que me interesa un código sencillo y muy robusto.
En estos momentos me estoy peleando con la interrupción rda y su implementación en el 18F452...

Un saludo...

[fenix_jn]

Bueno, pero una pregunta? en q lenguaje programas?, si en C esos protocolos ya estan instalados como procedimientos, lo unico q t kedaria seria configurar los pines y mandar los datos, otra opcion q estado pensando es usar las librerias de C en SPI e I2C, compilar un miniprograma q haga una escritura en SPI, una escritura en I2C, una lectura en SPI y otra en I2C y crear el hex a partir d eso. Luego, con desassembler (como el q trae integrado el ICProg) obtener las rutinas en formato ASM, asi tal vez podriamos publicar d una vez las rutinas de escritura y lectura en ASM de I2C y SPI.

[habasconpan]

Trabajo en C. No sabia que seleccionando cualquier patilla funcionaría. Soy un inutil con esto. Lo que me dices del asm no se yo si dabré hacerlo, si quieres te puedo mandar un hex con una rutina de escritura y lectura en spi

[fenix_jn]

No, la idea es escribir las rutinas en C usando CCS y compilar esas lineas, por supuesto esas no llegaran a 5 (espero), luego usar el ICProg (su desensamblandor) y recuperar el codigo del .hex en el formato ASM, lo he hecho con un display LCD y me sirvio para detectar q estaba mal, al final corregi la rutina en ASM y MPASM me genero el hex y a grabar en el PIC.


Oops, no habia leido bien el post antes de responder.

Ok mejor todavia porq no habria q desASM ni nada, el CCS trae rutinas preescritas q ejecutan funciones del MSSP/USART y funcionan sin usar los modulos del PIC (y sin usar las mismas patillas, lo cual nos da casi todo el PIC para implementar la comunicacion en cualquier pin q se desee), entonces en tu caso seria usar el SPI del modulo del PIC (configurando los registros y todo lo demas) y el I2C dejarlo para las funciones de CCS

[ivangc]

Hola a todos:

Tengo un problema similar al que se está tratando.

Necesito 2 puertos serie para un proyecto que estoy realizando y la placa de pruebas que tengo que usar, ADUC812Qs, tiene un solo puerto. Uno lo necesito para conectar a la placa un modulo RFID ( nivel TTL )y el otro para conectar la placa al PC(RS232). El micro posee interfaz i2c pero no se si se puede emular una UART a partir de este.

Una solución que se me ocurrió fue emular una UART muestreando un pin de un puerto de propósito general pero no me funciona. La simulación me rula perfectamente pero cuando hago la prueba real, el micro no recibe.

Alguien sabe como puedo solucionar este problema?

Muchas gracias por vuestra ayuda.

[Sasián]

Buenas Ivan:
si no necesitas operar con los puertos simultaneamente puedes multiplexarlos, funciona de maravilla y dispones de las ventajas de usar la UART interna del micro.
mira http://www.maxim-ic.com/appnotes.cfm/appnote_number/588 quizás te ayude.

saludos