[RS232] Enviando datos del PC a la FPGA.

[Democrito]

Hola!

Es muy tarde para mí, pero quería hacer una pequeña aportación para la gente que está como yo (en estado embrionario con las FPGA) y próximamente tengo varias preguntas sobre lo que presento, pero lo dejaré para otro día.

Se trata de un circuito que recibe caracteres del PC vía puerto serie con configuración 9600,8,1 (un bit de stop y sin paridad). Lo que le llega lo representa en 8 leds (icestick=TR3..TR10). Funciona muy bien, de momento no me ha fallado por más pruebas que le he hecho. Pese a lo que digo quiero mejorar una cosa para asegurarme de que toma los bits que recibe a mitad de estos (por eso hay un contador de más, el contador de la izquierda se podría eliminar, pero está para terminar de diseñar lo de tomar los datos a mitad de éstos), para tener mayor seguridad en la recepción, y luego quiero añadirle el poder enviar datos al PC.

El esquema (adjunto el "ice") de la recepción de datos queda así:

Tuve problemas (uso windows) para poder configurar la icestick el puerto serie que tiene, le pasé Zadig para convertir el puerto 1 que se supone que está libre (porque el 0 está para programar la FPGA) como puerto CDC (puerto virtual de comunicaciones), pero no lo hace bien. Total, que me tuve que pillar un FTDI aparte que puede trabajar con 3.3V y con eso no tuve problema, le enchufé el TX de la FTDI al BR10 de la icestick y así pude hacer las pruebas.

Para muchísimos proyectos es importante poder comunicarse con el PC, es por ello que estoy trabajando ahora este tema.

Saludos!

[Democrito]

Hay unas conexiones que son confusas, lo aclaro con un nuevo esquema e ice.

[Democrito]

Hola de nuevo!

He estado investigando la recepción de datos con la icestick, que seguramente funcionará igual una icezum Alhambra y las otras tarjetas compatibles con icestudio. Conseguí resolver el poder recibir datos sin la necesidad de una FTDI aparte. Como muchos saben, pero lo comento para los que vayan llegando a este apasionante mundo, la icestick y Alhambra tiene un chip FTDI que es doble, se llama FT2232H. Ese chip se encarga de transmitir el bitstream a la FPGA y como tiene un segundo puerto, también se puede utilizar como puerto virtual de comunicaciones (VCO) y es el que vamos a utilizar para enviar datos a la icestick. Lo nuevo en todo esto es poder recibir datos a 230400 baudios, pero antes de comenzar, comentar que Obijuan tiene en su tutorial un ejercicio completo de emisor y receptor hecho con verilog puro y duro; puedes hacer clic aquí y aquí para ver sus ejemplos. Para conocer todos los entresijos de la comunicación asíncrona, te recomiendo fehacientemente leer esos capítulos.

El esquema es el siguiente, casi una copia del anterior, y he pintado las líneas principales para que se vea más claras las conexiones.

Todavía me queda aspectos por investigar, y lo digo porque en el esquema se aprecia un divisor de frecuencia (DIV4) que probablemente se pueda eliminar, pero de momento es así como mejor resultado me ha dado. FFDCPN es un flip-flop que se activa por flanco de bajada, y sirve para detectar cuándo se pone a cero la señal que entra por RX. Ese flip-flop es el detonante para que todo se ponga en marcha. Permite a través de una puerta AND que entre la señal cuya frecuencia (en el prescaler) junto con el divisor de frecuencia "DIV4" da los baudios que necesitamos para ir tomando los bits que entran por RX, y decodificar la información.

Pongo una imagen de cómo se ve en el osciloscopio.

La señal amarilla es lo que entra por RX, y la verde son los pulsos que recibe a través del clock (CP) del registro de desplazamiento, esta vez de 10 bits. He añadido a la imagen aspectos para mejor comprensión en la interpretación de la gráfica. Como se aprecia, el bit más bajo (LSB) es el primero en entrar, justos después del bit de inicio. El registro de desplazamiento "SR10" carga y a la vez desplaza los bits que le van llegando con cada pulso que recibe. El valor recibido es el caracter ascci '¬' (170 en decimal) y puse ese valor a propósito porque es 10101010 en binario (por la línea de tiempo y teniendo en cuenta que el primer bit es el más bajo, es por eso se ve al revés), de esa manera se aprecia mejor los unos y ceros con cada flanco de subida.

Una cosa que he tenido muy presente y esto lo puedo ver gracias al osciloscopio (para ver lo que realmente está sucediendo) es tratar de que el flanco de subida caiga a la mitad del bit recibido. Esto es importante para tener seguridad en los datos recibidos. En mi caso particular (el ejemplo que muestro y adjunto) cae ligeramente hacia la izquierda, pero está dentro de una zona razonable y fiable. Si estuviera un desplazamiento mayor hacia la izquierda, sería un riesgo y no lo daría por válido. En mi caso particular la fórmula que utilizo para calcular la frecuencia es teniendo presente el divisor de frecuencia:

Donde "Valor del Prescaler" es el valor que usaremos en el prescaler, los "12000000" la frecuencia del cristal, DIVn es el divisor de frecuencia y 230400 es a los baudios que quieres manejar y puedes poner ahí el que más te interese. Todo esto parece que sea complicarse la vida, pero como busco que la señal del flanco de subida caiga lo más en medio posible, entonces hemos de ir buscando que el valor del prescaler sea lo más "entero" posible. Por ejemplo, el que estoy utilizando es un DIV8 (n=4) porque de todos los divisores que he calculado es el que más se acerca a un valor entero del prescalar, y me da 12000000/(4*230400)=13.02803333... Si observas el esquema, el valor del prescaler es de 13. Cuanto mayor sea el valor de esos decimales, mayor será el desplazamiento de la onda y con esto hay que tener mucho cuidado si queremos fiabilidad en los datos.

Por último os dejo con una estupenda página web en castellano que explica de una manera amena y sencilla todos los detalles sobre el funcionamientos del RS232: Clic aquí!.

Adjunto ICEs, dos versiones de velocidad (115200 y 230400) y programa en FreeBASIC (fácilmente traducible a cualquier otro lenguaje de programación) para enviar datos a nuestra FPGA. El programa consiste enviar números que va del 0 al 255.

Saludos!

[Democrito]

Fe de erratas.

Donde digo:

Por ejemplo, el que estoy utilizando es un DIV8 (n=4)

quise decir:

Por ejemplo, el que estoy utilizando es un DIV4 (n=4)

[Democrito]

Una última cosa!

Desconozco la razón, pero después de cargar el bitstream verás que los 8 leds quedan como en triestado (lucen un poco, pero muy débilmente) y la FPGA queda como colgada (por decirlo de alguna manera). Pero eso sólo sucede al cargar el bitstream; si le haces un "reset" es decir, desenchufas y vuelves a enchufar la icestick (en la icezum tiene un botón de encendido y apagado), se pone en marcha y asunto resuelto. Supongo que se debe a que como está utilizando el puerto COM y el bitstream por el otro puerto de la FTDI, no termina de darle el mando para el puerto que nosotros usamos.

[Jesús Arroyo]

Genial! Qué chulo!!

Quedan muy bien los cables de colores. Me lo apunto para Icestudio del futuro. Me encantan las imágenes del osciloscopio.

Lo he validado en la iCEstick y la IceZUM.

Adjunto el script en Python que he utilizado para probarlo.

Un saludo!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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/45037eb2-25f4-4f6e-b910-36fc3d3877e5%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Cristóbal Contreras Rubio]

¿Jesus ese script te funciona? Llevo peleándome unos días con PySerialun tiempo y si ese script lo usáramos en las máquinas que tenemos no andaría (además que no veo que abras el puerto por ningún lado).

Lo que yo hago para que funcione es primero cerrar el puerto y luego abrirlo (no se porque, pero si no lo hago no va).

Adjunto la versión modificada (disculpad si me meto donde no me llaman)

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/45037eb2-25f4-4f6e-b910-36fc3d3877e5%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 "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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/CAOPL7Bm242DgK_Jh8HBnttN3n-AGmbbMXYoRpyr4pRPuERzdYw%40mail.gmail.com.

[Juan Gonzalez Gomez]

Hola Cristo,

El script Serial.py funciona bien. A mí me va perfecto.  Puedes comprobar en la API [1] que esta línea abre el puerto serie:

port = serial.Serial('/dev/ttyUSB1', 115200)

En tu script los que estás haciendo es abrir el puerto, volver a cerrarlo y volver a abrirlo

Si en tus máquinas no te funciona simplemente abriendo, es posible que tengas problemas con las señales DTR/RTS, que según la placa que tengas, se usan para hacer un reset

[1] http://pyserial.readthedocs.io/en/latest/pyserial_api.html

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAOPL7Bm242DgK_Jh8HBnttN3n-AGmbbMXYoRpyr4pRPuERzdYw%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 "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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%2BtaF2pe_vFBdkGYP_esgGVrKQ1U9Hezok%2BiBaW_vepN85hdhw%40mail.gmail.com.

[Cristóbal Contreras Rubio]

Hola Juan,

gracias por la respuesta. Si, se que hago eso repetitivo, pero es que en mis máquinas no usamos el USB tal cual, sino que usamos un conversor USB - RS232, así que las señales DTR/RTS no las tenemos.

Si conectarais la placa por unos pines con una llibrería como la SoftwareSerial en arduino, yo necesito hacer eso para que vaya.

Dicho lo cual, try-catchear algo como al apertura de un puerto nunca está de más, porque puede ser que no vaya 😉

Saludos

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CA%2BtaF2pe_vFBdkGYP_esgGVrKQ1U9Hezok%2BiBaW_vepN85hdhw%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 "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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/CABqu7xrrWPMW4PNvoVDW74PHxA6SF%3DjfMuwgRwgeLHp7_XGUOw%40mail.gmail.com.

[Juan Gonzalez Gomez]

Hola Cristo,

Try-catch siempre es bueno, pero asegúrate de incluir la instrucción que abre el puerto dentro del try, porque sino te peta (si no existe el puerto /dev/ttyUSB1). En tu script tienes:

import time
import serial

port = serial.Serial('/dev/ttyUSB1', 115200)  <--- No hay Try-catch. Aquí petaría si no existe /dev/ttyUSB1. Recuerda que serial.Serial() Abre el puerto serie
try:
..

Saludos, Obijuan

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABqu7xrrWPMW4PNvoVDW74PHxA6SF%3DjfMuwgRwgeLHp7_XGUOw%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 "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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%2BtaF2p9t0Pa59pzF4yLE5wHniJpnFH7DGS%3DsgHVJ8t6-jNDkA%40mail.gmail.com.

[Juan Gonzalez Gomez]

Hola Cristo,

  Para que la gente no se líe, voy a comentar un par de errores que es muy probable que sean fruto del copy & paste. Lo comento para que a la gente no le pase:

import time
import serial

port = serial.Serial('/dev/ttyUSB1', 115200)  <--- Debería estar en el try (ya comentado antes)
try:
    port.close()
    port.open()
except Exception, e:
    print 'Error abriendo serial'
    prin # coding=utf-8     <---------  Esto no tiene sentido en python. Tal vez querías que fuese un comentario?  # prin coding=utf-8
else:
    for i in range(255):
        h = hex(i)
        print(h)
        port.write(h)
        time.sleep(0.2)
        port.close()     <------  El close tiene que estar fuera del for, de lo contrario en la segunda vuelta, port.write(h) peta. Es muy probable que por error de copy&paste se hayan añadido espacios de más

Saludos, Obijuan

[Cristóbal Contreras Rubio]

Hola Juan,

gracias por el apunte, llevas toda la razón. De hecho yo lo que suelo poner es un bucle recorriendo los puertos hasta encontrarlo.

Saludos

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/CABqu7xqXdMicujxqkDQMxDbXwfGXP-ngPQRftoYso_Xg%3DHdCig%40mail.gmail.com.

[Democrito]

Hola de nuevo!

Antes de comenzar agradece a Jesús y Obijuan por probar los esquemas y tener la amabilidad de poner el código en otro lenguaje de programación (Python en este caso), de esta manera alcanzamos a más gente! A Jesús comentarle que la idea de poder tener la opción de colorear las pistas en icestudio, por mi parte me parece una idea genial; es otra manera de visualizar un esquema sin necesidad de nodos de unión. A mí personalmente me gusta las imágenes con colores porque las encuentro más pedagógicas, cercana y le quita ese aire de solemnidad o seriedad a los esquemas: La electrónica es para divertirse (jugar) y mola un montón!

Os presento otra manera y mucho más sencilla y comprensible de poder recibir datos con nuestra FPGA. He hecho innumerables pruebas buscando ver por dónde peta, pero hasta el momento todo los ICEs que he adjuntado funcionan de maravilla. También comentaré las limitaciones y pormenores que me he encontrado. Para mí es muy importante detallarlo todo y que si alguien ve alguna anomalía que yo no haya percibido lo comente sin tapujos. Al fin y al cabo la electricidad y la electrónica es una rama de la física y como tal hemos de estar seguros desde qué punto hasta que otro punto podemos dar por bueno algo.

Aunque he puesto muchos ICEs con distintas velocidades (9600, 115200, 230400, 460800, 921600 y 12000000) exceptuando el último, todos los esquemas son exactamente iguales y lo único que cambia es el valor del prescaler.

Lo que cambia con respecto a anteriores esquemas, es que en este no me baso en procurar que la señal de clock (luego lo verás con más detalles) tenga que caer obligatoriamente en medio de la señal que entra por TX, sino que ahora uso otra filosofía y es que esa señal de clock esté siempre fija en el mismo lugar y siempre comience con un flaco ascendente. Esto se consigue inyectando la señal de 12MHz de forma indirecta, en el sentido de que una puerta AND (izquierda) sea la que permita el paso o no de esa señal. Como ya se explicó en un anterior post, un DFFcpn (flip-flop tipo D con entrada de clock negada) es el detector de entrada de datos. Justo al bajar TX pone a '1' la 'q' del DFFcpn y se mantendrá así hasta que hayan pasado todos los datos al registro de desplazamiento, es decir, 10 pulsos de clock; el contador (counter_4bits) se encarga de resetear dicho flip-flop para volver a ponerlo en estado de alerta para el siguiente paquete de bits que entre. De hecho ese flip-flop es el que permite la entrada de pulsos. Si no estuviera recibiendo datos, el flip-flop "cortaría" la señal de entrada al clock del prescaler. Esto es todo el secreto que tiene el circuito. ¿¿¿A qué es super mega sencillo??? Lo demás ya lo conocerás de anteriores esquemas, y es la obligación de contar esos pulsos para tenerlo todo sincronizado. La puerta NOT que ves a la entrada del clock del registro de desplazamiento sirve para invertir la señal que le llega y lo que se consigue es que haya un espacio entre ese clock y la señal TX antes de guardar ese dato en el registro de desplazamiento.

Las imágenes valen más que mil palabras. Ahora veamos en acción, desde un osciloscopio, cómo se valida la información dentro del registro de desplazamiento (son las entradas a éste). Recuerda que siempre, siempre, siempre verás que la señal de clock (y siempre, siempre, siempre es flaco de subida) está después del cambio (o no) de la señal TX. Voy a poner todas las pruebas que he hecho y más abajo explico por qué no funciona con todas las frecuencias pero sí con estas que veremos ahora.

En esta primera, explica gráficamente detalles del funcionamiento, en las siguientes lo omito porque era mucho curro y es información redundante. Todas las imágenes representa, para mejor comprensión y sencillez, el número 170.

A 9600 baudios.

Observa que en todas las imágenes el flaco de subida del clock (en verde) está después de la señal TX (la que entra en el registro de desplazamiento, "Din", en amarillo).

A 115200 baudios.

Las imágenes que vienen a continuación se van poniendo tétricas... En realidad son ondas perfectamente cuadradas, pero mi osciloscopio (USB) es de gama baja y los cables para tomar las señales tienen efecto capacitivo, a mayor frecuencia, más terrorífica se ponen las ondas. Pero eso no es del todo malo, pega con la fecha en las que estamos; Halloween es dentro de pocos días!

A 230400 baudios.

A 460800 baudios.

A 921600 baudios.

Hasta aquí todo perfecto, pero hay baudios que podríamos considerar estándar y que no funciona. Pongo una imagen de un pequeño programa (está adjunto en este post) donde verás en rojo esas frecuencias con las que no funciona.

Como puedes apreciar en la imagen, las opciones de color amarillo funcionan perfecto, pero las que son rojas no funcionan. Me hice ese programa (en FreeBASIC) con todo detallado para además de enviar datos en forma de serie de números (0..255, repetidamente), que también tuviera la información, de por ejemplo, el valor que ha de ir en el prescaler en el esquema. La razón de por qué no funciona a esas otras frecuencias (en rojo) es sólo una opinión mía y que si alguien tiene más conocimientos, por favor, que me corrija. Pienso que se trata, como en un anterior post comenté, de que es necesario de que las frecuencias sean lo más "enteras" posibles (en el sentido de los decimales). A esas frecuencias no se corresponde con la que puede dar el prescaler y no puede ir sincronizada, porque es más ancha o estrecha de lo normal. Y esto se hace más patente en frecuencias altas, o dicho de otra manera, a medida de que nos acercamos a los 12MHz.

Pero... ¿¿¿¿cómo es posible que haya puesto un código que permita enviar información a 12 millones de baudios???? Pues... yo soy el primer sorprendido!!! Tiene otro esquema, no es como los anteriores. He de advertir que en este caso no puedo garantizar el perfecto funcionamiento. Dentro de las pruebas que le he realizado, en este caso ha funcionado todo bien, con excepción de una cosa extraña, y me explico: Al ejecutar mi programa hace bien la cuenta. Del programa puedes salir de 3 maneras; dándole a escape, enter (o return) y a la X de la ventana (no le des ahí pensando que te llevará a páginas eróticas!). Pues si salgo del programa con enter o escape y vuelvo a ejecutar el programa, todo funciona correctamente. Pero si le doy a la X y vuelvo a ejecutar el programa, entonces falla un bit (el más bajo no se enciende) como si se hubiese desplazado los número y comenzase a contar a partir del segundo led. Esto tiene una solución muy sencilla a través de programación y hacer que cierre bien el programa, pero lo he dejado como curiosidad de lo que sucede, porque en los otras frecuencias (en una imagen anterior en color amarillo) con esas no importa lo que hagas que siempre va bien.

Es un pasote poder alcanzar esas velocidades porque permite hacer experimentos muy interesantes en tiempo real. Si no me equivoco (y por favor, corregidme si no es cierto) 12000000/10=1200000 es decir, 1,2 mega bytes por segundo. El número 10 es el paquetes de información, es decir, los 8 bits de datos, más el bit de inicio, más el bit de stop, todo eso junto es lo que llamamos baudio (en este caso 1 baudio = 10bits, si tuviera además un bit de paridad entonces sería 11bits para un baudio). Y aunque fuese un poquito menos no dejaría de ser menos interesante! En cuanto envíe el presente post probaré si es posible enviar (al menos con ordenadores modernos) a cualquier baud rate no estándar, porque da la sensación de que se puede hacer.

Antes de terminar, comentar que hubo un chico hace unos meses que subió a GitHub una historia que a mí me sobrepasa y todavía no he visto su trabajo. Pero comentaba de cómo aumentar los 12MHz a 275MHz si mal no recuerdo. Su intención era fabricarse una tarjeta de adquisición de datos para programarse un osciloscopio. Todo lo que digo es impreciso porque lo leí hace tiempo (no mucho), cuando todavía me peleaba con las configuraciones de apio para hacer funcionar icestudio. Dejo el enlace de lo que comentaba sobre over clocking a los 12MHz a través de unos PLLs.

Saludos!

[Juan Gonzalez Gomez]

Alucinante demócrito!!!  Madre mía qué trabajazo!!!!!!!  Tus documentaciones son alucinantes!!!  Muchísimas gracias!  :-)  En cuanto pueda lo prueba en la icezum alhambra

Salludos, Obijuan

--

Has recibido este mensaje porque estás suscrito al grupo "FPGA-WARS: explorando el lado libre" de Grupos de Google.
Para anular 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/7ecc85a7-fa1b-44d7-8740-d5a185abe77e%40googlegroups.com.

[Jesús Arroyo]

Hola Demócrito,

Estás a tope!!! :-)

Gracias a ti por los proyectos que estás creando!

Lo de los cables de colores ya lo tengo apuntado (https://github.com/FPGAwars/icestudio/wiki/Icestudio-0.3.0:-proposed-features). Tengo pensado refactorizar la GUI para que sea más flexible y configurable, no se si finalmente terminaré por sustituir JointJS. Tengo mucho por aprender en ese campo aún.

Comentarte que están implementados los Biestables D asinc por defecto en Icestudio, aunque tu versión es más concreta e igual de correcta.

He probado los diseños y funcionan :) Incluso el de 12Mbaud con el script Serial.py del ejemplo inicial.

Le dejo a Obijuan si tiene algún comentario técnico sobre el diseño del circuito digital. Una pregunta, cuando te refieres a TX en realidad es RX no?

Si quieres cuando lo tengas listo puedes subirlo a icestudio-examples. Incluso la documentación se puede añadir a un fichero Readme.md en la carpeta del proyecto. Estaremos por aquí si necesitas ayuda con eso.

Un saludo!

[Jesús Arroyo]

Por cierto, yo no he necesitado reiniciar la placa después de cargar el bitstream. A lo mejor es por cómo maneja Visual Basic los puertos serie.

Si quieres puedes probar el script Serial.py para ver si te ocurre lo mismo. Puede que debas instalar pyserial si no lo tienes instalado: `pip install pyserial`.

Debes ajustar el nombre de tu puerto serie y los baudios, por ejemplo:

port = serial.Serial('COM5', 115200)

Y lo ejecutas como `python Serial.py`. Así de paso ya lo validamos para Windows.

PD: puedes ajustar la velocidad de envío con el time.sleep(0.02).

Un saludo.

[Democrito]

Gracias Obijuan!

Sobre subirlo al GitHub me gusta que pase un tiempo razonable por si alguien se da cuenta de alguna anomalía, mejorar alguna cosilla que ahora mismo no caigo y cosas así. Pasado ese tiempo lo subiré y será un placer hacerlo!

Gracias Jesús!

* Tienes razón!!! es RX!!!!! joer... Gracias por avisar!

* Cuando salgo de mi entorno de programación (FreeBASIC) me siento como un niño perdido en una playa llena de gente! Pero lo he intentado y tuve que hacer un pequeño cambio para que me funcionase, supongo que es debido al cambio de plataforma (Linux vs Windows). Adjunto tu archivo con la modificación, simplemente la función hex() la cambié por chr(). He probado con 115200 y 12000000 y en Python funciona bien salgas como salgas (haciendo clic sobre la X de la ventaba, o pulsando Control+C), eso sí, he de dejar unos segundos para que funcione bien (supongo que tarda un rato en cerrar el puerto), si respeto ese tiempo todo perfecto. Si no dejo esos segundos de tiempo entonces me sale el contaje desplazado un bit a la izquierda (sólo en el de 12000000, en el otro sin problemas).

* Lo de los leds medio encendidos (o medio apagados), me temo que son cosas de los drivers de Windows. Desde luego que en plataformas Linux, por lo visto hasta el momento, todo funciona mejor. Lo he intentado hacer con tu programa (modificado), y sigo necesitando desenchufar y volver a enchufar la icestick. No me cabe duda de que es un problema de gestión de drivers que tiene Windows.

Voy a probar una cosa que acabo de descubrir accidentalmente: Pulsando control+E se abre una cosa para meter código, o eso dice, voy a probarlo con tu código a ver cómo aparece cuando se publique... [democrito.mode test --on]

import time

import serial

port = serial.Serial('COM5', 115200)

for i in range(255):

    h = chr(i)

    print(i)

    port.write(h)

    time.sleep(0.2)

port.close()

Saludos!

[Jesús Arroyo]

Genial Demócrito!

Tienes razón en lo del chr en vez de hex. Lo correcto es chr para que tenga el mismo funcionamiento que tu programa en VB. Gracias por detectarlo. Para que se visualicen bien en la consola quedaría algo así:

import time

import serial

port = serial.Serial('COM5', 115200)

for i in range(256):

    print(i)

    port.write(chr(i))

    time.sleep(0.2)

port.close()

Efectivamente parece problema de Windows la necesidad de resetear la placa para sincronizar. Aunque habrá que seguir explorando.

Adjunto video con la IceZUM a 9600 baud y 0.05 segundos de sleep: https://drive.google.com/open?id=0B_vQY-TVqNFYQS1qR3ZYOHZubjg

Un saludo.

[Democrito]

Hola otra vez, soy el pesado de siempre!


Me gustaría hacer un paréntesis sobre la FPGA y comentar muy rápido y gráficamente cómo instalar FreeBASIC en Windows. Es multiplataforma, eso quiere decir que tb existe para entornos Linux, DOS y Xbox; y por supuesto es libre. La sintaxis es muy semejante a QBasic y VisualBasic.

Si tienes problemas para hacer funcionar lo que he publicado sobre recepción RS232, o tienes pocos conocimientos de programación, prueba a instalarte FreeBASIC IDE. Tiene editor de texto y todo eso. Es una versión muy antigua pero a la vez muy estable y siempre se está a tiempo de poder actualizar el compilador (para 32 y 64 bits) a la última versión, pero no voy a entrar ahí ahora.

Ves a esta web: http://fbide.freebasic.net/

Verás lo siguiente, y has de hacer clic en el botón en la parte derecha. Sigue el orden que indico.

No has hacer nada más, sólo esperar un poco hasta que comience la descarga.

Una vez en tu disco duro, haces doble clic y comienzas la instalación, le vas dando "Yes" o "Next" a todo lo acostumbrado. Cuando veas la siguiente imagen, haz justo lo que señalo, creo que por defecto no tendrás que hacer nada más que darle a "Next".

Y cuando te salga esta imagen de abajo, puedes dejar todas las casillas validadas, pero la más importante es que esté validada la última, que es asociar la extensión .BAS al entornos de programación FreeBASIC (FBIde).

(Next... Next... Next...) Y ya está todo. Ahora, antes de nada, toma tu icestick (o icezum alhambra, pero en ese caso tendrías que cambiar las direcciones de los leds) y le subes el bitstream de por ejemplo el de 115200 baudios. Como estás en Windows, desenchufas y vuelves a enchufar la icestick una vez que haya subido el bitstream. Ahora tomas el fichero "serial.bas" (que se supone que lo has descargado de mi post extenso anterior) y le haces doble clic. Se te abrirá como un editor de texto en plan bonito con el código visible a la vista. Y para hacerlo funcionar has de hacer clic en uno de estos botones que muestra esta siguiente imagen.

 (Haz clic en la imagen para ampliar si no ves la imagen completa.)

Y cuando se ejecute el código, elige la opción con la frecuencia con la que has programado la icestick o pulsando en la tecla '2' en este ejemplo que comentaba antes (para 115200 baud).

Y ya está, has de ver los leds contar en binario. Esto es sólo una minucia de testeo para comprobar que las velocidades de comunicación son correctas, pero se pueden hacer verdaderas maravillas con esto.

Por cierto, si te sale este mensaje al abrir FBIde, no pasa nada, es que detecta que tu ordenador es de habla hispana y no tiene el parche o como se diga que hace se ponga las opciones en tu idioma. Le das a aceptar cuando te salga y listo.

Fin!

[Democrito]

He hecho un pull request para subir el proyecto.

Saludos!

[Jesús Arroyo]

Añadido!

Muchas gracias por compartir!!