Ciao a tutti, sto sviluppando sulla board TiDiGino che, come è ormai noto a chi ci ha lavorato, spesso e volentieri non il modulo GSM non si inizializza dopo un power cycle, a meno che non gli venga dato un impulso di reset da USB.
Siccome nell'installazione che devo fare non posso avere sempre un Pc a disposizione vorrei sapere come poter, al momento dell'avvio della board, mandare un impulso di reset per inizializzare correttamente il tutto.
Per farlo potrei usare la board stessa(è il modulo a non partire, la board gira correttamente) oppure un hw esterno.
un condensatore da 100nF (o maggiore) posto tra il pin di reset del micro e GND dovrebbe provocare un reset iniziale, la cui durata è direttamente proporzionale alla capacità del condensatore, rapportata alla R di pull-up.
leo72:
Non ho capito... se l'alimentazione è staccata... più reset di quello...
A che ti serve spedire un ulteriore reset?
Il problema è che quando viene tolta e poi ridata l'alimentazione il modulo SIM900 non si inizializza e rimane in blocco, e solo un reset via USB(neanche col pulsante di reset sulla board funziona) riesce a farlo partire
Ma quel tipo di reset non è quello dato dal pulsante? Perchè in quel caso come già detto non funziona...
Che differenza c'è tra il reset via pulsante e quello usb?
cirowner:
E allora perchè parte solo se collego la usb?
Perché si vede che il problema non è legato al solo reset, io ho un TiDiGino che ho utilizzato come "muletto" per i test legati allo sviluppo di questo articolo, non ho mai riscontrato i problemi che citi.
Sol forum della futura vedo che non sono l'unico ad avere questo problema, ed è il secondo TiDiGino che mi passa sottomano, quindi non è un un difetto del mio esemplare.
Sempre sul forum leggevo che avevano risolto modificando il file dei pin dell'IDE, ma si riferivano ad un IDE vecchio, e nella versione che uso io(l'ultima) quelle modifiche sono già applicate.
L'unica, sottilissima, differenza che mi viene a mente fra un avvio della scheda con alimentazione ed un reset successivo è data dal diverso comportamento del bootloader.
Quando viene data alimentazione all'Atmega328P con bootloader Optiboot, questo va a leggere in un apposito registro per vedere se la scheda è stata alimentata per la prima volta oppure se si è dato un reset (fatto col pulsantino o tramite USB non fa differenza, te l'ha spiegato ora Astrobeed). Cambia però il comportamento che tiene il bootloader: nel caso di un primo avvio, fa partire immediatamente il programma. Nel caso di un reset, si mette prima in ricezione sulla seriale per vedere se è in arrivo uno sketch dall'USB da scrivere eventualmente sulla Flash. Se non arriva nulla, viene avviato il programma dell'utente.
Ora, potrebbe darsi che l'apertura/attività sulla seriale "svegli" la TiDiGino?
Forse, quella piccola attesa prima che venga avviato il programma dell'utente, basta alla scheda per inizializzarsi prima che lo sketch la interroghi, e non possa rispondere perché non è "pronta"?
Sono ipotesi, non so neanche cosa sia questa TiDiGino, quindi vado a tentoni.
leo72:
Cambia però il comportamento che tiene il bootloader: nel caso di un primo avvio, fa partire immediatamente il programma. Nel caso di un reset, si mette prima in ricezione sulla seriale per vedere se è in arrivo uno sketch dall'USB da scrivere eventualmente sulla Flash. Se non arriva nulla, viene avviato il programma dell'utente.
Vero, però non è questo il caso perché il TiDiGino lo devi alimentare a parte, la USB alimenta solo l'FTDI, ovvero quando lui connette la USB c'è solo il classico reset e non l'avvio a freddo.
Ma il GSM come comunica con l'Arduino? Tramite seriale?
Forse è questo allora il nodo cruciale? Vi ricordate di quando abbiamo parlato tempo addietro della presenza di una minima corrente sulla linea RX o TX, non ricordo bene, data dalla presenza dell'Atmega8U2/16U2 che, con le sue pull-up teneva la linea alta e che Astrobeed aveva detto che tale stato era la norma della seriale?
Vi ricordate anche che dai test condotti tale stato svaniva non appena il pin suddetto veniva messo come output?
Siccome appunto il bootloader, quando viene avviata la scheda, non controlla la seriale per l'arrivo di uno sketch, tale piccola corrente di pull-up permane sulla linea. E forse dà noia alla TiDiGino?
Quando invece il chip viene resettato, la prima cosa che fa il bootloader è quella di "sentire" se sulla seriale arriva qualcosa. Ma così facendo fa sparire quella corrente, ed il TiDiGino magari parte regolarmente per questo?
Io non ho la scheda ma potrebbe essere un test da fare. Se fosse così, basterebbe mettere un
pinMode(pinRX, OUTPUT);
digitalWrite(pinRX, LOW);
per far sbloccare la TiDiGino?
Non so... pensieri in libertà
cirowner:
Sempre sul forum leggevo che avevano risolto modificando il file dei pin dell'IDE, ma si riferivano ad un IDE vecchio, e nella versione che uso io(l'ultima) quelle modifiche sono già applicate.
Sei sicuro?
Io ho aperto ora nell'IDE 1.0.4 il file pins_arduino.h della Mega e non vedo traccia dei pin dal 70 in poi.
Che sia proprio in questo il bug?
Sull'IDE 1.0.x questo file devi metterlo in una specifica cartella sotto /hardware/arduino/variants e poi la voce in boards.txt deve essere impostata in modo da usare quel file. Altrimenti compili per la scheda Arduino Mega2560, quindi con il pins_arduino.h originale.
Con qualcuno ha funzioanto.
E poi, come ha ha detto astrobeed, perchè pur avendo lo stesso hw e le stesse lib a lui funzionava?
Non vorrei dire ma secondo me riguarda l'IDE/compilatore.
