Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Hola,
Estaba pensando hacer un sistema todo integrado para producción. Sería un módulo general para domótica o industria que lo llevase casi todo hecho y sólo fuera programar, ¿qué le pondríais?
Yo he mirado lo siguiente:
Procesador:
- PIC32 o ARM7
- Coprocesador DSP o FPGA.
Comunicaciones:
- Bus 485.
- Módulo GSM, GPRS o 3G.
- Módulo inhalambrico 898MHz.
Otros módulos:
- GPS
- I/O generalistas
- Caja de rail DIN
S2
Ranganok Schahzaman
No me gusta hacer de abogado del diablo pero, ten en cuenta que a nivel industrial ya existen muchas marcas que ofrecen microautomatas, que me parece que es mas o menos lo que tu quieres hacer, a un precio razonable y cuenta con la ventaja de ser conocidas dentro del mundillo.
Además, no es lo mismo un bus de comunicaciones para domotica que para uso industrial. Para el primero se esta tirando hacia KNX mientras que para el segundo tienes protocolos estandarizados como Modbus, Profibus, Device-Net, etc.
ModBus es en la capa 7 (aplicación) y hay implementaciones para RS485. Profibus está definido sobre un RS485. DeviceNet está definido sobre CAN. KNX sobre par trenzado es compatible con un bus RS485 (hay que añadir los cables de poténcia).
De los que has dicho el único que no se podría usar es DeviceNet (porque usa un bus CAN).
S2
Ranganok Schahzaman
Hola:
Dada mi absoluta ignorancia respecto de los PIC32, ¿podría alguien hacerme el favor de explicarme que cosas tienen que no tengan los ARM7? Gracias.
De vuelta al ajo, de 6 a 24VDC implica que igual hace falta mirarse bien que fuente usar para alimentarlo todo. Los relés tienen una horquilla de trabajo grande, pero no tanto, y alimentarlos a 5VDC significa fuente conmutada si no queremos tener un módulo que también sea calefactor.
Todos lo ARM7 más o menos nuevos que conozco tienen bootloader incorporado, o sea que por ahí no va a haber problema.
FPGA en Farnell (o sea, caaaaaro) las tienes desde 9€ hasta más de 1000. Una presentable, como una XC3S200AN, con la memoria de programción interna, en FTG256 (BGA, toma ya) está por 16.7€ o así, pero en encapsulados más 'manejables' (TQFP144 o similar) las hay más económicas. Claro que si la tirada es más o menos grande, se puede hablar con AVnet a ver por cuanto nos venden una bandeja.
Particularmente abogo más por los ARM, pero sólo por aquello de 'más vale malo conocido...'.
Los ARM7 que conozco llevan HW para manejar directamente el cambio de 'dirección' en un ModBus, que por cierto, tiene librerías gratuitas (otra cosa es que yo las use, ya que tengo las mias propias) en http://www.freemodbus.org " onclick="window.open(this.href);return false; o similar. Ethernet es muy usado, hasta el punto que FreeRTOS tiene librerías y ejemplos para ARM7 con IwIP (pila TCP/IP gratuita) fáciles de descargar. Yo tengo una corriendo en un AT91SAM7X256 de Olimex en casa, con servidor Web incluido.
De vuelta al ajo, de 6 a 24VDC implica que igual hace falta mirarse bien que fuente usar para alimentarlo todo. Los relés tienen una horquilla de trabajo grande, pero no tanto, y alimentarlos a 5VDC significa fuente conmutada si no queremos tener un módulo que también sea calefactor.
Yo prefiero la opción 12-24VDC, que sirve para coche, para seguridad (12V), para domótica y para industria (24V).
Dada mi absoluta ignorancia respecto de los PIC32, ¿podría alguien hacerme el favor de explicarme que cosas tienen que no tengan los ARM7? Gracias.
Mi ignorancia es la misma que la tuya respecto a los pic32, pero esto es lo que dicen ellos de sí mismos:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2591&redirects=32bit
S2
Ranganok Schahzaman
Hola:
Quizás esto debería ir en otro lado, pero creo que como continuación y dada la superficialidad real del comentario, de momento lo dejo aquí.
Ante todo, decir que me he limitado a una lectura superficial del la página Web del PIC32, con un ligero recuento de 'cosas'. No tengo el tiempo necesario para realizar una comparativa presentable a fondo ni una crítica pormenorizada de los mismos, así que coged lo que explico a continuación con pinzas, un 'a bote pronto' de lo primero que he visto a simple vista.
Por lo que se refiere a HW, el core parece un poco más potente (124 DMIPS@80MHz, frente a los 120DMIPS@96MHz de los CortexM3), con la ventaja añadida de 32 acumuladores frente a los 16 de estos últimos, pero con la desventaja de 5 niveles de Pipeline frente a 3 (o sea, que en un Jump se come ciclos de reloj frente a 3).
Si nos centramos en periféricos, parece que los PIC32 adolecen de bastantes faltas, pero también depende de con que los comparamos. Es decir, frente a los (ahora TI) Stellaris o los LPC210X, vienen bastante equipados, pero comparado con los STM o los SAM7/SAM3, están en clara desventaja: ADC's de 12 bits, Ethernet on chip, Hi-Speed USB, CAN2.0B, interfaz SD/MMC de 4-8bits en lugar de SPI, DMA dedicado para cada periférico con RAM y FLASH en varios planos (o sea, acceso simultáneo), además de DMA propiamente dicho para la RAM/Flash/memoria externa, etc.
Además, o mi memoria me falla (y me consta que así es muchas veces) no entiendo cómo una presunta arquitectura Harvard del PIC32 puede ejecutar código desde RAM.
Por tanto, a nivel de silicio, yo dejaría en empate o incluso ligera desventaja a los PIC, eso sí, en un análisis preliminar y dejando claro que estamos hablando de soberbias máquinas (comparad con un 80386SX de la época). Según opiniones de terceros, las máquinas MIPS en la que se basa el PIC32 (y el AVR32!) son ligeramente más potentes que las ARM, aunque la diferencia no es precisamente arrolladora.
Si vamos a parar al tema SW y herramientas de desarrollo, el PIC tiene unas claras ventajas de 'solución de continuidad' respecto de lo ya existente. Además de completas librerías y paquetes de SW, etc. Las herramientas de desarrollo son propietarias, cosa que generalmente me asusta, a excepción siempre de Microchip, pues la política de estos es ejemplar en este aspecto.
Comparando lo que hay de SW de ARM, el problema es claro: exceso y empacho de soluciones. No hay una librería, hay toneladas de ellas, y eso hace difícil encontrar lo que uno necesita. Incluso hay sistemas operativos gratuitos que ya cubren productos que todavía no se pueden encontrar (FreeRTOS, CooCox), como los SAM3. Herramientas de desarrollo, bueno, un Wiggler clone por 2-3€ es imbatible, pero cuando uno lleva una semana intentando trabajar con el, seguro que lo tira y se compra uno de los nuevos OCD compatibles basados en FTDI, como los que vende Olimex. Aún así, un Segger sale por unos 100€, con unos resultados estupendos.
Por tanto, a la hora de decidir, en mi humilde y ligera opinión, todo se reduce a un 'más vale malo conocido que bueno por conocer', es decir, los que sólo hemos usado ARM (o otros micros con GNU-GCC) continuaremos con éstos, los que sólo hayan usado PIC's, seguramente harán mejor seguir fieles a Microchip. Recordemos otra vez que estamos hablando de máquinas realmente potentes (>100DMIPS) que seguramente darán más que de sobras para realizar lo que haga falta, y que lo único que he trabajado de PIC son los 16F84 en el 2001.
Volviendo al tema en cuestión, yo también prefiero 12-24VDC (que en realidad deberían ser 8-28VDC reales) que empezar desde los 6. Una fuente conmutada StepDown con salida a 5V o incluso salida doble a 5 y 3V3 sería la solución, y no precisamente cara. El micro, por supuesto, a elección del que decida liarse al diseño, ya que cualquiera de las dos opciones planteadas son más que válidas. Comunicaciones Ethernet, CAN y RS-485 recomendables. Unos pocos relés también. Además de la NTC interna (si viene, ¿para que no usarla?), creo conveniente el poner una externa con regleta, no sólo por el tema de precisión (las internas suelen tenerla peor) si no por el punto de medida (he tenido muchas sorpresas en este tema).
Respecto del 4-20, yo hice un sistema (comercial) que permitía tener 4-20mA, NTC, PT100, PT1000, termopares J y K, y 0..2V5. Con ligeras modificaciones y pocos componentes se puede hacer un 0..50mA y 0..10V en la misma entrada. Una salida analógica tampoco sería mala idea. La posibilidad de añadir varios tipos más de sensores (con electrónica incluida, quizás) no sería descabellada, pero se debería definir un estándar.
En cualquier caso, lo que más falta creo que hace, es acotar el campo de uso del sistema, incluyendo un pequeño recopilatorio de funciones que nos interesaría cubrir. Por mi parte, propongo varias para domótica: regulación tipo termostato en la propia habitación, control de persianas y/o luces, simulación presencial, gestión inteligente de la energía (es decir, si hace sol y frío, abrir las persianas, por ejemplo).