Ciao Luca, ricordati di prendere ad esempio il secondo codice che ho postato!! (ma anche il terzo se preferisci, sono entrambi funzionanti). 

caricare il tutto su una stringhetta e lavorarla non vi piace?

Si mi piace. Però dipende se conviene, cioè non ho a vista il codice di String, se il ridimensionamente è gestito in modo efficiente potrebbe essere l'ideale per il parser a pacchetto.

Visti tutti i problemi di saturazione della RAM che si hanno con l'oggetto String, non credo che esso gestisca in modo "efficiente" la memoria 

Come detto più volte nei miei post, io sono un profano in materia, voi ne sapete MOOOOLTO più di me al riguardo, ma nelle mie sperimentazioni, ho costatato che l'uso di string è una "mazzata" per il consumo di RAM e FLASH, quindi avendolo anche letto in giro, ho preferito il mio approccio "grezzo" più che altro perché devo adeguare il codice alle mie capacità (un po scarse per il momento!) quindi non posso prendere un codice bello e pronto, magari super ottimizzato se non sono in grado di capirlo, altrimenti rischio che se devo apportare modifiche dopo qualche mese o due, non ci capisco un bel niente (ah, la mia memoria!) non è che cambi tantissimo fare il codice a modo mio, ma qualcosa in più ci capirei (almeno spero!).

Per esempio, l'idea di usare le string proposta da Pablos la capisco appena, se ho capito bene, tutto quello che viene sul buffer seriale viene accodato in una string da 100 caratteri giusto?  sarebbe tipo un'array ma di string?  ma poi, come si estraggono i dati da essa all'interno, come farei con un' array immagino? ovviamente a questo punto dovrei conoscere l'index o qualche char identificativo o separatore no? e poi dovrei convertirlo a int visto che quasi sempre sono dati numerici quelli che mi servono.  MMM...  C'è tanto da imparare...

Code:

void leggi(){  //legge 3 caratteri numerici ASCII sulla seriale, li converte a integer
     delay(50);   ////<------------------questo delay è indispensabile!!
     if (Serial.available())
     { a = Serial.read()-48;                       //viene sottratto 48 per rientrare nel range dei caratteri numerici ASCII (0=49,1=50....9=58)
       b = Serial.read()-48;                       //senza un sistema di check errore, se il sistema ricevesse una "a" per esempio,  
       c = Serial.read()-48;                       //verrebbe calcolato come "65"... x1000 o x100 o x10 o x1, quindi errato.
       d = Serial.read()-48;

Il pezzo di codice che hai postato non è male ed eviterebbe la atoi. Ma secondo me ha un problema di base, da per scontato che arrivino sempre 4 cifre.  
Quel pezzo di codice legge il carattere numerico, esempio '2' che equivale a 48='0';49='1';50='2' perciò 50; 50-48->2
Un metodo matematico semplice per convertire '2' (ovvero 50) in 2 come cifra.

spero di averti spiegato i pezzi di codici che hai postato.

Si, effettivamente fatto così, devo per forza struturare i dati in modo che sappia sempre il numero di dati in arrivo, in realtà l'avevo creato per provare a creare un mio protocollo di comunicazione tra pc e arduino, come base funziona abbastanza bene, visto che i dati sono organizzati in base al carattere "comando" che arriva per primo, i dati numerici che arrivano in seguito devono avere il formato stabilito (ma del resto i protocolli come funzionano? se prendiamo il CAN per esempio, ha una struttura ben definita da standard, i singoli sviluppatori decidono in che ordine e con che metodo organizzare i dati trasmessi, ad esempio, giri motore, MAP, TPS, TempMotore ecc)
io ho tentato di crearmi un mio "protocollo" consapevole che è ben lontano dall'essere perfetto e a prova di errori, ma essendo che sto imparando, e per ora, i risultati ottenuti sono buoni,  ho ridotto ad un minimo il numero di function predisposte alla ricezzione dei dati in arrivo, per esempio, ci sono comandi che implicano la ricezzione di 8 numeri composti da 3 cifre, quindi viene chiamata due volte la routine che "legge" le prime 4 cifre in modo da creare 8 numeri, spiegarlo a parole è difficile ma credo abbia reso l'idea.  Con questo metodo, riesco a programmare una serie di array diverse costituite da 1, 2, 4, 8 numeri a 3 cifre tutto in un unico "colpo", del tipo:  a100200300400b120130140150160c001002003004...   l'idea è questi dati siano inviati da un programma su pc dove questi comandi siano ben stabiliti con i dati da trasmettere,  ovviamente trasmettiamo stringhe troppo lunghe, prima o poi avvengono degli errori, ma ho notato che immettendo un delay di 50ms il problema non si presenta con un'invio di oltre 40 byte, ovviamente, l'idea è di non superare una soglia considerata affidabile, per esempio, le linee CAN possono avere diverse lunghezze in base alla specifica versione fino a 29 bytes (la 2.0B se non ricordo male).  Come detto, so che esistoni metodi migliori, ma io sto agli inizi, e mi baso più sulla pratica che sulla teoria, per ora questa è ancora piena di lacune, sto provvedendo, ma sono lento ad imparare, purtroppo oltre ad altri problemini il tempo a disposizione è pochino.

in giro trovo tantissimi esempi di protocolli seriali per comandare a distanza arduino, ma anche li, esperti e meno esperti, ogn'uno ci mette del suo, non è che abbia trovato un' unica strada per farlo, alcuni sono semplici come il mio (l'ho imparato da un esempio) ed altri dove serve indubbiamente tanta esperienza di C per capirci qualcosa, per ora, non è il mio caso...

Ciao e grazie per le critiche costruttive!    

@Mauro,

è interessante ciò che dici anche se per ora risulta un po complicato da capire, dopotutto con il C/C++ ci sto lavorando da natale, ma anche io ho visto che la miglior forma di semplificare è avere quanti meno caratteri possibili per comando, infatti, sul primo approcio che ho fatto alla ricezione di comandi da pc, avevo assegnato ad ogni comando una unica (ed univoca) lettera, quindi avendo 3 comandi da impartire, avevo lettere dalla 'a' alla 'c' , ad ogn'una di esse corrispondeva una chiamata ad una function che seguiva a leggere il contenuto della seriale per stabilire il resto dei dati del comando, del tipo a1002  il comando era 'a' un ciclo if/else if selezionava quale carattere era arrivato per primo, quindi quale comando, poi rimandava ad una function unica che assegnava a diverse variabili il contenuto del buffer seriale, gli sottraeva 48 per essere sicuro che fossero numeri da 0 a 9 faceva un controllo di errore (se diverso dal range 0-9), e creava un numero intero da questi caratteri numerici ricevuti, così:

Code:

void loop(){
 
if (Serial.available() )
  { ser=Serial.read();
    if(ser=='a')
    {
      leggi();
    }
 
    else if (ser== 'b')
    {
      leggi_b();
     
    }
    else if (ser== 'c')            //aggiungere qui altri comandi e chiamare le function corrispondenti, in questo caso, ho aggiunto un'utile chiamata a freeRam()
    {
      Serial.println(freeRam());
    }
  }
 
}

//*****************************************************
  void leggi(){  //legge 3 caratteri numerici ASCII sulla seriale, li converte a integer
   
    //Serial.println("OK, a premuto");
     
     delay(50);   ////<------------------questo delay è indispensabile!!
     if (Serial.available()) {
     
      a = Serial.read()-48;                       //viene sottratto 48 per rientrare nel range dei caratteri numerici ASCII (0=49,1=50....9=58)
      b = Serial.read()-48;                       //senza un sistema di check errore, se il sistema ricevesse una "a" per esempio, 
      c = Serial.read()-48;                       //verrebbe calcolato come "65"... x1000 o x100 o x10 o x1, quindi errato.
      d = Serial.read()-48;
      delayTime = (a*1000)+(b*100)+(c*10)+(d*1);  //se si deve ricevere 1, dalla seriale dovrà arrivare 0 0 0 1
      Serial.println(a);                          //debug
      Serial.println(b);                          //debug
      Serial.println(c);                          //debug
      Serial.println(d);                          //debug
      Serial.println(delayTime);                  //debug
    }

}
  //******************************************************
  void leggi_b(){  //questa function riceve un singolo carattere numerico, per esempio: 0=stop, 1=Forrard, 2=Reverse...
   
    //Serial.println("OK, b premuto");
    delay(5);
    if (Serial.available()) {
      x = Serial.read()-48;
     
      Serial.println(x);}
 
  }
 
  //*******************************************************
  int freeRam () {
  extern int __heap_start, *__brkval;
  int v;
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);

}

questo qui sopra, in realtà fu un codice modificato che ho fatto per una risposta ad un post su comunicazione seriale ed era basato sull'approccio che avevo realizzato per me, dove vi erano appunto 15 comandi che mettevano arduino in attesa per i dati che ad ogni comando seguivano (dal pc invio dei dati che arduino converte a integer e poi memorizza in delle array specifiche per quel comando), il tutto mi funziona molto bene, ma ovviamente, per un'esperto  magari ci sarebbero tante altre strade di ottenere gli stessi risultati senza creare un codice lunghissimo e pesante.

Scusate, Mauro, hai ragione, ho fatto un errore, ho dimenticato quel particolare, in realtà il mio codice originale ricevendo il primo byte della seriale tramite un ciclo if..else if  mi selezionava i comandi "base" poi vi era una chiamata ad un'altra function che si incaricava di

ho fatto una nuova correzione,  l'ho collaudata e funziona, basta indicare prima il numero di led da accendere/spegnere cosi:

1on  1of  2on  2of 3on  3of questo è il codice:

Code:

void loop(){
 
if (Serial.available() )
  { ser=Serial.read();
    if(ser=='1')
    {
      Led_1();
    }
 
    else if (ser== '2')
    {
      Led_2();
     
    }
    else if (ser== '3')            //aggiungere qui altri comandi e chiamare le function corrispondenti, in questo caso, ho aggiunto un'utile chiamata a freeRam()
    {
      Led_3();
    }
  }
 
}

//*****************************************************
  void Led_1(){  //legge 3 caratteri numerici ASCII sulla seriale, li converte a integer
   
    //Serial.println("OK, a premuto");
     
     delay(50);   ////<------------------questo delay è indispensabile!!
     if (Serial.available()) {
     
      a = Serial.read();                       
      b = Serial.read();                       
     
      Serial.println(a);                          //debug
      Serial.println(b);                          //debug
     
    }
    if (a=='o' && b=='n') { digitalWrite(LedPin1,HIGH); Serial.println("led 1 ON"); }
      else if (a=='o' && b=='f') { digitalWrite(LedPin1,LOW); Serial.println("led 1 OFF"); }

}
  //******************************************************
  void Led_2(){  //legge 3 caratteri numerici ASCII sulla seriale, li converte a integer
   
    //Serial.println("OK, a premuto");
     
     delay(50);   ////<------------------questo delay è indispensabile!!
     if (Serial.available()) {
     
      a = Serial.read();                       
      b = Serial.read();
           
     
      Serial.println(a);                          //debug
      Serial.println(b);                          //debug
     
    }
      if (a=='o' && b=='n') { digitalWrite(LedPin2,HIGH); Serial.println("led 2 ON"); }
      else if (a=='o' && b=='f') { digitalWrite(LedPin2,LOW); Serial.println("led 2 OFF"); }

}
  //*******************************************************
  void Led_3(){  //legge 3 caratteri numerici ASCII sulla seriale, li converte a integer
   
    //Serial.println("OK, a premuto");
     
     delay(50);   ////<------------------questo delay è indispensabile!!
     if (Serial.available()) {
     
      a = Serial.read();                       
      b = Serial.read();                       
     
      Serial.println(a);                          //debug
      Serial.println(b);                          //debug
     
    }
     if (a=='o' && b=='n') { digitalWrite(LedPin3,HIGH); Serial.println("led 3 ON"); }
      else if (a=='o' && b=='f') { digitalWrite(LedPin3,LOW); Serial.println("led 3 OFF"); }
}

Spero di non aver commesso altri errori, non voglio aggiungere confusione al nostro amico Luca con il quale mi scuso per il disguido di ieri sera (sarà stato la stanchezza ) sperando che la risposta di oggi sia migliore a scapito della doppia stanchezza!! (non solo me ne sono andato a letto alle 2, ho preso sonno verso le 3 ed un rompi...  di vicino si è messo a fare il fabbro a tagliare metallo con il Flex alle 5!! )

 

nel codice precedente, se vuoi aggiungere altri comandi, basterà aggiungerli nel ciclo if con un'altro (od altri) "else if" , ovviamente se prevedi diversi led che si possano accendere o spegnere, dovrai fare qualcosa del tipo --> 'Led1on"  considera però la lunghezza della stringa, prende del tempo trasmetterle ed occupano anche più memoria (flash e di RAM), quindi se il tuo programma sarà molto lungo, tieni a mente ciò.  In alternativa, potresti fare --> 1on, 1off, 2on, 2off ...  o ancora più abbreviato 1n (n come on), 1f(f come off) cosy occupi solo 2 byte.

Ciao, io non sono un'esperto ma credo di poterti aiutare visto che sto "giocando" con questo argomento ultimamente. Allora, innanzitutto, devi stabilire i comandi, tieni a mente che la sintassi deve coincidere anche nelle minuscole/maiuscole, poi nella function loop() metti qualcosa come segue:

Code:

if (Serial.available() )
  { ser=Serial.read();
    if(ser=='on')
    {
      //<<<<qui devi mettere il tuo codice
    }
 
    else if (ser== 'off')
    {
      //<<<<qui devi mettere l'alternativa in caso di comando "off"
     }
   
  }
 
}

ovviamente, la variabile "ser" la dovrai dichiarare dove ti serve, global (in questo caso) o locale se sarà vista solo all'interno del loop, in questo caso, visto che servirebbe solo per sapere i comandi in arrivo, potrebbe benissimo essere locale.


spero ti essere stato d'aiuto e abbastanza chiaro.

ciao!

Basta non spostare i fili mentre la scheda è alimentata... 

Certamente, ma se tra una selva di fili volanti, capita di far spostare uno dalla sua posizione?  Purtroppo può capitare, togliere l'alimentazione ogni volta che si apporta una modifica non è sempre una scelta pratica, ma effettivamente, riduce i pericoli, per fortuna, ora il pericolo è stato eliminato alla base, le breadboard sono alimentate a 5V quindi nessun pericolo per la UNO, qualche pericolo concreto per la DUE ma per ora non me ne preoccupo molto, no ho ancora una DUE, anzi, per ora l'ho accantonata propio per la sua "diversità" di alimentazione rispetto ai canonici 5V.

 hai mai pensato di usare la vetroresina o il carbonio  ? entrambi usati in "stoffa" sagomati ed induriti con punti di carico specifici a seconda del bisogno ?

Ne abbiamo già parlato, a parte i costi c'è il "piccolo" problema che serve uno stampo per produrre degli oggetti finiti, serve pure una bella attrezzatura, tra cui una pompa a vuoto, molta abilità che si assume solo con l'esperienza, non ultimo il fatto di lavorare con sostanze tossiche/puzzolenti che richiedono ambienti lavorativi dedicati e idonee protezioni personali.
Su questo argomento parlo con cognizione di causa visto che in passato mi realizzavo da solo le fusoliere in fibra per gli elicotteri, so bene quanto è complesso il lavoro e quanto tempo/denaro ho dovuto investire prima di ottenere risultatati decenti.

quoto Astrobeed, i materiali compositi sono fantastici ma richiedono costi elevati, tempi lunghissimi ed operazioni ben pianificate, e solo l'esperienza garantisce risultati eccellenti, anch'io ne so qualcosa, quindi quando l'ho nominato in questo toic l'ho fatto per aggiungere alla lista una serie di materiali, ma ovviamente, va oltre le necessità base che un materiale per prototipazione deve avere, ovvero: costo contenuto, facilità d' uso e velocità di applicazione senza dimenticare i fattori sicurezza.  Fino ad adesso, sembra che il PVC espanso in lastre riassume tutte queste qualità.

Magari se un giorno a qualcuno gli verrà il desiderio di crearsi un quadcorter che debba avere resistenze particolari agli urti, sarà necessario prendere in considerazione anche questi materiali compositi.

PS. la pompa di vuoto non è indispensabile, dipende dal tipo di manufatto che si richiede o dal grado di precisione/perfezione/compattezza meccanica necessari per tale pezzo.  Io c'è l'ho, ma non la uso quasi mai, ma esistono pezzi che senza la lavorazione a vuoto non li fai (decentemente).  Per esempio, per fare delle lastre, come quelle già pronte vendute in siti come Jonathan (o qualcosa del genere) possono essere realizzate in casa (con un minimo di manualità e chiaro senza tralasciare la sicurezza ovviamente) con due piastre di materiale liscio e ben piatto, del tipo due lastre di vetro (quelle delle cornici dei quadri economici per esempio), foderate da una pellicola plastica trasparente (anche quella per alimenti va bene), incerare con cera per auto (non è indispensabile perchè la resina epoxy o poliestere non attacca molto su plastiche come quella per alimenti, ma avvolte comunque oppone una certa resistenza allo staccarsi, quindi un po di cera facilita il compito), spargere un po di resina su una delle superfici, applicarvi il pezzo di stoffa di vetroresina o carbonio o kevlar ben inbevuto di resina facendo attenzione a far uscire le bolle d'aria intrappolate tra le fibre picchettando con il pennello (e se si ha, un rullo frangibolle) applicare i vari strati richiesti, poi appoggiarci la seconda lastra protetta come quella base, facendo pressione uniformemente, magari con delle morse o qualche peso, tenendo conto dello schiacciamento in ogni lato per far si che sia omogeneo (meglio ancora, con degli spessori ai 4 lati delle due piastre che formano il "sandwich", ad asciugamento avvenuto (dipendente dalla temperatura ambiente e dalla resina utilizzata, resina polyestere = circa 8 h a 20°C se più caldo, cura in meno tempo, se più freddo viceversa, per la resina epoxy i tempi sono maggiori, circa 8-24h a 20°C ma a 14-15°C può volerci anche 36 ore).  Una volta asciugata bene la resina, procedere cautamente allo stacco delle due lastre, se avete messo le pellicole plastiche, si toglierà facilmente, il manufatto sarà inglobato tra queste due pellicole, separatele delicatamente, avrete il manufatto bello liscio e con poche bolle (senza la pompa di vuoto è difficile riuscirci al 100%) basterà poi tagliare gli eccessi di resina colata nei 4 lati del manufatto con segnetto o elettroutensile (indossare guanti occhiali ed indumenti protettivi, questa fase è delicata).

Come detto però, per prototipare, niente meglio del PVC espanso, costa poco, pesa poco, facile da tagliare ed incollare, non richiede attrezzi particolari ed in 30 minuti si è già operativi, nessun altro materiale qui trattato ha tutti questi pregi.

 

Fin' ora, l'unica cosa che so per esperienza, è che si bruciano solo se in un pin ADC/digitale (o qualsiasi a sto punto) malauguratamente gli viene alimentato a 12V!!  alcuni anni fa ho avuto una doppia "disgrazia" con dei moduli Basicx BX24, avevo una breadboard alimentata con un trasformatore da parete a 12v, poi un regolatore di tensione a 5v ed i canonici condensatori e quindi avevo da un lato della breadboard la linea 12V - GND e dall'altra 5V - GND, poi dalla breadboard (lato 5V) alla scheda del modulo Bx24 che ha già onboard un regolatore tensione (5V), tutto ok per più di un paio d'anni, poi un giorno, stavo spostando uno dei fili volanti di un channel ADC, malauguratamente mi è caduto... dove? esattamente dentro uno dei pin della 12v sulla breadboard!!  MANNAGGIA !!!  BX24 defunto.  Ne comprai un'altro e questo fece la stessa fine dopo pochi mesi, da lì ho imparato la DURA lezione, adesso ho schermata la zona delle tensioni over 5V, con tanti pin dove poteva entrarci e non fare danni.  Ma proprio nella fila dei 12V doveva capitare? e su due MCU (dal costo complessivo di oltre 120 €!!) ?
Bèh, e per questo che si dice, sbagliando s'impara! e che sbaglio!!  Adesso con Arduino ho fatto un'altro upgrade nella sicurezza, ho un'alimentazione a 5V sulla breadboard, quindi un rischio in meno!

Ho anche pianificato di mettere un condensatore vicinissino al piedino di alimentazione del MCU come consigliato su svariati siti dove ho cercato info.

Ogni integrato attivo dovrebbe avere un C da 0.1uF (100nF) ceramico posto tra il pin VCC e GND.

hai ragione Leo, è propio il valore che mi è stato consigliato, servirebbe a ridurre le oscillazioni di tensione in frequenza sul pin di VCC della MCU, ma essendo che non è sufficiente, questa volta voglio andarci con più prudenza ed usare un MOV o un TVS, ho letto un pochino e sono ottimi per la protezione contro picchi di tensione molto veloci, pensa che il primo tipo, l'ho trovato in un circuito aftermarket basato su PIC e che non aveva nemmeno un regolatore di tensione!  il clamping a 5V lo faceva un semplice zener da 5,1V, qualche resistenza e un MOV, e devo essere sincero, di quanti ne ho visti montati, funzionano tutti, nessuno si lamenta, quindi, immagino funzioni  bene in ambito automotive l'uso dei MOV, di fatti, adesso che li conosco, li riconosco anche in altri prodotti automotive, sapete, man mano che la propia conoscenza aumenta, si fanno nuove scoperte (con anni di ritardo, ma meglio tardi che mai!!) quando mi capita qualche centralina aperta per mani, tento sempre di identificare la componentistica.

La cosa buffa di questi problemi che sperimentai su quella vettura è che ho tentato in tutti i modi di riprodurre il difetto a banco ma dopo ore ed ore di prove, metti e togli l'alimentazione bruscamente, fagli scendere la tensione, ecc, non sono riuscito a farlo andare in tilt.  Certo, le sollecitazione EMI della vetture sono maggiori di quelle a banco. Spero che pronto potrò ripartire con i test, magari su un'altra vettura.

Astrobeed, sarà pure del 2007 ma a me sembra fantastico!

Lesto, ecco adesso capisco la ragione del m^3 !! 

Per i condendatori non saprei, ma per gli optoisolatori almeno in quel progetto, non ne avrei avuto necessità anche se in effetti, uno c'è n' era ed era nel circuito di rilevamento segnale giri motore (da ECU da competizione, pullup 12v ,segnale gnd-> giri) e funzionava egregiamente, gli altri due erano analogici, ma ben isolato dalla MCU, ogni segnale aveva il suo circuito di condizionamento-filtraggio, l'ho copiato dalla megasquirt, mi ha funzionato bene per 3 corse, poi si è piantato.  Adesso ho letto su questi MOV (Metal oxide Varistor) e TVS (Transient Voltage Suppressor diode) sono due soluzioni diverse per gli spikes di tensione, i primi sono più lenti, i TVS hanno tempi di risposta molto più veloci.  Ho anche pianificato di mettere un condensatore vicinissino al piedino di alimentazione del MCU come consigliato su svariati siti dove ho cercato info.

appunto, hai usato i canonici 4 condensatori in un ambiente che sapevi necessitare di un sistema di filtrazione del segnale assai più complessa... quindi è stato un tuo errore di progettazione.

gli sbalzi di tensione se non correttamente gestiti possono anche friggertelo il micro e il regolatore, quindi occhio

qualche suggerimento?   Per i prossimi progetti ho intenzione di inserirvi un MOV o un TVS, cosa ne pensi?

Astrobeed, Belli sti telai per robot, veramente interessanti!  mi fa piacere di sentito parlare del PVC espanso, lo conoscevo ma povo e non pensavo fosse così versatile per lavoretti del genere. mmmm

Lesto, ma allora veramente vuoi comprare 1m^3 di PVC ?  pensavo che stavi scherzando!  le 6 piastre e per realizzare un cubo da 1 m di lato, non un cubo pieno (che poi peserebbe sui 650 kg) se poi il tuo calcolo si riferiva al costo a m^3, beh allora scusami, avevo capito male!!