Buenas noches, es la primera vez que escribo, espero estar en el foro correcto. Quiero armar un circuito con un PIC y conectarlo a una red ethernet para poder manejar las entradas y salidas, encender y apagar dispositivos y leer las entradas analógicas y digitales.
El tema es que lo quiero hacer con componentes que se consigan en Argentina y con integrados y micros DIP. No dispongo de la tecnología como para armar placas y soldar micros SMD como los
PIC18F97J60 ni los controladores ethernet como los
CP220. Tampoco quiero usar nada armado como el
CP2201EK porque no se consiguen y si se consiguieran se me complica con el programador. Mi idea es usar un PIC "común" como el 16F877 o el 18F2550 pero les tengo que agregar el módulo de ethernet. Y aquí vienen las preguntas a ver que opinan.
Lo primero que pensé fue en usar el
ENC28J60, es DIP, se consigue, pero lo que no se consigue es el conector RJ45 con las bobinas (o las bobinas solas). Buscando, encontré que en
McElectronics los venden, pero con lo que pasó
aquí me da un poco de miedito comprar ahí. Entonces, a una placa PCI con el chip RTL8139 le saqué el chip y conecté la salida y entrada del trafo de la placa (la parte que iba al Tx y Rx del RTL8139) al ENC28J60 y funcionó. Lo único que tuve que cambiar fue el resistor de RBIAS a 1K8, y es lógico porque el trafo del RTL8139 no está diseñado para el ENC28J60. El problema se puede dar cuando haya un cable largo, hay mas ruido eléctrico y va a ser mas sensible a las interferencias. ¿Alguien sabe si hay alguna placa que se consiga que tenga el trafo mas o menos compatible?.
Después me dije, si el trafo que viene con las placas PCI es para el RTL8139, ¿porqué no manejar a ese integrado?. El problema es que el bus PCI es de 32 bits multiplexado, y el RTL8139 maneja las transferencias de datos con DMA. Pero en la hoja de datos del RTL dice que el clock del bus PCI puede ser de 0 a 33MHz. Mi idea era armar un pseudo bus PCI con 4 74HC595 como salida y 4 74LS244 como entrada, y darle los pulsos de clock desde el mismo micro. Según la especificación PCI, las transferencias se hacen en el pulso ascendente del reloj. Entonces el PIC iba a escribir la dirección en los latchs de salida, manda el pulso y así emular las señales del bus PCI. Bueno... no se porqué no funcionó.... quizá sea porque el clock es demasiado lento o porque no estaba mandando las señales en el orden correcto o porque no generaba la señal de paridad... Igualmente no lo seguí mucho porque hubiera sido una placa demasiado grande, con 8 integrados mas la placa PCI mas el PIC... (antes que digan algo, tengan en cuenta que no necesito velocidad, no me importa si la luz se enciende 1 segundo después).
Otra opción que tuve en cuenta es manejar una placa de red ISA, pero no se consiguen mas. Sólo se consiguen usadas y con suerte con un chip que tenga la hoja de datos. Encima son muy grandes, ocupan mucho espacio.
La última que se me ocurrió es usar un PIC18F2550 con USB para controlar un conversor de USB a ethernet como
este. Tienen el chip DM9601 de Davicom, está la hoja de datos, no parece complicado, es de tamaño reducido, pero leyendo en los foros
aquí y
aquí aclaran que no se puede porque se necesita que el PIC haga de host USB. Y aquí viene la pregunta del millón. ¿No se puede de ninguna manera con un PIC18F2550?. Estuve buscando info de USB y todos los ejemplos son para dispositivos con una PC como host y el PIC usando las librerías del compilador. ¿El que no pueda ser un host es un tema del hardware del PIC?. ¿No se pueden enviar los mensajes y "engañar" al DM9601?. O sea, tengan en cuenta que en este caso (quizá) no se necesite implementar todo el estandard de un host USB, lo único que va a estar conectado es el DM9601, va a estar conectado siempre, no se necesita ahorro de energía ni nada de eso. ¿O es que el hardware del PIC preprocesa los mensajes y en los buffers viene todo procesado con los datos en limpio?. Si es así, desde el programa no se tiene control de los mensajes de bajo nivel (setup, handshakes, etc). ¿Es así?.
Gracias y disculpen el largo del post.
Miguel.
