Desarrollo de la Alhambra II
2,528 views
Skip to first unread message
Eladio Delgado
Mar 22, 2018, 9:44:22 AM3/22/18
to FPGAwars: explorando el lado libre
Hola!
Mientras fabricamos las últimas unidades de la IceZUM Alhambra, estamos con el desarrollo de la nueva versión de esta placa, la Alhambra II. Abro este hilo para comentar sobre el diseño y las características que va a tener esta placa.
Los cambios más importantes que va a tener son estos:
Mientras fabricamos las últimas unidades de la IceZUM Alhambra, estamos con el desarrollo de la nueva versión de esta placa, la Alhambra II. Abro este hilo para comentar sobre el diseño y las características que va a tener esta placa.
Los cambios más importantes que va a tener son estos:
- FPGA ice40 HX 4K
- GPIO a 3.3V tolerante a 5V (como entrada acepta niveles entre 3.3 y 5V, como salida genera 3.3V)
- Alimentación por USB (dos conectores), hasta 4.8A, para alimentarla con power bank y tener más corriente para los servos
- Los pines de selección de bitstream para cold boot están accesibles en el GPIO
- Reguladores conmutados de 1A para las alimentaciones de 1.2 y 3.3V, lo que permitirá activar los PLLs y trabajar a velocidades mucho mayores.
- Pines analógicos integrados en los pines D0 a D3 (sólo 4 de los 6 pines del header son analógicos) para mayor compatibilidad con Arduino
- Pulsadores de usuario cómodos de accionar (3 veces menos fuerza por unidad de superficie que los anteriores)
Creo que esto recoge lo que más se ha echado en falta con la IceZUM Alhambra pero por supuesto todas las ideas son bienvenidas!!
El diseño está ya bastante avanzado (terminando el esquemático).
Un saludo,
Eladio
Carlos García
Mar 22, 2018, 1:40:33 PM3/22/18
to FPGA-WARS: explorando el lado libre
Qué bueno Eladio! Son unas mejoras muy interesantes y útiles!
Me entra la duda de si la placa seguirá teniendo entrada de alimentación no regulada, ¿ahora sería solamente por el pin Vin de arduino?
Me entra la duda de si la placa seguirá teniendo entrada de alimentación no regulada, ¿ahora sería solamente por el pin Vin de arduino?
--
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/6354bb93-972c-4b13-b3c7-0376d9ec0c1f%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Eladio Delgado
Mar 22, 2018, 5:22:40 PM3/22/18
to FPGAwars: explorando el lado libre
Hola Carlos!
La nueva versión sólo se alimenta con USB, el pin Vin queda anulado ya que ahí puede haber tensiones mayores.
La placa sólo acepta alimentación a 5V pero con un rango bastante flexible: no superar los 5.5V y que en los picos de demanda de corriente no baje de 3.3V. Lleva un condensador electrolítico de polímero para desacoplar la impedancia de los cables USB.
Un saludo,
Eladio
El 22 mar. 2018 6:40 p. m., "Carlos García" <carlosga...@gmail.com> escribió:
Qué bueno Eladio! Son unas mejoras muy interesantes y útiles!
Me entra la duda de si la placa seguirá teniendo entrada de alimentación no regulada, ¿ahora sería solamente por el pin Vin de arduino?
2018-03-22 14:44 GMT+01:00 Eladio Delgado <email...@gmail.com>:
Hola!
Mientras fabricamos las últimas unidades de la IceZUM Alhambra, estamos con el desarrollo de la nueva versión de esta placa, la Alhambra II. Abro este hilo para comentar sobre el diseño y las características que va a tener esta placa.
Los cambios más importantes que va a tener son estos:
- FPGA ice40 HX 4K
- GPIO a 3.3V tolerante a 5V (como entrada acepta niveles entre 3.3 y 5V, como salida genera 3.3V)
- Alimentación por USB (dos conectores), hasta 4.8A, para alimentarla con power bank y tener más corriente para los servos
- Los pines de selección de bitstream para cold boot están accesibles en el GPIO
- Reguladores conmutados de 1A para las alimentaciones de 1.2 y 3.3V, lo que permitirá activar los PLLs y trabajar a velocidades mucho mayores.
- Pines analógicos integrados en los pines D0 a D3 (sólo 4 de los 6 pines del header son analógicos) para mayor compatibilidad con Arduino
- Pulsadores de usuario cómodos de accionar (3 veces menos fuerza por unidad de superficie que los anteriores)
Creo que esto recoge lo que más se ha echado en falta con la IceZUM Alhambra pero por supuesto todas las ideas son bienvenidas!!
El diseño está ya bastante avanzado (terminando el esquemático).
Un saludo,
Eladio
--
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-lib...@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/6354bb93-972c-4b13-b3c7-0376d9ec0c1f%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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/CAJCftXVnPfYqLiFtNcYDF%2B3M9mYTDnYEr6SS39kKRc4Vpqu2DA%40mail.gmail.com.
Diego Fernandez Gonzalez
Mar 22, 2018, 6:56:39 PM3/22/18
to FPGAwars: explorando el lado libre
Que buena noticia!
Y que buena pinta tienen las especificaciones.
¿Donde voy haciendo la transferencia?
Y que buena pinta tienen las especificaciones.
¿Donde voy haciendo la transferencia?
Eladio Delgado
Mar 22, 2018, 7:41:20 PM3/22/18
to FPGAwars: explorando el lado libre
😃😃 gracias Diego!! Me alegra que gusten los cambios que vamos a hacer.
Os iré contando más cosas sobre el desarrollo según avancemos.
Un saludo,
Eladio
--
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 una entrada 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 este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ed7ac1f7-bde4-4396-aaa3-551e6ee3a206%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Message has been deleted
Eladio Delgado
Mar 23, 2018, 1:46:15 PM3/23/18
to FPGAwars: explorando el lado libre
Hola Unai,
Respondo entre líneas:
El 23 de marzo de 2018, 4:56, 1138-4EB <umarti...@ikasle.ehu.es> escribió:
Los cambios tienen muy buena pinta para poder trabajar con diseños un poco más "exigentes"! Especialmente interesante hacer accesibles los pines para cold boot.
En este mismo sentido, me gustaría preguntar si, junto con estos, se va a dar acceso a los pines que se utilizan para conectar la FPGA y la Flash. El objetivo es, por un lado, aprovechar esos pines para conectar otros periféricos SPI (aunque para esto pueden usarse otros GPIO). Pero, especialmente, para poder programar tanto la FPGA como la memoria Flash desde un dispositivo externo, como un Arduino, por ejemplo (una especie de ISCP). Esto permitiría sacar mucho partido al cold boot, al facilitar que sea el Arduino el que (reordene) las imágenes en la flash, y pueda borrar por completo la FPGA antes de cargar un nuevo diseño. Hice algunas consideraciones al respecto en este hilo: https://groups.google.com/forum/#!topic/fpga-wars-explorando-el-lado-libre/4L0QO0WVPm4
He seguido los hilos sobre el cold boot y la programación de la flash pero éste al que has puesto el enlace me lo había perdido. Lo acabo de leer, luego contesto en ese hilo las notas que tengo de cuando estuve haciendo las pruebas de la versión 1.0 de la IceZUM.
Tener acceso a esos pines no sólo implica el conector sino la electrónica para multiplexar el acceso, ya hay tres dispositivos en el bus (flash, FTDI y FPGA) y hay colisión entre ellos con lo que no podemos añadir más sin multiplexores. Sí se puede hacer de otra forma. Se puede cargar un bitstream que simplemente conecte los pines del SPI de la FPGA a los que tú quieras del GPIO de la placa (cada uno con la config de I/O adecuada). Puedes dejar este bitstream en una zona de la flash reservara sólo para esto y que puedas seleccionar esa zona con los pines de cold boot. De esta forma con un switch externo conectado a los pines de cold boot, activas o desactivas el acceso a los pines del SPI.
Elevando la vista, la combinación Alhambra II + Arduino sería el equivalente "sencillo" con PCBs libres de los SoC que se utilizan actualmente para ADAS, Machine-Learning, Amazon... (principalmente ARM + FPGA). Como ejemplo práctico: un arduino puede utilizarse para gestionar una TFT de 2" táctil o para servir una web, y que la FPGA esté controlando mediante PIDs los 2-10 motores de un robot o brazo. Es difícil que un Arduino sólo realice ambas tareas sin problemas de temporización. Y también es difícil sintetizar un Lattuino capaz de controlar una TFT y que al mismo tiempo haya sitio para todos los PID y otro hardware que pueda requerirse. Sin embargo, es relativamente sencillo que cada componente haga aquello que mejor se le da.
La idea de tener en una placa un ARM + FPGA hace tiempo que la tengo en mente, todos los que hemos trabajado con microcontroladores hemos echado en falta muchas veces algo de lógica programable en el micro. Esta idea tiene muchas aplicaciones en control industrial y me gustaría hacerla con un M4 o un M7.
Profundizando en la idea de facilitar la combinación de la Alhambra II con Arduino, ¿es posible un diseño dual? Por dual me refiero a que la placa se pueda utilizar como sustitución de un Arduino (planteamiento actual) o que pueda utilizarse como una shield para Arduino. Entiendo que, en caso de utilizarse como shield, la alimentación imprescindible sería la de la Alhambra. A partir de ahí, no sé si debería ser obligatorio utilizar dos cables USB para programar la FPGA por un lado (con el FTDI) y el Arduino por otro; si debería ser posible, pero no obligatorio; o si, por el contrario, debería utilizarse uno solo de los USB (ya sea programando la FPGA a través del Arduino, o programando el Arduino a través del FTDI de la Alhambra). Aunque estoy imaginando la shield de un Arduino Uno/Leonardo, creo que el planteamiento es igual o más interesante simplemente añadiendo un zócalo debajo de la Alhambra para poder colocar un Arduino Nano o Arduino Micro. En cualquier caso, entiendo que la elección depende principalmente del espacio disponible, del número de capas, de las limitaciones físicas para añadir los pines que actúen como shield, y de hasta qué punto os interesa que el PCB sea exactamente igual que el un Arduino UNO.
Ese diseño dual que comentas es posible, bastaría con montar sockets apilables en lugar de los normales. Esto va a ser posible porque he diseñado la placa de forma que todos los componentes necesarios para funcionar son SMD y opcionalmente se puede enviar la placa con las tiras de pines y los zócalos sin soldar. Antes, el switch de alimentación, el jack y el pulsador de reset se montaban en la misma fase que los pines y sin estos componentes no podías usar todas las funciones de la placa. Ahora podemos enviar la placa sin montar las tiras de pines y todo funciona sin los componentes de inserción, la puedes empezar a usar tal cual te llega. Luego tú puedes soldar el tipo de zócalos y pines que quieras y esto permite el montaje que comentas. Además hemos modificado el diseño térmico del PCB para que sea mucho más fácil de soldar.
En cuanto a comunicación habría que conectar una o las dos placas como comentas, según la aplicación. En cuanto a la alimentación, la Alhambra puede alimentar al Arduino a través del pin de 5V y al revés.
Por último, un planteamiento totalmente diferente, pero relacionado, es si sería posible que los LEDs de prueba, los pulsadores de prueba, el FTDI y el USB estuvieran parcialmente "aislados" en el PCB para poder "cortar" esa parte. Si se añade algún ICSP, como he comentado al principio, el resultado es una FPGA con su Flash, ADC y alimentación propia que se puede programar y utilizar con cualquier uC a través de SPI. Ver como ejemplo la familia st.com/stm32nucleo que incluyen un ST-LINK/V2-1 en el mismo PCB, pero físicamente están claramente diferenciados ambos circuitos. Y también este proyecto de hackaday basado en una Spartan6 https://hackaday.com/2014/03/05/a-low-cost-arduino-fpga-shield/.
Dicho lo anterior, creo que con saber qué 4-6 pines concretos hay que utilizar para tener acceso maestro al bus SPI es más que suficiente. A partir de ahí, cualquier modificación de la placa debe tener en cuenta factores mucho más complejos y depende de cómo queréis (re)plantear el producto.
Esta opción que comentas es muy habitual en placas de evaluación de microcontroladores pero en nuestro caso creo que el planteamiento de tenerlo todo en una placa para empezar a hacer cosas con las FPGAs, parece acertado.
Sí que vemos interesante tener módulos con la FPGA y la memoria (programables con la Alhambra o con un Arduino) para la aplicación que has desarrollado previamente con la Alhambra (u otra placa con iCE40). Es una idea que teníamos desde el principio y que ahora es más interesante con la aparición de la TinyFPGA. El módulo que teníamos en mente es exactamente una TinyFPGA salvo por la comunicación USB. No se nos había ocurrido implementar la interfaz USB en la propia FPGA. Con el bootloader que ha desarrollado Luke, este módulo pasa a ser "autónomo", lo programas directamente con el PC sin necesidad de otra placa, y sólo has añadido al módulo un conector USB y dos resistencias.
Un saludo
PD: tras responder en el hilo del Pong, me he acordado de este PMOD de Digilent: https://store.digilentinc.com/pmod-vga-video-graphics-array/ No sé hasta qué punto os interesa hacer minishields de este tipo, que no están disponibles para Arduino porque un uC no puede utilizarlas, pero que no tienen ninguna complejidad de diseño.
Cierto, no son complejas ni costosas. Seguramente las hagamos pronto, la de VGA y la de displays de 7 segmentos + pulsadores son dos que llevan tiempo en el to-do, pero en fin, el tiempo es lo que limita :-)
Un saludo,
Eladio
--
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/61ac6c26-6ff2-4764-8e40-518a7522bb64%40googlegroups.com.
Carlos García
Mar 23, 2018, 1:55:31 PM3/23/18
to FPGA-WARS: explorando el lado libre
Muchas gracias por la aclaración respecto al Vin!
Está muy bien ese rango tan generoso (3.3 a 5.5V) que sigue permitiendo alimentar con baterías sueltas sin power-bank :D
Está muy bien ese rango tan generoso (3.3 a 5.5V) que sigue permitiendo alimentar con baterías sueltas sin power-bank :D
Gracias por seguir contándonos todo el proceso de diseño para que podamos aprender!!!
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAJCftXVnPfYqLiFtNcYDF%2B3M9mYTDnYEr6SS39kKRc4Vpqu2DA%40mail.gmail.com.
--
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/CAJXdXgT82kPxZTUhNMvmTH553LLd%2B-LMqx7U%2BO26GZVDPMS%2BgQ%40mail.gmail.com.
Eladio Delgado
Mar 23, 2018, 7:05:48 PM3/23/18
to FPGAwars: explorando el lado libre
Gracias Carlos!! Lo que dices sería la solución definitiva para alimentar los servos sin problemas de corriente, pero habría que tener cuidado, no puede conectarse el USB a la vez, entre otras cosas. Haremos pruebas con esto!!
Hasta ahora la mejor solución que he encontrado es usar un pequeño PCB externo que implemente un diodo ideal con MOSFETs, para que la batería (una célula LiPo) inyecte corriente sólo cuando la tensión en 5V baje por debajo de la tensión del la batería. Lo iremos viendo...
Un saludo,
Eladio
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAJXdXgT82kPxZTUhNMvmTH553LLd%2B-LMqx7U%2BO26GZVDPMS%2BgQ%40mail.gmail.com.
--
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/CAJCftXWiRiSGg0kn7afoT3ZwZmZ5Tw%3Dx%3Dgqa2DNd5iejOTj8gA%40mail.gmail.com.
Juanma Rico
Mar 24, 2018, 6:46:52 AM3/24/18
to FPGAwars: explorando el lado libre
¡Genial Eladio!
Se estaba echando de menos el proyecto de una segunda versión, las TinyFPGA están "pegando fuerte" y la 1K ya se quedaba corta para los que malgastamos recursos sin mirar atrás... :))
Igual hay que aclarar que la 4K de la futura versión, con las herramientas libres, se comportan como una 8K... veo en Twitter que Clifford aún tiene que ir aclarando el concepto... así que propongo poner entre paréntesis algo así como... "8K con las herramientas libres del proyecto icestorm", cuando indiques las características de la nueva versión y el chip de Lattice que utiliza, puede que muchos no se decidan por ella por ver que son 4K y no saber más allá.
Por otro lado, lo de tener disponibles los pines del "Cold Boot" es algo que sabes que te agradezco... No hay discusión en eso... +10... :))
Por otro lado, hablando de las TinyFPGA y del "Cold/Warm Boot"... ¿Se va a mantener el chip FTDI? Según creo recordar comentaste una vez que es uno de los componentes más caros de la placa... ¿No sería mejor utilizar un bootloader como la estrategia que usa la TinyFPGA y eliminar dicho componente abaratando la placa?
Además si se tienen disponibles los pines del "Cold Boot", el arrancar el bootloader se puede hacer en cualquier momento y no hay nada más robusto para arrancarlo en "frío" que con una conexión hardware externa (que puede ser con un pequeño interruptor).
Digo esto porque en la TinyFPGA veo que a veces hay problemas para arrancar la imagen ya grabada del usuario porque antes pasa por el bootloader. Si se alimenta con un puerto USB del PC a veces se queda en el bootloader esperando porque detecta conexión y no hay manera de arrancar el programa del usuario... (creo que Luke ya está trabajando en un bootloader más robusto en este sentido), pero en el caso del "Cold Boot" por hardware no habría problema... tenemos robustez de arranque en las distintas imágenes y nos quitamos el FTDI de la placa.
Bueno, no me enrollo más. Enhorabuena y suerte en esta nueva versión.
Saludos
Juan manuel Rico
Eladio Delgado
Mar 24, 2018, 7:40:03 PM3/24/18
to FPGAwars: explorando el lado libre
Hola Juanma,
Respondo entre líneas:El 24 de marzo de 2018, 11:46, Juanma Rico <juan...@gmail.com> escribió:
¡Genial Eladio!
Se estaba echando de menos el proyecto de una segunda versión, las TinyFPGA están "pegando fuerte" y la 1K ya se quedaba corta para los que malgastamos recursos sin mirar atrás... :))
Igual hay que aclarar que la 4K de la futura versión, con las herramientas libres, se comportan como una 8K... veo en Twitter que Clifford aún tiene que ir aclarando el concepto... así que propongo poner entre paréntesis algo así como... "8K con las herramientas libres del proyecto icestorm", cuando indiques las características de la nueva versión y el chip de Lattice que utiliza, puede que muchos no se decidan por ella por ver que son 4K y no saber más allá.
Me parece buena idea indicar de alguna forma lo de 8K. Habrá que buscar una forma de hacerlo para que no resulte confuso, que se vea claro que la FPGA montada es la 4K pero que se puede tener acceso a 8K con las herramientas libres.
Por otro lado, lo de tener disponibles los pines del "Cold Boot" es algo que sabes que te agradezco... No hay discusión en eso... +10... :))
Lo tuve claro desde que empezásteis a hacer pruebas con esto!! :-) Además es una característica que me encanta, poder conmutar manual o electrónicamente entre distintas CPUs por ejemplo, de forma casi instantánea, mola mucho!! :-))
Por otro lado, hablando de las TinyFPGA y del "Cold/Warm Boot"... ¿Se va a mantener el chip FTDI? Según creo recordar comentaste una vez que es uno de los componentes más caros de la placa... ¿No sería mejor utilizar un bootloader como la estrategia que usa la TinyFPGA y eliminar dicho componente abaratando la placa?
Además si se tienen disponibles los pines del "Cold Boot", el arrancar el bootloader se puede hacer en cualquier momento y no hay nada más robusto para arrancarlo en "frío" que con una conexión hardware externa (que puede ser con un pequeño interruptor).
Digo esto porque en la TinyFPGA veo que a veces hay problemas para arrancar la imagen ya grabada del usuario porque antes pasa por el bootloader. Si se alimenta con un puerto USB del PC a veces se queda en el bootloader esperando porque detecta conexión y no hay manera de arrancar el programa del usuario... (creo que Luke ya está trabajando en un bootloader más robusto en este sentido), pero en el caso del "Cold Boot" por hardware no habría problema... tenemos robustez de arranque en las distintas imágenes y nos quitamos el FTDI de la placa.
Sí, estoy de acuerdo en todo lo que comentas. De momento no lo hemos hecho por ir a lo seguro y esperar a que esté mejor resuelto cómo se selecciona entre el bootloader u otro bitstream. Aunque sólo fuera poner un interruptor externo, eso ahora es automático en la Alhambra y mucho más cómodo. Y entiendo que esa es una de las principales ventajas de la Alhambra, poder hacer montajes rápido sin necesidad de protoboard. En cualquier caso es un cambio que haremos.
Bueno, no me enrollo más. Enhorabuena y suerte en esta nueva versión.
Saludos
Juan manuel Rico
Muchas gracias!! Seguimos adelante!!
Un saludo,
Eladio
--
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/776db659-0218-4067-94e7-d88fd0f2273b%40googlegroups.com.
Jesús Arroyo
Mar 25, 2018, 7:04:01 PM3/25/18
to FPGAwars: explorando el lado libre
Buenas Eladio!
Qué emocionante ver las especificaciones de la Alhambra II :)
Una cosa que comentamos en su momento es la posibilidad de incluir un chip de memoria en la placa. Como esta FPGA es en teoría 8 veces más grande podemos sintetizar procesadores más completos y potentes. Una de las aplicaciones directas de la memora externa sería almacenar el firmware de esos procesadores. También se podría utilizar para almacenar tablas de datos para operaciones matemáticas, datos capturados por sensores, etc.
Me gustaría saber también si habéis considerado añadir una micro-SD con este mismo fin de tener memoria disponible/accesible por la FPGA.
Gracias!
Un saludo.
Qué emocionante ver las especificaciones de la Alhambra II :)
Una cosa que comentamos en su momento es la posibilidad de incluir un chip de memoria en la placa. Como esta FPGA es en teoría 8 veces más grande podemos sintetizar procesadores más completos y potentes. Una de las aplicaciones directas de la memora externa sería almacenar el firmware de esos procesadores. También se podría utilizar para almacenar tablas de datos para operaciones matemáticas, datos capturados por sensores, etc.
Me gustaría saber también si habéis considerado añadir una micro-SD con este mismo fin de tener memoria disponible/accesible por la FPGA.
Gracias!
Un saludo.
El jueves, 22 de marzo de 2018, 14:44:22 (UTC+1), Eladio Delgado escribió:
1138-4EB
Mar 25, 2018, 11:11:14 PM3/25/18
to FPGAwars: explorando el lado libre
Buenas Eladio,
Si no he entendido mal, la idea es que sólo podemos tener dos maestros conectados al bus, sin utilizar multiplexores externos. Actualmente, esos dos maestros son el FTDI y la FPGA, ya que la flash siempre es un esclavo. Por lo tanto, para utilizar un tercer maestro sin incurrir en problemas eléctricos, lo que propones es utilizar la FPGA como un simple buffer o bypass. Esto permite utilizar el tercer maestro para acceder a la flash, pero no permite configurar la FPGA directamente. Para "programar" la FPGA desde el Arduino habría que:
- Programar la imagen de buffer/bypass en la región asociada al cold boot 00, a través del FTDI.
- Conectar los GPIO escogidos a los pines SPI del Arduino, y los cold boot y el reset a pines digitales.
- Poner las salidas del Arduino a 00 y resetear.
- A través de los pines SPI del Arduino, programar en la región asociada al cold boot 01 de la flash el bitstream del diseño que queremos usar en la FPGA.
- Poner las salidas del Arduino a 01 y resetear.
- (Opcional) los pines GPIO conectados a los SPI del Arduino se pueden utilizar para comunicar Arduino con la aplicación en la FPGA. Es decir, no sólo para el proceso de programación/configuración.
Lo cierto es que me gusta la propuesta. Me parece una solución creativa y muy didáctica para ver las múltiples utilidades de una FPGA.
No obstante, es ligeramente limitante el hecho de no poder acceder "sustituyendo" al FTDI, en vez de tomar la posición de la FPGA. La ventaja principal de un hipotético puerto ISCP es la posibilidad de acceder a la flash y a la FPGA como esclavos, para así guardar los bitstream comprimidos en la flash, de forma que el "tercer" maestro pueda leer, descomprimir al vuelo y programar la FPGA. Sigue siendo posible con la propuesta anterior, sólo que es necesario que los cuatro bitstream asociados al cold boot estén descomprimidos, por lo que cada vez que queremos cambiar uno de ellos, el Arduino tiene que leer, descomprimir al vuelo, volver a escribir en la flash y resetear mediante cold boot. No sé qué vejez puede tener ese requerimiento de reescribir "continuamente" en la flash.
Por lo anterior, ¿sería disponible disponer de orificios en el PCB correspondientes a los pines SPI que van del FTDI a la FPGA/flash?
El sentido es que sea sencillo soldar una tira de pines (no incluida) para:
- Conectar periféricos (esclavos) programables desde el FTDI y/o la FPGA.
- Cortar las pistas del FTDI y conectar un Arduino.
Con la misma base, si hay espacio para dos filas, el "multiplexado" puede ser manual:
En el dibujo anterior las dos filas no están unidas entre si, por lo que serían necesarios jumpers para mantener el circuito intacto. Pero bien pueden estar unidas y que deba cortarlas quien quiera soldar las tiras de pines.
Lo interesante de esta solución es que puede utilizarse para poner un Arduino Pro Mini, entre el FTDI y la FPGA. En la práctica son dos ISCP en serie. Así, con una sola conexión USB:
- Se puede utilizar el FTDI para programar el Arduino, la FPGA y la flash.
- Se puede utilizar el Arduino para programar la FPGA y la flash.
- Se puede utilizar la FPGA para programar la flash.
Creo que lo interesante de posibilitar acceso maestro al SPI, sea arbitrando el FTDI manualmente, automáticamente, o añadiendo un buffer (como en mi propuesta anterior), es que ya se dispondría del hardware necesario para prototiparlo. Es decir, escribir las rutinas software en el Arduino/CortexM para leer la flash, programar la FPGA, recibir un bitstream del FTDI y/o programarse a si mismo a través del FTDI. Cualquier uC que pueda ser programado a través del FTDI, y que disponga de un SPI adicional, puede conectarse a la tira de 2x6 como una "shield".
Entiendo que la idea de hacerlo en una placa es sugerente, pero no sé hasta qué punto mejorará el rendimiento con respecto a Alhambra II + cualquier Arduimo/CortexM ya existente.
Sencillamente genial. Tanto el hecho de que sea posible, como saber los cambios que has hecho en el diseño para reordenar algunas fases. Es un lujo conocer este nivel de detalle.
Ciertamente, se me había pasado por alto el detalle de cómo funcionan la TinyFPGA. Muy interesante. No obstante, creo que vuestra idea original (sólo la FPGA y la flash), sigue teniendo cabida. No sé dónde queda la regulación de la tensión, pero si el módulo que proponéis está pensado para conectarse directamente a una batería de 3,7v, y esto permite ajustar el coste con respecto al conector USB y los 5v, es un producto con un objetivo diferente de la TinyFPGA. Pero es cierto que son márgenes muy pequeños donde la diferencia de precio puede ser despreciable.
Personalmente, creo que no tiene tanto valor el hecho de tener el USB integrado, como la posibilidad de conectar fácil y rápidamente algo que te ofrezca un USB. Estoy pensando particularmente en los cables JTAG, que en este caso sería USB a SPI (ISCP).
¡Buena noticia! Si está en el to-do, algún día será. No hay prisa ninguna ;)
Un saludo
Tener acceso a esos pines no sólo implica el conector sino la electrónica para multiplexar el acceso, ya hay tres dispositivos en el bus (flash, FTDI y FPGA) y hay colisión entre ellos con lo que no podemos añadir más sin multiplexores. Sí se puede hacer de otra forma. Se puede cargar un bitstream que simplemente conecte los pines del SPI de la FPGA a los que tú quieras del GPIO de la placa (cada uno con la config de I/O adecuada). Puedes dejar este bitstream en una zona de la flash reservara sólo para esto y que puedas seleccionar esa zona con los pines de cold boot. De esta forma con un switch externo conectado a los pines de cold boot, activas o desactivas el acceso a los pines del SPI.
Si no he entendido mal, la idea es que sólo podemos tener dos maestros conectados al bus, sin utilizar multiplexores externos. Actualmente, esos dos maestros son el FTDI y la FPGA, ya que la flash siempre es un esclavo. Por lo tanto, para utilizar un tercer maestro sin incurrir en problemas eléctricos, lo que propones es utilizar la FPGA como un simple buffer o bypass. Esto permite utilizar el tercer maestro para acceder a la flash, pero no permite configurar la FPGA directamente. Para "programar" la FPGA desde el Arduino habría que:
- Programar la imagen de buffer/bypass en la región asociada al cold boot 00, a través del FTDI.
- Conectar los GPIO escogidos a los pines SPI del Arduino, y los cold boot y el reset a pines digitales.
- Poner las salidas del Arduino a 00 y resetear.
- A través de los pines SPI del Arduino, programar en la región asociada al cold boot 01 de la flash el bitstream del diseño que queremos usar en la FPGA.
- Poner las salidas del Arduino a 01 y resetear.
- (Opcional) los pines GPIO conectados a los SPI del Arduino se pueden utilizar para comunicar Arduino con la aplicación en la FPGA. Es decir, no sólo para el proceso de programación/configuración.
Lo cierto es que me gusta la propuesta. Me parece una solución creativa y muy didáctica para ver las múltiples utilidades de una FPGA.
No obstante, es ligeramente limitante el hecho de no poder acceder "sustituyendo" al FTDI, en vez de tomar la posición de la FPGA. La ventaja principal de un hipotético puerto ISCP es la posibilidad de acceder a la flash y a la FPGA como esclavos, para así guardar los bitstream comprimidos en la flash, de forma que el "tercer" maestro pueda leer, descomprimir al vuelo y programar la FPGA. Sigue siendo posible con la propuesta anterior, sólo que es necesario que los cuatro bitstream asociados al cold boot estén descomprimidos, por lo que cada vez que queremos cambiar uno de ellos, el Arduino tiene que leer, descomprimir al vuelo, volver a escribir en la flash y resetear mediante cold boot. No sé qué vejez puede tener ese requerimiento de reescribir "continuamente" en la flash.
Por lo anterior, ¿sería disponible disponer de orificios en el PCB correspondientes a los pines SPI que van del FTDI a la FPGA/flash?
El sentido es que sea sencillo soldar una tira de pines (no incluida) para:
- Conectar periféricos (esclavos) programables desde el FTDI y/o la FPGA.
- Cortar las pistas del FTDI y conectar un Arduino.
Con la misma base, si hay espacio para dos filas, el "multiplexado" puede ser manual:
En el dibujo anterior las dos filas no están unidas entre si, por lo que serían necesarios jumpers para mantener el circuito intacto. Pero bien pueden estar unidas y que deba cortarlas quien quiera soldar las tiras de pines.
Lo interesante de esta solución es que puede utilizarse para poner un Arduino Pro Mini, entre el FTDI y la FPGA. En la práctica son dos ISCP en serie. Así, con una sola conexión USB:
- Se puede utilizar el FTDI para programar el Arduino, la FPGA y la flash.
- Se puede utilizar el Arduino para programar la FPGA y la flash.
- Se puede utilizar la FPGA para programar la flash.
La idea de tener en una placa un ARM + FPGA hace tiempo que la tengo en mente, todos los que hemos trabajado con microcontroladores hemos echado en falta muchas veces algo de lógica programable en el micro. Esta idea tiene muchas aplicaciones en control industrial y me gustaría hacerla con un M4 o un M7.
Creo que lo interesante de posibilitar acceso maestro al SPI, sea arbitrando el FTDI manualmente, automáticamente, o añadiendo un buffer (como en mi propuesta anterior), es que ya se dispondría del hardware necesario para prototiparlo. Es decir, escribir las rutinas software en el Arduino/CortexM para leer la flash, programar la FPGA, recibir un bitstream del FTDI y/o programarse a si mismo a través del FTDI. Cualquier uC que pueda ser programado a través del FTDI, y que disponga de un SPI adicional, puede conectarse a la tira de 2x6 como una "shield".
Entiendo que la idea de hacerlo en una placa es sugerente, pero no sé hasta qué punto mejorará el rendimiento con respecto a Alhambra II + cualquier Arduimo/CortexM ya existente.
Ese diseño dual que comentas es posible, bastaría con montar sockets apilables en lugar de los normales. Esto va a ser posible porque he diseñado la placa de forma que todos los componentes necesarios para funcionar son SMD y opcionalmente se puede enviar la placa con las tiras de pines y los zócalos sin soldar. Antes, el switch de alimentación, el jack y el pulsador de reset se montaban en la misma fase que los pines y sin estos componentes no podías usar todas las funciones de la placa. Ahora podemos enviar la placa sin montar las tiras de pines y todo funciona sin los componentes de inserción, la puedes empezar a usar tal cual te llega. Luego tú puedes soldar el tipo de zócalos y pines que quieras y esto permite el montaje que comentas. Además hemos modificado el diseño térmico del PCB para que sea mucho más fácil de soldar.En cuanto a comunicación habría que conectar una o las dos placas como comentas, según la aplicación. En cuanto a la alimentación, la Alhambra puede alimentar al Arduino a través del pin de 5V y al revés.
Sencillamente genial. Tanto el hecho de que sea posible, como saber los cambios que has hecho en el diseño para reordenar algunas fases. Es un lujo conocer este nivel de detalle.
Esta opción que comentas es muy habitual en placas de evaluación de microcontroladores pero en nuestro caso creo que el planteamiento de tenerlo todo en una placa para empezar a hacer cosas con las FPGAs, parece acertado.Sí que vemos interesante tener módulos con la FPGA y la memoria (programables con la Alhambra o con un Arduino) para la aplicación que has desarrollado previamente con la Alhambra (u otra placa con iCE40). Es una idea que teníamos desde el principio y que ahora es más interesante con la aparición de la TinyFPGA. El módulo que teníamos en mente es exactamente una TinyFPGA salvo por la comunicación USB. No se nos había ocurrido implementar la interfaz USB en la propia FPGA. Con el bootloader que ha desarrollado Luke, este módulo pasa a ser "autónomo", lo programas directamente con el PC sin necesidad de otra placa, y sólo has añadido al módulo un conector USB y dos resistencias.
Ciertamente, se me había pasado por alto el detalle de cómo funcionan la TinyFPGA. Muy interesante. No obstante, creo que vuestra idea original (sólo la FPGA y la flash), sigue teniendo cabida. No sé dónde queda la regulación de la tensión, pero si el módulo que proponéis está pensado para conectarse directamente a una batería de 3,7v, y esto permite ajustar el coste con respecto al conector USB y los 5v, es un producto con un objetivo diferente de la TinyFPGA. Pero es cierto que son márgenes muy pequeños donde la diferencia de precio puede ser despreciable.
Personalmente, creo que no tiene tanto valor el hecho de tener el USB integrado, como la posibilidad de conectar fácil y rápidamente algo que te ofrezca un USB. Estoy pensando particularmente en los cables JTAG, que en este caso sería USB a SPI (ISCP).
Cierto, no son complejas ni costosas. Seguramente las hagamos pronto, la de VGA y la de displays de 7 segmentos + pulsadores son dos que llevan tiempo en el to-do, pero en fin, el tiempo es lo que limita :-)
¡Buena noticia! Si está en el to-do, algún día será. No hay prisa ninguna ;)
Un saludo
1138-4EB
Mar 25, 2018, 11:45:58 PM3/25/18
to FPGAwars: explorando el lado libre
Hola Juanma!
Veo que las ideas que proponemos van en el mismo sentido XD. Sólo un apunte que creo es importante tener presente: las FPGAs no son la plataforma más adecuada para "programar" un bootloader pensado para interactuar con un PC en el conexto de un entorno de desarrollo. El diseño hardware en general es muy adecuado para paralelizar tareas relativamente regulares y poco complejas. Para aplicaciones que requieren hacer muchas cosas diferentes, pero dedicar muy poco tiempo a cada una, es más adecuado el software (si el tiempo de ejecución es aceptable). Por ello, quizá sería incluso razonable que el bootloader fuera un Lattuino, y así la lógica de la aplicación sería firmware (es decir, software).
Esto quiere decir que, subrayando el notable mérito de Luke al escribir el bootloader, y estando seguro de que resolverá este "bug" y otros que puedan surgir, es difícil que "crezca" funcionalmente; simplemente porque lleva mucho tiempo. De hecho, el IP es un conversor de UART a SPI, muy en la línea de lo que comentaba a Eladio en un mensaje anterior. Es decir, la funcionalidad del bootloader en realidad está en el PC, no en la placa.
Enlazándolo con "mi libro", facilitar la conexión de un Arduino como maestro al SPI, o utilizar Lattuino como bootloader, facilitan que el bootloader tenga más funcionalidades. Digamos que el bootloader puede ser el árbitro del sistema, que decide en función del estado de diferentes entradas, cómo debe reordenar la flash antes de reconfigurar la FPGA. Recibir una comunicación por USB es una de las entradas que puede provocar un cambio de estado. Pero también puede ser una pantalla táctil con una tarjeta SD. De hecho, una "demo" muy interesante para el cold boot sería seleccionar en la pantalla uno de los ¿cuántos bitstream calculamos que cabían? y que automáticamente se reconfigure la FPGA. Yo qué sé, se me ocurre poder probar/usar todos los circuitos de los tutoriales de Obijuan uno detrás de otro, sin tener que tocar el PC para nada. Imaginando un juguete didáctico: un soporte impreso en 3D que sostenga el LCD y muestre sólo las conexiones de la Alhambra, en un pack con periféricos impresos en 3D.
Lo anterior es potencialmente fáctible con el diseño actual, pero requeriría necesariamente algo de hardware externo, y sería una solución más hack/ñapa que elegante.
También es posible que el FTDI que incluye la Alhambra permita ejecutar código arbitrario. Según tengo entendido, es programable, pero sólo en lo que respecta a qué interfaces se convierten; no permite ejecutar código sin intervención del maestro/PC. Sin embargo, si se puede escribir código en C y que se ejecute continuamente (con modo de bajo consumo, etc.), todo lo que he comentado sobre Arduino/CortexM podría hacerse directamente con el FTDI. No es la mejor plataforma para ello, pero sería posible.
Un saludo
Veo que las ideas que proponemos van en el mismo sentido XD. Sólo un apunte que creo es importante tener presente: las FPGAs no son la plataforma más adecuada para "programar" un bootloader pensado para interactuar con un PC en el conexto de un entorno de desarrollo. El diseño hardware en general es muy adecuado para paralelizar tareas relativamente regulares y poco complejas. Para aplicaciones que requieren hacer muchas cosas diferentes, pero dedicar muy poco tiempo a cada una, es más adecuado el software (si el tiempo de ejecución es aceptable). Por ello, quizá sería incluso razonable que el bootloader fuera un Lattuino, y así la lógica de la aplicación sería firmware (es decir, software).
Esto quiere decir que, subrayando el notable mérito de Luke al escribir el bootloader, y estando seguro de que resolverá este "bug" y otros que puedan surgir, es difícil que "crezca" funcionalmente; simplemente porque lleva mucho tiempo. De hecho, el IP es un conversor de UART a SPI, muy en la línea de lo que comentaba a Eladio en un mensaje anterior. Es decir, la funcionalidad del bootloader en realidad está en el PC, no en la placa.
Enlazándolo con "mi libro", facilitar la conexión de un Arduino como maestro al SPI, o utilizar Lattuino como bootloader, facilitan que el bootloader tenga más funcionalidades. Digamos que el bootloader puede ser el árbitro del sistema, que decide en función del estado de diferentes entradas, cómo debe reordenar la flash antes de reconfigurar la FPGA. Recibir una comunicación por USB es una de las entradas que puede provocar un cambio de estado. Pero también puede ser una pantalla táctil con una tarjeta SD. De hecho, una "demo" muy interesante para el cold boot sería seleccionar en la pantalla uno de los ¿cuántos bitstream calculamos que cabían? y que automáticamente se reconfigure la FPGA. Yo qué sé, se me ocurre poder probar/usar todos los circuitos de los tutoriales de Obijuan uno detrás de otro, sin tener que tocar el PC para nada. Imaginando un juguete didáctico: un soporte impreso en 3D que sostenga el LCD y muestre sólo las conexiones de la Alhambra, en un pack con periféricos impresos en 3D.
Lo anterior es potencialmente fáctible con el diseño actual, pero requeriría necesariamente algo de hardware externo, y sería una solución más hack/ñapa que elegante.
También es posible que el FTDI que incluye la Alhambra permita ejecutar código arbitrario. Según tengo entendido, es programable, pero sólo en lo que respecta a qué interfaces se convierten; no permite ejecutar código sin intervención del maestro/PC. Sin embargo, si se puede escribir código en C y que se ejecute continuamente (con modo de bajo consumo, etc.), todo lo que he comentado sobre Arduino/CortexM podría hacerse directamente con el FTDI. No es la mejor plataforma para ello, pero sería posible.
Un saludo
Message has been deleted
Juanma Rico
Mar 26, 2018, 2:53:19 PM3/26/18
to FPGAwars: explorando el lado libre
El lunes, 26 de marzo de 2018, 5:45:58 (UTC+2), 1138-4EB escribió:
Hola Juanma!
¡Hola Unai! ;)
Veo que las ideas que proponemos van en el mismo sentido XD. Sólo un apunte que creo es importante tener presente: las FPGAs no son la plataforma más adecuada para "programar" un bootloader pensado para interactuar con un PC en el conexto de un entorno de desarrollo. El diseño hardware en general es muy adecuado para paralelizar tareas relativamente regulares y poco complejas. Para aplicaciones que requieren hacer muchas cosas diferentes, pero dedicar muy poco tiempo a cada una, es más adecuado el software (si el tiempo de ejecución es aceptable). Por ello, quizá sería incluso razonable que el bootloader fuera un Lattuino, y así la lógica de la aplicación sería firmware (es decir, software).
Me gusta esa idea... :))
Esto quiere decir que, subrayando el notable mérito de Luke al escribir el bootloader, y estando seguro de que resolverá este "bug" y otros que puedan surgir, es difícil que "crezca" funcionalmente; simplemente porque lleva mucho tiempo. De hecho, el IP es un conversor de UART a SPI, muy en la línea de lo que comentaba a Eladio en un mensaje anterior. Es decir, la funcionalidad del bootloader en realidad está en el PC, no en la placa.
Pues no sé exactamente como funciona el bootloader de la TinyFPGA (no sabía que era un UART, la verdad), pero entiendo lo que me dices... :))
Enlazándolo con "mi libro", facilitar la conexión de un Arduino como maestro al SPI, o utilizar Lattuino como bootloader, facilitan que el bootloader tenga más funcionalidades. Digamos que el bootloader puede ser el árbitro del sistema, que decide en función del estado de diferentes entradas, cómo debe reordenar la flash antes de reconfigurar la FPGA. Recibir una comunicación por USB es una de las entradas que puede provocar un cambio de estado. Pero también puede ser una pantalla táctil con una tarjeta SD. De hecho, una "demo" muy interesante para el cold boot sería seleccionar en la pantalla uno de los ¿cuántos bitstream calculamos que cabían? * y que automáticamente se reconfigure la FPGA. Yo qué sé, se me ocurre poder probar/usar todos los circuitos de los tutoriales de Obijuan uno detrás de otro, sin tener que tocar el PC para nada. ** Imaginando un juguete didáctico: un soporte impreso en 3D que sostenga el LCD y muestre sólo las conexiones de la Alhambra, en un pack con periféricos impresos en 3D.
* A lo bruto y sin comprimir, en la memoria flash de la iceZum Alhambra (de 32Mb, la TinyFPGA-B2 tiene 4Mb y la nueva TinyFPGA-Bx tiene 8Mb) he llegado a meter todos los bitstream de los tutoriales de Obijuan para la iCEStick (por aquel entonces 56, si no rescuerdo mal), pero caben 128 bitstream diferentes, con sus nombres respectivos, todo con las mismas herramientas del proyecto icestorm un poco modificadas por mi. (Orgulloso estoy de aquello, oye... ;) )
** Esa era mi meta, el no tener que usar el PC para cambiar de bitstream pregrabado... pero ya sabes... los vectores a elegir desde la iCE40 como máximo son cuatro y la granulometría de la flash impide cambiar los vectores de la flash si no se hace en bloques de 4k... la BRAM en la FPGA no es suficiente, con lo que se necesita una RAM externa que sirva de buffer... en ello estaba, ya con la RAM por SPI en el buzón de casa, cuando llegó Obijuan con su MonsterLED y me vino el SAV de la VGA.... jajajajajajajajaja :))
Lo anterior es potencialmente fáctible con el diseño actual, pero requeriría necesariamente algo de hardware externo, y sería una solución más hack/ñapa que elegante.
jejejejeje, efectivamente... :))
También es posible que el FTDI que incluye la Alhambra permita ejecutar código arbitrario. Según tengo entendido, es programable, pero sólo en lo que respecta a qué interfaces se convierten; no permite ejecutar código sin intervención del maestro/PC. Sin embargo, si se puede escribir código en C y que se ejecute continuamente (con modo de bajo consumo, etc.), todo lo que he comentado sobre Arduino/CortexM podría hacerse directamente con el FTDI. No es la mejor plataforma para ello, pero sería posible.
Eso ya son palabras mayores... yo a lo máximo que he llegado con el FTDI es a programarlo para cambiar el nombre que proporciona al PC cuando se conecta por USB... y ya me pareció mucho riesgo si en un error podía quedarme sin conectividad con la FPGA... jajajajajaja :))
Un saludo
Dos para ti... ;)
1138-4EB
Mar 26, 2018, 11:24:11 PM3/26/18
to FPGAwars: explorando el lado libre
26 de marzo de 2018, Juanma:
Me gusta esa idea... :))
Lattuino ya tiene un SPI. Habría que añadir un segundo SPI, y utilizar el "bootloader" de tinyFPGA entre el USB y el Lattuino. O, alternativamente, integrarlo en el Lattuino, de forma que disponga de una entrada USB con una región directamente mapeada en memoria de datos.
Pues no sé exactamente como funciona el bootloader de la TinyFPGA (no sabía que era un UART, la verdad), pero entiendo lo que me dices... :))
La explicación general y los "opcodes" que se utilizan están explicados de forma bastante sencilla (al menos para entender cuál es el planteamiento general de la solución): https://github.com/tinyfpga/TinyFPGA-Bootloader#the-tinyfpga-usb-bootloader
* A lo bruto y sin comprimir, en la memoria flash de la iceZum Alhambra (de 32Mb, la TinyFPGA-B2 tiene 4Mb y la nueva TinyFPGA-Bx tiene 8Mb) he llegado a meter todos los bitstream de los tutoriales de Obijuan para la iCEStick (por aquel entonces
56, si no rescuerdo mal), pero caben 128 bitstream diferentes, con sus nombres respectivos, todo con las mismas herramientas del proyecto icestorm un poco modificadas por mi. (Orgulloso estoy de aquello, oye... ;) )
¡Y no es para menos! Fue un sprint de aprendizaje muy interesante y efectivo ;). Me sonaba que andábamos por encima de la centena, pero creía que era con compresión. 128 sin comprimir ya es muchísimo.
** Esa era mi meta, el no tener que usar el PC para cambiar de bitstream pregrabado... pero ya sabes... los vectores a elegir desde la iCE40 como máximo son cuatro y la granulometría de la flash impide cambiar los vectores de la flash si no se hace en bloques de 4k... la BRAM en la FPGA no es suficiente, con lo que se necesita una RAM externa que sirva de buffer... en ello estaba, ya con la RAM por SPI en el buzón de casa, cuando llegó Obijuan con su MonsterLED y me vino el SAV de la VGA.... jajajajajajajajaja :))
Por eso mismo estoy "insistiendo" en disponer de alguna manera de acceso maestro al SPI sustituyendo al FTDI, sea con más o menos modificaciones a la placa, sea la opción por defecto o una ñapa factible. Cuando miramos el tema del cold-boot, exploramos cómo funcionaba la SPI y qué posibilidades había, etc. el SAV se fue a pique en cuanto vimos que el hardware requería alteraciones fuera del target de la Alhambra. En otras palabras: podríamos soldar los pines del cold-boot, añadir algo de hardware externo y/o anular el FTDI. Sin embargo, habiendo comprobado los pasos anteriores (y después de las modificaciones que hiciste a icestorm), sabíamos que iba a funcionar y cómo hacerlo; sencillamente, no hay motivación para aplicarlo si sólo dos de los cuatro gatos van a poder darle uso.
Así, estoy tratando de "minimizar daños"; hacer sólo las modificaciones indispensables para alterar lo mínimo posible el diseño que parece estar bastante avanzado ya. Si la ñapa es coger un cutter y hacer un corte recto, nada más, es más probable que otros usuarios se animen a "sacrificar" una placa, sabiendo que no pierden funcionalidad (aunque las tripas cambien). Si, además, es reversible o se puede hacer sin cortes, es ideal.
Estoy de acuerdo en que lo "mejor" sería hacer un placa pequeñita con el FTDI + LEDs + botones + conector de 12-20 pines, y vender el pack de Alhambra + (opcional) módulo/cable Debug/Prog. El módulo/cable podría utilizarse para interactuar con cualquier periférico SPI. Y la Alhambra sola podría ser más económica para los usuarios que ya disponen de un Arduino, FTDI, CH340, PL2303... Además, la Alhambra tendría más espacio para que los componentes estén más espaciados, o para añadir memoria RAM externa, o lector microSD (que proponía Jesús).
Pero esto es un cambio de planteamiento de producto, y como ha comentado Eladio, quieren tenerlo todo en una sola placa y que tenga el tamaño de un Arduino Uno. Por eso propuse sólo la "separación" en el PCB, para que siga siendo una placa, pero poder partirlo fácilmente. Eladio lo ha desestimado también, y es razonable porque no tiene que ser nada fácil sacar espacio extra y rediseñar los planos de alimentación/masa, en una placa que ya tiene muchos componentes.
Eso ya son palabras mayores... yo a lo máximo que he llegado con el FTDI es a programarlo para cambiar el nombre que proporciona al PC cuando se conecta por USB... y ya me pareció mucho riesgo si en un error podía quedarme sin conectividad con la FPGA... jajajajajaja :))
Me suena vagamente que, cuando investigaron el tema de la actualización de drivers que "mataba" los Arduinos, concluyeron que algunos FTDI eran en realidad un uC, no un ASIC. No recuerdo si eran los originales o las copias. El caso es que, aunque el original sea un uC, si no se proporcionan el SDK y la datasheet es complicado utilizarlo. De hecho, no sé qué diferencia de coste y consumo habrá para seguir utilizando FTDI+EEPROM en la Alhambra, en vez de un Atmega32u4 o Attiny.
Juanma Rico
Mar 27, 2018, 6:53:38 PM3/27/18
to FPGAwars: explorando el lado libre
El martes, 27 de marzo de 2018, 5:24:11 (UTC+2), 1138-4EB escribió:
26 de marzo de 2018, Juanma:Me gusta esa idea... :))
Lattuino ya tiene un SPI. Habría que añadir un segundo SPI, y utilizar el "bootloader" de tinyFPGA entre el USB y el Lattuino. O, alternativamente, integrarlo en el Lattuino, de forma que disponga de una entrada USB con una región directamente mapeada en memoria de datos.
Sí más o menos entiendo lo que me quieres decir... Habrá que probar el Lattuino en la TinyFPGA... :)
Pues no sé exactamente como funciona el bootloader de la TinyFPGA (no sabía que era un UART, la verdad), pero entiendo lo que me dices... :))
La explicación general y los "opcodes" que se utilizan están explicados de forma bastante sencilla (al menos para entender cuál es el planteamiento general de la solución): https://github.com/tinyfpga/TinyFPGA-Bootloader#the-tinyfpga-usb-bootloader
Sí, a esta página ya le había dado unas cuantas vueltas... de hecho eso es lo que me ha sorprendido, que no he visto por ningún lado que hubiera un módulo UART... pensé que era un puente directo entre un USB y el SPI. :(
* A lo bruto y sin comprimir, en la memoria flash de la iceZum Alhambra (de 32Mb, la TinyFPGA-B2 tiene 4Mb y la nueva TinyFPGA-Bx tiene 8Mb) he llegado a meter todos los bitstream de los tutoriales de Obijuan para la iCEStick (por aquel entonces56, si no rescuerdo mal), pero caben 128 bitstream diferentes, con sus nombres respectivos, todo con las mismas herramientas del proyecto icestorm un poco modificadas por mi. (Orgulloso estoy de aquello, oye... ;) )
¡Y no es para menos! Fue un sprint de aprendizaje muy interesante y efectivo ;). Me sonaba que andábamos por encima de la centena, pero creía que era con compresión. 128 sin comprimir ya es muchísimo.
Pues sí, fue muy interesante... y por aquel entonces yo no conseguí llenarlo... ahora igual con todos los proyectos de VGA igual sí... :))
El tema está en poder intercambiar todos ellos desde la propia FPGA, sin necesidad del PC... si con la RAM SPI fuera suficiente... ¡igual me vuelvo a animar!. :))
** Esa era mi meta, el no tener que usar el PC para cambiar de bitstream pregrabado... pero ya sabes... los vectores a elegir desde la iCE40 como máximo son cuatro y la granulometría de la flash impide cambiar los vectores de la flash si no se hace en bloques de 4k... la BRAM en la FPGA no es suficiente, con lo que se necesita una RAM externa que sirva de buffer... en ello estaba, ya con la RAM por SPI en el buzón de casa, cuando llegó Obijuan con su MonsterLED y me vino el SAV de la VGA.... jajajajajajajajaja :))
Por eso mismo estoy "insistiendo" en disponer de alguna manera de acceso maestro al SPI sustituyendo al FTDI, sea con más o menos modificaciones a la placa, sea la opción por defecto o una ñapa factible. Cuando miramos el tema del cold-boot, exploramos cómo funcionaba la SPI y qué posibilidades había, etc. el SAV se fue a pique en cuanto vimos que el hardware requería alteraciones fuera del target de la Alhambra. En otras palabras: podríamos soldar los pines del cold-boot, añadir algo de hardware externo y/o anular el FTDI. Sin embargo, habiendo comprobado los pasos anteriores (y después de las modificaciones que hiciste a icestorm), sabíamos que iba a funcionar y cómo hacerlo; sencillamente, no hay motivación para aplicarlo si sólo dos de los cuatro gatos van a poder darle uso.
Pues sí... hay que reclutar a más gatos... :)))
Igual si hacemos un pull-request a Clifford con los cambios y los acepta, daríamos un pasito para llamar la atención a ciertos felinos... ¡Me estoy animando yo sólo! jajajajajaja
Así, estoy tratando de "minimizar daños"; hacer sólo las modificaciones indispensables para alterar lo mínimo posible el diseño que parece estar bastante avanzado ya. Si la ñapa es coger un cutter y hacer un corte recto, nada más, es más probable que otros usuarios se animen a "sacrificar" una placa, sabiendo que no pierden funcionalidad (aunque las tripas cambien). Si, además, es reversible o se puede hacer sin cortes, es ideal.
Estoy de acuerdo en que lo "mejor" sería hacer un placa pequeñita con el FTDI + LEDs + botones + conector de 12-20 pines, y vender el pack de Alhambra + (opcional) módulo/cable Debug/Prog. El módulo/cable podría utilizarse para interactuar con cualquier periférico SPI. Y la Alhambra sola podría ser más económica para los usuarios que ya disponen de un Arduino, FTDI, CH340, PL2303... Además, la Alhambra tendría más espacio para que los componentes estén más espaciados, o para añadir memoria RAM externa, o lector microSD (que proponía Jesús).
Pero esto es un cambio de planteamiento de producto, y como ha comentado Eladio, quieren tenerlo todo en una sola placa y que tenga el tamaño de un Arduino Uno. Por eso propuse sólo la "separación" en el PCB, para que siga siendo una placa, pero poder partirlo fácilmente. Eladio lo ha desestimado también, y es razonable porque no tiene que ser nada fácil sacar espacio extra y rediseñar los planos de alimentación/masa, en una placa que ya tiene muchos componentes.
Eso ya son palabras mayores... yo a lo máximo que he llegado con el FTDI es a programarlo para cambiar el nombre que proporciona al PC cuando se conecta por USB... y ya me pareció mucho riesgo si en un error podía quedarme sin conectividad con la FPGA... jajajajajaja :))
Me suena vagamente que, cuando investigaron el tema de la actualización de drivers que "mataba" los Arduinos, concluyeron que algunos FTDI eran en realidad un uC, no un ASIC. No recuerdo si eran los originales o las copias. El caso es que, aunque el original sea un uC, si no se proporcionan el SDK y la datasheet es complicado utilizarlo. De hecho, no sé qué diferencia de coste y consumo habrá para seguir utilizando FTDI+EEPROM en la Alhambra, en vez de un Atmega32u4 o Attiny.
Yo, personalmente, ya visto que se dispone de un bootloader probado y funcionando gracias al "Warm boot" (como el de la TinyFPGA) y que además se va a disponer de LUTs de sobra (incluso para tu propuesta del Lattuino) y los pines del "Cold boot" van a estar disponibles para poder elegir el bitstream físicamente si fuera necesario y así hacer más robusto el arranque y la comunicación con el PC... como que no termina de convencerme el seguir arrastrando el lastre del FTDI, pero bueno... comprendo que es cuestión de querer ir a lo conocido o seguro y no de arriesgarse en emplear un tiempo de desarroloo que igual no se tiene.
Bueno... todo contestado... :)))
Saludos
Juan Manuel Rico
1138-4EB
Mar 28, 2018, 2:33:09 AM3/28/18
to FPGAwars: explorando el lado libre
28 de marzo de 2018, Juanma:
Sí, a esta página ya le había dado unas cuantas vueltas... de hecho eso es lo que me ha sorprendido, que no he visto por ningún lado que hubiera un módulo UART... pensé que era un puente directo entre un USB y el SPI. :(
Concretamente dice "It implements a USB virtual serial port to SPI flash bridge on the FPGA fabric itself". Ese "virtual serial port" quiere decir que, de entre todas las funcionalidades/protocolos que se pueden utilizar en un dispositivo USB, se ha implementado una UART. Lo cual es interesante, porque creo que sirven los mismos drivers que utiliza apio.
Pues sí, fue muy interesante... y por aquel entonces yo no conseguí llenarlo... ahora igual con todos los proyectos de VGA igual sí... :))
El tema está en poder intercambiar todos ellos desde la propia FPGA, sin necesidad del PC... si con la RAM SPI fuera suficiente... ¡igual me vuelvo a animar!. :))
Diría que es posible incluso sin RAM externa (utilizando sólo la flash). Siendo cierto que la flash sólo puede borrarse en bloques de 4k, se pueden leer y escribir segmentos más pequeños. Por lo tanto, en vez de copiar el bitstream en una sola operación, se puede implementar un proceso que primero borre 4k y después vaya leyendo y escribiendo segmentos de 256, 512, 1024... elementos en un bucle. Así es como funciona en realidad el bootloader de TinyFPGA: https://github.com/tinyfpga/TinyFPGA-Bootloader#spi-flash-programming-flow
Pero, como he comentado, en el caso de TinyFPGA el bucle está ejecutándose en el PC. Así, habría que implementarlo en HDL, programar el Lattuino o tener una "shield", para que fuera "autónomo".
Pues sí... hay que reclutar a más gatos... :)))
Igual si hacemos un pull-request a Clifford con los cambios y los acepta, daríamos un pasito para llamar la atención a ciertos felinos... ¡Me estoy animando yo sólo! jajajajajaja
Creo que para que sea "llamativo" faltan un par de detalles:
- Estructurar/documentar el formato utilizado para componer el binario de programación de la memoria. E.g., al principio está el menú de Lattice, entre las direcciones X e Y hay una tabla con punteros a todos los bitstream (opcionalmente indicando si están comprimidos o no), entre las direcciones W y Z hay espacio disponible para almacenamiento de datos, el espacio entre I y J se espera que sea utilizado como RAM y sobreescrito arbitrariamente, etc. Básicamente, añadir unos cuantos printf a icestorm. Así, quien reciba el binario sabe qué hacer con ello.
- Proveer un prototipo funcional en el que se muestre cómo es posible mirar un bitstream en la tabla, hacer que uno de los registros de warm/cold boot apunte al mismo, y resetear con ese diseño. Creo que de cara a una pull-request da exactamente igual si eso se hace con el FTDI, HDL, Lattuino, Arduino... Lo relevante es que las funciones para reconfigurar la FPGA estén claramente diferenciadas de las utilizadas para generar el binario original. Las dos opciones más "directas":
- Utilizar el bootloader de TinyFPGA y escribirlo en el PC.
- Seguir la sugerencia de Eladio y hacer accesibles a través de pines GPIO los correpondientes al cold/warm boot (dos bits de selección + un bit de trigger) y al SPI (sck, mosi, miso, cs). Conectar un Arduino, que sea el que utilice el SPI para gestionar la flash, y que pierda el control en cuanto empieza el reset. Cada vez que se quiera reconfigurar, hay que resetear a la imagen 0, informar a Arduino de que tiene el control, reordenar y resetear.
Juanma Rico
Mar 28, 2018, 5:44:09 AM3/28/18
to FPGAwars: explorando el lado libre
Buenas de nuevo Unai,
Me tienes muy entretenido últimamente... me gusta, me gusta que te pases por aquí... jejejejeje :))
El miércoles, 28 de marzo de 2018, 8:33:09 (UTC+2), 1138-4EB escribió:
28 de marzo de 2018, Juanma:Sí, a esta página ya le había dado unas cuantas vueltas... de hecho eso es lo que me ha sorprendido, que no he visto por ningún lado que hubiera un módulo UART... pensé que era un puente directo entre un USB y el SPI. :(
Concretamente dice "It implements a USB virtual serial port to SPI flash bridge on the FPGA fabric itself". Ese "virtual serial port" quiere decir que, de entre todas las funcionalidades/protocolos que se pueden utilizar en un dispositivo USB, se ha implementado una UART. Lo cual es interesante, porque creo que sirven los mismos drivers que utiliza apio.
jajajajajajaja, te puedes creer que lo he leido varias veces, incluso le eché un vistazo rápido antes de contestarte y no había visto lo de "virtual serial port"...
¡Y está en el primer párrafo! jajajajaja, que desastre soy leyendo inglés... por eso tú eres el maestro y yo el joven padawan, porque estas cosas, entre otras, no se te escapan... :)))
Bueno... no sé si utiliza los mismos drivers que Apio... lo que sí te puedo decir es que en Windows 7 en ninguno de mis puertos USB del portátil funciona (ni instalando el driver que aconseja Luke) y en GNU/Linux sólo me funciona en un puerto USB bajo Ubuntu y como te digo, el bootloader no carga el bitstream del usuario quedándose con el control si lo alimentas por ese puerto. :((
Ahora que ya he rebajado un poco el SAV con la adaptación del Pong a la collección iPxs, igual me centro un poco en el bootloader y lo investigo más en profundidad, porque está claro que falta me hace... Lo traduciré antes... :)))
Pues sí, fue muy interesante... y por aquel entonces yo no conseguí llenarlo... ahora igual con todos los proyectos de VGA igual sí... :))
El tema está en poder intercambiar todos ellos desde la propia FPGA, sin necesidad del PC... si con la RAM SPI fuera suficiente... ¡igual me vuelvo a animar!. :))
Diría que es posible incluso sin RAM externa (utilizando sólo la flash). Siendo cierto que la flash sólo puede borrarse en bloques de 4k, se pueden leer y escribir segmentos más pequeños. Por lo tanto, en vez de copiar el bitstream en una sola operación, se puede implementar un proceso que primero borre 4k y después vaya leyendo y escribiendo segmentos de 256, 512, 1024... elementos en un bucle. Así es como funciona en realidad el bootloader de TinyFPGA: https://github.com/tinyfpga/TinyFPGA-Bootloader#spi-flash-programming-flow
¡¡Uy!! ¡Pues eso lo tengo que probar! Si se puede hacer... perfecto, no se necesita ningún componente exterior, otro motivo más para profundizar en el bootloader. :))
Pero, como he comentado, en el caso de TinyFPGA el bucle está ejecutándose en el PC. Así, habría que implementarlo en HDL, programar el Lattuino o tener una "shield", para que fuera "autónomo".
¡Vaya!, no todo es perfecto... y sabiendo que Lattuino no entra (en condiciones) en una 1K... me veo al final soldando la RAM y haciendo una "shield" con ella... total, ya que se hace una shield... :))
Pues sí... hay que reclutar a más gatos... :)))
Igual si hacemos un pull-request a Clifford con los cambios y los acepta, daríamos un pasito para llamar la atención a ciertos felinos... ¡Me estoy animando yo sólo! jajajajajaja
Creo que para que sea "llamativo" faltan un par de detalles:
- Estructurar/documentar el formato utilizado para componer el binario de programación de la memoria. E.g., al principio está el menú de Lattice, entre las direcciones X e Y hay una tabla con punteros a todos los bitstream (opcionalmente indicando si están comprimidos o no), entre las direcciones W y Z hay espacio disponible para almacenamiento de datos, el espacio entre I y J se espera que sea utilizado como RAM y sobreescrito arbitrariamente, etc. Básicamente, añadir unos cuantos printf a icestorm. Así, quien reciba el binario sabe qué hacer con ello.
Bueno, en esencia, y haciendo memoria, los cambios que hice fueron en dos programas muy básicos del conjunto de programas de icestorm tools.
Uno es el icepack, que genera un mega-bitstream a partir de bitstream individuales (en nuestro caso con 32Mb, los posibles 128 bitstream que entran) y que yo modifiqué para que incluyera el nombre del fichero (.bin) al empaquetar. Este nombre se guarda en la zona de comentarios que también utiliza, al parecer, la herramienta de Lattice (iceCube2), con lo que está documentada en el proyecto icestorm.
Luego este mega-bitstream generado se carga en la flash mediante el iceprog que también modifiqué para poder consultar la lista de nombres y poder intercambiar los vectores de acceso (grabar los primeros 4k) para no tener que volver a grabar el bitstream si se encontrara entre esos 128 pregrabados (con lo que se ahorra tiempo si solo hay que grabar 4k), todo está en la ayuda del binario explicado... en fin, esto sé que lo sabes, pero era para situar a los que nos lean.
<Incisillo>
Por si acaso...
Si tenéis curiosidad o queréis probarlo el código está en este hilo: https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/discussion
Y el código con funcionalidad final en este mensaje: https://groups.google.com/d/msg/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/MURi0XStAwAJ
Tened en cuenta que icestorm tools ha seguido desarrollándose y no he integrado los cambios en la rama principal, luego funcionar funciona... pero igual está desactualizado con la rama principal del proyecto. Si hay muchas personas interesadas igual me animo a retomarlo... ;P
</Incisillo>
- Proveer un prototipo funcional en el que se muestre cómo es posible mirar un bitstream en la tabla, hacer que uno de los registros de warm/cold boot apunte al mismo, y resetear con ese diseño. Creo que de cara a una pull-request da exactamente igual si eso se hace con el FTDI, HDL, Lattuino, Arduino... Lo relevante es que las funciones para reconfigurar la FPGA estén claramente diferenciadas de las utilizadas para generar el binario original. Las dos opciones más "directas":
¡Pero si eso ya está hecho! jajajajaja, Aquí se lo explico a Jesús Arroyo: https://groups.google.com/d/msg/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/xUqVUNoNCAAJ
Eso sí, al usar el iceprog, se hace sobre la comunicación del PC sobre el FTDI. :((
- Utilizar el bootloader de TinyFPGA y escribirlo en el PC.
- Seguir la sugerencia de Eladio y hacer accesibles a través de pines GPIO los correpondientes al cold/warm boot (dos bits de selección + un bit de trigger) y al SPI (sck, mosi, miso, cs). Conectar un Arduino, que sea el que utilice el SPI para gestionar la flash, y que pierda el control en cuanto empieza el reset. Cada vez que se quiera reconfigurar, hay que resetear a la imagen 0, informar a Arduino de que tiene el control, reordenar y resetear.
Si lo hacemos sobre la TinyFPGA o sobre alguna futura Alhambra que tenga más de 1K, yo sería más partidario de usar un Lattuino en FPGA, más que hacerlo exteriormente con un Arduino... la verdad... ya que tenemos el poder de las FPGA... ¡Utilicémoslo! jajajajajaja
Saludos
Juan Manuel Rico
Eladio Delgado
Mar 28, 2018, 11:23:36 AM3/28/18
to FPGAwars: explorando el lado libre
Hola Jesús!
Sí, hemos considerado la opción de añadir memoria pero con el placement preliminar que ya tenemos no queda espacio. Creo que con la flash hay bastante espacio para lo que comentas (según la aplicación, claro). También pensamos en poner algo de RAM aunque fuera por SPI, pero lo descartamos por la misma razón.
Lo de la microSD es muy buena idea para algunas aplicaciones. Tomo nota para una futura versión :o)
Un saludo,
Eladio
Juanma Rico
Mar 29, 2018, 7:10:31 AM3/29/18
to FPGAwars: explorando el lado libre
¡Cachis, Eladio! Siento oir eso de que habéis descartado la RAM por SPI... para grabar los vectores en la flash desde la propia FPGA y darle potencia con el "cold/warm boot" hubiera venido de escándalo... :((
Pero si se quedan los pines accesibles del SPI y deja de haber problemas con los maestros en el bus, igual sería suficiente con añadirla externamente en una shield para animar a todos a usar mútiples bitstream. :)))
Está claro que si hubiera estado integrada hubiera sido mucho más fácil usar esta característica, nos habríamos adelantado y hubiera sido un hecho diferencial con otras placas con la misma (o mayor) potencia de LUTs (y menos RAM de flash que tienen), pero con la shield externa y un sencillo acceso al SPI conectado a la flash no todo está perdido... :)))
Saludos
Juan Manuel Rico
Eladio Delgado
Mar 29, 2018, 3:18:08 PM3/29/18
to FPGAwars: explorando el lado libre
Hola Unai,
El 26 de marzo de 2018, 5:11, 1138-4EB <umarti...@ikasle.ehu.es> escribió:
Buenas Eladio,Tener acceso a esos pines no sólo implica el conector sino la electrónica para multiplexar el acceso, ya hay tres dispositivos en el bus (flash, FTDI y FPGA) y hay colisión entre ellos con lo que no podemos añadir más sin multiplexores. Sí se puede hacer de otra forma. Se puede cargar un bitstream que simplemente conecte los pines del SPI de la FPGA a los que tú quieras del GPIO de la placa (cada uno con la config de I/O adecuada). Puedes dejar este bitstream en una zona de la flash reservara sólo para esto y que puedas seleccionar esa zona con los pines de cold boot. De esta forma con un switch externo conectado a los pines de cold boot, activas o desactivas el acceso a los pines del SPI.
Si no he entendido mal, la idea es que sólo podemos tener dos maestros conectados al bus, sin utilizar multiplexores externos. Actualmente, esos dos maestros son el FTDI y la FPGA, ya que la flash siempre es un esclavo. Por lo tanto, para utilizar un tercer maestro sin incurrir en problemas eléctricos, lo que propones es utilizar la FPGA como un simple buffer o bypass. Esto permite utilizar el tercer maestro para acceder a la flash, pero no permite configurar la FPGA directamente. Para "programar" la FPGA desde el Arduino habría que:
- Programar la imagen de buffer/bypass en la región asociada al cold boot 00, a través del FTDI.
- Conectar los GPIO escogidos a los pines SPI del Arduino, y los cold boot y el reset a pines digitales.
- Poner las salidas del Arduino a 00 y resetear.
- A través de los pines SPI del Arduino, programar en la región asociada al cold boot 01 de la flash el bitstream del diseño que queremos usar en la FPGA.
- Poner las salidas del Arduino a 01 y resetear.
- (Opcional) los pines GPIO conectados a los SPI del Arduino se pueden utilizar para comunicar Arduino con la aplicación en la FPGA. Es decir, no sólo para el proceso de programación/configuración.
Es exactamente eso!!
Lo cierto es que me gusta la propuesta. Me parece una solución creativa y muy didáctica para ver las múltiples utilidades de una FPGA.
Cuesta acostumbrarse a todo lo que pueden hacer las FPGAS... yo estoy en ello :-)
No obstante, es ligeramente limitante el hecho de no poder acceder "sustituyendo" al FTDI, en vez de tomar la posición de la FPGA. La ventaja principal de un hipotético puerto ISCP es la posibilidad de acceder a la flash y a la FPGA como esclavos, para así guardar los bitstream comprimidos en la flash, de forma que el "tercer" maestro pueda leer, descomprimir al vuelo y programar la FPGA. Sigue siendo posible con la propuesta anterior, sólo que es necesario que los cuatro bitstream asociados al cold boot estén descomprimidos, por lo que cada vez que queremos cambiar uno de ellos, el Arduino tiene que leer, descomprimir al vuelo, volver a escribir en la flash y resetear mediante cold boot. No sé qué vejez puede tener ese requerimiento de reescribir "continuamente" en la flash.
La opción que comentamos no es tan ágil como acceder directamente al bus pero permite hacerlo para experimentar con cold boot y el desgaste de la memoria no sería un problema. Estas memorias soportan 100K ciclos de escritura por sector.
Por lo anterior, ¿sería disponible disponer de orificios en el PCB correspondientes a los pines SPI que van del FTDI a la FPGA/flash?
El sentido es que sea sencillo soldar una tira de pines (no incluida) para:
- Conectar periféricos (esclavos) programables desde el FTDI y/o la FPGA.
- Cortar las pistas del FTDI y conectar un Arduino.
Con la misma base, si hay espacio para dos filas, el "multiplexado" puede ser manual:
En el dibujo anterior las dos filas no están unidas entre si, por lo que serían necesarios jumpers para mantener el circuito intacto. Pero bien pueden estar unidas y que deba cortarlas quien quiera soldar las tiras de pines.
Lo interesante de esta solución es que puede utilizarse para poner un Arduino Pro Mini, entre el FTDI y la FPGA. En la práctica son dos ISCP en serie. Así, con una sola conexión USB:
- Se puede utilizar el FTDI para programar el Arduino, la FPGA y la flash.
- Se puede utilizar el Arduino para programar la FPGA y la flash.
- Se puede utilizar la FPGA para programar la flash.
La primera opción que comentas me parece interesante y si no la hago es por falta de espacio en la placa, ya que no añade ningún coste. Lo he probado también con pines de 2 mm de pitch pero no cabe. Lo anoto para próximas versiones.
Lo que sí creo que se podrá hacer es poner puntos de test en estas señales para que se puedan soldar cables en lugar de la tira de pines, no es tan elegante pero valdría igualmente.
La idea de tener en una placa un ARM + FPGA hace tiempo que la tengo en mente, todos los que hemos trabajado con microcontroladores hemos echado en falta muchas veces algo de lógica programable en el micro. Esta idea tiene muchas aplicaciones en control industrial y me gustaría hacerla con un M4 o un M7.
Creo que lo interesante de posibilitar acceso maestro al SPI, sea arbitrando el FTDI manualmente, automáticamente, o añadiendo un buffer (como en mi propuesta anterior), es que ya se dispondría del hardware necesario para prototiparlo. Es decir, escribir las rutinas software en el Arduino/CortexM para leer la flash, programar la FPGA, recibir un bitstream del FTDI y/o programarse a si mismo a través del FTDI. Cualquier uC que pueda ser programado a través del FTDI, y que disponga de un SPI adicional, puede conectarse a la tira de 2x6 como una "shield".
Entiendo que la idea de hacerlo en una placa es sugerente, pero no sé hasta qué punto mejorará el rendimiento con respecto a Alhambra II + cualquier Arduimo/CortexM ya existente.
Me refería en general a la idea de tener uC + FPGA en una placa para poder hacer unas tareas por HW y otras por SW según las características de cada una. Me parece que sería una placa muy didáctica y con muchas capacidades. Y no habria FTDI, su función la haría el uC.
Ese diseño dual que comentas es posible, bastaría con montar sockets apilables en lugar de los normales. Esto va a ser posible porque he diseñado la placa de forma que todos los componentes necesarios para funcionar son SMD y opcionalmente se puede enviar la placa con las tiras de pines y los zócalos sin soldar. Antes, el switch de alimentación, el jack y el pulsador de reset se montaban en la misma fase que los pines y sin estos componentes no podías usar todas las funciones de la placa. Ahora podemos enviar la placa sin montar las tiras de pines y todo funciona sin los componentes de inserción, la puedes empezar a usar tal cual te llega. Luego tú puedes soldar el tipo de zócalos y pines que quieras y esto permite el montaje que comentas. Además hemos modificado el diseño térmico del PCB para que sea mucho más fácil de soldar.En cuanto a comunicación habría que conectar una o las dos placas como comentas, según la aplicación. En cuanto a la alimentación, la Alhambra puede alimentar al Arduino a través del pin de 5V y al revés.
Sencillamente genial. Tanto el hecho de que sea posible, como saber los cambios que has hecho en el diseño para reordenar algunas fases. Es un lujo conocer este nivel de detalle.Esta opción que comentas es muy habitual en placas de evaluación de microcontroladores pero en nuestro caso creo que el planteamiento de tenerlo todo en una placa para empezar a hacer cosas con las FPGAs, parece acertado.Sí que vemos interesante tener módulos con la FPGA y la memoria (programables con la Alhambra o con un Arduino) para la aplicación que has desarrollado previamente con la Alhambra (u otra placa con iCE40). Es una idea que teníamos desde el principio y que ahora es más interesante con la aparición de la TinyFPGA. El módulo que teníamos en mente es exactamente una TinyFPGA salvo por la comunicación USB. No se nos había ocurrido implementar la interfaz USB en la propia FPGA. Con el bootloader que ha desarrollado Luke, este módulo pasa a ser "autónomo", lo programas directamente con el PC sin necesidad de otra placa, y sólo has añadido al módulo un conector USB y dos resistencias.
Ciertamente, se me había pasado por alto el detalle de cómo funcionan la TinyFPGA. Muy interesante. No obstante, creo que vuestra idea original (sólo la FPGA y la flash), sigue teniendo cabida. No sé dónde queda la regulación de la tensión, pero si el módulo que proponéis está pensado para conectarse directamente a una batería de 3,7v, y esto permite ajustar el coste con respecto al conector USB y los 5v, es un producto con un objetivo diferente de la TinyFPGA. Pero es cierto que son márgenes muy pequeños donde la diferencia de precio puede ser despreciable.
Personalmente, creo que no tiene tanto valor el hecho de tener el USB integrado, como la posibilidad de conectar fácil y rápidamente algo que te ofrezca un USB. Estoy pensando particularmente en los cables JTAG, que en este caso sería USB a SPI (ISCP).
En este caso se pueden tener las dos cosas: que sea un módulo programable desde el PC como la TinyFPGA y que sea muy pequeño y de bajo coste. Yo creo que lo haríamos así, ya que el conector USB no añade mucho coste y la placa tiene tan pocos componentes que queda espacio.
La alimentación tampoco es problema siempre que no ese activen los PLLs y se haga trabajar a alta frecuencia. Podemos utilizar reguladores lineales que tienen bajo coste y ocupan poco espacio.
El tema que comentas de la batería de 3.7V siempre lo tengo en mente. El sistema de alimentación de estas placas es compatible con el rango de tensión de las baterías LiPo 1S y muchos las tenemos a mano (sobre todo ahora con los drones). Pueden ser una buena solución para montajes con muchos servos.
Cierto, no son complejas ni costosas. Seguramente las hagamos pronto, la de VGA y la de displays de 7 segmentos + pulsadores son dos que llevan tiempo en el to-do, pero en fin, el tiempo es lo que limita :-)
¡Buena noticia! Si está en el to-do, algún día será. No hay prisa ninguna ;)
Un saludo
Esperemos que pronto!! :-)
Un saludo,
Eladio
--
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/9312b268-b6cf-4b33-82fe-6c7e1600e454%40googlegroups.com.
Eladio Delgado
Mar 29, 2018, 3:39:35 PM3/29/18
to FPGAwars: explorando el lado libre
Hola Juanma,
Te entiendo perfectamente porque el cold/warm boot es una de las características que más me gustan. Si ya es rápido configurar la FPGA con las herramientas libres, con el cold/warm boot es cuestión de milisegundos y me parece que eso tiene mucho potencial.Habrá que hacer una placa "maker pro" para los que estáis con los temas más avanzados :))
En la Alhambra II no hay problema por haber dos maestros en el bus, está 100% resuelto con las resistencias. En la IceZUM (al igual que en la Icestick) también funciona aunque no esté resuelto de la forma más correcta. Por otro lado, como he comentado antes, podemos poner puntos de test para acceder al bus con un tercer maestro sin problemas, ya que el FTDI no domina el bus gracias a las resistencias, y el otro maestro (la FPGA) se puede poner fácilmente como esclavo con la señal SS o incluso, si se quiere, ponerla en alta impedancia con el reset. De esta forma un tercer maestro puede acceder a la flash.
Y si lo que buscas es acceso a una RAM SPI siempre lo puedes hacer rutando el BUS al GPIO de la Alhambra y montando una memoria en DIP en la protoboard (sólo son 6 cables). No es tan cómodo como tenerla en la placa pero esto lo necesitarías sólo para el cold/warm boot (ya sé que en tu caso es gran parte del uso de la placa :) mientras que en placas pequeñas como la TinyFPGA o la UPDuino estos montajes en la protoboard hay que hacerlos casi para cualquier aplicación.
Y si lo que buscas es acceso a una RAM SPI siempre lo puedes hacer rutando el BUS al GPIO de la Alhambra y montando una memoria en DIP en la protoboard (sólo son 6 cables). No es tan cómodo como tenerla en la placa pero esto lo necesitarías sólo para el cold/warm boot (ya sé que en tu caso es gran parte del uso de la placa :) mientras que en placas pequeñas como la TinyFPGA o la UPDuino estos montajes en la protoboard hay que hacerlos casi para cualquier aplicación.
Opción 2:
El bloque más pequeño que puedes borrar en la flash es 4KB pero puedes escribir un byte. Se podría usar un segundo bloque de la flash como si fuera la RAM, donde copias el contenido del sector que quieres modificar excepto los bytes que quieres modificar (o la página de n bytes donde estén), que puedes escribirlos una vez copiadas las páginas que no cambian. Después borras el sector inicial y copias en él el sector buffer.
Por supuesto el proceso tardaría el doble porque borras y escribes dos veces un bloque. Por desgaste de la memoria no hay problema porque cada sector se escribe el mismo número de veces que si usas RAM.
Aunque no tan apropiado como usar RAM ¿ves viable esta opción?
Un saludo,
Eladio
--
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/e48cbe60-a5dd-4d69-9fb8-40f698f3e324%40googlegroups.com.
Juanma Rico
Mar 29, 2018, 5:32:40 PM3/29/18
to FPGAwars: explorando el lado libre
Gracias por responder Eladio...
muchas veces no sé si mi modo desenfadado de preguntar las cosas favorece la respuesta respetuosa... en tu caso me congratula ver que es así. :))
El jueves, 29 de marzo de 2018, 21:39:35 (UTC+2), Eladio Delgado escribió:
Hola Juanma,Te entiendo perfectamente porque el cold/warm boot es una de las características que más me gustan. Si ya es rápido configurar la FPGA con las herramientas libres, con el cold/warm boot es cuestión de milisegundos y me parece que eso tiene mucho potencial.
Habrá que hacer una placa "maker pro" para los que estáis con los temas más avanzados :))
Me alegra ver que le ves el potencial que hasta ahora, que yo sepa, de las tarjetas para "makers" que hay en el mercado, solo la TinyFPGA parece usar (y para mi entender, lo hace de forma muy básica). Creo que es un potencial que hay que aprovechar para diferenciarse, ahora y en un futuro, de las tarjetas existentes (más cuando los LUTs de las iCE40 son tan limitados) y así poder potenciar al máximo la tecnología que ofrecen los integrados de Lattice.
De esta forma se le puede inyectar y dar valor a la placa en sí misma para que pase a ser referente de esta punta de lanza en la "investigación" que llevan a cabo los integrantes del grupo FPGAwars. A mi entender es algo que no se puede desaprovechar, es una oportunidad que no se puede dejar pasar, sino siempre iremos por detrás (es mi humilde opinión).
Si la placa dispone de este hecho diferencial, hará que sea más atractiva a otras opciones existentes en el mercado; de hecho, para los que quieran investigar esa posibilidad del cambio entre múltiples sintetizados en tiempo real sería la única opción.
Y si es ésta la única opción que tengan algunos, es posible que Pinos del Valle acabe siendo de verdad el nuevo Silicon Valley y no simplemente una broma entre los del grupo (intuyo el potencial, lo creo sinceramente).
Respecto a lo de la placa "master pro", no veo la estrategia clara. Me explico...
En el mercado hay miles de tarjetas "master pro" con una capacidad mil veces mejor, simplemente hay que pagarlas y a veces no hay que pagar mucho para la potencia que tienen. El único precio a pagar realmente es que hay que pasarse al lado oscuro (- ¿Es más fuerte el "reverso tenebroso"? - No, no, no, más fácil, más rápido, más seductor... ).
Así que no creo que haya que hacer una placa compleja para solo cosas avanzadas, sino hacer el esfuerzo de incluir lo más avanzado de lo que se dispone en ese momento (y libre) en placas más sencillas. De esta forma, ponerlo al alcance de todos; para que todos, de forma fácil y sencilla, puedan utilizar lo más avanzado que exista. (En esto mi gran referente es Obijuan, como maestro Jedi que es... no puede hacer las cosas más fáciles a los demás tomando y simplificando los conceptos más complejos).
¡Uy! ¡Qué serio me ha quedado este párrafo! :)))
No quiero repetirme con el tema de que no quede espacio en la placa, pero si es así es porque hay otros componentes que hacen otras cosas que también son interesantes, al menos para la mayoría de gente que va a usar esta placa. Esa ha sido nuestra intención al menos, no sé si habremos acertado. En estos días pondré un post para contar más en detalle las nuevas características.
Sí, te entiendo, pero soy de la opinión de que si es necesario sacrificar algún componente o la propia forma de la placa misma en pos de estar en la "punta de lanza", yo lo haría.
Quizás sea arriesgado, pero si no os hubiérais arriesgado en su momento en sacar la iceZum Alhambra con "cuatro perras" de "cuatro gatos" que éramos, ahora seguramente no estaríamos hablando ni de una segunda versión. ¿Os vais ahora a contentar en hacer "lo de siempre" o "lo que todos hacen" o "corregir errores" sin aportar nada "transguesor"? :))
A mi entender hay que preguntarse... ¿Qué aporta el FTDI para estar "en punta de lanza"? (Creo que nada, todos lo usan...) ¿Y la forma de la tarjeta como un Arduino Uno? ¿Quieres que se utilicen las shield existentes de Arduino? Bien... pues se pueden mantener la distancia de pines, pero la forma y dimensiones es atarse a algo que, en sí, ya aporta poco.
Estoy pensando en el ejemplo del D1 de WeMos, sustituyó el ARM por un módulo basado en ESP8266 manteniendo la forma del Arduino Uno, después crearon un D1 mini donde se eliminaba todo lo supérfluo dejando lo mínimo en una placa pequeña a más no poder... creo que se han vendido 20 veces más (incluidos clones chinos), de D1 mini que de D1 con la forma de Arduino original. Igual es una señal de algo.
Bueno, igual me estoy metiendo en lo que no me compete... imagino que es cosa de diferentes estrategias y es fácil hablar de hacer cosas arriesgadas (aunque probadas) y no hacerlas... además yo sólo puedo intuir el potencial de diseño que tenéis pero realmente, siendo sinceros, no lo conozco.
Opción 1:Y como dices, no está todo perdido. Propongo dos opciones:En la Alhambra II no hay problema por haber dos maestros en el bus, está 100% resuelto con las resistencias. En la IceZUM (al igual que en la Icestick) también funciona aunque no esté resuelto de la forma más correcta. Por otro lado, como he comentado antes, podemos poner puntos de test para acceder al bus con un tercer maestro sin problemas, ya que el FTDI no domina el bus gracias a las resistencias, y el otro maestro (la FPGA) se puede poner fácilmente como esclavo con la señal SS o incluso, si se quiere, ponerla en alta impedancia con el reset. De esta forma un tercer maestro puede acceder a la flash.
Y si lo que buscas es acceso a una RAM SPI siempre lo puedes hacer rutando el BUS al GPIO de la Alhambra y montando una memoria en DIP en la protoboard (sólo son 6 cables). No es tan cómodo como tenerla en la placa pero esto lo necesitarías sólo para el cold/warm boot (ya sé que en tu caso es gran parte del uso de la placa :) mientras que en placas pequeñas como la TinyFPGA o la UPDuino estos montajes en la protoboard hay que hacerlos casi para cualquier aplicación.
Sí, claro, Eladio. Esto se puede hacer, creo que incluso con la propia icezum Alhambra actual (tengo conocimientos de electrónica, pero no soy experto), de hecho tengo las RAM SPI compradas para probar el montaje (cuando pueda), pero creo que finalmente se trata de eso... de ponerlo fácil y diferenciarse (entre otras de la TinyFPGa y la UPDuino).
Incluso yo estaba por dejarlo más ordenado todo y soldar una shield para esos "experimentos", pero claro... entonces la "punta de lanza" estaría en la shield y no en la placa misma... perdemos una oportunidad (humilde opinión como siempre).
Opción 2:El bloque más pequeño que puedes borrar en la flash es 4KB pero puedes escribir un byte. Se podría usar un segundo bloque de la flash como si fuera la RAM, donde copias el contenido del sector que quieres modificar excepto los bytes que quieres modificar (o la página de n bytes donde estén), que puedes escribirlos una vez copiadas las páginas que no cambian. Después borras el sector inicial y copias en él el sector buffer.Por supuesto el proceso tardaría el doble porque borras y escribes dos veces un bloque. Por desgaste de la memoria no hay problema porque cada sector se escribe el mismo número de veces que si usas RAM.Aunque no tan apropiado como usar RAM ¿ves viable esta opción?
Sí, creo que es viable y una gran idea. Pero por desgracia veo que se pierde la gran ventaja que tiene el sistema "cold/warm boot" que es que en milisegundos tienes un circuito digital totalmente distinto funcionando en la FPGA.
Mi idea en su momento, cuando buscaba y pensaba en la RAM SPI para el "cold/warm boot", era "clonar" el contenido completo de la flash en la RAM SPI en el momento del encendido de la placa y trabajar con la RAM SPI en los reinicios y selecciones de los distintos bitstreams para la FPGA en lugar de la flash, sería posible porque no se pierde la alimentación del integrado con lo que se mantiene la información en ella. Con esto la flash sufriría menos grabaciones y se prolongaría su vida de uso. Es verdad que tengo que probar todo esto... a ver si se me termina el SAV con la VGA y vuelve a ser prioridad el "cold/warm boot" y puedo confirmar que es posible... :))
Un saludo,Eladio
Un saludo enorme.
Juan Manuel Rico
Eladio Delgado
Mar 30, 2018, 1:31:06 PM3/30/18
to FPGAwars: explorando el lado libre
Hola Juanma,
El 29 de marzo de 2018, 23:32, Juanma Rico <juan...@gmail.com> escribió:
Gracias por responder Eladio...
muchas veces no sé si mi modo desenfadado de preguntar las cosas favorece la respuesta respetuosa... en tu caso me congratula ver que es así. :))
Qué va!! A mí el tono desenfadado no me molesta, al contrario, lo prefiero!! :-) Si tardo en contestar o se me pasan posts es por el tiempo, que no hay para todo lo que se quiere hacer.
El jueves, 29 de marzo de 2018, 21:39:35 (UTC+2), Eladio Delgado escribió:Hola Juanma,Te entiendo perfectamente porque el cold/warm boot es una de las características que más me gustan. Si ya es rápido configurar la FPGA con las herramientas libres, con el cold/warm boot es cuestión de milisegundos y me parece que eso tiene mucho potencial.
Habrá que hacer una placa "maker pro" para los que estáis con los temas más avanzados :))
Me alegra ver que le ves el potencial que hasta ahora, que yo sepa, de las tarjetas para "makers" que hay en el mercado, solo la TinyFPGA parece usar (y para mi entender, lo hace de forma muy básica).
Disculpa Juanma, no sé a qué te refieres. La TinyFPGA y la Alhambra son conceptos distintos, pero funcionalmente la TinyFPGA es un subconjunto de la Alhambra II (incluida la BX, no sé si te refieres a esa). Según lo que vayas a hacer puedes preferir una u otra pero todo lo que hagas con la Tiny lo puedes hacer con la Alhambra II.
Creo que es un potencial que hay que aprovechar para diferenciarse, ahora y en un futuro, de las tarjetas existentes (más cuando los LUTs de las iCE40 son tan limitados) y así poder potenciar al máximo la tecnología que ofrecen los integrados de Lattice.
De esta forma se le puede inyectar y dar valor a la placa en sí misma para que pase a ser referente de esta punta de lanza en la "investigación" que llevan a cabo los integrantes del grupo FPGAwars. A mi entender es algo que no se puede desaprovechar, es una oportunidad que no se puede dejar pasar, sino siempre iremos por detrás (es mi humilde opinión).
Si la placa dispone de este hecho diferencial, hará que sea más atractiva a otras opciones existentes en el mercado; de hecho, para los que quieran investigar esa posibilidad del cambio entre múltiples sintetizados en tiempo real sería la única opción.
Y si es ésta la única opción que tengan algunos, es posible que Pinos del Valle acabe siendo de verdad el nuevo Silicon Valley y no simplemente una broma entre los del grupo (intuyo el potencial, lo creo sinceramente).
Entiendo y comparto lo que dices pero no podemos pretender que una placa valga para todo. Vamos a hacer otras placas, unas más avanzadas y otras más básicas, eso vendrá ahora. Todo este tiempo desde que nació FPGAwars hemos estado resolviendo otros muchos aspectos para poder producir con calidad y poder hacerlo aquí además, que creo que es algo que también habría que destacar. Quizás no he dado suficiente visibilidad a este trabajo (y aún queda mucho por hacer), pero ahí está, espero que se vaya viendo en los próximos meses. El próximo 11 de mayo doy una charla sobre el tema en GranaBot18, si te animas (tú estás cerca) allí nos veremos! :-)
Me alegra que veas potencial en el "nuevo Silicon Valley"!! :-) lo tomo como una forma de dar ánimo, realmente nos lo da. Aunque esto es Andalucía y no California (para lo bueno y para lo malo), por intentarlo que no quede!! :-) En cualquier caso, si lo conseguimos, no creo que sea por ser la única opción. Queremos ser una gran opción pero siempre habrá otras. Y si los "competidores" son como Luke, bienvenidos sean!! Ha aportado una idea sencilla pero genial como es meter el controlador USB en la FPGA y ha desarrollado el bootloader para hacerla realidad.
Respecto a lo de la placa "master pro", no veo la estrategia clara. Me explico...
En el mercado hay miles de tarjetas "master pro" con una capacidad mil veces mejor, simplemente hay que pagarlas y a veces no hay que pagar mucho para la potencia que tienen. El único precio a pagar realmente es que hay que pasarse al lado oscuro (- ¿Es más fuerte el "reverso tenebroso"? - No, no, no, más fácil, más rápido, más seductor... ).
Así que no creo que haya que hacer una placa compleja para solo cosas avanzadas, sino hacer el esfuerzo de incluir lo más avanzado de lo que se dispone en ese momento (y libre) en placas más sencillas. De esta forma, ponerlo al alcance de todos; para que todos, de forma fácil y sencilla, puedan utilizar lo más avanzado que exista. (En esto mi gran referente es Obijuan, como maestro Jedi que es... no puede hacer las cosas más fáciles a los demás tomando y simplificando los conceptos más complejos).
¡Uy! ¡Qué serio me ha quedado este párrafo! :)))
:-)) serio no, pero creo que ha habido una confusión. Yo puse "maker pro", no "master pro" :-) No me refería a placas muy avanzadas sino a las que podéis necesitar los que estáis haciendo cosas más avanzadas en la comunidad.
No quiero repetirme con el tema de que no quede espacio en la placa, pero si es así es porque hay otros componentes que hacen otras cosas que también son interesantes, al menos para la mayoría de gente que va a usar esta placa. Esa ha sido nuestra intención al menos, no sé si habremos acertado. En estos días pondré un post para contar más en detalle las nuevas características.
Sí, te entiendo, pero soy de la opinión de que si es necesario sacrificar algún componente o la propia forma de la placa misma en pos de estar en la "punta de lanza", yo lo haría.
Quizás sea arriesgado, pero si no os hubiérais arriesgado en su momento en sacar la iceZum Alhambra con "cuatro perras" de "cuatro gatos" que éramos, ahora seguramente no estaríamos hablando ni de una segunda versión. ¿Os vais ahora a contentar en hacer "lo de siempre" o "lo que todos hacen" o "corregir errores" sin aportar nada "transguesor"? :))
A mi entender hay que preguntarse... ¿Qué aporta el FTDI para estar "en punta de lanza"? (Creo que nada, todos lo usan...) ¿Y la forma de la tarjeta como un Arduino Uno? ¿Quieres que se utilicen las shield existentes de Arduino? Bien... pues se pueden mantener la distancia de pines, pero la forma y dimensiones es atarse a algo que, en sí, ya aporta poco.
Estoy pensando en el ejemplo del D1 de WeMos, sustituyó el ARM por un módulo basado en ESP8266 manteniendo la forma del Arduino Uno, después crearon un D1 mini donde se eliminaba todo lo supérfluo dejando lo mínimo en una placa pequeña a más no poder... creo que se han vendido 20 veces más (incluidos clones chinos), de D1 mini que de D1 con la forma de Arduino original. Igual es una señal de algo.
Bueno, igual me estoy metiendo en lo que no me compete... imagino que es cosa de diferentes estrategias y es fácil hablar de hacer cosas arriesgadas (aunque probadas) y no hacerlas... además yo sólo puedo intuir el potencial de diseño que tenéis pero realmente, siendo sinceros, no lo conozco.
Aquí comparto sólo parte de lo que dices. Yo creo que lo realmente transguesor es poner las FPGAs al alcance de cualquiera, sin importar edad o conocimientos de electrónica digital. Las placas que utilicemos sólo son una herramienta para ese fin. Por supuesto, para los que diseñamos y fabricamos la placa, es crítico que podamos vender suficientes unidades como para que sea viable la actividad.
Y te agradezco tus comentarios porque creo que es a lo que pretendes ayudar.
En definitiva no intentamos hacer la mejor placa sino la que creemos que mejor se ajusta al uso al que la hemos dirigido. Como decía antes haremos otras placas para un uso más avanzado. Piensa que Luke, para un concepto muy específico, tiene tres modelos a la venta. No podemos cubrir todas las necesidades con un modelo, pero habrá más, te lo prometo! :-))
En definitiva no intentamos hacer la mejor placa sino la que creemos que mejor se ajusta al uso al que la hemos dirigido. Como decía antes haremos otras placas para un uso más avanzado. Piensa que Luke, para un concepto muy específico, tiene tres modelos a la venta. No podemos cubrir todas las necesidades con un modelo, pero habrá más, te lo prometo! :-))
En la Alhambra II hay cosas que no son "lo que todos hacen" (también en la IceZUM), no por nada, simple reto personal :-) Estas placas son relativamente sencillas y me gusta aportar siempre algo nuevo para motivarme :-) Hablo por ejemplo de que la placa tenga el GPIO tolerante a 5V (necesario por tener alimentación para servos en los pines) o que no se necesite jumper para poner una referencia externa al convertidor AD (conmuta automáticamente al poner una tensión externa). Avisaré aquí cuando publique el esquemático.
Opción 1:Y como dices, no está todo perdido. Propongo dos opciones:En la Alhambra II no hay problema por haber dos maestros en el bus, está 100% resuelto con las resistencias. En la IceZUM (al igual que en la Icestick) también funciona aunque no esté resuelto de la forma más correcta. Por otro lado, como he comentado antes, podemos poner puntos de test para acceder al bus con un tercer maestro sin problemas, ya que el FTDI no domina el bus gracias a las resistencias, y el otro maestro (la FPGA) se puede poner fácilmente como esclavo con la señal SS o incluso, si se quiere, ponerla en alta impedancia con el reset. De esta forma un tercer maestro puede acceder a la flash.
Y si lo que buscas es acceso a una RAM SPI siempre lo puedes hacer rutando el BUS al GPIO de la Alhambra y montando una memoria en DIP en la protoboard (sólo son 6 cables). No es tan cómodo como tenerla en la placa pero esto lo necesitarías sólo para el cold/warm boot (ya sé que en tu caso es gran parte del uso de la placa :) mientras que en placas pequeñas como la TinyFPGA o la UPDuino estos montajes en la protoboard hay que hacerlos casi para cualquier aplicación.
Sí, claro, Eladio. Esto se puede hacer, creo que incluso con la propia icezum Alhambra actual (tengo conocimientos de electrónica, pero no soy experto), de hecho tengo las RAM SPI compradas para probar el montaje (cuando pueda), pero creo que finalmente se trata de eso... de ponerlo fácil y diferenciarse (entre otras de la TinyFPGa y la UPDuino).
Incluso yo estaba por dejarlo más ordenado todo y soldar una shield para esos "experimentos", pero claro... entonces la "punta de lanza" estaría en la shield y no en la placa misma... perdemos una oportunidad (humilde opinión como siempre).
A esto te respondo en el párrafo siguiente, por el plateamiento de uso de la RAM.
Opción 2:El bloque más pequeño que puedes borrar en la flash es 4KB pero puedes escribir un byte. Se podría usar un segundo bloque de la flash como si fuera la RAM, donde copias el contenido del sector que quieres modificar excepto los bytes que quieres modificar (o la página de n bytes donde estén), que puedes escribirlos una vez copiadas las páginas que no cambian. Después borras el sector inicial y copias en él el sector buffer.Por supuesto el proceso tardaría el doble porque borras y escribes dos veces un bloque. Por desgaste de la memoria no hay problema porque cada sector se escribe el mismo número de veces que si usas RAM.Aunque no tan apropiado como usar RAM ¿ves viable esta opción?
Sí, creo que es viable y una gran idea. Pero por desgracia veo que se pierde la gran ventaja que tiene el sistema "cold/warm boot" que es que en milisegundos tienes un circuito digital totalmente distinto funcionando en la FPGA.
Mi idea en su momento, cuando buscaba y pensaba en la RAM SPI para el "cold/warm boot", era "clonar" el contenido completo de la flash en la RAM SPI en el momento del encendido de la placa y trabajar con la RAM SPI en los reinicios y selecciones de los distintos bitstreams para la FPGA en lugar de la flash, sería posible porque no se pierde la alimentación del integrado con lo que se mantiene la información en ella. Con esto la flash sufriría menos grabaciones y se prolongaría su vida de uso. Es verdad que tengo que probar todo esto... a ver si se me termina el SAV con la VGA y vuelve a ser prioridad el "cold/warm boot" y puedo confirmar que es posible... :))
Creía que tu idea era modificar sólo el sector 0 para cambiar los vectores, no trabajar en la RAM. No sé si esto no es viable con RAM SPI. Con la HX 4K el bitstream ocupa lo mismo que el de la 8K (ahora ya sabemos por qué ;), algo más de 1 Mb. Las RAM por SPI más grandes que he visto son de 2 Mb, con lo que no llegan a entrar dos bitstreams sin compresión. No sé si dependiendo del circuito y con compresión daría para las pruebas que quieres hacer. Por otro lado, la RAM en 2 Mb es un componente costoso. Como buffer de uno o dos sectores (4 a 8 KB) sí sería viable.
Para lo que quieres hacer sería una RAM con interfaz paralelo y ya estaríamos hablando de otro concepto de placa.
Un saludo,Eladio
Un saludo enorme.
Juan Manuel Rico
Un saludo y espero verte en GranaBot18!! :-)
Eladio
--
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/009d738a-6692-4e25-8380-b13a50e0c4c1%40googlegroups.com.
Message has been deleted
1138-4EB
Mar 30, 2018, 3:14:15 PM3/30/18
to FPGAwars: explorando el lado libre
Hola Juanma!
Bueno... no sé si utiliza los mismos drivers que Apio... lo que sí te puedo decir es que en Windows 7 en ninguno de mis puertos USB del portátil funciona (ni instalando el driver que aconseja Luke) y en GNU/Linux sólo me funciona en un puerto USB bajo Ubuntu y como te digo, el bootloader no carga el bitstream del usuario quedándose con el control si lo alimentas por ese puerto. :((
De ahí mi enfoque para facilitar la utilización de un Arduino o Attiny: se puede utilizar el propio bootloader de Arduino (que funciona) o V-USB (https://www.obdev.at/products/vusb/index.html). Como comenté, es muy complicado que un bootloader HDL se comporte como un USB "en condiciones".
Luego este mega-bitstream generado se carga en la flash mediante el iceprog que también modifiqué para poder consultar la lista de nombres y poder intercambiar los vectores de acceso (grabar los primeros 4k) para no tener que volver a grabar el bitstream si se encontrara entre esos 128 pregrabados (con lo que se ahorra tiempo si solo hay que grabar 4k), todo está en la ayuda del binario explicado... en fin, esto sé que lo sabes, pero era para situar a los que nos lean.
No lo recordaba del todo. De hecho, algunos de los últimos mensajes no los llegué a leer. Voy a revisar...
Si lo hacemos sobre la TinyFPGA o sobre alguna futura Alhambra que tenga más de 1K, yo sería más partidario de usar un Lattuino en FPGA, más que hacerlo exteriormente con un Arduino... la verdad... ya que tenemos el poder de las FPGA... ¡Utilicémoslo! jajajajajaja
La cuestión principal es si la solución puede o no ser del tipo stop-the-world. En el caso de TinyFPGA, o de la solución propuesta por Eladio, es necesaria una imagen sólo durante la programación, y después se arranca otra. En el contexto de la reconfiguración dinámica, esto supone un parón:
1. En la RAM hay cuatro imágenes descomprimidas y ocho comprimidas (las cuatro y otras cuatro).
2. Estoy utilizando un circuito (digamos que el 3) y por condiciones del entorno tengo que cambiar a otro que no está entre los cuatro direccionables. Es decir, a uno no comprimido (digamos que el 6).
3. Si es necesario guardar información de estado, la escribo en la flash (en un espacio para datos).
4. Hago un cold/warm boot y paso al circuito "bootloader" (el 0).
5. El "bootloader" (Lattuino) lee la imagen 6, la descomprime y la escribe en la sección correspondiente al cold boot 2.
6. Se reinicia y carga el circuito 2.
7. Si es necesario, se leen los datos guardados anteriormente.
Desde el paso 4 hasta el paso 7 el circuito no está operativo. Si es el controlador de una planta/motor, y el cambio es debido a que en ciertas condiciones se necesita otro circuito más específico, durante ese tiempo (que pueden ser desde decenas de ms hasta segundos) no hay control. Esto puede ser aceptable, o puede no serlo. Si se utiliza un dispositivo externo (conectado al bus en paralelo con la FPGA), el proceso se paraleliza:
3. Informo al "Arduino" del cambio requerido.
4. El "Arduino" lee la imagen 6, la descomprime y la escribe en la sección correspondiente al cold boot 2.
5. Si es necesario guardar información de estado, la escribo en la flash (en un espacio para datos).
6. Se reinicia y carga el circuito 2.
7. Si es necesario, se leen los datos guardados anteriormente.
En este caso, la FPGA sólo está inoperativa entre los pasos 6 y 7. Estos pasos son, además, muchos más rápidos que la operación de lectura, descompresión, etc.
En el supuesto del "Lattuino", si se puede añadir en todos los circuitos (y todavía queda espacio para la aplicación en si), se puede aplicar el proceso sin stop-the-world. Pero si no es así, y el "Lattuino" está en una sola imagen (que es el bootloader), estamos en el supuesto anterior. Adicionalmente, un micro externo permite lo siguiente y el Lattuino no:
- Leer la imagen, descomprimirla y programar la FPGA directamente (sin pasar por la flash) y sin necesidad de usar warm/cold boot.
- Usar la memoria interna del micro como RAM, para almacenar datos entre reconfiguraciones por medio de warm/cold boot.
Como ves, las posibilidades son muchas. Estoy de acuerdo en que utilizar Lattuino, aunque sea parando el mundo, es una solución muy útil y didáctica. De hecho, estoy reinstalando herramientas para hacer alguna prueba. Pero siendo este un hilo donde sugerir pequeños detalles, estoy tratando de ver la foto completa, para evitar carencias en el diseño del PCB a la hora de poner en práctica algunas de las pruebas.
Saludos
1138-4EB
Mar 30, 2018, 3:59:57 PM3/30/18
to FPGAwars: explorando el lado libre
Hola Eladio,
La opción que comentamos no es tan ágil como acceder directamente al bus pero permite hacerlo para experimentar con cold boot y el desgaste de la memoria no sería un problema. Estas memorias soportan 100K ciclos de escritura por sector.
Sabiendo que son 100K, puedo estar tranquilo por muchas pruebas que haga XD.
La primera opción que comentas me parece interesante y si no la hago es por falta de espacio en la placa, ya que no añade ningún coste. Lo he probado también con pines de 2 mm de pitch pero no cabe. Lo anoto para próximas versiones.
Lo que sí creo que se podrá hacer es poner puntos de test en estas señales para que se puedan soldar cables en lugar de la tira de pines, no es tan elegante pero valdría igualmente.
Miré el diseño de la Alhambra en KiCAD y ya me parecio difícil que entrara algo... Al no saber cuánto espacio habéis ahorrado en la nueva versión, tenía la esperanza. Pero, en cualquier caso, si se pueden poner los puntos de test sin que suponga un problema, sería muy de agradecer. Como comentabas en algún otro mensaje, no es el target de esta placa, pero ayudaría para no tener que hacer chapuzas. Creo que, de hecho, serían útiles no sólo para conectar un Arduino/CortexM, sino para ver las comunicaciones y hacer debug con un osciloscopio/analizador de señales.
Me refería en general a la idea de tener uC + FPGA en una placa para poder hacer unas tareas por HW y otras por SW según las características de cada una. Me parece que sería una placa muy didáctica y con muchas capacidades. Y no habria FTDI, su función la haría el uC.
Entiendo que te refieres a algo parecido a la BlackIce II: https://www.tindie.com/products/Folknology/blackice-ii/ Aunque en este caso hay un CH340 además del USB del uC (no acabo de entender por qué). La interfaz "rápida" de comunicación entre el Cortex y la FPGA es QUAD SPI: https://github.com/mystorm-org/BlackIce-II/wiki/Connections-between-the-STM32-and-the-iCE40 Por tu experiencia, ¿crees que habría problemas de ruido si la FPGA estuviera en una placa y el Cortex en otra? Sea la FPGA una shield/base para una placa ST32 tamaño Arduino Nano, o viceversa. En otras palabras, ¿por qué una placa y no dos stackeadas que se vendan como un solo producto? Lo pregunto desde la más absoluta ignorancia de si puede ser debido al rendimiento, o si realmente es mucho más caro fabricar un solo PCB que dos mitades.
En este caso se pueden tener las dos cosas: que sea un módulo programable desde el PC como la TinyFPGA y que sea muy pequeño y de bajo coste. Yo creo que lo haríamos así, ya que el conector USB no añade mucho coste y la placa tiene tan pocos componentes que queda espacio.
Si el coste del conector USB es despreciable y no complica el montaje, desde luego es un plus. Ya sea para programar la FPGA, o como un conector 'estandar' que permite una comunicación serie asíncrona full-duplex.
La alimentación tampoco es problema siempre que no ese activen los PLLs y se haga trabajar a alta frecuencia. Podemos utilizar reguladores lineales que tienen bajo coste y ocupan poco espacio.
El tema que comentas de la batería de 3.7V siempre lo tengo en mente. El sistema de alimentación de estas placas es compatible con el rango de tensión de las baterías LiPo 1S y muchos las tenemos a mano (sobre todo ahora con los drones). Pueden ser una buena solución para montajes con muchos servos.
Con respecto a las tensiones, mi pregunta iba más dirigida a si los reguladores que se utilizan para entradas de 5V (USB) son exactamente los mismos que utilizariais si la entrada estuviera "limitada" a 4,2V. Interpreto que no hay ahorro ni en coste ni en espacio por esos 0,8V, por lo que no hay nada que cambiar.
Sobre los PLLs, entiendo que el problema puede ser por los reguladores lineales en lugar de conmutados. ¿Es significativa la diferencia de coste? ¿Y el rendimiento/eficiencia?
Opción 1:En la Alhambra II no hay problema por haber dos maestros en el bus, está 100% resuelto con las resistencias. En la IceZUM (al igual que en la Icestick) también funciona aunque no esté resuelto de la forma más correcta. Por otro lado, como he comentado antes, podemos poner puntos de test para acceder al bus con un tercer maestro sin problemas, ya que el FTDI no domina el bus gracias a las resistencias, y el otro maestro (la FPGA) se puede poner fácilmente como esclavo con la señal SS o incluso, si se quiere, ponerla en alta impedancia con el reset. De esta forma un tercer maestro puede acceder a la flash.
Ya lo he comentado, pero lo de los puntos de test, unido al detalle de las resistencias que has subrayado, a mí me parece más que suficiente para considerar que la placa no "limita" la posibilidad de hacer pruebas. De hecho, lo pondría como una "feature".
Un saludo
1138-4EB
Mar 30, 2018, 6:01:06 PM3/30/18
to FPGAwars: explorando el lado libre
Hola de nuevo,
Eladio,
Deseoso de escuchar esos detalles del diseño :D
Teniendo en cuenta el cambio en el tamaño de los bitstream, ¿habéis considerado incrementar el tamaño de la flash?
Juanma,
Eladio,
Deseoso de escuchar esos detalles del diseño :D
Teniendo en cuenta el cambio en el tamaño de los bitstream, ¿habéis considerado incrementar el tamaño de la flash?
Juanma,
De esta forma se le puede inyectar y dar valor a la placa en sí misma para que pase a ser referente de esta punta de lanza en la "investigación" que llevan a cabo los integrantes del grupo FPGAwars. A mi entender es algo que no se puede desaprovechar, es una oportunidad que no se puede dejar pasar, sino siempre iremos por detrás (es mi humilde opinión).
Estando de acuerdo en la importancia de la realimentación entre la producción de la Alhambra y el grupo, creo que hay que ser cuidadosos con no confundir deseo con necesidad. Al final, introducir una nueva característica implica un balance entre coste y beneficio. Aunque podemos atisbarlo, ahora mismo no está claro el beneficio que ofrece la adición de una RAM, o la sustitución del FTDI por un Arduino. Así, siendo la punta en esta lanza, debemos conformarnos con poder prototipar con relativa facilidad; en comparación con, por ejemplo, tener que soldar los pines cold boot en la Alhambra v1.1. Si se detecta alguna necesidad adicional al poner en marcha los prototipos, o se ve que sobra algo, hay tiempo de cambiarlo. Si se hacen cambios para soportar posibles características y después se comprueba que faltaba un pin auxiliar por conectar, el estropicio ya está hecho.
Dicho esto, una "shield" de RAM QUAD SPI + conector micro-SD + para la Alhambra II sería un complemento muy interesante (a añadir al VGA). Si no he entendido mal, ya no existen los adaptadores de nivel, por lo que los pines GPIO no tienen "ninguna" latencia con respecto al pin correspondiente en la FPGA, así que se puede esperar un rendimiento mejor que en la Alhambra v1.1. ¿Es así Eladio?
Si la placa dispone de este hecho diferencial, hará que sea más atractiva a otras opciones existentes en el mercado; de hecho, para los que quieran investigar esa posibilidad del cambio entre múltiples sintetizados en tiempo real sería la única opción.
En relación con lo comentado en el bloque anterior, hay que prototipar para depurar las ideas. Por ejemplo, cuando envié las primeras respuestas a este hilo creía que era necesario conectar el Arduino como maestro de la FPGA y la SPI, para poder programar la FPGA desde Arduino. A lo largo de la conversación, Eladio me ha hecho ver que se puede usar la propia FPGA como bypass (en principio en la icestick y en la Alhambra v1.1, sin tener que esperar a la II). No es la solución ideal, pero ya ofrece un punto en el que poder trabajar para explorar las diferentes formas de empaquetar múltiples bitstreams, qué metainformación añadir, qué compresión utilizar, etc. Asimismo, yo ya estaba cutter en mano para deshacerme del FTDI, y nos ha explicado cómo poder ignorarlo, gracias a las resistencias que ya se han añadido (por otro motivo).
De hecho, estos últimos días he llegado a la conclusión de que tampoco es necesario conectar en el PCB los pines cold boot a GPIO. Del mismo modo que se puede usar la FPGA como bypass para hacer el bus SPI accesible a través de GPIO, se puede instanciar el módulo de warm boot y conectar los puertos a dos pines cualquiera. El proceso sería: cargar "bootloader" que incluye warm boot, leer las entradas y ejecutar reboot inmediatamente después. No es óptimo, porque implica que en cada (re)inicio hay que reconfigurar dos veces la FPGA; por lo tanto, sigue siendo útil tener accesibles los cold boot "de verdad". Pero sirve como analogía, y como un "no hay excusas para no cacharrear".
En el mercado hay miles de tarjetas "master pro" con una capacidad mil veces mejor, simplemente hay que pagarlas y a veces no hay que pagar mucho para la potencia que tienen. El único precio a pagar realmente es que hay que pasarse al lado oscuro (- ¿Es más fuerte el "reverso tenebroso"? - No, no, no, más fácil, más rápido, más seductor... ).
No estoy muy seguro de que en el mercado haya muchas "master pro" tan pequeñas y, por tanto, tan de bajo consumo. No soy ni mucho menos un experto en este rango/nicho, pero diría que una tipo BlackIce II pero sin tanto conector grande y con la mitad de tamaño podría empezar a tener sentido para "computing in-the-edge" en el contexto del IoT. Digamos, por ejemplo, una OV7670 + Arduino/CortexM + iCE40 para detección facial/control de acceso. Lo más cercano que conozco es http://gnarlygrey.atspace.cc/development-platform.html Tienen forma de Nano y hay adaptador para OV7670, pero el modelo de FPGA que incluyen no soporta warm/cold boot (sólo las series LP y HX). Además, en línea con lo comentado anteriormente con Eladio, la versión 1 no tiene conector USB, y la versión 2 lo tiene pero incluyendo FTDI.
Sí, te entiendo, pero soy de la opinión de que si es necesario sacrificar algún componente o la propia forma de la placa misma en pos de estar en la "punta de lanza", yo lo haría.
En cuanto a la forma, estoy de acuerdo. Me gustaría saber hasta qué punto es relevante que la forma sea la de Arduino Uno, en vez de tener los "zócalos" pero ser ligeramente diferente en cuanto a dimensiones. E.g. BlackIce.
A mi entender hay que preguntarse... ¿Qué aporta el FTDI para estar "en punta de lanza"? (Creo que nada, todos lo usan...) ¿Y la forma de la tarjeta como un Arduino Uno? ¿Quieres que se utilicen las shield existentes de Arduino? Bien... pues se pueden mantener la distancia de pines, pero la forma y dimensiones es atarse a algo que, en sí, ya aporta poco.
Sin acritud ninguna, ¿cuál es la solución actual sin el FTDI que ofrezca la misma funcionalidad y no de más problemas de soporte/conexión? Estoy de acuerdo en que puede reemplazarse por un Atmega32u4, porque ya lo hizo Arduino en su día con los Leonardo y se puede reutilizar el framework. Pero habría que pogramar las rutinas para que cumpla la función del FTDI entre el PC y la FPGA/flash; que, sin ser difíciles, no conozco si están escritas. También podría prescindirse del Atmega y usar directamente un bootloader como el de TinyFPGA; pero habría que depurarlo/mejorarlo. Lo que quiero decir es que, a pesar de que el FTDI sobre, no hay un reemplazo directo que sólo requiera cambios en el PCB. ¡Prototipemos!
Sí, claro, Eladio. Esto se puede hacer, creo que incluso con la propia icezum Alhambra actual (tengo conocimientos de electrónica, pero no soy experto), de hecho tengo las RAM SPI compradas para probar el montaje (cuando pueda), pero creo que finalmente se trata de eso... de ponerlo fácil y diferenciarse (entre otras de la TinyFPGa y la UPDuino).
Incluso yo estaba por dejarlo más ordenado todo y soldar una shield para esos "experimentos", pero claro... entonces la "punta de lanza" estaría en la shield y no en la placa misma... perdemos una oportunidad (humilde opinión como siempre).
Sí, creo que es viable y una gran idea. Pero por desgracia veo que se pierde la gran ventaja que tiene el sistema "cold/warm boot" que es que en milisegundos tienes un circuito digital totalmente distinto funcionando en la FPGA.
Mi idea en su momento, cuando buscaba y pensaba en la RAM SPI para el "cold/warm boot", era "clonar" el contenido completo de la flash en la RAM SPI en el momento del encendido de la placa y trabajar con la RAM SPI en los reinicios y selecciones de los distintos bitstreams para la FPGA en lugar de la flash, sería posible porque no se pierde la alimentación del integrado con lo que se mantiene la información en ella. Con esto la flash sufriría menos grabaciones y se prolongaría su vida de uso. Es verdad que tengo que probar todo esto... a ver si se me termina el SAV con la VGA y vuelve a ser prioridad el "cold/warm boot" y puedo confirmar que es posible... :))
Juanma, con todo el cariño, creo que estás pensando de más XD. Por más que releo tus explicaciones sobre cómo usar esa RAM SPI (no flash), no me hago a la idea de por qué hacerlo así. Podría tener su utilidad para lo que entendí que propuso Jesús de usarla para almacenar tablas, datos, capturas... (aunque ya le indiqué que la flash se puede usar para ello) Incluso como memoria de programa de un Lattuino (aunque con un rendimiento muy pobre). Pero en el contexto del cold/warm boot no entiendo por qué necesitas/necesitamos una. ¿Qué podemos hacer con ella que no podamos hacer sólo con la FPGA + SPI?
Entiendo que puede ser quisquillosa la limitación para borrar contenido en la flash, pero no es nada que no se pueda solucionar con un poco de creatividad. Supongamos que en los primeros 4k en realidad sólo está el applet, porque movemos el resto del contenido. Además, situamos las imágenes que vamos a utilizar en direcciones concretas, de forma que de la primera a la quinta sólo cambien 0s a 1s, o viceversa (no recuerdo cuál es la limitación de escritura). Lo mismo con la segunda y la sexta. Así, podemos probar las cuatro imágenes del warm boot y que la última de ellas lo que haga sea modificar (escribir) sólo los bytes que diferencian la dirección de la quinta imagen de la dirección de la primera (y 2ª vs 6ª). Ya tenemos una demo para probar el uso de más de cuatro imágenes sin intervención externa, ni del FTDI ni de ningún Arduino. Y para ello no es necesario ni un Lattuino, porque sólo hay que escribir unos pocos bytes por SPI. Evidentemente es una demo muy limitada, pero sirve para demostrar la esencia del planteamiento. De hecho, es al mismo tiempo la justificación de por qué es necesario Lattuino o Arduino/CortexM.
Un saludo
PD: estoy juntando las ideas en este repo https://github.com/1138-4EB/icemulti, que pretende ser un frontend para tus variantes de icemulti e iceprog. La idea es cargar una colección de bitstreams y poder agruparlos/reordenarlos gráficamente para generar el mapa de la memoria flash. Estoy tratando de ordenar las múltiples posibilidades y de aclarar los esquemas eléctricos; a partir de las notas que tenía por el disco, de los hilos que has enlazado en los últimos mensajes y de las aclaraciones de Eladio. Todavía está muy muy verde, pero igual encuentras algo interesante o erróneo.
Juanma Rico
Mar 30, 2018, 6:13:09 PM3/30/18
to FPGAwars: explorando el lado libre
El viernes, 30 de marzo de 2018, 21:14:15 (UTC+2), 1138-4EB escribió:
¡Hola Unai! ;)
Hola Juanma!
¡Hola Unai! ;)
Bueno... no sé si utiliza los mismos drivers que Apio... lo que sí te puedo decir es que en Windows 7 en ninguno de mis puertos USB del portátil funciona (ni instalando el driver que aconseja Luke) y en GNU/Linux sólo me funciona en un puerto USB bajo Ubuntu y como te digo, el bootloader no carga el bitstream del usuario quedándose con el control si lo alimentas por ese puerto. :((
De ahí mi enfoque para facilitar la utilización de un Arduino o Attiny: se puede utilizar el propio bootloader de Arduino (que funciona) o V-USB (https://www.obdev.at/products/vusb/index.html). Como comenté, es muy complicado que un bootloader HDL se comporte como un USB "en condiciones".
Bueno, no te lo quería preguntar... pero te lo pregunto. :))
¿Por qué es complicado que un bootloader HDL se comporte como un USB? Imagino que es por la secuencialidad de las instrucciones... pero para que me lo confirmes... porque ya empiezo a dudar. :))
(Por cierto, muy interesante lo del V-USB... :)))
Luego este mega-bitstream generado se carga en la flash mediante el iceprog que también modifiqué para poder consultar la lista de nombres y poder intercambiar los vectores de acceso (grabar los primeros 4k) para no tener que volver a grabar el bitstream si se encontrara entre esos 128 pregrabados (con lo que se ahorra tiempo si solo hay que grabar 4k), todo está en la ayuda del binario explicado... en fin, esto sé que lo sabes, pero era para situar a los que nos lean.No lo recordaba del todo. De hecho, algunos de los últimos mensajes no los llegué a leer. Voy a revisar...
Te doy tiempo para que revises... y si lo puedes probar, mejor. :))
A todo esto... he visto que con las prisas puse icepack y no, el programa que genera el mega-bitstream es el icemulti (este es el que yo modifiqué, en el hilo aparece el nombre correcto).
Si lo hacemos sobre la TinyFPGA o sobre alguna futura Alhambra que tenga más de 1K, yo sería más partidario de usar un Lattuino en FPGA, más que hacerlo exteriormente con un Arduino... la verdad... ya que tenemos el poder de las FPGA... ¡Utilicémoslo! jajajajajaja
La cuestión principal es si la solución puede o no ser del tipo stop-the-world. En el caso de TinyFPGA, o de la solución propuesta por Eladio, es necesaria una imagen sólo durante la programación, y después se arranca otra. En el contexto de la reconfiguración dinámica, esto supone un parón:
1. En la RAM hay cuatro imágenes descomprimidas y ocho comprimidas (las cuatro y otras cuatro).
2. Estoy utilizando un circuito (digamos que el 3) y por condiciones del entorno tengo que cambiar a otro que no está entre los cuatro direccionables. Es decir, a uno no comprimido (digamos que el 6).
3. Si es necesario guardar información de estado, la escribo en la flash (en un espacio para datos).
4. Hago un cold/warm boot y paso al circuito "bootloader" (el 0).
5. El "bootloader" (Lattuino) lee la imagen 6, la descomprime y la escribe en la sección correspondiente al cold boot 2.
6. Se reinicia y carga el circuito 2.
7. Si es necesario, se leen los datos guardados anteriormente.
Desde el paso 4 hasta el paso 7 el circuito no está operativo. Si es el controlador de una planta/motor, y el cambio es debido a que en ciertas condiciones se necesita otro circuito más específico, durante ese tiempo (que pueden ser desde decenas de ms hasta segundos) no hay control. Esto puede ser aceptable, o puede no serlo. Si se utiliza un dispositivo externo (conectado al bus en paralelo con la FPGA), el proceso se paraleliza:
3. Informo al "Arduino" del cambio requerido.
4. El "Arduino" lee la imagen 6, la descomprime y la escribe en la sección correspondiente al cold boot 2.
5. Si es necesario guardar información de estado, la escribo en la flash (en un espacio para datos).
6. Se reinicia y carga el circuito 2.
7. Si es necesario, se leen los datos guardados anteriormente.
En este caso, la FPGA sólo está inoperativa entre los pasos 6 y 7. Estos pasos son, además, muchos más rápidos que la operación de lectura, descompresión, etc.
En el supuesto del "Lattuino", si se puede añadir en todos los circuitos (y todavía queda espacio para la aplicación en si), se puede aplicar el proceso sin stop-the-world. Pero si no es así, y el "Lattuino" está en una sola imagen (que es el bootloader), estamos en el supuesto anterior. Adicionalmente, un micro externo permite lo siguiente y el Lattuino no:
- Leer la imagen, descomprimirla y programar la FPGA directamente (sin pasar por la flash) y sin necesidad de usar warm/cold boot.
- Usar la memoria interna del micro como RAM, para almacenar datos entre reconfiguraciones por medio de warm/cold boot.
Como ves, las posibilidades son muchas. Estoy de acuerdo en que utilizar Lattuino, aunque sea parando el mundo, es una solución muy útil y didáctica. De hecho, estoy reinstalando herramientas para hacer alguna prueba. Pero siendo este un hilo donde sugerir pequeños detalles, estoy tratando de ver la foto completa, para evitar carencias en el diseño del PCB a la hora de poner en práctica algunas de las pruebas.
Pues es cierto, yo no había caído en eso del "stop-the-world"... pero es que me da tanta "pereza" que haya un microcontrolador "puñetero" regulándolo todo teniendo una FPGA en la placa... que casi prefiero que se pare el mundo... pero es cierto que hay que temerlo en cuenta, por supuesto. :))
Saludos
Saludos
Juan Manuel Rico
1138-4EB
Mar 30, 2018, 7:11:41 PM3/30/18
to FPGAwars: explorando el lado libre
Buenas!
Bueno, no te lo quería preguntar... pero te lo pregunto. :))
¿Por qué es complicado que un bootloader HDL se comporte como un USB? Imagino que es por la secuencialidad de las instrucciones... pero para que me lo confirmes... porque ya empiezo a dudar. :))
Efectivamente, son muchas secuencias muy diferentes, es un flujo muy poco paralelizable y muy pensado para ejecución secuencial. Pero, principalmente, porque es un estándar para muchas cosas: transferencia de archivos de un disco externo, conexión de webcam, adaptador a TTL (FTDI), teclado/ratón, impresoras.... cada dispositivo con sus particularidades. Por ello, tiene múltiples capas de abstracción, que dificultan su realización en hardware. Además de lo anterior, que es común a muchos estándares, el del USB no debe ser el mejor escrito/pensado. Pero esto último no estoy en condiciones de afirmarlo.
Como muestra, la especificación son 80MB: http://www.usb.org/developers/docs/usb20_docs/#usb20spec
El manual de un IP-core: http://www.farnell.com/datasheets/1906962.pdf
Un proyecto en opencores: https://opencores.org/project,usb
No es casualidad el éxito de FTDI y de otros chips parecidos para convertir USB a UART. Cuando los PCs tenían puerto serie, las FPGAs incluian conectores DB9 RS-232 y lo habitual era utilizar una UART directamente: https://www.xilinx.com/products/boards-and-kits/1-elhacw.html Algo muy habitual en placas con uC también. Al decidir los fabricantes de placas quitar los puertos DB9 y dejar sólo USB, hubo unos años de desorientación, porque muchísimos desarrolladores se quedaron sin una forma fácil de comunicar las placas con el PC (primero portátiles y después torres). Los adaptadores tipo FTDI que hay ahora en aliexpress a 1€, eran cables de 20€. Esto no es hace mucho. Diría que una década.
(Por cierto, muy interesante lo del V-USB... :)))
Y tanto. Tengo muchas ganar de conectar un NRF24L01 a un Attiny y otro a un nunchuk impreso en 3D para tener un "presentador" inalámbrico.
Pues es cierto, yo no había caído en eso del "stop-the-world"... pero es que me da tanta "pereza" que haya un microcontrolador "puñetero" regulándolo todo teniendo una FPGA en la placa... que casi prefiero que se pare el mundo... pero es cierto que hay que temerlo en cuenta, por supuesto. :))
Paso a paso XD. Primero deshagámonos del FTDI. Probemos que un Arduino puede sustituirlo y demos una excusa a Eladio para reemplazarlo por un atmega32u o para quitarlo. La ventaja principal que nos ofrece es que ya hay librerías para manipular memorias SPI; eso que no hay que hacer. Ahora hay que escoger un protocolo para transferir los bitstream del PC a través del Arduino; y así adaptar o reemplazar iceprog. Después hay que integrar esos cambios en las rutinas de programación en apio.
Una vez hecho lo anterior, se dispone de una separación clara entre la funcionalidad que debe tener PC y qué debe hacer el bootloader.
A partir de ahí, ¿cuánta de la funcionalidad que está implementada en el Arduino se puede/merece mover a HDL? ¿cuánto a Lattuino? En el camino irás viendo que el uC, sea externo o empotrado, hace más falta que molestia. Si es externo, en última instancia se puede mantener dormido todo el tiempo. Por contra, no tenerlo limita muchísimo las posibilidades de interacción con el mundo exterior. Hace casi treinta años que todas las FPGAs tienen al menos un procesador, ya sea hard o soft, y ya sea sólo para desarrollo o incluido en el producto final. No es casual.
Otro punto de vista es que el código que se ejecute en Lattuino debería ser el mismo que el del Arduino externo y algo más. Por lo tanto, hacer pruebas con Arduino es una forma de desarrollar y depurar el software sin tener que pelear con la síntesis para que quepa todo en la FPGA. Para gustos, puntos de vista.
Un saludo
Juanma Rico
Mar 30, 2018, 7:24:19 PM3/30/18
to FPGAwars: explorando el lado libre
¡Hola Unai!
El sábado, 31 de marzo de 2018, 0:01:06 (UTC+2), 1138-4EB escribió:
Hola de nuevo,
Eladio,
Deseoso de escuchar esos detalles del diseño :D
Teniendo en cuenta el cambio en el tamaño de los bitstream, ¿habéis considerado incrementar el tamaño de la flash?
Juanma,De esta forma se le puede inyectar y dar valor a la placa en sí misma para que pase a ser referente de esta punta de lanza en la "investigación" que llevan a cabo los integrantes del grupo FPGAwars. A mi entender es algo que no se puede desaprovechar, es una oportunidad que no se puede dejar pasar, sino siempre iremos por detrás (es mi humilde opinión).
Estando de acuerdo en la importancia de la realimentación entre la producción de la Alhambra y el grupo, creo que hay que ser cuidadosos con no confundir deseo con necesidad.
Sí, es posible que yo me deje llevar por el deseo... eso no te lo voy a negar. :))
Al final, introducir una nueva característica implica un balance entre coste y beneficio. Aunque podemos atisbarlo, ahora mismo no está claro el beneficio que ofrece la adición de una RAM, o la sustitución del FTDI por un Arduino. Así, siendo la punta en esta lanza, debemos conformarnos con poder prototipar con relativa facilidad; en comparación con, por ejemplo, tener que soldar los pines cold boot en la Alhambra v1.1. Si se detecta alguna necesidad adicional al poner en marcha los prototipos, o se ve que sobra algo, hay tiempo de cambiarlo. Si se hacen cambios para soportar posibles características y después se comprueba que faltaba un pin auxiliar por conectar, el estropicio ya está hecho.
Sí, es posible... es posible que yo sea más lanzado en este tema porque me dejo llevar por el deseo... es posible. :((
Dicho esto, una "shield" de RAM QUAD SPI + conector micro-SD + para la Alhambra II sería un complemento muy interesante (a añadir al VGA). Si no he entendido mal, ya no existen los adaptadores de nivel, por lo que los pines GPIO no tienen "ninguna" latencia con respecto al pin correspondiente en la FPGA, así que se puede esperar un rendimiento mejor que en la Alhambra v1.1. ¿Es así Eladio?
Si la placa dispone de este hecho diferencial, hará que sea más atractiva a otras opciones existentes en el mercado; de hecho, para los que quieran investigar esa posibilidad del cambio entre múltiples sintetizados en tiempo real sería la única opción.
En relación con lo comentado en el bloque anterior, hay que prototipar para depurar las ideas.
Pues sí, en eso te doy la razón... hay que prototipar... y yo precisamente soy el que no lo está haciendo (y ya hace meses que tengo las RAM SPI en el cajón)... al final te voy a dar la razón en todo y me voy a tragar todas las regañinas... jajajajaja
Por ejemplo, cuando envié las primeras respuestas a este hilo creía que era necesario conectar el Arduino como maestro de la FPGA y la SPI, para poder programar la FPGA desde Arduino. A lo largo de la conversación, Eladio me ha hecho ver que se puede usar la propia FPGA como bypass (en principio en la icestick y en la Alhambra v1.1, sin tener que esperar a la II). No es la solución ideal, pero ya ofrece un punto en el que poder trabajar para explorar las diferentes formas de empaquetar múltiples bitstreams, qué metainformación añadir, qué compresión utilizar, etc. Asimismo, yo ya estaba cutter en mano para deshacerme del FTDI, y nos ha explicado cómo poder ignorarlo, gracias a las resistencias que ya se han añadido (por otro motivo).
De hecho, estos últimos días he llegado a la conclusión de que tampoco es necesario conectar en el PCB los pines cold boot a GPIO. Del mismo modo que se puede usar la FPGA como bypass para hacer el bus SPI accesible a través de GPIO, se puede instanciar el módulo de warm boot y conectar los puertos a dos pines cualquiera. El proceso sería: cargar "bootloader" que incluye warm boot, leer las entradas y ejecutar reboot inmediatamente después. No es óptimo, porque implica que en cada (re)inicio hay que reconfigurar dos veces la FPGA; por lo tanto, sigue siendo útil tener accesibles los cold boot "de verdad". Pero sirve como analogía, y como un "no hay excusas para no cacharrear".
Bueno, lo que propones con "simular" los pines del "cold boot" y utiliizar dos pines cualesquiera conectados al "warm boot" y resetear... es prácticamente lo mismo que yo llevo haciendo con los botones de la iceZum Alhambra desde que empezamos con este tema. En el reset se carga el warmboot.bin (que sería el bootloader al que te refieres...) y luego un botón cambia el bitstream a seleccionar y el otro provoca el reset para cargar el nuevo bitstream.
Incluso hay por ahí ya un bloque hecho en icestudio para facilitar la cosa y seleccionar el bitstream desde la propia pantalla VGA.
En definitiva creo que es lo mismo que propones, pero en lugar de tomar los valores de los dos pines externos (simulando los pines reales del "cold boot") los toma de un registro interno... no aporta nada "mirar" el valor en el registro interno a mirarlo en los pines externos. Lo que aporta los pines del "cold boot" es precisamente eso, un "arranque en frío" al encender o resetear directamente la FPGA (sin pasar por la carga de cualquier tipo de bootloader).
Así que aquí no te admito la "regañina"... que en esto no ha "cacharreado" nadie tanto como yo... jejejejejejeje :))
En el mercado hay miles de tarjetas "master pro" con una capacidad mil veces mejor, simplemente hay que pagarlas y a veces no hay que pagar mucho para la potencia que tienen. El único precio a pagar realmente es que hay que pasarse al lado oscuro (- ¿Es más fuerte el "reverso tenebroso"? - No, no, no, más fácil, más rápido, más seductor... ).
No estoy muy seguro de que en el mercado haya muchas "master pro" tan pequeñas y, por tanto, tan de bajo consumo. No soy ni mucho menos un experto en este rango/nicho, pero diría que una tipo BlackIce II pero sin tanto conector grande y con la mitad de tamaño podría empezar a tener sentido para "computing in-the-edge" en el contexto del IoT. Digamos, por ejemplo, una OV7670 + Arduino/CortexM + iCE40 para detección facial/control de acceso. Lo más cercano que conozco es http://gnarlygrey.atspace.cc/development-platform.html Tienen forma de Nano y hay adaptador para OV7670, pero el modelo de FPGA que incluyen no soporta warm/cold boot (sólo las series LP y HX). Además, en línea con lo comentado anteriormente con Eladio, la versión 1 no tiene conector USB, y la versión 2 lo tiene pero incluyendo FTDI.
No sé si tan pequeñas, pero lo que es seguro es que no las hay programables con herramientas libres ;) que utilicen intensivamente el "cold/warm boot" de Lattice, es más, seguro que es sólo en este grupo donde se ha tenido la idea (y se ha puesto en práctica, recuerdo que hay modificaciones de icestorm tools funcionales aunque se necesita del PC) de intercambiar los cuatro vectores que permite Lattice para aprovechar todo el espacio en flash,... después alguien lo utilizará en alguna placa y dirán que fue una idea genial (como ahora se anda diciendo de la idea del bootloader de Luke...), pero nosotros llevamos más de un año con el tema... :((
Ahora pensando en esto último.... Sí, lo reconozco una vez más... lo de la RAM SPI es posible que sea un deseo propio por impulsar esa gran idea, más que una necesidad del grupo... :((
Sí, te entiendo, pero soy de la opinión de que si es necesario sacrificar algún componente o la propia forma de la placa misma en pos de estar en la "punta de lanza", yo lo haría.
En cuanto a la forma, estoy de acuerdo. Me gustaría saber hasta qué punto es relevante que la forma sea la de Arduino Uno, en vez de tener los "zócalos" pero ser ligeramente diferente en cuanto a dimensiones. E.g. BlackIce.
Pues si estás de acuerdo... nada que añadir... ;))
A mi entender hay que preguntarse... ¿Qué aporta el FTDI para estar "en punta de lanza"? (Creo que nada, todos lo usan...) ¿Y la forma de la tarjeta como un Arduino Uno? ¿Quieres que se utilicen las shield existentes de Arduino? Bien... pues se pueden mantener la distancia de pines, pero la forma y dimensiones es atarse a algo que, en sí, ya aporta poco.
Sin acritud ninguna, ¿cuál es la solución actual sin el FTDI que ofrezca la misma funcionalidad y no de más problemas de soporte/conexión? Estoy de acuerdo en que puede reemplazarse por un Atmega32u4, porque ya lo hizo Arduino en su día con los Leonardo y se puede reutilizar el framework. Pero habría que pogramar las rutinas para que cumpla la función del FTDI entre el PC y la FPGA/flash; que, sin ser difíciles, no conozco si están escritas. También podría prescindirse del Atmega y usar directamente un bootloader como el de TinyFPGA; pero habría que depurarlo/mejorarlo. Lo que quiero decir es que, a pesar de que el FTDI sobre, no hay un reemplazo directo que sólo requiera cambios en el PCB. ¡Prototipemos!
La solución la veo fácil... en lugar de perder el tiempo grabando el FTDI, ese tiempo se use para grabar un bitstream (todo lo robusto que quieras, incluso el Lattuino de Salvador Tropea) que haga de bootloader y que se use el "cold boot" para darle velocidad y robustez al sistema (incluyendo los interruptores DIP para seleccionar los otros bitstreams libres del usuario)... es decir, se puede poner un bootloader en el reset que esté a la escucha y si no oye nada "salte" al bitstream del usuario... o se puede elegir los bitstreams por "cold boot" sin necesidad de que el bootloader intervenga. Pero es verdad... ¡Prototipemos! :D
Sí, claro, Eladio. Esto se puede hacer, creo que incluso con la propia icezum Alhambra actual (tengo conocimientos de electrónica, pero no soy experto), de hecho tengo las RAM SPI compradas para probar el montaje (cuando pueda), pero creo que finalmente se trata de eso... de ponerlo fácil y diferenciarse (entre otras de la TinyFPGa y la UPDuino).
Incluso yo estaba por dejarlo más ordenado todo y soldar una shield para esos "experimentos", pero claro... entonces la "punta de lanza" estaría en la shield y no en la placa misma... perdemos una oportunidad (humilde opinión como siempre).Sí, creo que es viable y una gran idea. Pero por desgracia veo que se pierde la gran ventaja que tiene el sistema "cold/warm boot" que es que en milisegundos tienes un circuito digital totalmente distinto funcionando en la FPGA.
Mi idea en su momento, cuando buscaba y pensaba en la RAM SPI para el "cold/warm boot", era "clonar" el contenido completo de la flash en la RAM SPI en el momento del encendido de la placa y trabajar con la RAM SPI en los reinicios y selecciones de los distintos bitstreams para la FPGA en lugar de la flash, sería posible porque no se pierde la alimentación del integrado con lo que se mantiene la información en ella. Con esto la flash sufriría menos grabaciones y se prolongaría su vida de uso. Es verdad que tengo que probar todo esto... a ver si se me termina el SAV con la VGA y vuelve a ser prioridad el "cold/warm boot" y puedo confirmar que es posible... :))
Juanma, con todo el cariño, creo que estás pensando de más XD. Por más que releo tus explicaciones sobre cómo usar esa RAM SPI (no flash), no me hago a la idea de por qué hacerlo así. Podría tener su utilidad para lo que entendí que propuso Jesús de usarla para almacenar tablas, datos, capturas... (aunque ya le indiqué que la flash se puede usar para ello) Incluso como memoria de programa de un Lattuino (aunque con un rendimiento muy pobre). Pero en el contexto del cold/warm boot no entiendo por qué necesitas/necesitamos una. ¿Qué podemos hacer con ella que no podamos hacer sólo con la FPGA + SPI?
Entiendo que puede ser quisquillosa la limitación para borrar contenido en la flash, pero no es nada que no se pueda solucionar con un poco de creatividad. Supongamos que en los primeros 4k en realidad sólo está el applet, porque movemos el resto del contenido. Además, situamos las imágenes que vamos a utilizar en direcciones concretas, de forma que de la primera a la quinta sólo cambien 0s a 1s, o viceversa (no recuerdo cuál es la limitación de escritura). Lo mismo con la segunda y la sexta. Así, podemos probar las cuatro imágenes del warm boot y que la última de ellas lo que haga sea modificar (escribir) sólo los bytes que diferencian la dirección de la quinta imagen de la dirección de la primera (y 2ª vs 6ª). Ya tenemos una demo para probar el uso de más de cuatro imágenes sin intervención externa, ni del FTDI ni de ningún Arduino. Y para ello no es necesario ni un Lattuino, porque sólo hay que escribir unos pocos bytes por SPI. Evidentemente es una demo muy limitada, pero sirve para demostrar la esencia del planteamiento. De hecho, es al mismo tiempo la justificación de por qué es necesario Lattuino o Arduino/CortexM.
Sí, es una opción... quizás la pruebe, pero teniendo la RAM SPI en la caja... como que me voy a poner con ella antes que hacer pruebas tan limitadas.
Un saludo
Un saludo
Juan Manuel Rico
PD: estoy juntando las ideas en este repo https://github.com/1138-4EB/icemulti, que pretende ser un frontend para tus variantes de icemulti e iceprog. La idea es cargar una colección de bitstreams y poder agruparlos/reordenarlos gráficamente para generar el mapa de la memoria flash. Estoy tratando de ordenar las múltiples posibilidades y de aclarar los esquemas eléctricos; a partir de las notas que tenía por el disco, de los hilos que has enlazado en los últimos mensajes y de las aclaraciones de Eladio. Todavía está muy muy verde, pero igual encuentras algo interesante o erróneo.
¡¡Perfecto!! Le echaré un vistazo. :))
Juanma Rico
Mar 30, 2018, 7:36:14 PM3/30/18
to FPGAwars: explorando el lado libre
Buenas de nuevo Unai... ya no te contesto entre líneas que sino hoy no duermo... jejejejejeje
Simplemente decirte que tienes razón, que hay que prototipar más y hay que ver que los conceptos funcionen...
A ver si saco tiempo y retomo la RAM SPI y me pongo a soldar. :))
Por cierto.... es verdad que algo le pasa a tu correo o a tus mensajes que el sistema los borra de vez en cuando del grupo... y curiosamente a mi me aparece en el cliente Thunderbird como "posible correo fraudulento"... debe ser alguna cuenta de correo de los tuyos o un servidor que uses que está en una lista negra o similar... o tengas puesto como servidor de salida SMTP en tu cliente uno no bien configurado... la cuestión es que sospechan de tus correos por algún motivo. :))
Échale un vistazo a tus servidores de entrega de correo que seguro algo le pasa.
Saludos
Juan Manuel Rico
Jesús Arroyo
Apr 5, 2018, 6:23:08 PM4/5/18
to FPGAwars: explorando el lado libre
Buenas Eladio!
Muchas gracias por las aclaraciones :)
Pero sobre todo agradecerte tu tiempo y esfuerzo dedicado a diseñar placas para que las disfrutemos todos. Mucho ánimo con las siguientes fases de desarrollo de la placa.
Un saludo!
Muchas gracias por las aclaraciones :)
Pero sobre todo agradecerte tu tiempo y esfuerzo dedicado a diseñar placas para que las disfrutemos todos. Mucho ánimo con las siguientes fases de desarrollo de la placa.
Un saludo!
Eladio Delgado
Apr 14, 2018, 3:01:26 PM4/14/18
to FPGAwars: explorando el lado libre
Hola Unai,
El 30 de marzo de 2018, 21:59, 1138-4EB <umarti...@ikasle.ehu.es> escribió:
Hola Eladio,La opción que comentamos no es tan ágil como acceder directamente al bus pero permite hacerlo para experimentar con cold boot y el desgaste de la memoria no sería un problema. Estas memorias soportan 100K ciclos de escritura por sector.
Sabiendo que son 100K, puedo estar tranquilo por muchas pruebas que haga XD.
La primera opción que comentas me parece interesante y si no la hago es por falta de espacio en la placa, ya que no añade ningún coste. Lo he probado también con pines de 2 mm de pitch pero no cabe. Lo anoto para próximas versiones.Lo que sí creo que se podrá hacer es poner puntos de test en estas señales para que se puedan soldar cables en lugar de la tira de pines, no es tan elegante pero valdría igualmente.
Miré el diseño de la Alhambra en KiCAD y ya me parecio difícil que entrara algo... Al no saber cuánto espacio habéis ahorrado en la nueva versión, tenía la esperanza. Pero, en cualquier caso, si se pueden poner los puntos de test sin que suponga un problema, sería muy de agradecer. Como comentabas en algún otro mensaje, no es el target de esta placa, pero ayudaría para no tener que hacer chapuzas. Creo que, de hecho, serían útiles no sólo para conectar un Arduino/CortexM, sino para ver las comunicaciones y hacer debug con un osciloscopio/analizador de señales.Me refería en general a la idea de tener uC + FPGA en una placa para poder hacer unas tareas por HW y otras por SW según las características de cada una. Me parece que sería una placa muy didáctica y con muchas capacidades. Y no habria FTDI, su función la haría el uC.
Entiendo que te refieres a algo parecido a la BlackIce II: https://www.tindie.com/products/Folknology/blackice-ii/ Aunque en este caso hay un CH340 además del USB del uC (no acabo de entender por qué).
En el caso de la BlackIce, yo creo que el uC está más para asistir a la FPGA que para ser una placa de co-diseño hardware/software, que es lo que veo muy interesante en general. Independientemente de eso, el planteamiento de la BlackIce me parece muy bueno.
La interfaz "rápida" de comunicación entre el Cortex y la FPGA es QUAD SPI: https://github.com/mystorm-org/BlackIce-II/wiki/Connections-between-the-STM32-and-the-iCE40 Por tu experiencia, ¿crees que habría problemas de ruido si la FPGA estuviera en una placa y el Cortex en otra? Sea la FPGA una shield/base para una placa ST32 tamaño Arduino Nano, o viceversa. En otras palabras, ¿por qué una placa y no dos stackeadas que se vendan como un solo producto? Lo pregunto desde la más absoluta ignorancia de si puede ser debido al rendimiento, o si realmente es mucho más caro fabricar un solo PCB que dos mitades.
Haciendo bien el rutado de los PCBs no hay ningún problema para alcanzar velocidades altas para QSPI. La opción de dos placas apiladas es más costosa de producir que una sola pero eso no significa que sea peor opción, depende de muchos factores y puede ser tan buena una opción como la otra.
En este caso se pueden tener las dos cosas: que sea un módulo programable desde el PC como la TinyFPGA y que sea muy pequeño y de bajo coste. Yo creo que lo haríamos así, ya que el conector USB no añade mucho coste y la placa tiene tan pocos componentes que queda espacio.
Si el coste del conector USB es despreciable y no complica el montaje, desde luego es un plus. Ya sea para programar la FPGA, o como un conector 'estandar' que permite una comunicación serie asíncrona full-duplex.
La alimentación tampoco es problema siempre que no ese activen los PLLs y se haga trabajar a alta frecuencia. Podemos utilizar reguladores lineales que tienen bajo coste y ocupan poco espacio.El tema que comentas de la batería de 3.7V siempre lo tengo en mente. El sistema de alimentación de estas placas es compatible con el rango de tensión de las baterías LiPo 1S y muchos las tenemos a mano (sobre todo ahora con los drones). Pueden ser una buena solución para montajes con muchos servos.
Con respecto a las tensiones, mi pregunta iba más dirigida a si los reguladores que se utilizan para entradas de 5V (USB) son exactamente los mismos que utilizariais si la entrada estuviera "limitada" a 4,2V. Interpreto que no hay ahorro ni en coste ni en espacio por esos 0,8V, por lo que no hay nada que cambiar.
Sí, eso es. En ese rango de tensión casi cualquier regurador acepta hasta 5.5V en su entrada.
Sobre los PLLs, entiendo que el problema puede ser por los reguladores lineales en lugar de conmutados. ¿Es significativa la diferencia de coste? ¿Y el rendimiento/eficiencia?
El regulador conmutado es más costoso que el lineal pero las ventajas que tiene compensan.
En el caso de la Alhambra II, usamos un regulador conmutado de dos salidas que nos da 1.2V y 3.3V con 1A en cada salida. Normalmente no se va a alcanzar esta corriente pero si se llegara, la placa estaría prácticamente fría y se podría alimentar con 1A a 5V (desde un USB 3.0). Y en la mayoría de los casos, incluso usando el PLL, se podría alimentar con menos de 0.5A desde cualquier puerto USB.
Si el regurlador fuera lineal, necesitaría 2A en el puerto USB (habría que usar el segundo puerto USB de la placa) y la disipación sería 5.5W con lo que la placa estaría muy caliente.
En el caso de la Alhambra II, usamos un regulador conmutado de dos salidas que nos da 1.2V y 3.3V con 1A en cada salida. Normalmente no se va a alcanzar esta corriente pero si se llegara, la placa estaría prácticamente fría y se podría alimentar con 1A a 5V (desde un USB 3.0). Y en la mayoría de los casos, incluso usando el PLL, se podría alimentar con menos de 0.5A desde cualquier puerto USB.
Si el regurlador fuera lineal, necesitaría 2A en el puerto USB (habría que usar el segundo puerto USB de la placa) y la disipación sería 5.5W con lo que la placa estaría muy caliente.
Opción 1:En la Alhambra II no hay problema por haber dos maestros en el bus, está 100% resuelto con las resistencias. En la IceZUM (al igual que en la Icestick) también funciona aunque no esté resuelto de la forma más correcta. Por otro lado, como he comentado antes, podemos poner puntos de test para acceder al bus con un tercer maestro sin problemas, ya que el FTDI no domina el bus gracias a las resistencias, y el otro maestro (la FPGA) se puede poner fácilmente como esclavo con la señal SS o incluso, si se quiere, ponerla en alta impedancia con el reset. De esta forma un tercer maestro puede acceder a la flash.
Ya lo he comentado, pero lo de los puntos de test, unido al detalle de las resistencias que has subrayado, a mí me parece más que suficiente para considerar que la placa no "limita" la posibilidad de hacer pruebas. De hecho, lo pondría como una "feature".
No sé si muy de destacar pero sí sería una feature :-) De todas formas estará en la documentación.
Un saludo
Un saludo,
Eladio
--
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/b43f8e54-b975-47fe-92f2-5c0fab40f24c%40googlegroups.com.
Eladio Delgado
Apr 14, 2018, 3:08:53 PM4/14/18
to FPGAwars: explorando el lado libre
Hola de nuevo,
Teniendo en cuenta el cambio en el tamaño de los bitstream, ¿habéis considerado incrementar el tamaño de la flash?
La IceZUM Alhambra monta una flash de 32 Mb que es la de mayor capacidad que he visto en estas placas. Como dices, en la Alhambra II el bitstream es mayor (8 veces más) pero aún así caben más de 30 bitstream. La idea es mantener esta memoria pero puede que tengamos que cambiarla por una de menor capacidad, no por la diferencia de coste sino por la disponibilidad. La de 32 Mb no se encuentra fácilmente a veces.
Si no puede ser la de 32 Mb será de 16 o de 8Mb como mínimo. En la de 8 Mb habría espacio para los 4 bitstream seleccionables por coldboot y aún queda otro tanto para más bitstream u otros usos.--
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/7cfe8184-f425-41bc-94d7-d084a4b0c884%40googlegroups.com.
Eladio Delgado
Apr 14, 2018, 3:12:51 PM4/14/18
to FPGAwars: explorando el lado libre
Muchísimas gracias Jesús!! Lo hago extensible al resto del equipo.
De la misma forma agradecerte a ti también el tiempo y esfuerzo que dedicas a esa maravillosa herramienta que es Icestudio y que a tantas personas está abriendo la puerta de la electrónica digital.
Un saludo!
Eladio
--
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/13b32342-a806-48f3-b9ea-c49771379f62%40googlegroups.com.
Jose Pico
Apr 14, 2018, 4:20:51 PM4/14/18
to FPGAwars: explorando el lado libre
Hola:
Porqué se ice40HX 4k ?
No sería más recomendable ice40LM-4k por ejemplo que tiene dos IP I2C y dos SPI ?
Supongo que no será compatible con la ice40HX.
Saludos y Gracias
Eladio Delgado
Apr 14, 2018, 6:08:17 PM4/14/18
to FPGAwars: explorando el lado libre
Hola Jose,
La iCE40LM4K está descartada para este diseño por varias razones:- En el encapsulado más grande tiene 37 GPIO y la Alhambra II usa 40 GPIO
- Encapsulado es ucBGA que dispararía el coste del PCB
- El tamaño de la HX4K en realidad parece ser 8K con las herramientas libres. La LM4K son 4K reales, fíjate en el tamaño de sus bitstreams:
- Parece no estar soportada oficialmente aún en el proyecto Icestorm http://www.clifford.at/icestorm/
No sé si hay alguna actualización sobre el último punto.
Un saludo, Eladio
--
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/893d5634-3cd8-47ac-a4f3-39e95afda2b3%40googlegroups.com.
Jose Pico
Apr 15, 2018, 5:06:43 AM4/15/18
to FPGAwars: explorando el lado libre
Algo tenía que ser...jejejeje
Una pena no poder poner uno con IP I2c.
Saludos y Gracias
Sigue así!
Eladio Delgado
Apr 17, 2018, 5:30:21 AM4/17/18
to FPGAwars: explorando el lado libre
Al menos en la nueva hay más espacio para meter esos IP :-)
Saludos,Sigue así!
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-lib...@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/893d5634-3cd8-47ac-a4f3-39e95afda2b3%40googlegroups.com.
--
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/dd8474ef-1fa9-4819-93fc-64f3cda97718%40googlegroups.com.
Eladio Delgado
Apr 17, 2018, 5:35:37 AM4/17/18
to FPGAwars: explorando el lado libre
Hola!
La Alhambra II ya está lista para rutar! Vamos a ello!!
El 22 de marzo de 2018, 14:44, Eladio Delgado <email...@gmail.com> escribió:
Hola!
Mientras fabricamos las últimas unidades de la IceZUM Alhambra, estamos con el desarrollo de la nueva versión de esta placa, la Alhambra II. Abro este hilo para comentar sobre el diseño y las características que va a tener esta placa.
Los cambios más importantes que va a tener son estos:
- FPGA ice40 HX 4K
- GPIO a 3.3V tolerante a 5V (como entrada acepta niveles entre 3.3 y 5V, como salida genera 3.3V)
- Alimentación por USB (dos conectores), hasta 4.8A, para alimentarla con power bank y tener más corriente para los servos
- Los pines de selección de bitstream para cold boot están accesibles en el GPIO
- Reguladores conmutados de 1A para las alimentaciones de 1.2 y 3.3V, lo que permitirá activar los PLLs y trabajar a velocidades mucho mayores.
- Pines analógicos integrados en los pines D0 a D3 (sólo 4 de los 6 pines del header son analógicos) para mayor compatibilidad con Arduino
- Pulsadores de usuario cómodos de accionar (3 veces menos fuerza por unidad de superficie que los anteriores)
Creo que esto recoge lo que más se ha echado en falta con la IceZUM Alhambra pero por supuesto todas las ideas son bienvenidas!!
El diseño está ya bastante avanzado (terminando el esquemático).
Un saludo,
Eladio
--
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/6354bb93-972c-4b13-b3c7-0376d9ec0c1f%40googlegroups.com.
Jose Pico
Apr 17, 2018, 5:50:35 AM4/17/18
to FPGAwars: explorando el lado libre
Es cierto 8 contra 1.
Saludos y Gracias
Sigue así!
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/893d5634-3cd8-47ac-a4f3-39e95afda2b3%40googlegroups.com.
Message has been deleted
Juanma Rico
Apr 19, 2018, 4:44:13 PM4/19/18
to FPGAwars: explorando el lado libre
Gracias Unai por el enlace.
No tengo mucho tiempo este mes, pero le he echado un vistazo rápido y si de algo me he dado cuenta es que tengo que estudiar mucho más el USB y su estructura. No tenía ni idea. Tu enlace con el tinyUSB me viene de escándalo... ;)). Gracias.
No tengo mucho tiempo este mes, pero le he echado un vistazo rápido y si de algo me he dado cuenta es que tengo que estudiar mucho más el USB y su estructura. No tenía ni idea. Tu enlace con el tinyUSB me viene de escándalo... ;)). Gracias.
Eladio Delgado
Apr 20, 2018, 1:20:49 PM4/20/18
to FPGAwars: explorando el lado libre
Hola,
Estamos dando el último repaso al PCB de la Alhambra II. Nos queda panelar y lo enviamos a fabricar!
--
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 una entrada 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 este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c79eac8e-12c5-4525-913e-d703283c7bdd%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Jose Pico
Apr 20, 2018, 4:29:30 PM4/20/18
to FPGAwars: explorando el lado libre
Guay!
Eladio Delgado
Apr 28, 2018, 8:35:33 AM4/28/18
to FPGAwars: explorando el lado libre
Hola,
El PCB ya está terminado. Esperemos que el envío sea rápido :o)
El 20 de abril de 2018, 22:29, Jose Pico <josp...@gmail.com> escribió:
Guay!
El viernes, 20 de abril de 2018, 19:20:49 (UTC+2), Eladio Delgado escribió:
EladioSaludos,Hola,Estamos dando el último repaso al PCB de la Alhambra II. Nos queda panelar y lo enviamos a fabricar!
El 19 de abril de 2018, 22:44, Juanma Rico <juan...@gmail.com> escribió:
Gracias Unai por el enlace.
No tengo mucho tiempo este mes, pero le he echado un vistazo rápido y si de algo me he dado cuenta es que tengo que estudiar mucho más el USB y su estructura. No tenía ni idea. Tu enlace con el tinyUSB me viene de escándalo... ;)). Gracias.
Un saludo
Juan Manuel Rico
--
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 una entrada en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-lib...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c79eac8e-12c5-4525-913e-d703283c7bdd%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
--
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/c442ae8e-caed-48ca-b413-b69baf5f8d63%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Diego
Apr 28, 2018, 8:37:26 AM4/28/18
to fpga-wars-explora...@googlegroups.com
Sav al 10000%
El sáb., 28 abr. 2018 14:35, Eladio Delgado <email...@gmail.com> escribió:
EladioSaludos,Hola,El PCB ya está terminado. Esperemos que el envío sea rápido :o)
El 20 de abril de 2018, 22:29, Jose Pico <josp...@gmail.com> escribió:
Guay!
El viernes, 20 de abril de 2018, 19:20:49 (UTC+2), Eladio Delgado escribió:
EladioSaludos,Hola,Estamos dando el último repaso al PCB de la Alhambra II. Nos queda panelar y lo enviamos a fabricar!
El 19 de abril de 2018, 22:44, Juanma Rico <juan...@gmail.com> escribió:
Gracias Unai por el enlace.
No tengo mucho tiempo este mes, pero le he echado un vistazo rápido y si de algo me he dado cuenta es que tengo que estudiar mucho más el USB y su estructura. No tenía ni idea. Tu enlace con el tinyUSB me viene de escándalo... ;)). Gracias.
Un saludo
Juan Manuel Rico
--
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...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c79eac8e-12c5-4525-913e-d703283c7bdd%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/c442ae8e-caed-48ca-b413-b69baf5f8d63%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/flvaYt9nCaA/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/CAJXdXgRtVdRbj7hviS4HRN7sedRp1x-TT4-%2B%2B0xVMkjsuJsEPQ%40mail.gmail.com.
Juan Gonzalez Gomez
Apr 28, 2018, 10:59:58 AM4/28/18
to FPGA-WARS: explorando el lado libre
Sav a tope!! Dios mio, no quiero ni pensar lo que vamos a poder hacer con 4K(8K)
Muchas gracias Eladio! 😃😃😃
Saludos, Obijuan
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABVaRgVh_PxBXNxDK%3D8dhvD7R3EttSz7TJhNBoG50uxXUY55zQ%40mail.gmail.com.
Eladio Delgado
May 2, 2018, 12:47:36 PM5/2/18
to FPGAwars: explorando el lado libre
Hola,
El prototipo de la Alhambra II está más cerca!
Tenemos casi todo el material y el PCB ya está en Sevilla! 😃😃
Saludos,
Eladio
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABqu7xrc%3DhGvd7yKG4ZSri4eMA7jz7VE-HWHtp40x0ZnK-DznQ%40mail.gmail.com.
Juanma Rico
May 14, 2018, 2:51:16 PM5/14/18
to FPGAwars: explorando el lado libre
Buenas Eladio,
Tengo curiosidad... teniendo en cuenta esto en este hilo y sabiendo que se va a mantener el FTDI en la nueva versión, siendo por tanto compatible con iceprog...
¿Se le han hecho a esta versión de la Alhambra las modificaciones necesarias para que se pueda transferir el bitstream directamente a memoria de la FPGA sin pasar por la grabación en la flash? Gracias.
Eladio Delgado
May 21, 2018, 3:52:34 PM5/21/18
to FPGAwars: explorando el lado libre
Hola!
Os actualizo los últimos avances con la Alhambra II.
El pasado 8 de mayo montamos los primeros prototipos (2 unidades) para verificar si todo funciona como esperamos. No teníamos algunos de los componentes de producción con lo que decidimos montarlos a mano.
Lo contamos en Twitter en tiempo real en este hilo: https://twitter.com/EladioDM/status/993849808631812096
Os lo cuento aquí con más detalle:
Para montarlo a mano ayuda mucho agrupar por colores los componentes con la misma referencia, nosotros lo llamamos mapa de designadores.
Aplicamos la pasta de estaño a dos PCBs de un panel (panel y stencil esta vez fabricados en PCBWay):
Ahora toca poner componentes a mano
Algunos de ellos son sensibles a la humedad, por lo que sacamos los que vamos a usar y volvemos a sellar la bolsa anti-humedad
Ponemos los componentes por altura y tamaño, terminando con el más alto
Pasamos a la soldadura por refusión con el pico de temperatura alrededor de 240 ºC
Y aquí están ya los primeros prototipos montados. Faltan los conectores de inserción pero no los montamos por ahora hasta que hagamos las mayoría de pruebas
Ahora viene el momento más emocionante conocido como smoke test 😁😁
Aunque no tiene por qué haber humo, basta con limitar la fuente a una corriente que no cause daños si algo está mal. En este caso a 60mA.
No puedo adjuntar el vídeo, pongo una captura y enlace al tuit: https://twitter.com/EladioDM/status/993913276068237313
Después configuramos el FTDI para que se comporte como puente USB-SPI + USB-UART y el PC la detecte como Alhambra II
Hasta ahora hemos hecho las pruebas funcionales para comprobar que las conexiones entre componentes están bien (no hay errores en el esquemático ni en la definición de símbolos y huellas). Todo está bien, no hemos encotrado errores por ahora.
Estos días estamos haciendo las pruebas que analizan la parte analógica del diseño. Son las que ocupan casi todo el tiempo de pruebas y las más interesantes porque son las que aportan fiabilidad al diseño. Estas las vemos en el otro post.
Un saludo,
Eladio
--
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-lib...@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/71fadbce-483b-40d5-bccd-3ba21c7ba4f2%40googlegroups.com.
Cristóbal Contreras Rubio
May 21, 2018, 4:11:55 PM5/21/18
to fpga-wars-explora...@googlegroups.com
Brutal Eladio, gracias por compatirlo ;-)
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/CAJXdXgS_TjMnUkQP690niy9ULKmA%3DSysWzON-Ok%3DKeW8NBJJhQ%40mail.gmail.com.
Eladio Delgado
May 21, 2018, 4:14:18 PM5/21/18
to FPGAwars: explorando el lado libre
Hola Juanma,
Tener la opción de configurar la FPGA sin pasar por la flash se puede hacer añadiendo 3 jumpers con 2 posiciones (9 pines en total).
Por el tema que se comenta en el hilo que mencionas, no le veo sentido. La flash tiene una vida de 100K ciclos lo que a efectos prácticos es ilimitada.
La única ventaja que le veo es que la carga del bitstream sería casi instantánea frente a los 3.5s que tarda en programarse desde Icestudio, en Windows. No me parece un tiempo que haga incómoda de usar la placa o al menos no en la mayoría de los casos.
Por otro lado poner jumpers complica el uso, las opciones de montaje (la placa no sería operativa sin la inserción montada) y sube el coste.
Y por último el espacio, añadir los jumpers tendría que ser a costa de quitar otra funcionalidad de la placa.
Además de lo mencionado ¿qué motivos ves para incluir estos jumpers?
Eladio
El 14 de mayo de 2018, 20:51, Juanma Rico <juan...@gmail.com> escribió:
--
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/71fadbce-483b-40d5-bccd-3ba21c7ba4f2%40googlegroups.com.
Eladio Delgado
May 21, 2018, 4:15:00 PM5/21/18
to FPGAwars: explorando el lado libre
Gracias Cristo! 😃
Un saludo,
Eladio
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAJXdXgS_TjMnUkQP690niy9ULKmA%3DSysWzON-Ok%3DKeW8NBJJhQ%40mail.gmail.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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/CA%2BtaF2oR-QhSh0GXq33QBsy97hXPJ0Cs3Q_7T%2BZzLzBoSabbTQ%40mail.gmail.com.
Juanma Rico
May 21, 2018, 6:48:27 PM5/21/18
to FPGAwars: explorando el lado libre
Buenas Eladio,
¿Por qué es necesario añadir "jumpers"? ¿No hay una forma más "limpia" de tomar el control del bus SPI que no sea conectando y desconectando pistas?¿Qué sería necesario para hacerlo?¿Se podrían hacer las conexiones "chapuceras" en la Alhambra v1.1 como indica Clifford para la ICEStick y poder grabar directamente el bitstream en la FPGA?
Realmente (como digo en mi mensaje) es simple curiosidad, aunque no creo que yo utilice todos los ciclos de borrado de la flash, estaría bien dar la posibilidad de no utilizarlos... sobre todo en toda una sesión de pruebas en las que no desconectas la placa ni llegas a hacer un reset en la misma.
Por otro lado, como tú dices, es todo más rápido... en las pruebas que hago cargando los bitstream más completos se pueden llegar a los 30 segundos (evidentemente más, pasando incluso de los minutos, si grabo toda la flash usando la posibilidad del Warm/Cold boot). De todas formas comprendo que (una vez más) esto es una inquietud personal mia y no de todos los posibles usuarios de la iceZum Alhambra, así que entiendo que tampoco se haya pensado en esta posibilidad como una característica necesaria en la nueva versión. Simplemente me acordé de dicha limitación y me asaltó la curiosidad (esas cosas que tiene el querer aprender de todo un poco... :)) ).
Muchas gracias por tu trabajo.
Un saludo
Juan Manuel Rico.
perick van der vir
May 22, 2018, 6:11:22 AM5/22/18
to FPGAwars: explorando el lado libre
Saludos Eladio!
Excelente trabajo de I+D. Eres un crack, ppor cierto vas a crear un grupo de crowfounding para la fabricación , si esta creado ya mándame el link si no es así cuenta conmigo.
un saludo .
Eladio Delgado
May 22, 2018, 8:38:51 PM5/22/18
to FPGAwars: explorando el lado libre
Hola Juanma,
Es cierto que no habría por qué usar jumpers, es la solución más simple pero se podrían usar multiplexores por ejemplo. Respecto a las conexiones que comentas se pueden hacer en la Alhambra II igual que en la Icestick, usamos una red de resistencias 1206 en lugar de las resistencias 0603 que usa la Icestick, con lo que puede resultar un poco más complicado pero se podría hacer. En la IceZUM no hay esas resistencias con lo que la única forma de hacerlo es cortando pistas, no he comprobado si sería posible según el rutado.
En cuanto a los tiempos que comentas de grabación de la flash, no sé a qué se deben. Según las especificaciones de estas memorias, un bitstream de la 8K debería de grabarse en el orden del segundo, más los tiempos de borrado y algo más. Haciendo pruebas me ha llamado a atención que hay muchos tiempos muertos en el SPI durante la programación, muchos más de los necesarios de programación de página. Lo he visto de pasada mientras comprobaba otoras cosas, no aseguro nada. Habría que ver a qué se debe y si esto se puede optimizar en el Iceprog.
Por otra parte, para el caso del cold/warm boot ya no nos vale programar la FPGA directamente, necesariamente hay que pasar por la flash. Esto, unido al hecho de que tendemos a eliminar el FTDI (obliga a que la FPGA se configure desde la flash), me hace pensar si no habría alguna forma de usar una flash pequeña sólo para el bootloader y cargar los bitstream desde una microSD. En este caso, además de eliminar problemas de espacio, los tiempos de programación serían mucho más cortos ¿Sería una solución para trabajar con múltibles bitstreams (aparte de las ventajas de tener la microSD como propuso Jesús Arroyo)? ¿cómo lo ves?
Un saludo,
Eladio
--
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/169b74f7-f2a6-4674-b8bc-4862fda42af9%40googlegroups.com.
Eladio Delgado
May 22, 2018, 8:42:17 PM5/22/18
to FPGAwars: explorando el lado libre
Gracias Perick!! 😃
Por ahora no vamos a hacer un crowdfunding para la Alhambra II. Con la IceZUM Alhambra estamos produciendo tiradas cortas pero con más frecuencia y logramos tener stock siempre. Las placas se pueden pedir aquí: https://alhambrabits.com/buy/
Para la Alhambra II haremos lo mismo. Por ahora las reservas que se están haciendo es con ese mismo formulario, indicando en el campo "Comments" que es una reserva para la Alhambra II.
Un saludo,
Eladio
--
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/4d76cae3-0096-4c7c-9442-2b5fe7853726%40googlegroups.com.
perick van der vir
May 23, 2018, 12:34:51 AM5/23/18
to fpga-wars-explora...@googlegroups.com
Buenos días Eladio.
Ya tengo tengo la suerte de haber estado en la lista de la primera edición.
Mi placa de momento no ha dado muchos problemas si bien es cierto que no he tenido mucho tiempo para ir probando todo lo que tenemos ya avanzado en el grupo de fpgawars .
Pero me gustaría en un futuro próximo poder hacerme con el nuevo modelo.
El SAV me come por dentro.😁😁
El mié., 23 may. 2018 2:42, Eladio Delgado <email...@gmail.com> escribió:
Gracias Perick!! 😃Por ahora no vamos a hacer un crowdfunding para la Alhambra II. Con la IceZUM Alhambra estamos produciendo tiradas cortas pero con más frecuencia y logramos tener stock siempre. Las placas se pueden pedir aquí: https://alhambrabits.com/buy/Para la Alhambra II haremos lo mismo. Por ahora las reservas que se están haciendo es con ese mismo formulario, indicando en el campo "Comments" que es una reserva para la Alhambra II.Un saludo,Eladio
El 22 de mayo de 2018, 12:11, perick van der vir <peri...@gmail.com> escribió:
Saludos Eladio!
Excelente trabajo de I+D. Eres un crack, ppor cierto vas a crear un grupo de crowfounding para la fabricación , si esta creado ya mándame el link si no es así cuenta conmigo.un saludo .
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/4d76cae3-0096-4c7c-9442-2b5fe7853726%40googlegroups.com.
--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/flvaYt9nCaA/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/CAJXdXgSQtk1TtZ-3dWwW72CERa1M8mP-XE-4VV0GLfx_GazB2Q%40mail.gmail.com.
Juanma Rico
May 23, 2018, 4:43:36 AM5/23/18
to FPGAwars: explorando el lado libre
Buenas Eladio, gracias por tus respuestas.
Lo de cortar pistas en la iceZum Alhambra ya me echa para atrás, era lo que quería saber... el nivel de "peligrosidad" necesario para obtener dicha funcionalidad... Ahora ya lo sé... Gracias... :))
Descarto entonces hacer pruebas de programación directa si hay que cortar pistas, que soy un "cagao" para estas cosas... Aunque todo depende del nivel de SAV del momento... como me pasó con el asunto del cold boot, en el que al final me puse a hacer equilibrios con los cables a riesgo de que saltaran chispas... así que no diré "nunca"... :)))
Estoy contigo... los tiempos de grabación no son "lineales" (por decirlo así) con el tamaño del bitstream. Imagino que depende de los sectores que finalmente se ocupen, lo que tenga que borrar antes de grabar o las pausas en la comunicación del iceprog, realmente no lo sé. Aunque he llegado a investigar el código del iceprog en profundidad para adaptarlo a su uso con el cold/warm boot, no tengo la capacidad ni la experiencia en comunicaciones con la flash y el FTDI como para saber dónde está el "cuello de botella" o a qué se deben estos parones en la grabación para optimizarlo. Recuerdo que en el código vi modificaciones de Salvador E. Tropea (SET) que indicaban optimizaciones... pero sinceramente no sé en qué afectaba a la optimización del iceprog.
Efectivamente para el cold/warm boot hay que pasar por la flash, con lo que los tiempos no mejoran aunque se disponga de la funcionalidad de la grabación directa en la FPGA, simplemente nos indica lo lento que puede llegar a ser grabar en una flash frente a dicha grabación directa.
Respecto a cargar los bitstream directamente desde una microSD y tener un pequeño bootloader en la flash... al leer la idea, en un primer momento, me ha dado un vuelco al corazón pensando en lo chulo que estaría, luego lo he pensado un poco mejor y no sé si funcionaría, te explico como yo lo veo....
La carga de los distintos bitstream mediante el cold/warm boot se decide desde la FPGA sobre un único dispositivo direccionado mediante el SPI.
Sobre este dispositivo con el que se establece la comunicación (y solo esta comunicación) carga una cabecera con cuatro direcciones distintas y "salta" (sobre este mismo dispositivo) según el número de vector establecido en los dos pines de selección (pines externos: cold boot o pines internos: warm boot).
Es decir, el problema fundamental es que tanto la cabecera con los vectores, como el bootloader, como los bitstream a cargar deben estar en el mismo dispositivo... y según te entiendo tú propones haya un bitstream de carga (bootloader) en la flash y el resto de bitstream en la microSD... son dos dispositivos distintos conectados a un mismo SPI que no sé si la FPGA está preparada para seleccionar en el proceso de reset... ¿De cuál lee la cabecera de direcciones?¿De cuál el bitstream con el bootloader?¿De cual el bitstream a ejecutar definitivamente en la FPGA?... hummmm, no lo veo, de momento no lo veo... claro de como se podría hacer, al menos, no lo tengo.
Lo seguiré pensando.... :)))
Un saludo y muchas gracias.
Juan Manuel Rico
心翔
Jun 20, 2018, 10:34:54 PM6/20/18
to FPGAwars: explorando el lado libre
Hi，
When will it be released？
thanks
在 2018年3月22日星期四 UTC+8下午9:44:22，Eladio Delgado写道：
在 2018年3月22日星期四 UTC+8下午9:44:22，Eladio Delgado写道：
Eladio Delgado
Jun 21, 2018, 5:21:42 AM6/21/18
to FPGAwars: explorando el lado libre
Hi,
We hope to have it ready in the second half of july.
Regards,
Eladio
--
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/7b8ae22e-99dd-4f30-9c22-daaaa9917b69%40googlegroups.com.
Vicente Navalo
Aug 16, 2018, 10:42:22 PM8/16/18
to FPGAwars: explorando el lado libre
buenas acabo de llegar a este grupo. ¿ hay algun simulador para IceZUM Alhambra? gracias
El jueves, 22 de marzo de 2018, 14:44:22 (UTC+1), Eladio Delgado escribió:
Moises Mendoza
Aug 25, 2018, 10:17:10 PM8/25/18
to FPGAwars: explorando el lado libre
Hola
Me gustaría estar enterado cuando salga la nueva versión de IceZUM Alhambra II. Podrías enviar una cotización con envío a México.
Lo anterior, ya que estamos interesados para actualizarnos en FPGA, ya que mi esposa es maestra de Mecatrónica en una escuela pública del Estado de Querétaro.
Saludos
Moy Mendoza
Eladio Delgado
Aug 26, 2018, 4:06:49 AM8/26/18
to FPGAwars: explorando el lado libre
Hola Moisés,
La Alhambra II ya se está vendiendo. Para pedirla lo puedes hacer con el formulario que hay en AlhambraBits.com/buy
Un saludo,
Eladio
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/b092f68a-66e7-494f-8eee-d142cb9fe129%40googlegroups.com.
Message has been deleted
Eladio Delgado
Aug 28, 2018, 12:34:27 PM8/28/18
to FPGAwars: explorando el lado libre
Hola Josep,
Sí por favor, inténtalo de nuevo. No sé qué habrá pasado pero no nos ha llegado.
Gracias!!
Eladio
El mar., 28 ago. 2018 16:26, Josep Klaro <klar...@gmail.com> escribió:
Hola Eladio.Hice el proceso de compra de en AlhambraBits.com/buy pero no me ha llegado el correo de contestación. ¿Lo hago de nuevo?Un saludo
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/06be0611-e034-46b3-af64-c226f3895568%40googlegroups.com.
Jesús Rodríguez Conde
Aug 28, 2018, 9:21:09 PM8/28/18
to FPGAwars: explorando el lado libre
Fuaaaaaa, me ha encantado todo el hilo, desarrollo, planteamientos, razonamientos y blablablabla
De verdad no sabéis lo que me habéis hecho. Antes de conoceros me sentía muy solo en el sentido profesional. Incluso en el OSHW nunca he tenido ni sentido el feedback que he tenido con vosotros y me encanta.
Desde que he recibido la placa la llevo analizando, y encima con vuestros comentarios ha sido puro porno para ingenieros. De verdad nunca tendré palabras suficientes para agradecer haberos conocido, porque en el mundo del i+d en España me invadía la desidia, incluso he llegado a pensar que aquí nada es posible tecnológicamente. Cada vez que me despierto antes miraba el facebook para ver gilipolleces, y ahora lo primero que hago es ver el twitter, sólo por vosotros.
Gracias de verdad.
Eladio Delgado
Aug 29, 2018, 6:56:50 PM8/29/18
to FPGAwars: explorando el lado libre
Hola Jesús,
Me alegra saber que FPGAwars te esté aportanto tantas cosas!!
Este hilo lo tengo muy abandonado, pero no tengo tiempo para más. Lo actualizaré en algún momento :-)
Un saludo,
Eladio
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/1ae77c42-1328-4e9a-a01a-069ab712d35f%40googlegroups.com.
Josep Klaro
Aug 30, 2018, 8:34:59 AM8/30/18
to FPGAwars: explorando el lado libre
Lo mandé ayer. A ver si ahora llega.
Un saludo
Eladio
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/b092f68a-66e7-494f-8eee-d142cb9fe129%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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.
Eladio Delgado
Aug 30, 2018, 10:00:38 AM8/30/18
to FPGAwars: explorando el lado libre
Josep, sigue sin llegarnos. Por favor envía un mail con tus datos a ad...@alhambrabits.com y nosotros creamos el pedido.
Disculpa las molestias 😊
Saludos, Eladio
Eladio
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/b092f68a-66e7-494f-8eee-d142cb9fe129%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/06be0611-e034-46b3-af64-c226f3895568%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/8c2514fc-ac52-4f95-82cb-69c87ae1bc64%40googlegroups.com.
Noemi Pérez
Sep 5, 2018, 2:00:00 PM9/5/18
to fpga-wars-explora...@googlegroups.com
Buenas tardes quisiera saber como utilizar la tarjeta con dip switch en vez de interruptores de 3 patas de conexión????
Eladio
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/b092f68a-66e7-494f-8eee-d142cb9fe129%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
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/CAJXdXgT2zABNUp309UErWsv2n1fbszCof29zKSmwXyx4fZ07kQ%40mail.gmail.com.
lberjan...@gmail.com
Sep 15, 2018, 9:31:54 AM9/15/18
to FPGAwars: explorando el lado libre
Hola a tod@s. Soy nuevo en esto de las FPGA (Alhambra II). La tengo conectada a un puerto usb 2.0, he instalado icestudio, (trabajo con ubuntu mate) siguiendo los pasos que indica obijuan y siempre me da "puertos E/S de la FPGA no definidos". ¿Alguien puede echarme una mano? Gracias
Juan Gonzalez Gomez
Sep 15, 2018, 10:24:34 AM9/15/18
to FPGA-WARS: explorando el lado libre
Los ejemplos están hechos para la icezum alhambra, por lo que al abrirlos para otra placa tienes que definir qué pines de entrada/salir
Si lo que tienes es cargado el ejemplo básico de encender un led, simplemente ve al bloque amarillo del led, pincha en el desplegable y selecciona el numero de LED, por ejemplo LED0
Todos los bloque amarillos tienen que estar asignados a algún pin de la placa
Saludos, Obijuan
El sáb., 15 sept. 2018 15:31, <lberjan...@gmail.com> escribió:
Hola a tod@s. Soy nuevo en esto de las FPGA (Alhambra II). La tengo conectada a un puerto usb 2.0, he instalado icestudio, (trabajo con ubuntu mate) siguiendo los pasos que indica obijuan y siempre me da "puertos E/S de la FPGA no definidos". ¿Alguien puede echarme una mano? Gracias
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/88a1962d-f5a6-43ff-8495-20309f7ebd62%40googlegroups.com.
rodriguezrod...@gmail.com
Sep 16, 2018, 4:30:17 AM9/16/18
to FPGAwars: explorando el lado libre
Hola, espara ver si alguien a usado los sensores de arduino en aceZUM alahambra o hay un video para ver gracias
Foxy CTG
Dec 1, 2018, 10:45:37 AM12/1/18
to FPGAwars: explorando el lado libre
La Alhambra || contiene protección a corto circuito?
Con que debo tener cuidado al hacer mis pruebas y practicas?
Democrito
Dec 1, 2018, 6:29:49 PM12/1/18
to FPGAwars: explorando el lado libre
Tiene resistencias de 200 ohmios, entonces no sucede nada.
Eladio Delgado
Dec 1, 2018, 7:17:58 PM12/1/18
to fpga-wars-explora...@googlegroups.com
Hola,
Los 20 pines de señal están protegidos con las resistencias que ha comentado Demócrito, se pueden cortocircuitar a masa, a 5V, a 3V3 y entre sí. Igual para el pin de reset y REF.
Los 5V que hay en los pines rojos (5V_P), y el pin 3V3 se pueden cortocircuitar a masa.
Todos estos cortos se pueden mantener sin límite de tiempo y no causan daños en la placa.
Es decir se puede cortocircuitar todo con todo sin límite de tiempo y no daña la placa, con una excepción: los pines 5V_P y 3V3. El corto entre ellos sólo puede ser momentáneo. Este caso lo tengo pendiente de caracterizar.
Saludos,
Eladio
El dom., 2 dic. 2018 0:29, Democrito <spo...@gmail.com> escribió:
Tiene resistencias de 200 ohmios, entonces no sucede nada.
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/4e8fc9b3-bd89-4e36-adb1-9ae197d43aa2%40googlegroups.com.
Foxy CTG
Dec 1, 2018, 7:33:49 PM12/1/18
to FPGAwars: explorando el lado libre
Gracias, igualmente el uso del pin 3v3 será de poco uso, el más común de usar será el 5V.
Solo que también, soy algo torpe y los cables Jumper se ponen en medio de las pistas, y me da miedo eso.
Solo que también, soy algo torpe y los cables Jumper se ponen en medio de las pistas, y me da miedo eso.
Eladio Delgado
Dec 2, 2018, 7:49:25 AM12/2/18
to fpga-wars-explora...@googlegroups.com
Sí, con los cables macho eso puede ocurrir. Usando estos cables lo más seguro es tener la placa apagada mientras se hacen conexiones.
Saludos,
Eladio
El dom., 2 dic. 2018 1:33, Foxy CTG <cristia...@gmail.com> escribió:
Gracias, igualmente el uso del pin 3v3 será de poco uso, el más común de usar será el 5V.
Solo que también, soy algo torpe y los cables Jumper se ponen en medio de las pistas, y me da miedo eso.
--
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...@googlegroups.com.
Para publicar una publicación en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/110bfa2a-7ee7-4831-99fd-4e76f79e6d70%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Foxy CTG
Dec 2, 2018, 5:40:49 PM12/2/18
to FPGAwars: explorando el lado libre
Hablando de apagar. Haciendo mis trabajos tomaba en cuenta un interruptor de encendido y apagado, pero al darle uso los componentes externos de la placa seguían encendidos.
Ese interruptor que función toma? A mi parecer es de dar o dejar de dar alimentación de 5V o 3v3
El domingo, 2 de diciembre de 2018, 13:49:25 (UTC+1), Eladio Delgado escribió:
Sí, con los cables macho eso puede ocurrir. Usando estos cables lo más seguro es tener la placa apagada mientras se hacen conexiones.Saludos,
Eladio
El dom., 2 dic. 2018 1:33, Foxy CTG <cristia...@gmail.com> escribió:
Gracias, igualmente el uso del pin 3v3 será de poco uso, el más común de usar será el 5V.
Solo que también, soy algo torpe y los cables Jumper se ponen en medio de las pistas, y me da miedo eso.
--
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 una publicación en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Foxy CTG
Dec 2, 2018, 6:02:11 PM12/2/18
to FPGAwars: explorando el lado libre
Pensándolo, hay alguna forma de configurar el voltaje de un pin? Si lo quiero de 5V o 3v3?
Democrito
Dec 2, 2018, 7:50:40 PM12/2/18
to FPGAwars: explorando el lado libre
Pensándolo, hay alguna forma de configurar el voltaje de un pin? Si lo quiero de 5V o 3v3?
No importa.
Pin como entrada: Acepta sin problemas lógica de 3.3v y 5v.
Pin como salida: Siempre dará ese pin 3.3v (y quizás un pelín más).
A no ser que tú externamente le añadas algo (un transistor, o un conversor de tensión, por ejemplo), no es posible tener salidas de 5v. De todas formas, la mayoría de las cosas que salen hoy en día funcionan a 3.3v y muchas otras cosas que funcionan a 5V capta sin problemas la lógica de 3.3v. Sin embargo hay que "andarse con ojo", y mirar el datasheet de lo que funcione a 5v para no llevarnos sorpresas o fallos intermitentes.
Un saludo.
Foxy CTG
Dec 3, 2018, 2:04:25 PM12/3/18
to FPGAwars: explorando el lado libre
Como usar periféricos de entrada o salida de PWM?
Llegue a controlar un servo mediante la tecnica de Obijuan, al usar un modulo de corazon microsegundos y temporizador microsegundos.
Ahora bien, me gustaría darle uso a este servo con un pontenciometro. Como indico una entrada PWM cuando el pontenciometro solo se mueve en amplitud y no longitud?
Jose Pico
Dec 8, 2018, 10:53:09 AM12/8/18
to FPGAwars: explorando el lado libre
2 pulsadores y un contador up-down con un valor de inicio.
por ejemplo un contador que inicie en un valor de 127 ( dutty aprox de 50% en un servo de 8 bits = 255 ) y con los pulsadores aumentar/decrementar en escalones de 10 (o lo que desees).
Resumen de lo necesario:
2 pulsadores ( con antirebote mejor ) + contador 8 bits Up-down + PWM con entrada de 8 bits.
todos esos recursos los tienes en el curso de Obijuan y un PWM puedes verlo
Saludos
Foxy CTG
Dec 15, 2018, 5:25:09 AM12/15/18
to FPGAwars: explorando el lado libre
Duda momentánea. Cuales son los pines que puede generar ondas? Tanto cuadradas, alternas, triangulares, etc... Y cuales son los pines que pueden recibir esas señales y entenderlas.
Foxy CTG
Dec 22, 2018, 6:49:56 PM12/22/18
to FPGAwars: explorando el lado libre
Probando el ultimo tutorial de la temporada 1 de Obijuan, cuando le junte un display Hexa con un Servo 8 bit. Si el Servo no llega a su punto correctamente, empieza hacer una especie de zumbido como si tratase de posicionarse en el punto correcto, y a la vez eso provoca que el display empiece a parpadear los leds apagados asta que el Servo deja de vibrar.
Eso no se si viene fallo del programa editado, o es proveniente de la Alhambra ||
El sábado, 8 de diciembre de 2018, 16:53:09 (UTC+1), Jose Pico escribió:
Eladio Delgado
Dec 26, 2018, 5:09:25 PM12/26/18
to fpga-wars-explora...@googlegroups.com
Hola,
Puede que esto se deba a los picos de corriente que absorve el servo. La placa debe tener una alimentación capaz de proporcionar esos picos, intenta usar una fuente USB de al menos 2A. También puede ser que el servo consuma picos muy granes (aunque sea pequeño) y necesites alimentar ambos puertos de la Alhambra II.
Saludos,
Eladio
--
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...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@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/d6097ced-c4fc-446e-b866-2f65c58f41fb%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Foxy CTG
Dec 26, 2018, 7:55:33 PM12/26/18
to FPGAwars: explorando el lado libre
Fue porbado el conectarle dos cargadores, pero el servomotor sigue interfiriendo en los 8 bits del POT.
Si alguien puede probarlo, y ver si el servomotor le hace efecto en los 8 bits,cuando se mueve o darle una fuerza.
El servo usado son los pequeños azules.
Si alguien puede probarlo, y ver si el servomotor le hace efecto en los 8 bits,cuando se mueve o darle una fuerza.
El servo usado son los pequeños azules.
Eladio Delgado
Dec 28, 2018, 12:52:48 PM12/28/18
to fpga-wars-explora...@googlegroups.com
Los servos a los que creo que te refieres consumen demandan picos de corriente mayores que otros servos más grandes, como los s3003.
Otras cosas que pueden ser: cable USB con poca sección en los hilos de alimentación o un cable demasiado largo.
--
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...@googlegroups.com.
Para publicar una publicación en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/47524ecd-b692-4639-ac67-2389627d5525%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Foxy CTG
Dec 28, 2018, 5:07:51 PM12/28/18
to FPGAwars: explorando el lado libre
el servomotor usado es el micro servo 9g sg90 tower pro
El viernes, 28 de diciembre de 2018, 18:52:48 (UTC+1), Eladio Delgado escribió:
Los servos a los que creo que te refieres consumen demandan picos de corriente mayores que otros servos más grandes, como los s3003.Otras cosas que pueden ser: cable USB con poca sección en los hilos de alimentación o un cable demasiado largo.
El jue., 27 dic. 2018 1:55, Foxy CTG <cristia...@gmail.com> escribió:
Fue porbado el conectarle dos cargadores, pero el servomotor sigue interfiriendo en los 8 bits del POT.
Si alguien puede probarlo, y ver si el servomotor le hace efecto en los 8 bits,cuando se mueve o darle una fuerza.
El servo usado son los pequeños azules.
--
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 una publicación en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages