KIT el coche fantástico.

[Democrito]

Hola!

Algunos habrán visto la serie "El coche fantástico" (en españa se llamaba así, no sé cómo habrá sido en otros países), pues ese coche tenía unas luces que se movían de izquierda a derecha y viceversa, de forma continua. Comento esto porque estoy intentando hacer que vayan 8 leds de esa manera pero me sucede una cosa extraña, siempre va en un sentido (cuenta) pero no se pone en modo inverso (descuenta). He usado un contador reversible tipo clk y U/D, con reset asíncrono (estilo 74LS169), aunque el reset en el esquema lo tengo puesto para que nunca actúe. He probado el contador para ver si realmente es capaz de contar y descontar y en apariencia lo hace bien. Observa el esquema y verás que llevo q3 a U/D para que haga el recorrido y cuando q3 se ponga a '1' invierta el sentido inverso y así sucesivamente.

Estoy utilizando una Icestick con el programa Icestudio 0.2.1

El programa del contador reversible es el siguiente:

//--------------------------------------------------------------------------------------

reg [4:0] q;

always @(posedge clk or posedge rst)

begin

    if(rst)

        q <= 0;

        else if(ud)

            q <= q - 1;

            else 

                q <= q + 1;

end

assign {q3, q2, q1, q0} = q;

//--------------------------------------------------------------------------------------

Adjunto el archivo "kit.ice" para quien quiera probarlo, pero como decía, de momento no funciona correctamente (sólo va en un sentido) y necesito saber dónde estoy metiendo la pata. He probado a poner a '0' la patilla de entrada U/D y cuenta (los led se mueve en un sentido) y luego a '1' y descuenta (los led se enciende al revés de antes), pero como comentaba, al conectar q3 a la patilla U/D, no hace lo que se espera, es como si q3 nunca se pusiera a '1'.

Ultima hora: Antes de enviar este correo me he querido asegurar poniendo sólo el contador reversible con las salidas directas a leds, y sucede lo mismo, la patilla de entrada U/D no aprecia el estado de q3, para U/D siempre es '0' haya lo que haya en q3. Adjunto también sólo el contador reversible tipo U/D y clk. 

Saludos.

[Democrito]

Acabo de probar puenteando a '0' y a '1' la entrada UD a mano (físcamente) y así sí que funciona bien. Con '0' cuenta y con '1' descuenta.

Pero lo dicho, al conectarlo a una salida de las 'q' (cualquiera de ellas) del contador, "nanai de la china"...

[rafael lozano]

Porqué no sacas q3 de la matriz, creo que al recorrerla se desactiva, es una sugerencia
Un saludo

[Obijuan]

Hola Demócrito!

Te comento algunos problemas de tu diseño:

En el contador estás utilizando 5 bits:

reg [4:0] q;   <-----  Defines un regitro con 5 bits:  q[4], q[3], q[2], q[1], q[0]

Creo que en realidad lo que querías decir era esto:

reg [3:0] q;


Tal como lo tienes, esta conexión de cables:

assign {q3, q2, q1, q0} = q;

quedaría así:      q3 ----  q[4]
                          q2 ----  q[3]
                          q1 ----- q[2]
                          q0 ----  q[1]

y el q[0] estaría sin asignar

Por otro lado, suponiendo que lo que querías era tener un contador de 4 bits, al llegar al valor binario 1000 empieza a decrementar, por lo que pasa a 0111 y q3 vuelve a ser 0, por lo que volvería a incrementar.
Para ver exactamente lo que pasa hay que hacer una simulación, pero se intuye que hay algo extraño que no lo hace funcionar bien. Es cierto que al probarlo, sólo va hacia adelante. Hay que analizarlo en simulación, pero se ve claro que tal como lo tienes planteado no puede funcionar

En hardware, pensar en modo "cuenta de la viaja" es difícil. Tendemos a pensar de modo algorítmico y aunque el código y lo que queremos expresar tiene mucho sentido para nosotros, luego el hardware se comporta de otra forma.

Por eso, siempre lo más seguro es recurrir a las estructuras típicas:  modelo Ruta de datos / controlador

Como ruta de dato has elegido un contador de 4 bits, con un multiplexor de 3 a 8. ok.  Sólo habrá 1 señal de control: ud que indica si el contador incrementa o decrementa
Como controlador usamos un autómata de 2 estados: UP y DOWM.  Los autómatas siempre se hacen de la misma manera. Sólo hay que indicar los estados y las condiciones de transición entre estados. Aunque el código lo veas más enrevesado, siempre se hace igual. Al modelar hardware ya verás como siempre acabas haciendo copy & paste de las estructuras típicas

Te adjunto el proyecto en icestudio sintetizado para una icezum alhambra (tendrás que cambiar a la icestick y modificar las salidas para que te funcione en la icestick)

Adjunto un pantallazo:




Uno puede pensar que en vez de un autómata, lo puede hacer directamente con un biestable que codifique el estado incremento/decremento y la lógica para hacerlo funcionar. Bueno, en realidad es lo mismo. El sintetizador optimizará el código y generará la lógica mínima para implementarlo

Hay más formas de implementar el circuito. A cada uno se le ocurrirá una diferente. Aquí pongo algunas otras posibles:

2)  Registro de desplazamiento + controlador  (En vez de usar un contador + mux, se puede usar directamente un registro de desplazamiento derecha/izquierda, inicializado con el valor binario 00000001
3) Memoria rom de 16x8. Cada posición de memoria almacena el valor de los leds en la secuencia: Dirección 0: 00000001, Dirección 1: 00000010.... Dirección 7: 10000000, Dirección 8: 01000000 ... Dirección 15: 00000001

La verdad es que es un buen ejemplo para la gente lo piense y aprenda a diseñar electrónica digital

Saludos, Obijuan

[Obijuan]

Aprovecho para comentar una cosa relacionada con el diseño hardware:

El hardware es muy intuitivo pensar en "espacio" en vez de tiempo. Cualquier cosa relacionada con espacio es más fácil. Sin embargo en programación lo fácil es pensar en forma de tiempo: primero se ejecuta una instrucción, luego otra, luego otra....

Imaginaros este ejemplo: un robot seguidor de línea.  Sabemos lo fácil que es implementarlo con un Arduino. Al final programamos el algortimo en plan: "Si el sensor tal está a 1, entonces gira a la derecha. Si el sensor Y está a 0 entonces....".  Bien.  Ahora modificar el programa para que siga la línea a la vez que toda una canción.  Hacer que toque notas por un zumbador es igual de fácil: "Nota x, espera duración, toca nota Y, espera duración....". Pero.... Ahora haz las dos cosas a la vez. Por supuesto que se puede hacer, pero el programa resultante NO es la suma de los dos algoritmos independientes. Hay que crear uno nuevo que tenga en cuenta todas las temporizaciones y usar el procesador para conmutar de un algoritmo a otro.

Esto en hardware es trivial. Por un lado pones el circuito de seguir la línea: tiene como entradas los sensores y como salidas los motores. Por otro lado tiene un circuito independiente conectado al zumbador que saca la canción. Como es hardware, los pones a funcionar los dos a la vez, en paralelo. Funcionarán igual que lo hacen por separado.

Sin embargo, en hardware, hacer que las cosas trabajen en el tiempo es más complicado. Hay que utilizar autómatas para secuenciar las tareas en el tiempo

Conclusión:  Hay cosas que son triviales en software y costarán un poco más en hardware, y al revés, hay cosas triviales en hardware que costarán mucho en software

Saludos, Obijuan

El jueves, 29 de septiembre de 2016, 2:57:53 (UTC+2), Democrito escribió:

[Juanillo Pillo]

Buena explicación,

[Democrito]

Hola Obijuan y Rafael Lozano,

de verdad, muchas gracias por responder y tomarse tantas molestias y en tan poco tiempo. Sólo comentar mi "estado actual": No tengo idea de Verilog, y las FPGA para mí es un paradigma totalmente nuevo. Estudié electrónica (FP) en el pleistoceno (broma que hace referencia a mucho tiempo) y este ejercicio se dio porque buscaba maneras de hacer contadores reversibles; más adelante lo quiero utilizar para controlar motores a través de encoders incrementales.

Yo pensaba que salvando algunos detalles sobre programación en verilog sería como montar un circuito en protoboard, pero veo que hay detalles y conceptos que se han de tener presentes y que poco a poco iré(mos) aprendiendo.

Pienso que sería una idea interesante crear componentes entre todos y meterlos en una biblioteca, en el sentido de, por ejemplo, tener un "74FPGA169" (el equivalente al 74LS169, obviando la tecnología si es TTL o CMOS) o un 74LS86 que es un comparador de 4 bits, y componentes de este estilo para al final poder montar en la FPGA circuitos como si fuera realmente una protoboard. Estoy convencido de que Icestudio es una herramienta más potente de lo que parece y es increíblemente sencillo de manejar. Lo que intento decir es que se puede enfocar de dos maneras, una de ella es la evidente y es aprender todos los entresijos y filosofía del lenguaje HDL, y la otra es mucho más sencilla, que es implementar componentes (que emularía en funcionamiento a los componentes físicos) y sacar directamente proyectos como si de una protoboard se tratase. El segundo enfoque permitiría utilizar una FPGA para aprender electrónica digital (ahorrándose el cableado de una protoboard), para luego, más adelante, ya familiarizados con los componentes y su funcionamiento, dar ese gran salto, que es el diseño del propio componente, comprendiendo la filosofía de las FPGA.

Otra cosa que me he dado cuenta es lo importante que es leer todos los hilos de este grupo de noticias, porque en cada correo, tanto Obijuan como Jesus Arroyo, vais dando pistas de cómo se resuelven ciertos problemas. Por ejemplo, para el ejercicio que he propuesto me leí ayer varios post y que nada tienen que ver entre ellos, en cada uno de ellos me daban pistas de por ejemplo "cómo crear un componente como bloque" o cómo hacer un contador reversible, y otros muchos detalles.

De nuevo, gracias por estar ahí y perdonadme si me he puesto trascendente! :D

[Obijuan]

Hola Demócrito!

 
El jueves, 29 de septiembre de 2016, 10:49:41 (UTC+2), Democrito escribió:

Hola Obijuan y Rafael Lozano,

de verdad, muchas gracias por responder y tomarse tantas molestias y en tan poco tiempo. Sólo comentar mi "estado actual": No tengo idea de Verilog, y las FPGA para mí es un paradigma totalmente nuevo. Estudié electrónica (FP) en el pleistoceno (broma que hace referencia a mucho tiempo) y este ejercicio se dio porque buscaba maneras de hacer contadores reversibles; más adelante lo quiero utilizar para controlar motores a través de encoders incrementales.

Es un ejercicio perfecto. Muy bueno para aprender los fundamentos del diseño hardware ;-)

 

Yo pensaba que salvando algunos detalles sobre programación en verilog sería como montar un circuito en protoboard, pero veo que hay detalles y conceptos que se han de tener presentes y que poco a poco iré(mos) aprendiendo.

En su esencia, es exactamente igual. Si tienes un circuito digital diseñado en una protoboard, y te funciona, ese mismo en la FPGA te funcionará igual. Y es totalmente viable hacerlo encapsulando los integrados en módulos verilog y conectarlos igual que en la protoboard (pero en verilog). El resultado es el mismo. Es decir, el trabajar con FPGAs es conceptualmente igual al trabajar con hardware de verdad. Porque las FPGAs son hardware de verdad :-)

Eso si. Esto es hardware real. En muchos libros encontraréis diseños que funciona en simulación pero que luego en la readlidad no funciona (porque el autor no lo ha probado). No es culpa de las FPGAs, sino que el diseño tiene alguna cosa mal :-)
 

Pienso que sería una idea interesante crear componentes entre todos y meterlos en una biblioteca, en el sentido de, por ejemplo, tener un "74FPGA169" (el equivalente al 74LS169, obviando la tecnología si es TTL o CMOS) o un 74LS86 que es un comparador de 4 bits, y componentes de este estilo para al final poder montar en la FPGA circuitos como si fuera realmente una protoboard.

Si correcto. Es totalmente viable

 

Estoy convencido de que Icestudio es una herramienta más potente de lo que parece y es increíblemente sencillo de manejar. Lo que intento decir es que se puede enfocar de dos maneras, una de ella es la evidente y es aprender todos los entresijos y filosofía del lenguaje HDL, y la otra es mucho más sencilla, que es implementar componentes (que emularía en funcionamiento a los componentes físicos)

Mejor que emular, que suena mucho a software, es mejor decir "crear un circuito equivalente". Es decir, que es el mismo circuito, pero en vez de estar implementado dentro de un circuito integrado tal, lo está en la FPGA. Pero en readlidad es el mismo hardware lógico.

 

y sacar directamente proyectos como si de una protoboard se tratase.

Correcto. Esto es hardware. Cada uno puede hacerlo como le sea más fácil. Efectivamente una opción es esa: crear en Verilog los circuitos equivalentes de los integrados, y luego unirnos con cable. Totalmente viable. Y el comportamiento lógico será el mismo. Esto en HDL se conoce con el nombre de diseño jerárquico. Hacer un diseño a base de unir componentes del nivel inferior, sin conocer los detalles de cómo están implementados los del nivel de abajo

 

El segundo enfoque permitiría utilizar una FPGA para aprender electrónica digital (ahorrándose el cableado de una protoboard), para luego, más adelante, ya familiarizados con los componentes y su funcionamiento, dar ese gran salto, que es el diseño del propio componente, comprendiendo la filosofía de las FPGA.

Correcto. En realidad, sería aprender cómo describir circuitos usando HDL. Da igual si usas una FPGA o no. En la FPGA lo puedes sintetizar rápidamente, pero el diseño HDL es indepenediente de la FPGA (Podrías usarlo para fabricar un chip custom), o podrías usarlo para hacer simulaciones.

 

Otra cosa que me he dado cuenta es lo importante que es leer todos los hilos de este grupo de noticias, porque en cada correo, tanto Obijuan como Jesus Arroyo, vais dando pistas de cómo se resuelven ciertos problemas. Por ejemplo, para el ejercicio que he propuesto me leí ayer varios post y que nada tienen que ver entre ellos, en cada uno de ellos me daban pistas de por ejemplo "cómo crear un componente como bloque" o cómo hacer un contador reversible, y otros muchos detalles.

Ahora mismo estamos en "economía de guerra": no somos capaces de producir todo lo que la gente demanda :-D  Una de las cosas que hay que hacer es poner cientos de ejemplos para icestudio: contadores, registros, etc... Ejemplos de cómo hacer autómatas, de cómo hacer periféricos, etc. Tengo en el TODO hacer muchas cosas relativas al contenido. De momento hay muchos frentes abiertos, y vamos avanzando poco a poco.  Por eso quiero involucrar a toda la comunidad, para que aprendamos todos juntos, y que creemos todo este contenido entre todos.
 

De nuevo, gracias por estar ahí y perdonadme si me he puesto trascendente! :D

Para eso está este grupo :-)

Gracias

Saludos, Obijuan

 

[Democrito]

Hace un rato que me he dado cuenta que mi diseño está mal, no puede funcionar. En mi erróneo razonamiento se me había metido en la cabeza que q3 no cambiaba de estado al invertir la cuenta, no sé por qué se me metió en eso en la cabeza, pero cuando eso sucede es como las ilusiones ópticas, no dejas de verlo.

Todo que comentaba sobre hardware y protoboard era pensando que las FPGA en algunos casos tenían una manera peculiar de funcionar. Pero no! hace exactamente lo que le pedimos!

Ay señor... la madre que me parió...

Os pido millón de disculpas. El diseño de Obijuan funciona perfectamente bien.

Voy a hacerme un reset!

[Juan Gonzalez Gomez]

Hola Demócrito!

Estamos para aprender ;-). Lo apasionante de esto es que está todo por hacer. Y entre todos aprenderemos y haremos cosas cada vez mejores. Yo he medio aprendido Verilog hace nada

El ejemplo de kit es muy inspirador (gracias!) Y con tu permiso lo usaré como uno de los ejemplos en las charlas

Y aquí propongo el reto de hacer nuevas implementaciones, de diferentes maneras.  A ver qué se le ocurre a cada uno, o qué problemas encuentra cada uno

Hagamos electrónica digital!!!!! :-)

Saludos, 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/a5803ccc-f24a-4b5b-9e0b-83fbc73f02ef%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Democrito]

Anoche me metí en la cama pensando y diciéndome a mí mismo, "Pero a ver tío, esto lo hiciste hace más de 20 años y salió bien, porque ahora no???" Y mientras intentaba coger el sueño (imposible ese ejercicio cuando estás pensando en cómo resolver ciertos problemillas) caí en la cuenta que en aquel entonces no usaba contadores reversibles, sino contadores normales de toda la vida, ascendentes. Una cosa que conocía pero no me acordaba en este ejercicio era que usaba puertas xor, y las utilizaba para invertir bits. Me explico: Si tomamos una puerta xor (de dos entradas) y en una patilla mantenemos fijo por ejemplo un '0', lo que entre por la otra patilla sale por la salida (no invierte), pero si a esa patilla "fija" le pones un '1', en la salida nos encontramos el valor invertido de la entrada. Pues es aquí donde el bit q3 del contador nos hará esa función de patilla "fija". No es que sea fija, porque se pondrá a '0' y a '1', pero cada recorrido de 0 al 7, esa patilla cambiará el estado. Total, que al hacer la xor de las salidas del contador q0, q1 y q2 con respecto a q3, conseguimos esa secuencia de ir y venir los leds, a través del demultiplexor.

Digamos que "funciona casi bien" en el sentido que hace el va y ven de los leds, pero los leds de los extremos consume un ciclo de reloj de más (dos en vez de uno) y se debe a que cuando hace el cambio (la inversión de q3, ya sea cuando pasa de 0 a 1 como de 1 a 0) se repite el mismo valor a las salidas de las puertas xor (no de las salidas del contador!). Este ejercicio es un acercamiento, falta mejorarlo, pero ahora todo tiene más sentido!

Adjunto el "Ice" y lo he llamado "pseudoKIT.ice" porque es un sucedáneo de cómo debería de funcionar de verdad.

Sí que es un ejercicio interesante!

Saludos y gracias!

[Juan Gonzalez Gomez]

WoW! Sí señor! Ahora en cuanto llegue a casa lo pruebo.

Pensamiento hardware puro y duro!!!!! :-)

Ese es el camino!!!!! Genial!!!  😃😃

Saludos, 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/033973ea-0c2f-43c7-9626-0a749b73aa71%40googlegroups.com.

[Jesús Arroyo]

Qué hilo más interesante!

Desde luego con cada hilo de FPGAwars aprendemos todos, y mucho :)

Acabo de probarlo en la Icezum y funciona genial. He aumentando la frecuencia de 4Hz a 12Hz, con una división de 1000000 (esto lo he editado directamente en el JSON) y se parece algo más al coche fantástico. Adjunto video.

Por cierto, toda la documentación de Icestudio está recopilada en: http://icestudio.readthedocs.io/en/stable/index.html. Los apartados más interesantes para utilizarlo son GUI y How to... De todas formas si surgen dudas nuevas comentadme y voy actualizando la documentación.

Un saludo.

[Jesús Arroyo]

Ups he subido el video de 4hz. Subo el de 12hz.

[Democrito]

Hola! Por fin he conseguido resolver los tiempos de latencia de los leds de los extremos!

Pongo una imagen para ver gráficamente el problema y la solución.

A la derecha, en azul, se ve el problema; a las salidas de las puertas xor nos repite '111' cuando el contador presenta los valores '0111' y '1000' (es cuando prende el último led). Y vuelve a suceder cuando el contador presenta los valores '1111' y '0000', a las salidas de las xor sale '000' en ambos casos (es cuando prende el primer led). Eso significa que los leds de los extremos nos consume un ciclo de reloj de más.

A la izquierda está la solución. Se trata de comparar la combinación donde sucede primero y lo que hacemos es asignar al contador la siguiente combinación antes de incrementar el contador, de esta manera eliminamos ese ciclo que nos sobra.

Adjunto el hardware fuente "kit_v2.ice".

Se me ha ocurrido hacer un vídeo con un toque friki con los leds en acción. La calidad es penosa...: https://www.youtube.com/watch?v=XbJLHRrc8X4

Saludos!

[Democrito]

Perdón, se me olvidó adjuntar el archivo.

[Democrito]

Pongo lo mismo de antes, pero usando los leds de la propia icestick. El led central (verde) lo dejo encendido permanente. Adjunto el "ice".

[Obijuan]

Hola Demócrito!

Felicidades por tus logros!!! El circuito funciona muy bien (tanto en la icezum cono en la icestick) y lo has razonado en hardware puro! Sí señor!  :-)

Tu solución final es contador + cto combinacional + demultiplexor. ¡Muy bien!

Voy a echar un vistazo con más detenimiento al código verilog y te comento detalles

¡Muchas gracias!  :-)

Saludos, Obijuan

El jueves, 29 de septiembre de 2016, 2:57:53 (UTC+2), Democrito escribió:

[Obijuan]

Hola Demócrito!

He estado echando un vistazo al código verilog del contador del ejemplo kit-v2.ice. El código funciona perfectamente. Te comento algunas cosas del estilo
El contador es un circuito secuencial (depende del reloj). Es más conveniente que las asignaciones sean siempre no bloqueantes con el opeardor <=

La regla que se usa es: "En los circuitos secuenciales usar <=.  En los combinacionales ="

Es mejor no mezclar los dos tipos en el mismo bloque always

El código, usando sólo asignaciones no bloqueantes, quedaría:


reg [4:0] q=0;

always @(posedge clk or posedge rst)
begin
    if(rst)
      q <= 0;
    else

      if (q==4'b0111)
        q <= 4'b1001;
      else if (q==4'b1111)
        q <= 4'b0001;

      else
        q <= q + 1;
end

assign {q3, q2, q1, q0} = q;

Fíjate que la temporización cambia. Ahora, cuando q vale '0111', hacemos que pase directamente al siguiente valor correcto ('1001'), que ya no tiene que ser incrementando (ya lo está)
También fíjate que hemos usado ifs encadenados: este estilo se usa siempre en circuitos secuenciales (contadores, registros...). Esto permite definir claramente las prioridades: primero se comprueba el caso '0111', si no se cumple, se pasa al caso '0001' y finalmente se incrementa

En la versión original, se hacen varias operaciones. Cuando se está en el caso '0111', cambias el valor '1000' y luego incrementas. Siempre hay que intentar dejar sólo 1 operación, para que sea todo más fácil de depurar

Por supuesto, el diseño funciona bien con el código original. Esto son recetas para ir aprendiendo a hacer un código más legible y más estandarizado

Al ir haciendo ejemplos, os daréis cuenta de que el hardware es siempre sota, caballo y rey. Siempre hay unas estructuras que se repiten. Y tendemos siempre a usar esas estructuras. Al final un registro lo modelamos siempre de la misma manera. No hay que "pensar"

Saludos, Obijuan

El jueves, 29 de septiembre de 2016, 2:57:53 (UTC+2), Democrito escribió:

[Obijuan]

Hola Demócrito,

Aquí te mando las mismas correcciones para la versión kit-leds-stick:

if(rst)
        q <= 0;
    else

        if (q==3'b011)
          q <= 3'b101;
        else if (q==3'b111)
          q <= 3'b001;

        else
          q <= q + 1;
end

Los comentarios son los mismos:

* Como es un contador (circuito secuencial), usa siempre las asignaciones no bloqueantes: <=
* Usar  ifs encadenados con todos los casos, de manera que en cada caso sólo se haga 1 operación de asignación al contador. Esta es la estructura típica de los contadores, registros, etc.

Saludos, Obijuan


El jueves, 29 de septiembre de 2016, 2:57:53 (UTC+2), Democrito escribió:

[Democrito]

Hola Obijuan!

Mi mente es como una tortuga, he necesitado leer tus comentarios con las correcciones unas 5 veces y no exagero, al final creo que lo he entendido. Con los "else if else if y otra vez else" me hago mucho lío, pero me consuela tu comentario de que esto es siempre lo mismo.

Muchas gracias por las correcciones y explicaciones!

[Democrito]

Estoy intentando fabricar sueño, y mientras me viene me he entretenido con un display de 7 segmentos, pero en vez de mostrar una cuenta lo que he hecho es que se mueva los leds en plan KITT. Ciertamente estoy muy "pesadicu" con este tema... Pero quién sabe, igual hay alguien que tiene un display y le apetece entretenerse un ratito.

Como el display es de ánodo común necesitaba invertir las salidas del demultiplexor (también llamado decoder) y me cree ese componente como un bloque. Modifiqué el programa del contador porque son menos leds (6), los externos del display.

Las salidas 'g' y 'p' no se utilizan, sólo de la 'a' hasta la 'f'. Si alguien lo quisiera hacer ha de recordar que el display que utilicé es ánodo común (común al positivo), si fuese cátodo común (común al negativo) entonces tendría que eliminar el demultiplexor (decoder) que está en el esquema y poner uno que ya viene en icestudio, porque esos no tienen las salidas invertidas.

Adjunto el "ice".

Saludos.

[Obijuan]

Mola!!!!

  Lo he probado en una go-board, que trae los 7-segmentos.  Aquí os paso el enlace a un vídeo de su funcionamiento:

https://goo.gl/photos/aMvzctfY4dB7RWxe7

Simplemente he cambiado la placa a go-board y los pines de salida asignados a S1_A, S1_B, ..., S1_G

Gracias por el ejemplo!  :-)

Saludos, Obijuan