[Placa] Nueva placa con la ice40: eCow-Logic pico-ITX

[Obijuan]

Hola,

  A través de Clifford me entero de la existencia de esta placa:

http://opencores.org/project,ecowlogic-pico,Overview

De momento es un prototipo. Tiene salida vga y un display oled.  Muy interesante para frikeo

Saludos, Obijuan

[Barkalez]

Hola Obi, pues justo ayer leí éste artículo.. 

http://www.xataka.com/componentes/hasta-siempre-puerto-vga-fuiste-un-gran-companero-de-viaje

Por cierto, me queda muy poco para que llegue mi placa... 

[Juanma Rico]

Buenas,

De este hilo que creó Carlos explorando el software, descubrí la placa eCow-Logic, luego he visto que Obijuan ya habló de ella en este hilo, por eso he creido más conveniente continuar por aquí el tema del hardware.

La cuestión es que, como contaba en el hilo anterior, la cabeza me hizo "pluff" al entender que la placa se podía programar por la propia conexión ethernet. Vi que todo estaba diseñado con KiCAD (herramienta libre) y en un impulso, sin meditar lo suficiente como todo impulso, mandé a fabricar la placa. El fabricante chino por el mismo precio me ha fabricado 10... ¡y ayer me llegaron!

Al final el impulso ha salido caro, (Aunque la fabricación no ha llegado a 12€ el precio se ha disparado por aquello del envío aéreo y los impuestos en costes de aduanas), pero la pinta que tienen es estupenda.

Ahora queda hacer un poco de Eladio y ver qué componentes son los estricatamente necesarios para hacerla funcionar, comprar, soldar y probar la programación en remoto por la red.

¡Esto puede ser un "boom" si únicamente se necesita conectar a un router para cambiar en remoto la estructura interna de la FPGA! jejejejeje :)

Si consigo algún progreso con esta placa os mantendré informados. :)

Saludos

[Cristóbal Contreras Rubio]

Como mola Juanma ;-)

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6de10a22-2ca5-4e80-ae81-2d91cb7a4efb%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[una...@gmail.com]

Hola Juanma,

Esencialmente, 'reconfigurar' una FPGA no es diferente de quemar un HEX en cualquier otra memoria. De hecho, normalmente se utiliza un puerto serie con un protocolo bastante sencillo. Es más, en las FPGA volátiles (basadas en SRAM), lo que se programa habitualmente es una flash para que cada vez que arranque la FPGA la lea. Tanto la programación de la flash como la de la propia FPGA se suele hacer por JTAG. Por ello, la complejidad se reduce a tener un dispositivo 'despierto' que pueda recibir el HEX/BIN/Bitstream por Ethernet, desempaquetarlo y transmitirlo en serie.

En la placa que comentas hay una CPU sólo para eso. Pero estoy casi seguro de que podrías hacer lo mismo con un Arduino y una shield Ethernet. Ya hay algún proyecto para usar Arduino como programador JTAG. Dependiendo de la shield, podrías prescindir del Arduino, ya que algunas incluyen una CPU programable con sitio suficiente.

Pero lo anterior sólo es 'lo habitual'. Lo mejor es que la iCE40 de la Alhambra se programa por SPI! No es que se utilice JTAG como un puente al SPI, es que directamente no hay JTAG. Conectas un maestro SPI al bus y programas todo. Tienes toda la información aquí: www.latticesemi.com/dynamic/view_document.cfm?document_id=46502

La arquitectura descrita (FPGA + CPU + Flash, puediendo estar la CPU incluida en la FPGA -sea hard-core o soft-core-, y pudiendo estar la flash también dentro de la FPGA) es una de las razones de éxito de las FPGA en aplicaciones industriales. Eso es lo que permite tener un circuito que se comporta 'casi' como un ASIC (tomando como referencia una alternativa software), pero que es programable remotamente. Mercados como las telecomunicaciones y el Sofftware Defined Radio, routers/switches, etc. son nichos donde las FPGA cogieron muy rápidamente una cuota importante de mercado.

La siguiente vuelta es cuando la FPGA permite apagar partes de la misma, mientras otras se mantienen encendidas. En ese caso se puede utilizar una CPU dentro de la FPGA para gestionar la comunicación Ethernet. Esto se denomina Reconfiguración Parcial Dinámica.

Por último, también es 'habitual' que la FPGA almacene en la Flash externa varios circuitos diferentes que no se vayan a utilizar/ejecutar al mismo tiempo. En ese caso, durante la ejecución de un algoritmo software se hacen las paradas en los momentos adecuados para cambiar el hardware. Si hacemos la analogía con un Arduino, sería como tener un periférico extra que a veces es un timer, otras un multiplicador, otras un conversor RGB/CMYK...

Un ejemplo bastante ilustrativo de lo anterior es la tarjeta PYNQ. Estoy seguro de que el concepto te enamorará. Está basado en ZYNQ, que es un ARM dual core y una FPGA en el mismo chip. Ejecuta GNU/Linux con un servidor web corriendo Jupyter que permite a los aprendices programar en Python con una interfaz web. Utilizan el término 'overlay' para referirze a las diferentes piezas de hardware que tienen guardadas como binarios y que se configuran según las necesidades. Disclaimer: es una solución pensada directamente para gente de software que no quiere esforzarse en saber cómo funciona el hardware. Personalmente, me parece un error didáctico. Pero en el contexto del cacharreo, la experimentación y ver cosas funcionando con poco esfuerzo... ¡ojalá algo así con icestorm!

Un saludo!

[una...@gmail.com]

Le he dado a enviar demasiado rápido. Página 14 del manual enlazado, Figura11. iCE40LP soporta 'cold boot', que no es otra cosa más que elegir de entre cuatro configuraciones diferentes guardadas en la flash.

[Juanma Rico]

Hola  una...@gmail.com (discúlpame, no me sale tu nombre),

¿Distinto hardware según se requiera en tiempo de ejecución y en "caliente"?... Sí, tienes razón, el concepto me ha enamorado... pero no solo el concepto... ¡tú también me has enamorado! jajajajajaja
¿No tienes escrito un libro o algo donde pueda leerte? :)

Por otra parte, según puedo ver en el enlace adjunto esto de la carga de distintas imágenes, es una característica que permite el chip iCE40 con un programa externo,... ¿No se podría hacer que la iceZum Alhambra, basada como está en el mismo chip, se comportara así y agregar distintas capas de carga? Yo estaría encantado de investigar el tema si se confirma que la construcción de la iceZum Alhambra lo permitiera.

Respecto a PYNQ, no le tengo especial aprecio a Python, lo que hace que me eche un poco para atrás (además del color rosa ese tan feo), pero imagino que son prejuicios que uno tiene y que tendré que quitarme poco a poco, de todas formas veo que la PYNQ se parece mucho a la ARTY (imagino que por ser de la misma marca DIGILENT), la descubrí en la web de SiFive para trabajar con el Freedom E300 Arty FPGA Dev Kity programando para el RISC-V (por cierto en esta misma web tienen una placa compatible con Arduino basada en su RISC-V, muy baratita, si alguien se anima a hacer un pedido conjunto que lo diga... :D ).

Esto de las FPGAs es una locura, la de posibilidades que te ofrece y la de proyectos que genera... y si encima comienzan a ser libres... ¡Esto va a explotar por algún lado! ¡seguro!  jajajajaja

Gracias por la info y saludos

[Juanma Rico]

Hola de nuevo unaimc,

Me he puesto en contacto con uno de los creadores del proyecto (un chaval muy apañao) y efectivamente, me ha confirmado que todo se puede configurar vía ethernet.

Al parecer usa el chip ethernet (W7500) que tiene una pequeña MCU donde descarga un firmware con un pequeño servidor web que además tiene funciones que hace de puente con el interface esclavo SPI de la iCE40 y que así puedes cargar el bitstream de la FPGA únicamente con peticiones HTTP... una pasada, vamos.

Además me ha comentado que también se puede reconfigurar el firmware del propio W7500 con las peticiones HTTP porque las funciones de bajo nivel están en un bootloader, con lo que puedes modificar el propio servidor web... una locura...

Me ha comentado que está el proyecto en github un poco parado porque están preparando una nueva versión para reducir el precio, que saldrá en unos meses y se podrá comprar... así que estaremos pendientes... :)

Mientras tanto vamos a intentar completar esta placa... a ver si soy capaz de cargar la FPGA con peticiones HTTP, antes de que ellos terminen la nueva versión... :)

Saludos

[1138-4EB]

2017-03-04, 17:53:07, Juanma Rico:

Hola (discúlpame, no me sale tu nombre),

Una...i! "Vaquero, pastor de vacas" en Euskera. 1138-4EB en GitHub.
 

¿Distinto hardware según se requiera en tiempo de ejecución y en "caliente"?...

Si... ¡pero cuidado! ¡no te me 'calientes' en exceso! Eso se denomina System-on-Programmable-Chip (SoPC) y en la práctica la dificultad está en escoger el particionamiento (del inglés partitioning) hardware-software. En otras palabras, a veces tardas más en cambiar el hardware y tener al software esperando, que si directamente realizaras esa tarea por software. Por lo tanto, hay todo un área de estudio e investigación que trata de desarrollar algoritmos automatizados para decidir cuándo hacer sólo soft, cuándo sólo hard, cuándo mezclar, y cómo hacerlo.

La razón principal de lo anterior es que para un procesamiento hardware-software eficiente hay que mover físicamente la información de un sitio a otro: las cachés de la CPU, memoria DDR externa, memoria Flash externa, BRAM dentro de la FPGA... Tradicionalmente esto se ha resuelto con un controlador de memoria central y por el hecho de que todos los cores en un procesador funcionan al mismo ritmo. Ya no es así, y nos encontramos en un contexto con CPUs y FPGAs más potentes que rápidas intercambiando información. Sí, me dedico a esto...
 

Sí, tienes razón, el concepto me ha enamorado... pero no solo el concepto... ¡tú también me has enamorado! jajajajajaja
¿No tienes escrito un libro o algo donde pueda leerte? :)

Nah, no soy tan guapo ;)
Soy sólo un estudiante, ¡déjame crecer un poquillo más! La gran mayoría de lo que he aprendido ha sido en la red. Lo que sucede es que el mundo del diseño hardware es bastante más opaco que el software, y hay que escudriñarla para encontrarlo. Por ejemplo, el libro 'Free Range VHDL' está bien técnicamente, aceptablemente bien didácticamente y ¡es libre! No te dejes llevar por el título. Aunque se utilice VHDL el contenido del libro es una introducción al diseño digital para quien sabe programar software.

http://freerangefactory.org/
http://www.gstitt.ece.ufl.edu/courses/eel4712/labs/free_range_vhdl.pdf

Por otro lado, lo que son los circuitos no han cambiado en los últimos treinta años. De hecho, se están recuperando muchísimos diseños de finales de los 70 y primeros de los 80 que en su día se dejaron a un lado en favor de las arquitecturas von Neumann. Con lo que quiero decir que cualquier libro clásico de introducción a "arquitectura de computadores" te sirve. Sólo tienes que coger los dibujos/diseños, entenderlos, y describirlos. ¡Por algo son Hardware Description Languages!

Sobre la reconfiguración (parcial) y el particionamiento hard-soft no hay mucho, pero porque técnicamente hay poco que explicar. El toolchain es el mismo, vayas a programar la FPGA una o varias veces, por lo que el problema desde un punto de vista teórico es de software. Es algo que hay que resolverlo en la CPU, por lo que no es problema el diseñador de hardware puro. De eso se encargan los arquitectos, que son los responsables de integrar el trabajo de los equipos de hardware y software.

Evidentemente en el contexto que estamos, uno es al mismo tiempo diseñador hardware, software y arquitecto. Pero es importante ponerte sólo una de las caretas cuando estés haciendo una tarea. Como son sistemas relativamente complejos con una variabilidad inmensa, hacerlo así ayuda a no mezclar churras y merinas.
 

Por otra parte, según puedo ver en el enlace adjunto esto de la carga de distintas imágenes, es una característica que permite el chip iCE40 con un programa externo,... ¿No se podría hacer que la iceZum Alhambra, basada como está en el mismo chip, se comportara así y agregar distintas capas de carga? Yo estaría encantado de investigar el tema si se confirma que la construcción de la iceZum Alhambra lo permitiera.

Me juego una cerveza a que la Alhambra, tal cual, permite hacerlo por SPI. Si no es así, será porque el USB o algún otro periférico tiene ocupados esos pines, y no están expuestos de otra manera. En cuyo caso, bastaría con 'pincharlos' ya que el SPI es un bus. Luego están los pines para escoger cuál arrancar de las cuatro imágenes ya programadas. Estamos en las mismas: si están 'ocupados' pueden cortarse y añadir un par de microswitches/conmutadores. No me mirado el pinout del PCB, y lo estoy diciendo a ojo. Por eso una cerveza, y no una cena ;)

NOTA: Sí, esto debería haberlo comentado antes, porque es evidente que la Alhambra antes o después deberá incluir un uC (un atmega, un attiny...). La directa es un atmega32u4 que sustituya directamente al FTDI. Pero, por un lado he llegado tarde y las placas ya estaban pedidas. Por otro lado, tendrán que valorar los diseñadores el impacto que tenga en el coste y la dificultad del rediseño. Por último, y sobre todo, tiene poco sentido el esfuerzo si no hay herramientas para utilizarlas, y ahora mismo el tema está muy verde. Además, la gran mayoría de los que adquieran una Alhambra tendrán ya un Arduino, por lo que con un mínimo cableado se puede experimentar igualmente.

Llamar 'programa' a lo que se necesita es demasiado. Es un trocito de software que lea un binario y lo transmita por SPI. La mayoría de uC incluyen módulos SPI. Es decir: el programa sólo tiene que leer n direcciones de memoria consecutivamente y escribirlas todas en el mismo registro de salida. Con un DMA vas que chutas.

A partir de ahí, como he comentado, es todo software y puedes ignorar que estás trabjando con una FPGA. Sería como estar trabajando con Arduino y querer controlar cuatro periféricos por SPI a través de ethernet.
 

Respecto a PYNQ, no le tengo especial aprecio a Python, lo que hace que me eche un poco para atrás (además del color rosa ese tan feo), pero imagino que son prejuicios que uno tiene y que tendré que quitarme poco a poco,

Estoy de acuerdo con ambas valoraciones. El rosa, más por atrevido o inusual que por feo. Python, porque le tengo mucha tirria. Pero, como sugieres, ambas cosas son irrelevantes. El concepto es:

FPGA a la que te conectas por ethernet a través de una página web. Gracias a Jupyter puedes programar y documentar al mismo tiempo (brutal para dodencia e investigación reproducible). El ¡boom!, es que desde la misma interfaz/lenguaje puedes ver la diferencia de rendimiento entre utilizar software o un acelerador hardware. El handicap: necesitas que alguien haya diseñado los bloques hardware antes. O, si quieres hacerlo tú, necesitas otro IDE.

NOTA: es todo software, concretamente una imagen en una tarjeta SD. Si no cargas esa imagen, lo que tienes es una tarjeta de desarrollo normal y corriente. El color no se lo puedes cambiar ;), pero te olvidas de Python y utilizas las herramientas que quieras + Vivado. Para estudiantes cuesta 69$, por lo que objetivamente no hay mejor opción en el mercado para aprender sobre FPGAs. Lo tienes todo: sólo hardware, hardware+soft, sólo soft, VHDL, Verilog, C, C++, Python, GNU/Linux (con todo lo que conlleva).. en una placa del tamaño de un Arduino. Lástima la dependencia de Vivado. ¡Y por eso andamos por aquí!
 

de todas formas veo que la PYNQ se parece mucho a la ARTY (imagino que por ser de la misma marca DIGILENT),

Ambas son de Digilent, sí. Y los chips son los dos de Xilinx. Pero hay una diferencia muy importante: la ARTY tiene una Artix, que es FPGA sólo. Tiene BRAM, DSPs, gestores de reloj, etc. La PYNQ lleva un Zynq, que es un SoPC: una FPGA y un dual-core ARM A9 a 667-900MHz, todo en un sólo chip. Puede que esta imagen te ayude a verlo:

http://www.digikey.com/-/media/Images/Product%20Highlights/X/Xilinx%20Inc/Zynq%207%20SoC/xilinx-zynq-7000-large.jpg?la=en&ts=5d05f3dc-8bf1-4a64-853a-21025bd12624
Lo mismo, pero esta representación es más técnica: http://wiki.fpganotes.com/lib/exe/fetch.php/fpga:zynq_archi_diagram.png

Ahí, la 'Artix' es sólo la parte amarilla, la 'Programmable Logic' (PL). El Zynq es todo lo que se muestra ahí, el 'Processing System' (PS) y la PL.
Tanto la Artix como Zynq son de la serie 7 de Xilinx, por lo que tecnológicamente son equivalentes. El número de recursos puedes compararlo en:

https://www.xilinx.com/support/documentation/selection-guides/artix7-product-table.pdf
https://www.xilinx.com/support/documentation/selection-guides/zynq-7000-product-selection-guide.pdf

La ARTY lleva una XC7A35T y la PYNQ un Z7010 (lo digo de memoria, por lo que compruebalo si quieres). Por lo tanto la Artix es ligeramente más grande que la PL en PYNQ. Pero no por mucho.

Aún así, ten en cuenta que las referencias anteriores son cohetes espaciales. La Artix más pequeña que se comercializa tiene 12K8 celdas, mientras que la iCE40 más grande tiene 7K8. La ARTY tiene 33K2, la iCE40HX1K, 1K2.

Espero que con estos números, y sabiendo que están ya aplicando ingeniería inversa a la serie 7 de Xilinx, se entienda mi insistencia en el hilo del icestorm, al respecto de la escalabilidad y optimización. Y por qué digo que, aunque sin prisa, creo importante tenerlo en el horizonte.
 

la descubrí en la web de SiFive para trabajar con el Freedom E300 Arty FPGA Dev Kity programando para el RISC-V (por cierto en esta misma web tienen una placa compatible con Arduino basada en su RISC-V, muy baratita, si alguien se anima a hacer un pedido conjunto que lo diga... :D ).

De hecho, en esa página la única placa suya es esa, la HiFive1. El resto son de Digilent/Xilinx. Como el chip del RISC-V acaba de fabricarse hace nada, hasta ahora habían estado utilizando el IP-core (las fuentes del micro en Verilog/VHDL) para que los desarrolladores pudieran ir haciendo el software. Ahora su utilidad está en que el RISC-V fabricado es sólo una de las muchas combinaciones posibles, por lo que puedes querer probar otras opciones (más o menos caché, más o menos etapas en el pipeline, más o menos periféricos, etc.).

Por ello, técnicamente te recomendaría la ARTY antes que la que lleva el RISC-V, porque te permitirá probar el RISC-V y cualquier otro diseño. Suponiendo que no seas estudiante, la PYNQ creo que está en 200$, por lo que es la segunda opción. En el PYNQ, ignorando todo lo de Python, podrías meter el RISC-V en la PL y tenerlo funcionando al mismo tiempo que los dos ARM. Por ejemplo, uno que esté ejecutando GNU/Linux para que puedas acceder por Ethernet, otro que esté cogiendo imágenes de una webcam, y el RISC-V con algún periférico sencillito que haga un filtrado antes de sacar la imagen por HDMI.

Sin embargo, como hardware libre, la HiFive1 es la única opción. Sigue sin serlo al 100%, porque el chip de FTDI, entre otros, no es libre. Pero sin duda es lo más cercano.

 

Esto de las FPGAs es una locura, la de posibilidades que te ofrece y la de proyectos que genera... y si encima comienzan a ser libres... ¡Esto va a explotar por algún lado! ¡seguro!  jajajajaja

Es el 'problema' principal al que nos enfrentamos en la computación a nivel global. Las FPGAs están entrando en los datacenters, desbancando a las GPUs y GPGPUs como coprocesadores, porque son muchísimo más eficientes (hablamos de decenas de watios frente a cientos). Pero tenemos 40-60 años de programas/aplicaciones/sistemas pensados y optimizados exclusivamente para arquitecturas von Neumann. Un modelo que permite ejecutar código arbitrario pero es muy muy muy ineficiente. Por ello, no es sólo cambiar de plataforma, es que la amplísima mayoria de código tiene que ser reescrito y adaptado a (potencialmente) infinitas plataformas/arquitecturas posibles. De CPU a GPU cambias de un modelo a otro, ambos claramente definidos. Con una FPGA, ¡a saber!

Pero, si la contabilidad a nuestro alrededor la sostiene Excel, esto es un mal menor.
 

Gracias por la info y saludos

A ti por el interés. Yo no puedo cacharrear con una iCE40. Pero lo que pueda ayudarte con referencias y/o aclaraciones teóricas/conceptuales, ¡pregunta!

 

[una...@gmail.com]

2017-03-04, 19:35:15 (UTC+1), Juanma Rico:

Hola de nuevo unaimc,

¡Buenas!
 

Me he puesto en contacto con uno de los creadores del proyecto (un chaval muy apañao) y efectivamente, me ha confirmado que todo se puede configurar vía ethernet.

He visto que le has seguido por twitter ;)
 

Al parecer usa el chip ethernet (W7500) que tiene una pequeña MCU donde descarga un firmware con un pequeño servidor web que además tiene funciones que hace de puente con el interface esclavo SPI de la iCE40 y que así puedes cargar el bitstream de la FPGA únicamente con peticiones HTTP... una pasada, vamos.

A esto me refería al decir un par de mensajes atrás: "Dependiendo de la shield, podrías prescindir del Arduino, ya que algunas incluyen una CPU programable con sitio suficiente". Este es ethernet, pero los hay wifi, BT, RF2.4GHz... Digamos que quieres programa la Alhambra por wifi, ¿tienes siete euros sueltos? https://www.sparkfun.com/products/13678 Ese tiene 1MB, pero los hay de hasta 4MB: https://en.wikipedia.org/wiki/ESP8266

Si te fijas, la arquitectura es la misma que he comentado: una CPU + memoria Flash (QSPI) externa + FPGA. De hecho, pensándolo así, igual @Obijuan y cía quieren incluirlo como un complemento para próximas tiradas, antes de replantearse su inclusión en el PCB. El problema de integración principal es la EMR, ya que esos 2.4GHz pegaditos a la FPGA...

Siguiendo la misma línea, los NRF24 de Nordic también están disponibles en formato SoC con flash: https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P Estos pueden reaccionar a un tag BT. Digamos que cada alumno en un aula hace un diseño a través de una página web con el navegador de su RPI, todo el trabajo duro se hace en un solo PC suficientemente potente. Cuando funciona, se levanta, se acerca a una mesa con cuatro o cinco placas, pasa una tarjeta RFID  y se programa y corre su circuito. Si cada placa la usan 4 alumnos como máximo, el cambio es instantáneo. Si no, hay que esperar a que se descargue.

Además me ha comentado que también se puede reconfigurar el firmware del propio W7500 con las peticiones HTTP porque las funciones de bajo nivel están en un bootloader, con lo que puedes modificar el propio servidor web... una locura...

Es interesante, pero dependiendo del contexto. Al introducir el bootloader estás ocupando un espacio que, salvo en la etapa de desarrollo, se utiliza poco. Durante la misma, puedes reprogramar el propio chip directamente, porque tienes acceso al mismo. Por lo tanto, es útil si ahorra tiempo y permite hacer más iteraciones. O en aplicaciones de campo donde realmente se necesite modificar remotamente no sólo la FPGA sino la interfaz a la misma.
 

Me ha comentado que está el proyecto en github un poco parado porque están preparando una nueva versión para reducir el precio, que saldrá en unos meses y se podrá comprar... así que estaremos pendientes... :)

Mientras tanto vamos a intentar completar esta placa... a ver si soy capaz de cargar la FPGA con peticiones HTTP, antes de que ellos terminen la nueva versión... :)

Saludos

¡Saludos y ánimo!

[Juanma Rico]

Gracias Unai,

¡Me has abierto un nuevo mundo de posibilidades! ¡no voy a tener tiempo para experimentar con todo! Jajajajaja

Te preguntaré, te preguntaré... aunque ya con este par de mensajes me vas a tener entretenido un mes... jejejeje

Por lo pronto me voy a animar a buscarle las cosquillas a la Alhambra a ver si consigo el "boot warm" ese... y mientras intentaré montar una eCow-logic... sino, un Arduino y cablecitos como dices...

Y por supuesto, si ves que digo alguna burrada o imprecisión, por mi no te cortes, tienes todo mi permiso, desde ya, para darme en toda la cocorota y reconducirme... :)

Gracias miles. Saludos.