qsecofr:
hiperformance71:
queste cose che mi riferivo, avere tante fucntions o averne poche cosa cambia per la gestione dello stack?in teoria la chiamata (non la funzione in se) fa si che il processore si salvi appunto nell'area di stack quantomeno l'indirizzo di ritorno e questo fa si che le funzioni ricorsive (ossia una funzione che richiama se stessa continuamente) tendano ad occupare parecchia di questa memoria delle volte crashando il sistema... i ragazzi qua però hanno scoperto che stranamente il compilatore dell'arduino se ne accorge (forse solo a volte non so) e fa un abracadabra risparmiando memoria.
quanto al tuo programma non mi porrei la domanda sul quante volte dividere il loop in sottoprogrammi... io divido quando ho dei sottoprogrammi che fanno una cosa inerente... ossia se ho da gestire non so la temperatura, un lcd, dei tasti, faccio 3 sottoprogrammi uno per la temperatura uno per lcd uno per i tasti... se dopo quello dei tasti è lungo 100 righe e quello della temperatura sono 4 istruzioni non mi cambia la vita.
il mio consiglio è di studiare per bene come funziona il passaggio dei parametri e le dichiarazioni locali delle variabili che sono un po' la differenza tra i vecchi basic alla goto e questi linguaggi. esiste il goto anche in c ma non lo usa nessuno perche non serve ma soprattutto e' considerato il male supremo della programmazione razionale (imho invece rarissimamente ma delle volte aiuta)
invece utilissima pratica spesso trascurata è quella del commento di cosa fa una procedura... che poi delle volte se le variabili e le procedure hanno nomi mnemonici basta anche una riga di asterischi per delimitare una zona di programma che fa qualcosa da una zona di programma che fa un'altra cosa...sembra na stupidata ma il ns cervello se vede i blocchetti "alla lego" ragiona meglio...
Si, anch'io lo faccio così, suddivido il programma nei blocchi che ha, almeno quelli che ritengo richiedano una sub tutta loro, cose del tipo:
void Salva_in_EEPROM(){ ... } //function che salva i dati in EEPROM
void Check_EEPROM(){ ... } //function che controlla i dati in EEPROM se sono coerenti...
void Lettura_ADC_Channels(){ ... } //lettura dei pin analogici...
void LCD_out(){ ... } //routine che visualizza su LCD i dati raccolti/calcolati...
ecc...
Per fortuna tendo a documentare abbastanza ogni riga di codice e cosa fa, avendo qualche problemino di memoria mi torna molto ultile, avvolte su un progetto ci ritorno dopo mesi, se non ho commentato tutto, poi sono dolori per riprendere il flusso del programma!!
Per la ricorsività credo di non avere il problema, o almeno spero, credo di averne fatto un pò il callo in basic con i gosub, per esempio nei picaxe sono ammessi un massimo di 256 cicli di gosub ricorsivo e poi il compilatore va in errore, quindi una volta capito come fare, credo di poter evitarlo anche in C. A meno che non abbia ancora capito come lo si fa in C.
Per ora non posso neanche testare i codici che ho creato fino ad ora (mi correggo, alcuni li ho testati sul simulatore di arduino) perchè causa feste natalizie, il corriere non è ancora venuto a portarmi il mio nuovo ARDUINO UNO SMD, pensavo di giocarci questi ultimi giorni del 2012!! ed invece dovrò aspettare all'anno nuovo!! Quindi sto qua a tentare di assorbire come una spugna ogni consiglio utile ad imparare da chi lo sa fare meglio di me.
ciao,
Antonio