Schermo LCD I2C malfunzionante?

docdoc:
...
PS: steve, ma che indirizzo è "27F"? :wink:

Forse erano i 27 gradi di FRESCO a cui mi sare anche accontentato, dato che ero in Italia.

Fortunatamente ieri sono tornato a casa e ho di nuovo i miei 24 gradi: i 40 gradi ve li lascio volentieri!!!

Si, la tabellina dice tutto e non mi sono messo a guardare le piazzole. Però sono sicuro che se lampeggia la retro illuminazione ( e non solo uno sfarfallamento dei caratteri dovuto ad un continuo CLEAR ) dipende dalla libreria e dall'indirizzo sbagliato. Facendo copia-incolla da internet può succedere di cambiare anche l'indirizzo.

Ciao, ecco i primi test.

Ho caricato questo codice:

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x3F, 16, 2);

void setup()
{
	lcd.begin();
	lcd.backlight();
	lcd.print("Hello, world!");
}

void loop()
{
}

ed il risultato è questo: video

Se poi ricarico lo stesso identico sketch succede questo: video

Ho ricontrollato l’indirizzo dello schermo con lo scanner I2C e continua a dirmi 0x3F. Ho fatto anche una prova facendo ponte nelle piazzole A0 A1 A2 (mentre lo scanner funzionava) ma non mi diceva un indirizzo diverso, è normale?

Ah, volevo copiarvi anche l'output del caricamento dello sketch.
Purtroppo non me l'ero copiato quindi ho ricaricato lo sketch e l'output nuovo è questo (che però mi sembra proprio uguale a quello precedente):

ATTENZIONE: La categoria 'Device' della libreria ParPrinter non è valida. La imposto a 'Uncategorized'
ATTENZIONE: La categoria 'Device' della libreria Radar non è valida. La imposto a 'Uncategorized'
Lo sketch usa 264844 byte (25%) dello spazio disponibile per i programmi. Il massimo è 1044464 byte.
Le variabili globali usano 27256 byte (33%) di memoria dinamica, lasciando altri 54664 byte liberi per le variabili locali. Il massimo è 81920 byte.
esptool.py v2.6
Serial port COM4
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: 80:7d:3a:6e:fe:7e
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 256000
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 8.1s
Hard resetting via RTS pin...
esptool.py v2.6
Serial port COM4
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: 80:7d:3a:6e:fe:7e
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 256000
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 268992 bytes to 195874...

Writing at 0x00000000... (8 %)
Writing at 0x00004000... (16 %)
Writing at 0x00008000... (25 %)
Writing at 0x0000c000... (33 %)
Writing at 0x00010000... (41 %)
Writing at 0x00014000... (50 %)
Writing at 0x00018000... (58 %)
Writing at 0x0001c000... (66 %)
Writing at 0x00020000... (75 %)
Writing at 0x00024000... (83 %)
Writing at 0x00028000... (91 %)
Writing at 0x0002c000... (100 %)
Wrote 268992 bytes (195874 compressed) at 0x00000000 in 7.9 seconds (effective 271.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

foscone:
Ho fatto anche una prova facendo ponte nelle piazzole A0 A1 A2 (mentre lo scanner funzionava) ma non mi diceva un indirizzo diverso, è normale?

Hai fatto ponte e atteso un intero giro dello scanner?
Perchè lo scanner non è altro che una funzione che prova una comunicazione su tutti gli indirizzi possibili uno alla volta, evidenziando quelli per cui riceve una risposta valida.
Quindi, se fatto il ponte, il nuovo indirizzo è già stato verificato dallo scanner, non ti rileva variazioni.

maubarzi:
Hai fatto ponte e atteso un intero giro dello scanner?

Evidentemente non avevo fatto bene ponte perché ho fatto una seconda prova ed effettivamente cambiano gli indirizzi.
Cosa dici di quell'hello world che genera caratteri strani?

Francamente non me lo spiego.
Non lo scrive mai giusto ma non lo scrive nemmeno sempre diverso come quando ci sono disturbi sulla linea.
Il sospetto iniziale era l'inversione dei due cavi dell'I2C, ma fosse così non mi spiegherei la risposta allo scanner.

Comunque, sempre restando alle ipotesi, se girando il potenziometro del contrasto, si ottengono altri effetti, mi verrebbe da dire che ci sono connessioni ballerine sulla scheda.
Magari toccandolo si è spostato qualche collegamento fatto non proprio a regola d'arte e ora i dati si sballano.
Un qualche corto sulle piste della schedina che producono un trasferimento di dati corrotto.

Non è che per caso hai una seconda scheda da montare sul display per provare?

Non ho né altre schede né altri display, ora lo ordino così riesco a fare dei confronti.
Nel frattempo provo a vedere se dissaldando e rifacendo i collegamenti cambia qualcosa.

maubarzi:
Scusami, ma con questo caldo avevo visto solo la prima colonna, a guardare meglio c'era già tutto li.
sorry

Non devi scusarti, non c'è problema! :smiley:

maubarzi:
Non lo scrive mai giusto ma non lo scrive nemmeno sempre diverso come quando ci sono disturbi sulla linea.

Se ci fate caso, i caratteri che si vedono all'inizio del video sono sempre ("=" è quel simbolo con le righe):

=!,,/, 3/2. !

Ora affiancateli alla scritta che manda:

=!,,/, 3/2. !
Hello, World!

Se ci fate caso "H" è "=", "!" è la "e", "," la "l" minuscola, "/" la "o", mentre la virgola, spazio, e l'esclamativo sono apparentemente corretti.

Se si prende la tabella dei caratteri degli LCD, ignorando per ora il carattere iniziale "strano" vediamo che "ello world" sarebbero (valori decimali):
H 72
e 101
l 108
l 108
o 111

w 119
o 111
r 114
l 108
d 100

invece quei caratteri mostrati sono:

?? ??
! 33
, 44
, 44
/ 47

3 51
/ 47
2 50
, 44
32

Quindi si nota immediatamente che i caratteri mostrati corrispondono al codice del carattere meno un valore pari o a 64 o a 68 perché la "e" è 101 per cui 101-68=33, la "l" vale 108-64=44, e la "o" 111-64=47!

e 101 - 68 = 33 !
l 108 - 64 = 44 ,
l 108 - 64 = 44 ,
o 111 - 64 = 47 /

w 119 - 68 = 51 3
o 111 - 64 = 47 /
r 114 - 64 = 50 2
l 108 - 64 = 44 ,
d 100 - 68 = 32 (spazio)

quindi anche:
H 72 - 68 = 4
(carattere programmabile, forse default viene quel carattere con 4 righe)

Non so perché ci siano alcuni caratteri con 68 e tutti gli altri con 64, ma il tutto mi lascia pensare che ci sia qualche problema proprio col chip del display LCD o dell'interfaccia I2C.

Per cui si, comprane un altro e risolvi...

Attenzione che la pressione del tasto RESET su Arduino NON RESETTA anche lo schermo LCD.
Purtroppo questi schermi si resettano solo spegnendoli e riaccendendoli (su un mio progetto uso una uscita di un ESP-32 per pilotare un transistor che pilota l'alimentazione dello schermo).
Quindi è normale che il cambio delle piazzole non sortiva l'effetto, come anche l'apparizione degli stessi caratteri che in un video sono sicuramente causa di disturbi elettrici mentre per il primo video è come dice docdoc.

Però, scusate, ma le resistenze di pull-up sulla I2C ?

docdoc:
...
Quindi si nota immediatamente che i caratteri mostrati corrispondono al codice del carattere meno un valore pari o a 64 o a 68 perché la "e" è 101 per cui 101-68=33, la "l" vale 108-64=44, e la "o" 111-64=47!

Ammetto che sono stato pigro e non sono andato a controllare ma quando scrivevo:

maubarzi:
Non lo scrive mai giusto ma non lo scrive nemmeno sempre diverso come quando ci sono disturbi sulla linea.

stavo proprio sospettando cose di questo tipo.

Il fatto che sia cambiato toccando dietro per regolare la luminosità mi fa pensare ai collegamenti tra cip e scheda, non interni al cip.
Anche secondo me, in definitiva, è molto probabile che si tratti di una scheda difettosa.

Grazie per aver fatto i conti e avvalorato il mio sospetto più profondo...

Il video con tutti i caratteri con le righe orizzontali, potrebbe dipendere dallo sketch eseguito, uno dei primi postati aveva una ridefinizione dei caratteri e poi stampa dei caratteri ridefiniti. Quindi poteva essere un effetto voluto.

Le pull-up dovrebbero essere già sulla scheda, 10k se non ricordo male.

Se tocchi il pin E di un qualsiasi LCD, o con un dito o, meglio, con un giravite, lo schermo impazzisce ed appaiono quei caratteri strani del secondo video.
Quindi, per regolare il contrasto probabilmente lo ha preso in mano toccando questo pin.