Seriosamente (piu o meno), vorrei provare a pilotare un piccolo display da 1.5", 128x128 con interfaccia SPI collegandolo ad un 328 standalone, al posto di uno I2C (perche' ho visto che quelli I2C sembrano abbastanza lenti nei pochi esempi che ho trovato, mentre ho letto che la SPI puo andare piu velocemente dei 400KHz dell'I2C), ma i pin normalmente usati per connettere la SPI ai vari dispositivi (10, 11 e 13, che corrispondono a SCK, MOSI e SS) sono gia usati dal connettore ICSP dedicato (non essendo una scheda gia pronta ma uno standalone, niente USB, la programmazione la devo fare via ICSP).
Ho quindi un paio di dubbi ... primo, se c'e' connesso il display quando collego il programmatore (o l'arduino-as-isp) per riprogrammare la MCU, questo potrebbe creare dei problemi ? (non potrei scollegarlo) ... secondo, se li crea, potrei usare altri pin per realizzare una connessione "3-wire SPI", mantenendo la velocita' della SPI standard ? (da quello che ho letto sul datasheet, probabilmente no, dato che quei pin sono mostrati con percorsi hardware diversi dagli altri, quindi ci sara' qualche hardware aggiuntivo per la funzione SPI)
3-wire SPI, ma il pin CS per il display lo usi, se si non vedo problemi di alcun tipo, se il pin CS è HIGH il display non riceve e non trasmette, quindi il bus è libero per la programmazione come per altri device connessi allo stesso bus.
Poi prima della programmazione c'è un reset per entrare in modo programmazione. Il programmatore ISP non è slave ma master per cui se il bus va su e giù il programmatore non lo considera durante l'esecuzione dello sketch.
Ciao.
Si, il dubbio era se una volta alimentato il circuito (si alimenterebbe anche attraverso il connettore ICSP) ed iniziata la visualizzazione, dandogli i comendi di programmazione attraverso il programmatore, il fatto che ci fosse collegato anche il display potesse dargli fastidio (non mi interesserebbe che il display prenda segnali a caso o visualizzi robaccia se prende i comandi, solo che la programmazione non ne rimanga influenzata) ... ma in effetti hai ragione, non avevo pensato al fatto che c'e' il reset pre-programmazione, che manderebbe tutto a riposo.
Al massimo potrei prevedere di usare come SS un pin diverso (ne ho ancora liberi), in modo che il segnale proveniente dal programmatore ICSP non "accenda" il display durante la programmazione, potrebbe essere usato un qualsiasi pin digitale senza che la velocita' della SPI ne risenta ?
Per quanto riguarda il "3-wire", pensavo di usare quel sistema perche' in fondo il display non manda nulla alla MCU, solo l'opposto, quindi in teoria MISO non dovrebbe essere necessario ... e' corretto ?
Mah ... se il codice NON sta scrivendo su LCD (e sicuramente subito dopo il reset il codice ancora non è arrivato al punto in cui scrive sul LCD) il pin CS non è LOW (il LCD NON è selezionato) e quindi il display dovrebbe avere i pin del SPI in three-state e quindi, come se fossero scollegati
Ah, giusto, vengono usati MISO, MOSI, SCK e RESET, ma non il pin SS per la programmazione, quindi l'SS usato come chipselect dovrebbe rimanere tristate (sara' il caso, giusto per prudenza, di metterci pure un pullup da 47K o piu, cosi tanto per essere sicuri ? ) ... hai ragione scusa, ho fatto confusione io.
... potrebbe essere una buona idea, così, quando al RESET, tutti i pin del ATmega vanno in three-state anche loro, tu hai comunque il pin di CS che viene tenuto HIGH e quindi il LCD disabilitato.
Infatti, non avevo letto e capito tutto riguardo ai 6 pin ICSP. No non credo serva una pull-up. Se il display non è inizializzato (se c'è pin reset) e se CS non passa da HIGH TO LOW non è selezionato, è come dice Guglielmo "come se non fosse collegato".
Si presume che durante la programmazione il programmatore dopo il reset in tempo utile invii i comandi per entrare in programming mode, per cui lo sketch non parte.
PS: Ma un collegamento in breadboard minimale dovrebbe toglierti il dubbio, ma forse hai il display già saldato, diversamente una verifica su breadboard io la faccio sempre.
La verifica la faccio appena arriva il display SPI, l'unico che mi e' rimasto in casa e' I2C ... dovrebbe essere qui a giorni, ma per le poste il termine "a giorni" ha notoriamente un significato molto elastico
Ora pero' ho un diverso dubbio ... dopo qualche ricerca in rete, pur specificando che cercavo solo connessioni SPI "3-wire", ho trovato solo esempi di connessioni SPI che, invece della solita limitata connessione con MOSI, SCL e SS, usano anche i pin 9 e 8 (il 9 per il DC e l'8 per il RESET del display) ... non ho alcuna difficolta' a collegarli se servono (mi avanzano parecchi pin EDIT: usando altri pin perche' quelli sono gia usati), ma mi stupisce che da nessuna parte ci siano esempi di connessione "3-wire" per display ... e' qualcosa legato alle varie librerie che usano tali pin, per caso ?
Tipico dei display SPI. DC è il pin che permette di scegliere tra spedire DATA o COMMAND. Il reset è reset e serve solo all'inizio per inizializzare il display scegliendo ad esempio le diverse modalità di comunicazione, SPI, I2c, parallelo 8-bit o parallelo 16-bit. Però se il protocollo di trasmissione è scelto da hardware il reset alle volte non serve collegarlo, oppure lo colleghi con una rete R C al fine di mantenere basso (credo) il pin dopo avere dato alimentazione.
Il bus SPI è si veloce, ma un bit che si alza/abbassa è ancora più rapido che spedire un byte per dire solo al controllore del display che il byte successivo è un comando, Per cui c'è il pin DC.
PS: Per il reset vedi il datasheet del chip che c'è a bordo sul display e/o il datasheet del display, ma anche nella doc della libreria potresti trovare info sul reset, del tipo è necessario o meno.
Ho visto, alcuni dicono che serve, altri no ... per andare sul sicuro, li collego tutti, male che vada la libreria non li usera', ma se mi tocca usare una libreria che li richiede, almeno ci sono, grazie.
Tanto per non rimanere senza dubbi ... se MOSI e MISO sono gia usati (da una SD), avendo il MOSI in comune con il display non dovrebbe creare alcun problema, dato che i CS e relativi pin di controllo sono pin separati e che ad usarli per l'una o per l'altra cosa ci pensano le relative librerie (nelle quali posso dichiararli in una MOSI e MISO per la SD e nell'altra il solo MOSI per il display), e' corretto ?
No, il display SPI ha solo il serial data (che usa il MOSI) ed il serial clock (SCK), oltre ovviamente ai pin reset, CS e CD, che ovviamente sono diversi da quelli della SD.
Ho sempre letto un po dappertutto che SPI puo viaggiare piu velocedi I2C, per quello volevo provare un display SPI , sempre a trovare una libreria decente e che occupi il minor spazio possibile (solo testo) per gli 1.5 pollici da 128x128 che usano il controller SH1107 (o almeno cosi dichiara il venditore, vedro' appena arrivano).
Male che vada ho in giro anche un paio di 1.44 pollici TFT, stessa risoluzione ma a colori, che usano ST7735S, ma preferisco gli OLED per questa applicazione, in teoria dovrebbero avere un'assorbimento inferiore e darmi piu autonomia, oltre ad una visibilita' migliore.
Comunque, ho letto recentemente un paio di post in altri lidi dove si parlava di portare la velocita' dell'I2C di Arduino ad 1MHz come per la SPI, dichiarandolo come
Wire.setClock(1000000);
Io ho sempre saputo che al massimo l'I2C si poteva dichiararla a 400KHz (almeno con i 328P / PB), peraltro credo che anche se potesse andare piu veloce dei 400KHz poi dall'altra parte servirebbe hardware diverso che lo regga, non quello standard, e' corretto ?
Oltre consumo e visibilità, considera che con un display a colori devi comunque trasferire più dati, anche con un RGB 'mozzo' (565) sono sempre 2 byte per pixel, quindi, entro certi limiti, vanifichi il fatto di andare più veloce.
Riguardo i 328 non saprei, bisognerebbe consultare il datasheet, comunque è chiaro che il partner di comunicazione deve poter accettare una velocità maggiore. Io per un progetto ho usato 1Mhz (ma con altra MCU), e mi sono dovuto fermare li, perchè da prove fatte l'ADC (ADS1115) poteva lavorare anche a velocità maggiori, ma l'IO expander (MCP23017) si fermano ad 1 MHz.