MCP23S17 per comandare dei relay

Io ho il brutto vizio di dire le cose come stanno, tendo a dipingere la realtà in modo più aderente che riesca a fare, ma inevitabilmente vengo frainteso.

Quindi onde evitare fraintendimenti:
Arduino è una ottima scheda, l'ide è pessimo, il modo di sviluppare non forma il programmatore, ma ha il vantaggio di apparire semplice e intuitivo e senza limitazioni cosa che per un principiante è un aspetto allettante. Il principiante ancora non è cosciente che ogni cosa è complessa e nulla di facile esiste, persino bere un bicchiere di acqua può essere complicato quando non hai le mani.
PS: ci sono anche altri vantaggi e il corrispettivo rovescio della medaglia.

Ok allora ogni cosa che ci circonda è complessa e può apparire semplice perché altri hanno lavorato per farla sembrare semplice, purtroppo qualunque semplificazione ha il rovescio della medaglia e credo che sia un vantagio saperlo perchè nel caso di arduino quando non bastano le funzioni del core lib, l'ide ecc, si può ricorrere ad altre funzioni sulle quali arduino core lib è costruito.

Il C non è nato specificamente per applicazioni embedded, ma la grande flessibilità del linguaggio ha permesso un adattamento che per tanto tempo non è stato messo in discussione ( in realtà si, ma in modo marginale tanto che il C è il linguaggio più usato in applicazioni embedded).

Consigli:
Trova un IDE decente con cui ti trovi bene, questo deve essere in grado di avviare il compilatore nativo, cioè crea codice per la piattaforma su cui è eseguito il compilatore e l'ide. Io uso GNU/Linux e come ide uso QtCreator.

L'obbiettivo è quello di testare:

  1. La rappresentazione delle informazioni, stringhe, stringhe di array, valori numerici in esadecimale, decimale e ottale
  2. tutti gli operatori unari e quelli logici and, or e xor
  3. tutte le operazioni bitwise fino a comprenderle senza cadere nell'inganno, le macro _BV() e altre.
  4. alcune funzioni delle libreria standard C, ma in avrlibc alcune non sono standard e allora bisogna trovare il codice e portarlo sul
    pc compilarlo e testarlo.
  5. L'uso delle classi in C++, delle strutture in C e i puntatori a funzioni.

L'uso di esprimere un numero in formato binario 0b0010ecc non lo trovo educativo, ma è utile per il principiante che deve imparare a contare in binario ed esadecimale a mente, A=10, B=11 C=12 ecc. Esprimere il valore in formato binario è merito di arduino core lib, che crea delle macro 0b11011111 223.

Io per contare in binario ed esadecimale uso una applicazione calcolatrice :* , specie per i numeri esadecimali, ma anche per i binari da 16 bit.

L'uso e la vendità di librerie di estensione al linguaggio è comune in ambito non embedded, cioè con il PC, meno anzi molto meno in applicazioni embedded perchè il programmatore deve tenere sotto controllo le risorse limitate e per questo ha bisogno di sapere nel dettaglio cosa accade istruzione per istruzione, questo è vero in ambito professionale specie su commisione, perchè l'hardware viene scelto dal committente è il programmatore deve farci stare dentro tutte le richieste del committente e stranamente l'hardware è sempre appena sufficiente e mai abbondantemente sufficiente.

Mentre in ambito obistico anche evoluto torna sempre comodo spulciare nella libreria che si sta usando al fine di capire cosa fanno quelle funzioni, per fortuna il codice di avrlibc, di arduino core lib e dell'ide è rilasciato sotto GPL o LGPL che sia è quindi è consultabile oltre che modificabile, e li dentro impari cose che non trovi nei libri.

Tornando al progetto, ora non penso che siano altri intoppi e puoi procedere con magiore celerità e non dimenticare di fare partecipe tutto il forum circa i risultati raggiunti e penso proprio che la sezione Megatopic sia il posto migliore per condividere il progetto.

In modo assolutamente non informale:
Ti è andata di culo che il datasheet del 23S17 è lo stesso del 23017 che devo usare io, che quindi prima poi dovevo leggere. :grin:

Ciao.

Ottimo! grazie per le delucidazioni!
In ogni caso mi fa piacere che tu dica le cose come stanno... Ormai ho capito che è inutile scrivere programmi bypassando i problemi sfruttando pezzi di codice trovati qua e la... Vista l'esperienza con questo MCP23S17 mi sembra chiaro che è meglio andare a fondo e capire cosa c'è dietro a un semplice programmino di 10 righe.

Un paio di riflessioni tra me e me, anche se il thread tratta di tutt'altro.

Partiamo dall'IDE... Personalmene ho provato un po' di tutto sia per quanto riguarda i sistemi operativi sia per l'ambiente di programmazione: per il primo corso di C ho usato il vecchio Dev-C++ sotto windows, ma in quella fase era veramente solo questione di scrivere qualche ciclo e eseguire operazioni di base.
Dopodichè sono passato a linux e per il corso più "evoluto" consigliavano di scrivere il programma con uno dei vari editor standard di linux (Vim,nano,gedit e simili) e compilare con GCC. Ho poi provato per qualche tempo eclipse, più per curiosità che per necessità.
Ora sono principalmente su MacOS, anche se ho a disposizione ancora linux su macchina virtuale e windows su una partizione secondaria.
La scelta più ovvia sarebbe continuare ad usare eclipse sotto MacOS.

Non ho però capito come dovrei utilizzare un IDE diverso da Arduino. Sarebbe soltanto un'interfaccia più completa da sostituire alla solita interfaccia standard "verde e bianca" oppure mi permetterebbe di sviluppare tutto il software, compilarlo e caricarlo sulla scheda sempre dalla stessa interfaccia? Mi sembra di intuire che dovrei caricare tutte le librerie di Arduino nel nuovo IDE, ma non capisco come un diverso IDE si dovrà interfacciare con la scheda Arduino connessa al mio PC.

Come non detto... Nel frattempo sono andato a cercare qualche informazione e mi sono schiarito un po' le idee...
Ho visto che esistono dei plugin per estendere le funzionalità dei vari IDE al nostro AVR. Si tratta ora di capire se Eclipse va d'accordo con qusti plugin sotto Mac OSX... Altrimenti proverò a cercare un'altrnativa.

gamby:
Ottimo! grazie per le delucidazioni!
In ogni caso mi fa piacere che tu dica le cose come stanno... Ormai ho capito che è inutile scrivere programmi bypassando i problemi sfruttando pezzi di codice trovati qua e la... Vista l'esperienza con questo MCP23S17 mi sembra chiaro che è meglio andare a fondo e capire cosa c'è dietro a un semplice programmino di 10 righe.

Un paio di riflessioni tra me e me, anche se il thread tratta di tutt'altro.

Partiamo dall'IDE... Personalmene ho provato un po' di tutto sia per quanto riguarda i sistemi operativi sia per l'ambiente di programmazione: per il primo corso di C ho usato il vecchio Dev-C++ sotto windows, ma in quella fase era veramente solo questione di scrivere qualche ciclo e eseguire operazioni di base.
Dopodichè sono passato a linux e per il corso più "evoluto" consigliavano di scrivere il programma con uno dei vari editor standard di linux (Vim,nano,gedit e simili) e compilare con GCC. Ho poi provato per qualche tempo eclipse, più per curiosità che per necessità.
Ora sono principalmente su MacOS, anche se ho a disposizione ancora linux su macchina virtuale e windows su una partizione secondaria.
La scelta più ovvia sarebbe continuare ad usare eclipse sotto MacOS.

Non ho però capito come dovrei utilizzare un IDE diverso da Arduino. Sarebbe soltanto un'interfaccia più completa da sostituire alla solita interfaccia standard "verde e bianca" oppure mi permetterebbe di sviluppare tutto il software, compilarlo e caricarlo sulla scheda sempre dalla stessa interfaccia? Mi sembra di intuire che dovrei caricare tutte le librerie di Arduino nel nuovo IDE, ma non capisco come un diverso IDE si dovrà interfacciare con la scheda Arduino connessa al mio PC.

Mi sono spiegato male o hai capito male ma non importa il risultato sempre quello è.

Consigli:
Trova un IDE decente con cui ti trovi bene, questo deve essere in grado di avviare il compilatore nativo, cioè crea codice per la piattaforma su cui è eseguito il compilatore e l'ide. Io uso GNU/Linux e come ide uso QtCreator.

Deve essere in grado di avviare il compilatore nativo:
Il compilatore nativo genera codice per la stessa piattaforma su cui viene eseguito, detto alla carlona "compili codice che gira
sul PC.
Il compilatore non nativo è il cross-compiler il quale "gira" sul PC ma genera codice binario per una piattaforma diversa dal PC.
Si è più semplice dire che avrgcc gira sul pc e genera codice binario specifico per architettura AVR quindi è un cross-compiler.
Però avrgcc può anche essere compilato per girare su architettura "ARM" e quindi può essere eseguito su ARM ma genera codice per AVR.

Insomma nel cross-compiler la piattaforma su cui viene eseguito e diversa da quella per il quale genera codice binario.

Quindi io non ti ho consigliato di cambiare IDE per arduino, ma ti consiglio di usare il PC per testare codice che poi andrai a compilare con arduino. In questo modo per prendere confidenza con le classi ecc non devi flashare ma basta che usi le printf del C
o cin cout di C++ per fare debug. Puoi testare le bitwise, le macro, i calcoli per settare i timer ecc.

Per Mac puoi usare anche QtCreator come pure per windows, solo che per linux tutto si risolve con l'installazione di pacchetti pronti, per Mac e windows non credo che sia così immediato, in quanto mancano tutte le dipendenze, cioè il compilatore gcc per windows o Mac, make ecc che mi pare si trovino tutte in un unico file compresso da scaricare e sistemare nel filesystem manualmente. Mentre per Qt e QtCreator ci sono gli exe autoinstallanti e per Mac non lo so.

Ciao.

Ah beh... Ora è chiaro! Avevo interpretato male la cosa.
Pensavo che il consiglio di utilizzare un altro IDE fosse più che altro per un fatto di "leggibilità" del codice, ma non mi ero posto il problema del testare il codice senza flashare, cosa che in effetti sarebbe molto ma molto comoda.

A questo punto parto subito con qualche test...

Grazie di nuovo!

Di nuovo alle prese con il famoso MCP23S17...
Ormai è passato parecchio tempo da quando avevo fatto svariate prove con SPI e Slave Select. Avevo compreso abbastanza a fondo il funzionamento del comando di slave select della libreria con l'assegnazione tramite PORTB. Sfruttando il pin 53 del mega come Slave Select (appunto il pin SS predefinito) avevo ottenuto un funzionamento corretto e stabile. Avevo anche eseguito un buon numero di test con i vari comandi messi a disposizione dalla libreria ottenendo risultati positivi.

Ora per proseguire il progetto ho bisogno di spostare il pin di Slave Select di questo MCP su un altro pin, poichè il 53 è occupato dalla shield di uno schermino LCD.
Ho scelto per ora il "Digital pin 4" che sul ATMEGA 2560 corrisponde a PG5...

Detto fatto: ho sostituito nella libreria le due assegnazioni per abilitare e disabilitare il pin 5 della porta G:
PORTB &= 0b11111110 --> PORTG &= 0b11011111
PORTB |= 0b00000001 --> PORTG |= 0b00100000

Così facendo però il mio MCP non funziona correttamente, ho degli scatti "random" sui relay, stessa situazione che si era creata quando non avevo impostato correttamente PORTB nei primi tentativi... Ma cosa sbaglio in questo caso???

In questa maniera cambi lo stato di tutti i pin della porta G, non solo del pin PG5, però.
Inoltre non imposti la direzione del pin prima, nel senso che all'avvio tutti i pin sono INPUT per cui mettendo su HIGH il pin non fai altro che attivare la pull-up interna.

Tu invece devi mettere il pin in OUTPUT prima, per cui devi scrivere 1 sul bit PG5 della porta G.

DDRG |= (1<<5); //imposta il pin come OUTPUT
PORTG &= ~(1<<5); mette il pin a LOW

Per riportarlo su HIGH:

PORTG |= (1<<5);

Purtroppo quel codice è pessimo, ma è gia una base su cui lavorare.
Io non posso occuparmene, o meglio se chiedi e spieghi nel dettaglio come deve gestire il pin SS lo possiamo fare modificabile e gestito meglio di come è adesso, qui le competenze non mancano, (manca il tempo) ma come vedi non bastano perchè è necessario capire il protocollo.
Io non ho indagato più di tanto sul protocollo, mi sono accorto per caso di quella #define non usata nel codice.

Però se ti metti a studiare il protocollo e vuoi una mano, dillo entro domani, perchè farò una altra settimana full-immersion tra IFace, IPlugin, IObserve ecc, ma nelle pause per riprendermi posso dedicarti tempo.

Ciao.

Ringrazio entrambi per i consigli e la disponibilità. Purtroppo anche per me il tempo è poco, sto approfittando di un paio di giorni di ferie e del brutto tempo per riprendere in mano il progetto, ma in queste poche ore a disposizione preferisco completare la parte hardware, di cui mi manca veramente poco, dopodichè proseguire con calma con test vari e un software fatto bene.
Ora mi interessava appunto capire se fosse possibile e come spostare questo benedetto pin SS per poi fare tutti gli altri collegamenti del caso e testare il funzionamento dell'hardware... Senza dubbio mi metterò più avanti a capire meglio il protocollo e proverò sicuramente a migliorare qualcosa.

Nel frattempo mi devo limitare alle piccole modifiche suggerite... Tornando appunto al discorso "PORTG" io mi sono limitato a seguire la logica della libreria originale, che appunto usava gli operatori &= e |= per assegnare il valore al pin richiesto, ma assegnando comunque gli 8 bit.
Non avevo invece assolutamente calcolato il problema di settare PG5 come output, e non conoscevo il comando DDR... Ora mi sto leggendo la guida sul port manipulation dal sito di Arduino, e più tardi farò qualche test con queste modifiche...

Nel frattempo grazie a tutti, mi farò sentire spero con buone notizie!

Il pin SS è un pin di abilitazione per cui puoi usare qualsiasi pin dell'Arduino.

Per la manipolazione delle porte, ti suggerisco anche questo mio articolo, in italiano :wink:

Ottimo! Grazie per il suggerimento, lo leggo molto volentieri!

Ma non è possibile!!!

Ho provato poco fa ad effettuare le modifiche alla libreria, e subito ha funzionato tutto alla perfezione...
Quindi sono passato alla fase successiva, cioè scrivere un semplice programma che alla pressione di un tasto abilita, una per volta, le uscite del mio expander.
Nulla di più semplice, se non fosse per il fatto che adesso non so per quale strano motivo, senza aver toccato nulla e senza aver modificato le impostazioni dell'IDE, non esegue più l'upload!!!

Sotto windows funziona tutto perfettamente, mentre sotto mac osx (il mio sistema operativo principale) non c'è verso di flashare anche il più misero sketch...
Mi da il seguente errore:

avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/michele/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.Bluetooth-PDA-Sync
         Using Programmer              : wiring
         Overriding Baud Rate          : 115200
avrdude: wiring_open(): releasing DTR/RTS
avrdude: wiring_open(): asserting DTR/RTS
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

avrdude done.  Thank you.

Ripeto che con Windows funziona tutto correttamente, quindi escludo un problema alla scheda, in più anche scollegando l'usb non chiede più come prima di scegliere la porta, ma da lo stesso identico errore.
Ho anche provato a cancellare e ri-installare l'IDE, cancellare la cartella delle mie librerie e dei miei progetti, ma nulla. Non ho nemmeno trovato altri files di configurazione sparsi.

Sicuramente è un problema banalissimo, ma non riesco a venirne a capo! Metto apposto un tassello e se ne rompe un altro!!! :~

ARGGHHHH... Come non detto...

Ho scoperto che si era creato un duplicato del modem USB nelle impostazioni di rete del sistema operativo, praticamente erano comparso oltre a "Arduino Mega 2560" anche un "Arduino Mega 2561". Una volta eliminati e reinstallato quello corretto è tornato tutto a funzionare...

... Questa me la segno per la prossima volta