[Icestudio] Cuaderno técnico sobre LCD 16x2

[Obijuan]

Hola,

Estoy escribiendo un cuaderno técnico (en Español) sobre cómo crear un controlador para un LCD 16x2 desde 0

https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/wiki/Controlador-LCD-16x2

Estoy trabajando en ello, y NO está terminado (falta bastante), pero lo pongo por si queréis ver los avances

Si queréis manejar un LCD, está disponible la colección iceCrystal[1] que creó Charli. En los circuitos de ejemplos están las instrucciones para el conexionado y la puesta en marcha

En lo que me estoy centrando yo es en explicar desde 0 cómo crear el controlador, usando exclusivamente bloques de icestudio. También quiero mostrar el proceso de diseño, botton-up, en el que poco a poco se van añadiendo componentes y se van creando componentes de más alto nivel

Todavía es un borrador, y hay muchas cosas que van a cambiar, pero yo siempre trabajo en abierto (no espero a tener una versión final para publicar, sino que la hago directamente  en abierto)

Lo interesante de esto es que este proceso de crear el controlador es muy parecido para la construcción de otros controladores para otros periféricos. Y es esa idea la que intento plasmar: cómo hago yo para crearlos

Todos los ejemplos están en este repositorio:  https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/tree/master/wiki/LCD_16x2/Examples

Los bloques intermedios que se van creando los iré poniendo en la colección iceLCD[2]

Saludos, Obijuan

[1]https://github.com/cavearr/icecrystal

[2]https://github.com/FPGAwars/iceLCD

[Jose Picó]

Enhorabuena por tu trabajo y Gracias.

Todo lo q haces es oro en bruto!

Saludos

--
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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6b8d764e-4a98-4e31-ba74-4f3cd56f68e9n%40googlegroups.com.

[Jo mo]

Hola Juan,

Thanks for that new caderno technico.

It is a very well done / informative documentation as usual from you !

Your new LCD block also looks really nice! I still have some of these two lines LCD on my drawers, so i may play if it some day!

Muchas Gracias  again for the good work!

Have a nice week !

[charli va]

¡Qué gran trabajo Obijuan! como siempre enhorabuena! deseando probarlo todo y aportar lo que pueda.

Un fuerte abrazo!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/75fa62a7-c588-444a-8711-3f1574d1b700n%40googlegroups.com.

[Juan Gonzalez Gomez]

Este es el ejemplo 17, donde se puede ver un ejemplo de uso del controlador en bucle abierto para un LCD con interfaz de 8 bits:

https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/raw/master/wiki/LCD_16x2/Examples/level-1/17-controler-8bits-msg-2.ice

En total hay 15 comandos almacenados en la memoria. Los comandos son de 9 bits: el bit de mayor peso indica si se trata de una instrucción para el LCD, o de un carácter a imprimir. Los 8bits de menor peso contiene el dato/instrucción. En los comentarios de la memoria se puede ver qué hace cada comando. Al salir de la memoria estos 9 bits se separan en la señal rs de 1 bit y data de 8bits

El controlador está conectado directamente a los pines del LCD (pines de la derecha). Por sus entradas llega el dato/comando (din) y el tipo de comando (rs). Cuando se termina de escribir el comando en el LCD, el controlador genera un 'tic' de done que llega a la máquina de contar (next), lo que hace que se direccione el siguiente comando y que se vuelva a enviar

El proceso comienza cuando se aprieta el pulsador (que está conectado a la señal start de la máquina de contar)

En esta image se muestra el resultado:

Fijaros que el controlador funciona de forma muy similar al transmisor serie. Tiene una señal de busy que indica si está funcionando o está en espera, las señales de conexión con el dispositivo (en este caso el LCD) y la señal de done para indicar que se ha finalizado con el envío del comando

De esta forma, los bloques disponibles para realizar conversiones para enviar datos por el puerto serie también se pueden usar con este controlador (por ejemplo para convertir números a caracteres)

Saludos, Obijuan

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYo%3DuEtpyE91xGM_rtdL2qDX86d1RyLoxueA7o0ANu%3DUA%40mail.gmail.com.

[Obijuan]

Gracias a tí charli por la colección IceCrystal!, que es la que estoy usando como referencia para convertirla en bloques de icestudio

Saludos, Obijuan

[Obijuan]

Thanks Joaquim! This still is a work in progress. But as it is fully implemented using icestudio blocks (no verilog knowledge required) it is easier for newbies to change it and adapt it to their needs

Best regards, Obijuan

[Democrito]

Hola Juan,

Ayer me leí tu tutorial sobre el LCD y cuando lo terminé me dieron ganas de pillar una y hacer algo, y así ha sido. Retomé un viejo proyecto y lo he dejado mucho más pulido, mejorado y optimizado. He diseñado un circuito que usa la LCD con un I2C de sólo escritura.

(Esta es una imagen comercial)

 

Sólo se necesitan dos cables para la comunicación y evidentemente los dos de alimentación. Al comienzo intenté usar tu módulo de LCD, pero luego me di cuenta que no hacía falta, lo que sí tuve que hacer es respetar los tiempos de los comandos de configuración. En el envío de texto no es necesario porque el propio I2C a 100_000 KHz da un margen sobrado en este sentido en cada envío.

El chip que hace la comunicación I2C sólo es capaz de manejar 8 bits, por tanto he usado la configuración de 4 bits para la LCD. Son 4 bits de comando/carácter, y los otros 4 son para los bits RS, RW, EN y el bit 3 que se encarga de encender o apagar la pantalla. En realidad, en el diseño que adjunto sólo rs es el que cambia, los demás están fijos.

Adjunto el ICE, donde al pulsar SW1 saldrá en mensaje "Hello!"

Saludos y gracias!

[Democrito]

Se me olvidó comentar que la dirección I2C que veréis tiene el valor "78" en vez de 'h27 (hexadecimal) o 39 decimal. Se debe a que las direcciones I2C siempre nos la dan con 7 bits. Falta añadir el bit RW (que es el bit más bajo) para formar los 8 bits. Entonces lo único que hay que hacer es añadir un 0 (0=escritura), o lo que es lo mismo, es como multiplicar por 2.

[Democrito]

He creado otro módulo y ejemplo que permite escribir desde el puerto serie, pero es muy muy básico, no responde a los retornos de carro, sólo escribe en la primera línea. Si alguien siente curiosidad, aquí lo tiene: https://github.com/Democrito/repositorios/tree/master/Sensors/I2C/LCD

Dentro del módulo controlador está todo explicado.

Un saludo.

[charli va]

Muuchas gracia Demócrito! pull request aceptado!

--

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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/e344a06a-1895-408e-b0ca-e7f168ebff31n%40googlegroups.com.

[Obijuan]

Hola Demócrito!

Muchas gracias por todos los ejemplo. Los voy a tener en cuenta para la creacion de los siguientes niveles de controladores. La idea es poder usar bloques estándares con diferentes controladores: LCD (de conexión directa), LCD (conexión I2C), Puerto serie, etc... Estoy haciendo pruebas y pensando en abstracciones sencillas de usar

Me ha gustado mucho el convertirdor I2C a puerto de salida de 8 bits. Le veo mucho potencial didáctico. ¿Tienes su referencia? Me gustaría comprarlo para hacer más pruebas (Si busco seguro que aparecen muchos, pero me gustaría empezar por este que tienes tú, para garantizar que son compatibles)

Saludos, Obijuan

[Juan Gonzalez Gomez]

Este es el ejemplo 21: Un circuito para probar el controlador para un LCD de 4 bits en bucle abierto

Imprime la cadena "Artemis I" en el LCD, al apretar el pulsador SW1 de la Alhambra II. Lo he probado con la LCD-shield, que incluye teclas y un LCD retroiluminado azúl [1]

Este es el resultado al probarlo:

Esta es una shield para Arduino, pero como la Alhambra-II tiene la misma forma, todas las shield de Arduino las podemos usar con la FPGA de una forma muy fácil y rápida

El controlador para 4-bits tiene una línea de entrada nueva, cmd, que el de 8 no tiene. Y es que para la inicialización hay que enviar primero 4 comandos de sólo 4-bits (y esperar un tiempo de 5ms apox por cada comando), y el resto de comandos son de 8-bits, enviándose los dos nibbles por separado (primero el de mayor peso y luego el de menor) y luego la pausa. Es decir, que es necesario distinguir entre estos dos comportamientos

* Comando de inicialización: 4 bits + pausa

* Comando normal: 4 bits + 4bits + pausa

En el caso del controlador de 8-bits no hace falta, porque todos los comandos se envía igual: el comando + la pausa

En el siguiente nivel de controladores, la inicialización estará oculta al usuario, y la interfaz de entrada será la misma con independencia de qué LCD se conecte. En este nivel es donde se situarían controladores con otras interfaces del LCD (como la de I2C de Demócrito). Da igual cuál sea la conexión física con el LCD, desde este nivel para arriba todos tienen la misma interfaz, y por tanto son intercambiables. El resto de bloques que usan el LCD les da igual cómo esté el LCD conectado (sólo afectará a la frecuencia a la que podemos refrescar el LCD)

Saludos, Obijuan

[1] https://store.prometec.net/producto/lcd-keypad-shield/

--
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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6b8d764e-4a98-4e31-ba74-4f3cd56f68e9n%40googlegroups.com.

[Democrito]

Hola Juan,

La shield I2C que va conectado a la pantalla LCD es un estandar, en el sentido de que han adaptado el chip PCF8574T para conectarlo expresamente a una LCD cualquiera. En las pruebas he utilizado dos LCD azules (fondo azul y píxeles blancos), una de 16x2 y otra de 20x4. Aconsejo utilizar la de 20x4 porque cuando se termina de escribir en una fila, aparece en otra, pero no en orden, el orden es fila 1, 3, 2 y 4.

No puedo decirte qué shield I2C tengo exactamente porque no tiene ninguna referencia, pero te dejo con una imagen de la que estoy utilizando.

  

Utiliza específicamente el chip PCF8574T si amplías la imagen lo podrás comprobar. Creo que existen chips de versión anterior, en el que su nombre no está la 'T' final o tiene otra letra.

Una vez montado queda así (estoy utilizando una imagen que no es mía)

con los pines de conexión I2C y alimentación justo donde termina la superficie del LCD.

Cuando la shield I2C se conecta a la pantalla LCD queda así:

Vemos que el chip I2C utiliza las salidas P0 a P7, excepto P3. "P3" se utiliza para la retroiluminación (en la imagen no sale pero es así).

Estamos obligados a usar la configuración de 4 bits de datos en la LCD. Por tanto, los datos siempre van a ser el envío de un nibble (4 bits) + control de pines (RS, RW, E y retroiluminación, que son los otros 4 bits). Es decir, vamos a enviar siempre un byte (8 bits), pero dentro de ese byte, 4 bits son de datos, y 4 bits son de control.

El orden de los 8 bits han de ser así, a la izquierda está el bit de mayor peso (MSB):

D3, D2, D1, D0, retroiluminació, Enable, RW, RS

Para hacerlo más sencillo, los bits "retroiluminación" y RW los dejo fijos.

Esta forma de manejar la LCD es... un poco complicada, porque estamos obligados a enviar los datos así, y lo que es peor es que para enviar un comando o escribir un carácter lo hemos de hacer en 4 envíos. ¿Por qué lo hemos de hacer así?

Vamos a ver los 4 pasos en detalle, y vamos a imaginar que quiero enviar la letra "A" que es 41 en hexadecimal, por tanto el nibble alto es 4 y el nibble bajo es 1.

Por otra parte, los bits de control serán así y en este orden (como en binario, MSB a la izquierda)

Retroiluminación (siempre será 1), Enable (este bit lo vamos a controlar), RW (siempre a 0), RS (lo vamos a controlar dependiendo de si es comando o texto)

1)  Nibble alto "4" + control (enable=1, RS=1, los demás fijos)

2.) Nibble alto "4" + control (enable=0, RS=1, los demás fijos) En este punto, la LCD toma ese nibble alto, el "4", porque ha "notado" el cambio en el pin enable.

3.) Nibble bajo "1" + control (enable=1, RS=1, los demás fijos)

4.) Nibble bajo "1" + control (enable=0, RS=1, los demás fijos)

RS no es fijo, simplemente RS=1 significa que enviamos un carácter (como en el ejemplo) y no un comando, que en este último entonces pondríamos RS=0.

El módulo que diseñé automatiza todos estos procesos. Para ello utilicé 3 máquinas de contar de 1 bit. Hay dos máquinas de contar que automatiza estos 4 pasos, luego una tercera, también de 1 bits, que se encarga de encarga de la llegada de un dato o comando externo (por ejemplo, desde el puerto serie). Y la última máquina de contar, de 4 bits, sólo se utiliza para la carga de configuración.

El módulo que diseñé funciona perfectamente, el único problema es que al realizar estos 4 pasos y respetar los tiempos de la pantalla LCD, consume mucho tiempo. Lo que me falta por verificar es el pin busy del módulo, porque si se añade módulos de control externos (para convertir el "enter" en un goto xy, por ejemplo) se necesita saber muy bien si podemos ejecutar esa acción o no.


Para finalizar os comento cómo manejar el módulo I2C que está en su interior, es otro diseño nuevo y muchísimo más fácil de manejar. Está pensado para funcionar junto a una máquina de contar.

Si ponemos un dato de 8 bits (d[7:0]) y damos un tic el pin de "send", este módulo enviará ese dato por el I2C, y esto se hace con tantos bytes como queramos y con el tamaño de paquetes de bytes que queramos (es repetir esta acción). Cuando marcamos el pin "stop", el paquete de datos se cierra. El primer byte siempre debe ser la dirección I2C. Si conoce el protocolo I2C, debe saber que con el primer byte que envía, automáticamente se produce la señal de "start" del protocolo I2C (porque es el primero), y cuando haya terminado de enviar datos (de cualquier ancho), le damos un tic en el pin "stop" y crea la señal de "stop" del protocolo I2C.

Para este módulo I2C, la dirección se la trata como cualquier otro dato (no es diferente al resto de datos que envías), por lo que el byte de la dirección (que son 7 bits) hay que multiplicarlo por 2 para sumar el bit RW y formar los 8 bits. No tienes que preocuparte por nada más. El bit ACK del protocolo I2C se agrega dentro del módulo automáticamente.

Para ilustra lo sencillísimo que es hacerlo funcionar os dejo con esta imagen. Se trata de enviar 2 bytes a través del I2C. Para enviar dos bytes necesitamos una máquina de contar de 1 bit, ya que ese bit nos dará 0 y luego 1; estos valores son los que direccionará la tabla. La máquina de contar se encarga de enviar primero "55" y después "AA" y quedará todo como un paquete de 2 bytes con su señal de "start" y "stop" del protocolo I2C. Al terminar el envío, la señal de "done" del módulo I2C nos avisará de que ya está preparado para otro envío. Para cualquier otro paquete de información (2, 8 ó 1000000000 de bytes) se ha de poner una máquina de contar que llegue hasta ese número de envío. Para conseguir paquetes variables, la máquina de contar ha de tener una entrada con límite variable.

Si veis las señales a través de PulseView, el primer byte siempre lo interpreta como dirección, entonces no sale con el valor 55 (en este ejemplo), pero esto no quiere decir que esté mal, sólo que interpreta el byte de dirección como una dirección de 7 bits, en vez de 8.

Saludos!

[Democrito]

Para que no haya malas interpretaciones del mensaje anterior, el especificar el chip I2C estaba dirigido a Juan, el resto del post está dirigido a todo el mundo. 

[charli va]

Yo compré este hace tiempo y creo que es el mismo de Demócrito, no puedo probarlo porque estoy de viaje y no tendré acceso a el en varias semanas pero os dejo el enlace por si quereis echarle un vistazo, yo lo desoldé y lo monté a parte para poder utilizar la lcd con o sin i2c, seguramente el controlador este lo vendan suelto porque lo tienen todas las lcds que ves por aliexpress y amazon:

https://www.amazon.es/AZDelivery-HD44780-pantalla-interfaz-caracteres/dp/B01N3B8JMN/ref=sr_1_2_sspa?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=4TWRCO2O0BQP&keywords=lcd+i2c&qid=1661886744&sprefix=lcd+i2c%2Caps%2C107&sr=8-2-spons&psc=1&smid=A1X7QLRQH87QA3

Un abrazo equipo!

El mar, 30 ago 2022 a las 21:13, Democrito (<spo...@gmail.com>) escribió:

Para que no haya malas interpretaciones del mensaje anterior, el especificar el chip I2C estaba dirigido a Juan, el resto del post está dirigido a todo el mundo. 

--

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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/86a085e1-b852-4982-b61e-07865d4a1818n%40googlegroups.com.

[charli va]

Justo, los venden sueltos:

https://www.amazon.es/AZDelivery-%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90-HD44780-1602-visualizaci%C3%B3n/dp/B078SVXZHN/ref=psdc_683279031_t1_B07PGZ9B51

[Democrito]

Hola de nuevo,

Siguiendo con la temática LCD vía I2C, acabo de realizar un ejemplo de uso de un comando, el CLS que es limpiar pantalla. Como ya tenemos un driver (o controlador) que nos automatiza la parte de convertir carácter o comando a través del I2C, ahora falta definir los comandos. El envío de caracteres es directo (teniendo RS = 1), pero falta definir las acciones de los comandos. El más sencillo de todos es el CLS y tiene como valor "01", es decir que si envías a la entrada de datos un simple 1, pones RS = 0 (porque es un comando) y le das un tic a "start", ejecutará esa acción, que es limpiar la pantalla.

He asociado la tecla "escape" que tiene el valor ASCII 27, para que haga la función de CLS. En el ejemplo que adjunto puedes escribir cualquier cosa, y cuando pulses la tecla "escape", se borrará la pantalla.

En la imagen de arriba lo he dejado para que se vea directamente, pero una vez que vayamos creando comandos, convendrá crear un módulo dedicado a eso y que quede toda esas parte oculta.

El comando CLS es de los comandos más sencillos. Si vamos por niveles de dificultad, estaríamos en el primer nivel. El siguiente nivel será detectar el retorno de carro y ejecutar esa acción, que creo que requiere de dos procesos (o dos acciones), pero esto todavía no lo he mirado y no estoy seguro de que sea así. Y para terminar, el nivel más complejo sería crear un scroll, que a su vez está asociado con en retorno de carro. Por otra parte, un comando podría llamar a otro si fuese necesario.

Adjunto un ejemplo práctico. Escribes lo que quieras en pantalla y al pulsar "escape" comprobarás que la pantalla se borra y puedes continuar escribiendo.

Un saludo.

[Democrito]

Para jugar un poco, puedes sustituir el ASCII 27 por el 10 (en el comparador), de esta manera cuando pulses "enter", se borrará la pantalla.

[charli va]

Buenas Demócrito para que todo esto no se pierda si te apete súbelas a iceCrystal, puedes crear ahí una carpeta por cada ejemplo con el .ice y un readme.md con la explicación, así quedaría todo fenomenal.

No sé que te parece @Juan Gonzalez Gomez pero como el está organizando y modularizando la nueva colección de LCD no sé si te parece bien que todos estos nuevos ejemplos más desordenados los metamos en iceCrystal y ya luego tú los reaproveches o reorganices alineados a los nuevos bloques.

De todas formas si veis mejor centralizar foco, puedo poner iceCrystal en modo archivado para no aceptar pull requests y poner un mensaje que redireccione a la nueva de LCD ya me decís como lo veis.

Estaría genial que vieramos como focalizar el trabajo de todos, creo que sería muy motivante.

Estoy preparando a coalición de esto un planteamiento de arranque para la guía rápida, mi idea es que toquemos periféricos varios como el LCD.

En cualquier caso gracias por el ejemplo!

El jue, 1 sept 2022 a las 1:25, Democrito (<spo...@gmail.com>) escribió:

Para jugar un poco, puedes sustituir el ASCII 27 por el 10 (en el comparador), de esta manera cuando pulses "enter", se borrará la pantalla.

--

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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fb5c492c-3259-4734-813c-106eddaa7a30n%40googlegroups.com.

[Democrito]

Ya te he hecho un PR, Carlos.

He añadido la documentación del driver principal, y después he creado una carpeta en ese mismo lugar llamado "examples" y ahí he subido el ejemplo y una pequeña explicación.

Saludos!

[charli va]

a tope!!

--

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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/65cf3a35-8eb1-4a8a-80c7-86e34808a58an%40googlegroups.com.

[Jesus Arias]

Hola, Muy bien documentado.

Sin embargo creo que sería conveniente añadir un comentario acerca de la adaptación de niveles eléctricos porque sospecho que el LCD va a 5V, pero la FPGA va a 3.3V y sus pines no son tolerantes a 5V. Una conexión directa haría que el LCD ponga 5V en los pines de la FPGA que van conectados al bus de datos del LCD durante las lecturas (bucle cerrado) y eso a priori puede ser dañino para la FPGA.

 Se me ocurren las siguientes soluciones:

- No hacer lecturas en el LCD, sólo escrituras (operar en bucle abierto).

- Poner divisores resistivos en los pines del bus de datos: 1.8Kohm entre pin FPGA y pin LCD y 3.3Kohm entre pin FPGA y GND. Con esto los 5V del LCD bajan a poco menos de 3.3V en el lado de la FPGA

- Usar un convertidor de niveles integrado como el SN74LVCC3245 controlado por la señal R/W.

- Alimentar el LCD a 3.3V. El controlador del LCD funciona perfectamente con esta tensión aunque el cristal líquido va a necesitar más. Pero la tensión máxima en los pixeles es (Vcc-Vo) y Vo (contraste) puede ser negativa. Si se dispone de una tensión negativa este sería mi solución preferida.

Saludos

[Obijuan]

Hola,

Sí, las tensiones son diferentes. Pero esto no es un problema con la Alhambra-II (Con la que se hacen los ejemplos de los cuadernos ténicos). Los pines están protegidos y se pueden conectar sensores/dispositivos de 5v (Fue una de los criterios de diseño)

Pero llevas razón, que con placas que no lleven pines protegidos puedes tener problemas.

Saludos, Obijuan

[Jesus Arias]

Hola,

Ya he visto las resistencias serie en el esquemático de la Alhambra-II. Eso limita la corriente en los pines a un máximo de 4mA, lo que debería ser suficiente protección.

De todos modos adjunto un ejemplo de uso de LCD y microcontrolador a 3V y bomba de carga para la tensión de contraste en el LCD, por si te resultara interesante. (Puedes ignorar todo el tema analógico del documento)

[Obijuan]

Ya está terminado el Cuaderno Técnico 12 sobre el diseño de un controlador de LCD de 16x2, en Icestudio 

https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/wiki/CT.12:-Controlador-LCD-16x2

En total se han creado 4 controladores en el nivel superior (nivel 2): En bucle abierto y cerrado, y con interfaces de 8 ó 4 bits 

En el último apartado se pueden ver algunos ejemplos, ya con el controlador definitivo

Los bloques se encuentra en la colección iceLCD:

https://github.com/FPGAwars/iceLCD

Saludos, Obijuan

[Alfredo Sanz]

Increíble trabajo como siempre, gracias maestro.

saludos

[Fernando Mosquera]

Fantástico trabajo, Obijuan

Esos cuadernos técnicos son oro puro

Gracias y un saludo 

Get Outlook for Android

---

From: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com> on behalf of Alfredo Sanz <correo....@gmail.com>
Sent: Saturday, November 5, 2022 3:23:37 AM
To: FPGAwars: explorando el lado libre <fpga-wars-explora...@googlegroups.com>
Subject: Re: [Icestudio] Cuaderno técnico sobre LCD 16x2

 

--
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 ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4cb62808-1a62-44a1-a026-a061c0522170n%40googlegroups.com.

[Jo mo]

Oh my god, thaht's a funky s....

;-p

 Gracias Juan

[charli va]

Wow! great theme Jom!!! ;)

Obijuan, you are great! thanks a lot!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8cf8d845-206e-4b8a-812f-a9066a9bbda2n%40googlegroups.com.