Proteus - error al detectar cero

[Miguel Fominaya]

Perdón por la pregunta de antes. Me explico mejor.

Estoy haciendo un contador DMX que va de 1-512. la idea es que cuando vamos hacia abajo y llegue a cero pase automaticamente al 512 y cuando subimos y llegue al 513 pase al 1

el 513 me lo detecta sin problema, pero el cero me lo detecta cuando los display pasan del 9 al 10 y cuando pasan del 99 al 100, en cualquiera de estos dos casos y siempre ascendiendo, me detecta el cero y se carga el numero

me vendria bien algun ejemplo similar que pase del 1 a x viceversa para ver como se hace.

os paso el proyecto en proteus y en un jpg para ver si me podeis hechar una mano.

gracias

 

[MrCarlos]

Hola Miguel Fominaya

Bien,
Quieres que ese contador cuente de 1 a 512(ascendentemente), cuando llegue a 512+1 se programe a 001.
Y que siga contando de 1 a 512 ??? . . . o que se detenga ??
Quieres que ese contador cuente de 512 a 1(descendentemente) cuando llegue a 1 -1 se programe a 512.
Y que siga contando de 512 a 1 ??? . . . o que se detenga ??

O no es cíclico??
O es cíclico ascendentemente de 1 a 512 Y descendentemente 512 a 1 ??

saludos
a sus ordenes

 

[Miguel Fominaya]

Hola.

Es cíclico, no se detiene, cuando llegue a 512+1 se pone a 1 y sigue ascendentenmente, viceversa cuando llega a 1-1

hay que hacerlo con dos botones de subida y de bajada, aunque en el ejemplo que os he pasado lo hace automático para no estar dandole al botón.

un detalle, en el diseño que os mando, hay tres switch, son para iniciar el contador en esa posición, ya que no tiene por que empezar en 1 o en 512, se debe poder empezar en cualquier número comprendido en el rango 1-512.

y si me decis como se hace para que parpaden los displays ya seria un lujo para mi

gracias

 

[Eduardo]

...
el 513 me lo detecta sin problema, pero el cero me lo detecta cuando los display pasan del 9 al 10 y cuando pasan del 99 al 100, en cualquiera de estos dos casos y siempre ascendiendo, me detecta el cero y se carga el numero
........

Eso es por un aleatorio (logic hazard) en la OR de 12 entradas.

La única solución simple es una solución pedorra --> agregarle un pasabajo RC a la salida de la OR dimensionado "justito", porque si no a alta frecuencia te va a morfar también el pulso bueno.

Las soluciones "mas ingenieriles" son hacer un análisis cuidadoso de la transición y agregar las compuertas que hagan falta. Otra forma es hacer una carga sincrónica.
Como sea, queda un bloque más complicado.

 

[Miguel Fominaya]

Lo que he observado es que cuando pasa del 98 al 100, los displays hacen esto:

-098
-099
- 090
- 000
-100

y es en ese 000 cuando la or dispara el Load cargando el número, por lo tanto,no pasa del 100 cuando subimos la cuenta.

Eduardo, ¿para que ponemos un pasabajo RC en la salida de la OR? ¿que hace realmente?

gracias, compañero de fatigas

 

[Eduardo]

... ¿por que ponemos un pasabajo RC en la salida? ¿que es lo que hace realmente?

Porque físicamente las salidas no pueden cambiar todas en el mismo instante.

Fijate que en la transición 99-100, debe pasar que:

El 2do contador va a 0 -> activa el carry -> hace avanzar el 3er contador.

Pero eso no es instantáneo, desde que el 2do contador va a 0 hasta que se incrementa la salida del 3ero hay un retardo de digamos 200ns , aunque por supuesto depende de la familia de integrados que uses.
Como durante ese intervalo está todo en 0 --> la OR te hace un pulso cortito en su salida.

Lo de poner un filtrito RC como el adjunto, es nada más que para que se coma ese pulso parásito.
Pero ojo! no hagas bandera porque es una solución desprolija.


También tené cuidado, porque como este problema depende fuertemente de los retardos reales en las compuertas, lo que salga en el simulador no tiene por qué corresponderse con la realidad.

 

[Miguel Fominaya]

Hola

Muchas gracias eduardo, con el filtro RC funcionó a la perfección. por lo menos en el simulador, cuando lo termine lo pasare a placa y os diré si también funciona en real.

un saludo