Info stringa seriale

Ciao,
spero di non attirare l'ira di qualcuno, vista la domanda forse banale... :slight_smile:
Sto ricevendo dati da un modulo BlueTooth, 2 cose non mi tornano, il buffer che riceve i dati, quanto è lungo (quanti char)? Ogni dispositivo ha la sua lunghezza o c'è uno standard?
Nel caso del BT, dopo che ha inviato una stringa, termina con \r\n, dopo questi, il buffer viene svuotato? Cioè la lettura seriale termina? Oppure se il BT può anche mandare più righe con la solita lettura? Esempio: datidaleggere\r\naltrodato\r\nterzodato\r\n
In pratica, posso considerare finita la lettura dopo i terminatori? Perchè mi sembra di perdere dei dati...
Grazie

Il modulo BT lo devi considerare UN FILO
… salvo nel caso in cui lo stai programmando con i comandi AT, dove allora è lui che risponde, negli altri casi non fa altro che trasferire in modo trasparente e senza aggiungere o togliere nulla quello che gli viene detto di trasmettere, quindi … guarda chi trasmette cosa sta trasmettendo, no il modulo BT che non c’entra nulla !

Guglielmo

Ciao,
quello ok, e mi funziona... E' che lo sto usando come master, e devo smattare parecchio con i comandi AT per la ricerca degli slave, gli indirizzi, il nome etc Ed è quì che mi serve "prendere" le risposte dal modulo, fare il parsing (che mi è riuscito) etc.

Facendo una verifica di quello che salvo quando leggo la seriale del BT, vedo che non sempre mi salva sul mio array di char i dati, ecco la parte di lettura, c’è qualcosa di sbagliato?

void leggiBT()                            // legge la seriale del BT
{
  for (conta = 0; conta < 40; conta++)    // cancello l'array, svuoto il buffer (mio)
  {
    dato[conta] = 0;
  }
  conta = 0;

  while (Serial1.available())           // Controlla se il bluetooth riceve qualche dato
  {
    c = Serial1.read();                 // Il dato va in una variabile di tipo char
    Serial.write(c);                    // Scrive sul terminale i dati ricevuti
    if ( c != '\n' ) {                  // Ignora i fine linea
      if ( c != '\r' ) {                // Se non ho ricevuto il term CR, accumulo il char
        dato[conta] = c;                // copio il carattere nella mia stringa
        conta++;                        // incrementa di 1
      }
      else
      {
        conta++;
        dato[conta] = '\0';             // inserisco terminatore null
        fatto = true;                   // avviso che ho letto i dati
        
        Serial.print("\r\n");           // ristampo in seriale per vedere cosa ho salvato
        Serial.print("-----dati miei="); // scrivo in seriale il mio salvato dato
        Serial.write(dato);
        Serial.print("\r\n");
      }
    }
  }
}

... può essere il buffer troppo corto, può essere che devi aggiungere una piccola delay() all'interno del loop di lettura, oppure può essere che leggi troppo lentamente e si riempie il buffer della SoftwareSerial (che è solo di 64 caratteri) ... troppe cose possono essere ... ::slight_smile:

Bisogna che ti armi di santa pazienza e fai un "debug" approfondito ...

Guglielmo

Allora, buffer corto no, al max ogni riga è 31 caratteri, non uso la softwareserial, uso arduino due, e come il mega ha altre seriali, uso quelle...
Io sono convinto che anche se il BT invia i terminatori, poi continua a trasmettere, per esempio l'OK, e io fermandomi con i primi terminatori che trovo, perdo i dati successivi della stringa, posso provare a continuare a leggere fino a che non trovo un carattere vuoto?
Grazie

... ma cosa ti importa dei caratteri successivi se hai ricevuto la risposta al tuo comando AT ? Ovvero, o la risposta l'hai ricevuta completa e allora qualsiasi cosa dopo è da scartare, o la risposta l'hai ricevuta incompleta ed allora devi continuare a ricevere ... ::slight_smile:

Quali altre possibilità ci sono ? ? ?

Guglielmo

Faccio un esempio di risposta del BT:

INQUIRING \r\n OK \r\n

Io cercando i terminatori, sul mio array vado a salvare solo la scritta INQUIRING e mi perdo l'OK
Se metto un carattere 0 come fine di ricerca, non lo trova mai, e nemmeno \0, quindi non so come fare a sapere se ha altri dati dopo il 1°, e quando c'è qualcosa che mi serve, lo perdo...

Se la risposta è quella che scrivi, dovrai aspettare la seconda coppia \r\n per considerare terminata la trasmissione ...
... se fai diversamente è sbagliato.

Guglielmo

ma non è sempre doppia la risposta, se io aspetto la doppia coppia, la volta che mi da un parametro solo, non esco mai dalla lettura... provo a cercare un po'...

No, NON hai capito, DEVI differenziare i vari casi e quindi devi parametrizzare la routine di ricezione in modo che riceva la risposta completa, sia che essa sia conclusa con una coppia \r\n sia se ce ne sono due che se ce ne sono 10 !

A secondo del comando, ti studi sul datasheet come è fatta la risposta e adatti la routine per ricevere la risposta a quel comando !

Guglielmo

ah, si complica la cosa, quindi farò diverse routine di lettura a seconda della domanda che faccio...
Ci provo, grazie

thedrifter:
ah, si complica la cosa, quindi farò diverse routine di lettura a seconda della domanda che faccio...

... o un'unica routine "parametrizzata" a cui dici quanti \n\r attendere :slight_smile:

Guglielmo