gpb01:
@ Leo : Su una cosa però overmike ha ragione ...
overmike:
Mi sono riletto la documentazione delle varie funzioni stringa, e in nessun caso è stato riportato "attenzione all'uso delle funzioni stringa perche' puo creare instabilita".
... se tu puoi segnalare la cosa ... magari nella descrizione di "String" ... una nota che indica di stare attenti all'uso della memoria che fa questa classe ... ci starebbe bene 
Guglielmo
Nella documentazione mancano altre informazioni che un programmatore esperto comprende, ma che sono motivo di confusione per un principiante, specie se questi non vuole proprio diventare un programmatore perché è più un artista che tecnico, per cui il suo primo obbiettivo e fare funzionare l'applicazione da mostrare. Poi in seguito Arduino viene usato in tutti campi non solo nel campo artistico digitale, con tutte i problemi del caso.
In campo artistico digitale (Arduino è rivolto a questo principalmente) se una applicazione smette di funzionare dopo 10 ore, per qualsiasi ragione non è problema basta resettare. In altri settori applicativi ci sono vincoli molto stretti, non solo il codice non si deve bloccare con "certezza" ma se per caso questa certezza venisse a mancare il codice deve essere rianimato in modo assolutamente trasparente e ciò che è accaduto viene registrato.
Cosa manca nella documentazione:
Funzioni, classi ecc possono essere:
- Rientranti o meno.
- Usare o meno allocazione dinamica di RAM
- Statiche o meno
- Virtuali o meno
- inline o meno
.... ma c'è sicuramente altro da documentare.
Tuttavia il codice è aperto e si può analizzare, lavoro che richiede competenza.
Il assembly l'allocazione dinamica della memoria è fattibile, tuttavia raramente se ne sente la necessità.
String è un classe comodo, che dovrebbe essere evitata quando tra i requisiti dell'applicazione c'è security constraint, ciò il vincolo della sicurezza. In una applicazione artistica non c'è vincolo di sicurezza, per cui ci basta che l'applicazione lavori per il tempo necessario a mostrarla. In più un reset programmato non comporta alcun danno all'applicazione per è sempre possibile dare l'impressione che l'applicazione stia lavorando continuamente senza problemi.
Come è stato detto ogni cosa ha i suoi limiti e capire quando si è vicini a questi limiti alle volte è complesso, questo è
il caso di String o in genere della allocazione dinamica di memoria, che se applicata con criterio e competenza non comporta alcun problema di alcuna natura. Gli oggetti locali che allocano memoria dinamica al termine del loro scope (ciclo di vita) vengono distrutti e l'eventuale memoria dinamica viene resa disponibile, stessa cosa per gli oggetti che non allocano memoria dinamica che quindi vivono nello stack che diminuisce di dimensioni quando l'oggetto locale esce fuori dallo scope.
In assembly se fai uso di stack (come in C che lo usa implicitamente) non chiami 100 funzioni in cascata, perché lo stack si riempirebbe di un mare di dati ed equivarrebbe ad usare funzioni ricorsive. Il massimo che conviene fare è la chiamata di funzioni in cascata fino a 3-4, poi dipende dall'applicazione.
Le macchine a stati e i toolkit event-driven sono pensati proprio per evitare la chiamata di funzioni in cascata.
Con questi sistemi una funzione al massimo chiama un'altra funzione, ed entrambe emettono segnali che verranno interpretati dal sistema event-driven dopo che queste funzioni ritornano. Si c'è anche qui un problema subdolo: Una funzione che rimane in loop infinito blocca comunque l'intero programma; una funzione che rimane in loop per x tempo impedisce per x tempo la propagazione di eventi. Quindi funzioni di breve durata che terminano subito il lavoro da svolgere, che emetto segnali (o eventi) che verranno interpretati al prossimo ciclo di loop del sistema che gestisce gli eventi. Ovviamente il sistema di gestione degli eventi impegna risorse.
@overmike
Mi si è aperto un nuovo mondo e io che pensavo di aver già imparato qualcosa.
Si, sicuramente ha già imparato qualcosa, ma non è mai abbastanza e raramente è sufficiente 
Ho letto alcune tue risposte in un altro post e mi sono fatto l'idea che aver avuto a che fare con
'assembly ti è servito, per cui consolati hai già una ottima base di partenza, devi solo digerire
la natura subdola del linguaggio C/C++.
Tieni conto che se vuoi, puoi scendere in assembly in due modi:
- Scrivendo una libreria arduino di cui uno o più compile unit sono scritte in assembly
- Miscelando nello sketch del codice assembly grazie alla direttiva "asm" che viene detta asm inline,
in quanto il compilatore durante l'analisi riconosce la direttiva asm e passa ad assemblare più che compilare.
PS: Prendila con filosofia, nulla è perfetto e tutto è migliorabile.
Ciao.
)