Xbee - lettura dal seriale

non usare la softwareserial, scariocati la newsoftwareserial

lesto:
non usare la softwareserial, scariocati la newsoftwareserial

E allora, rieccomi qua.
Come vedrete posterò tante immagini per essere più chiaro possibile (non lo farei se non fossi disperato).
La situazione è questa: ho due arduini: uno in standalone con questo regolatore di voltaggio; ed uno attaccato ad una normale scheda arduino sui pin 2 e 3 (usando newsoftserial).
Ora,ho fatto diverse prove:
(le due entrate analogiche sono collegate al GND)
-inviando dallo standalone e ricevendo sulla scheda arduino il risultato è questo. Cioè una ricevuta disordinata e non costante.

-inviando dall'xbee attaccato al computer sulla scheda arduino il risultato è questo. Cioè normale, da aggiustare solo nel codice perchè la lettera viene printata di continuo.

-inviando dalla scheda arduino all'xbee sul computer il risultato è questo. Cioè normale, il "." in byte dovrebbe essere uno 0

E' chiaro che il problema sta nello standalone..ma non capisco dove !

Non prendetemi per scemo..disperato si, ma scemo non ancora.

Vi ringrazio tutti in anticipo e ringrazio lesto per la pazienza ed i consigli

manca la resistenza di pull-up sullo stand alone... da 10kohm sarebe l'ideale, vedi http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard

Uhm. Mi pare tu stia sbagliando protocollo di trasmissione.

Se spedisci Serial.println(qualcosa) è normale che tu abbia tutto messo con i ritorni a capo.
Se spedisci una lettura numerica con Serial.println(valore, BYTE), è normale che ti arrivino caratteri senza senso.
Ad esempio, se spedisci Serial.println(map(AnalogRead(X), 0, 1023, 0, 255), BYTE) e ricevi un carattere casuale è normale perché tu non stai ad esempio spedendo il valore 123 (faccio un esempio) ma spedisci il byte che rappresenta quel valore, ossia il carattere ASCII corrispondente. Per ricevere un numero devi spedirlo come numero, ossia Serial.println(map(ecceccc), DEC).
Quando poi lo ricevi devi rimandarlo a video come lo hai ricevuto, ossia mettere:
while (my.available()) {
Serial.print(my.read(), BYTE);
}

In questo modo ricostruisci ciò che ti arriva come lo hai ricevuto.
Riprendiamo l'esempio di prima. Mettiamo di spedire il numero 123.
Tu lo spedirai come "1"-"2"-"3"-"\n" (parte anche il carattere di ritorno a capo perché hai messo Serial.println)

Quando lo ricevi, leggerai il byte "1" e lo stamperai a video, poi il 2 a seguire, poi il 3 ed infine il ritorno a capo (CHR(13)->\n)

lesto:
manca la resistenza di pull-up sullo stand alone... da 10kohm sarebe l'ideale, vedi http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard

Le resistenze sono solo per i led e il reset.. dove la dovrei mettere io ?

leo72:
Uhm. Mi pare tu stia sbagliando protocollo di trasmissione.

Se spedisci Serial.println(qualcosa) è normale che tu abbia tutto messo con i ritorni a capo.
Se spedisci una lettura numerica con Serial.println(valore, BYTE), è normale che ti arrivino caratteri senza senso.
Ad esempio, se spedisci Serial.println(map(AnalogRead(X), 0, 1023, 0, 255), BYTE) e ricevi un carattere casuale è normale perché tu non stai ad esempio spedendo il valore 123 (faccio un esempio) ma spedisci il byte che rappresenta quel valore, ossia il carattere ASCII corrispondente. Per ricevere un numero devi spedirlo come numero, ossia Serial.println(map(ecceccc), DEC).
Quando poi lo ricevi devi rimandarlo a video come lo hai ricevuto, ossia mettere:
while (my.available()) {
Serial.print(my.read(), BYTE);
}

In questo modo ricostruisci ciò che ti arriva come lo hai ricevuto.
Riprendiamo l'esempio di prima. Mettiamo di spedire il numero 123.
Tu lo spedirai come "1"-"2"-"3"-"\n" (parte anche il carattere di ritorno a capo perché hai messo Serial.println)

Quando lo ricevi, leggerai il byte "1" e lo stamperai a video, poi il 2 a seguire, poi il 3 ed infine il ritorno a capo (CHR(13)->\n)

Io finora pensavo il contrario !
Cioè: stampo in byte sul trasmittente, leggo i byte dal ricevente e poi me li trasformo in decimali interi o caratteri..
ora provo !

Grazie mille :smiley:

sciorty:

lesto:
manca la resistenza di pull-up sullo stand alone... da 10kohm sarebe l'ideale, vedi http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard

Le resistenze sono solo per i led e il reset.. dove la dovrei mettere io ?

se non metti una pull-up sul pin reset (http://arduino.cc/en/Hacking/PinMapping168) per intenderci è il pin sopra TX, il micro continuerà a resettarsi. Le scritte che vedi sono probabilmente le richeste del boot-loader per un nuovo skecth o salti di tensione causati dal riavvio del micro
la resistenza è da 10kohm (ma se non ce l'hai per ora va bene la resistenza più grande che hai) tra il pin reset (che vedo chiamato col nome A6, sicuro sia un atmega 168 o 328P?) e vcc

p.s. il codice dello stand-alone, provalo prima con l'arduino... se funziona sull'arduino, (e non funziona la pull-up sul reset che comunque è obbligatoria se vuoi far funzionare qualcosa) allora il problema deriva da qualche collegamento, anche se non mi pare di vedere altri errori.

leo72:
Uhm. Mi pare tu stia sbagliando protocollo di trasmissione.

Se spedisci Serial.println(qualcosa) è normale che tu abbia tutto messo con i ritorni a capo.
Se spedisci una lettura numerica con Serial.println(valore, BYTE), è normale che ti arrivino caratteri senza senso.
Ad esempio, se spedisci Serial.println(map(AnalogRead(X), 0, 1023, 0, 255), BYTE) e ricevi un carattere casuale è normale perché tu non stai ad esempio spedendo il valore 123 (faccio un esempio) ma spedisci il byte che rappresenta quel valore, ossia il carattere ASCII corrispondente. Per ricevere un numero devi spedirlo come numero, ossia Serial.println(map(ecceccc), DEC).
Quando poi lo ricevi devi rimandarlo a video come lo hai ricevuto, ossia mettere:
while (my.available()) {
Serial.print(my.read(), BYTE);
}

In questo modo ricostruisci ciò che ti arriva come lo hai ricevuto.
Riprendiamo l'esempio di prima. Mettiamo di spedire il numero 123.
Tu lo spedirai come "1"-"2"-"3"-"\n" (parte anche il carattere di ritorno a capo perché hai messo Serial.println)

Quando lo ricevi, leggerai il byte "1" e lo stamperai a video, poi il 2 a seguire, poi il 3 ed infine il ritorno a capo (CHR(13)->\n)

Forse mi sono espresso male, però al momento il problema non è il tipo di dato che ricevo, ma il dato stesso.
Ho messo la pull up come nell'articolo mettendo anche il bottone di reset ed ho usato la newsoft anche per lo standalone. Ho usato questi due codici come da te consigliato:

#include <NewSoftSerial.h>
NewSoftSerial my (3,2);
byte val;
void setup(){
  Serial.begin(9600);
  my.begin(9600);
}
void loop(){
 if(my.available())
  val= my.read();
  Serial.print(val, BYTE);
}
#include <NewSoftSerial.h>
NewSoftSerial my (3,2);

void setup(){
  Serial.begin(9600);
    my.begin(9600);
}
void loop(){
  my.print(map(analogRead(A0),0,1023,0,255),DEC);
  delay(10);  
  my.print(map(analogRead(A1),0,1023,0,255),DEC);
  delay(10);  
}

Adesso i problemi che avevo prima sono in parte risolti (i dati arrivano di continuo), ma ricevo una roba come 025555555555555550000000000000002550000000000000025555555555555000000000000000025555555555555,
che teoricamente sarebbe giusta perchè un'ingresso è sul gnd ed uno sui 5v ma evidentemente ci sono problemi di "tempo" o che so io..

EDIT: Ho tolto la variabile val mettendo Serial.print(my.read(), BYTE); ma, visto che ricevo 0-2-5-5-0-2-5-5-0, ho pensato che ci volesse un separatore in modo da identificare ed unire ciò che ricevo. Ma quando l'ho fatto, ahimè, i valori li ricevo di nuovo a tratti T,T

anzichè usare la my.print usa una my.println, al lato ricezione dovresti vedere il numero inviato seguito da uno \n.

oppure usi my.write, che dovrebbe stampare 2 bute per ogni numero indipendentemente dal valore (in pratica la print converte OGNI CIFRA in una lettera, con la write i dati arrivano "puliti", ma illeggibili da un'essere umano)

lesto:
anzichè usare la my.print usa una my.println, al lato ricezione dovresti vedere il numero inviato seguito da uno \n.

oppure usi my.write, che dovrebbe stampare 2 bute per ogni numero indipendentemente dal valore (in pratica la print converte OGNI CIFRA in una lettera, con la write i dati arrivano "puliti", ma illeggibili da un'essere umano)

Ora provo anche in questo modo, ma se leggi l'edit ho in parte risolto la parte di lettura. Il problema è ancora il fatto che i dati mi arrivino ad intermittenza ed interrompendosi in maniera strana tipo: a0b255a0b25
su di un piedino del pulsante per il reset ho messo il gnd, l'uscita dell'altro piedino finisce nel pin reset dell'atmega e sempre nello stesso pin c'è una resistenza di 10 kohm che viene dai 5 v :confused:

hai messo i gnd dei due arduino insieme?

lesto:
hai messo i gnd dei due arduino insieme?

?

sciorty:

lesto:
hai messo i gnd dei due arduino insieme?

?

domanda stupida da parte mia,stai usando gli xbee.

quegli "a" e "b" che vedo nel tuo esempio, immagino che li avrai aggiunti per capire quando inizia un numero e finisce l'altro..

non capisco cosa intendi per arrivo di dati ad intermittenza. l'interruzione forse deriva dal fatto che spegni il serial monitor?

lesto:

sciorty:

lesto:
hai messo i gnd dei due arduino insieme?

?

domanda stupida da parte mia,stai usando gli xbee.

quegli "a" e "b" che vedo nel tuo esempio, immagino che li avrai aggiunti per capire quando inizia un numero e finisce l'altro..

non capisco cosa intendi per arrivo di dati ad intermittenza. l'interruzione forse deriva dal fatto che spegni il serial monitor?

Si, sono per capire quando inizia un numero e quando finisce l'altro.
Per intermittenza intendo dire che sul serial monitor ricevo
b
2
5
5
[..]
a
0
b
2
5
Qui si ferma(non sempre in un determinato punto)
Aspetto circa 1 secondo e riparte..

uhmmm magari si resetta arduino? se nello stand alone metti il led al pin 13 te ne accorgi perchè quando arduino si resetta il led fa un lampeggio

lesto:
uhmmm magari si resetta arduino? se nello stand alone metti il led al pin 13 te ne accorgi perchè quando arduino si resetta il led fa un lampeggio

Fatto, non è un reset :frowning:

uhmmm fai una bella cosa, ogni liip invia anche un numero che si incrementa ogni loop (usa un unsigned long), poi fai la stessa cosa anche sull'arduino che riceve. in questo modo capiamo chi dei due "rallenta"

lesto:
uhmmm fai una bella cosa, ogni liip invia anche un numero che si incrementa ogni loop (usa un unsigned long), poi fai la stessa cosa anche sull'arduino che riceve. in questo modo capiamo chi dei due "rallenta"

Per "fare la stessa cosa sull'arduino che riceve" intendi inviare da quello che perora sta a ricevere?

no, anche in quello che riceve stampi il numero attuale di loop.
Metti caso che quello che si blocca è il ricevente, se solo quello che invia manda il numero di loop, ti sembrerebbe che il bloccato è il trasmittente. invece se anche il ricevente stampa il numero di loop, noteresti che sì, il trasmittente smette di inviare il numero di loop, ma anche il ricevente smette di farlo..

la cosa ideale sarebbe da testare entrambi contemporaneamente: magari si impallano contemporaneamente!!!

Ma non puoi mettere il codice che stai usando ora?
Senza codice, sappiamo cosa ti fa, ma non come lo fa.

lesto:
no, anche in quello che riceve stampi il numero attuale di loop.
Metti caso che quello che si blocca è il ricevente, se solo quello che invia manda il numero di loop, ti sembrerebbe che il bloccato è il trasmittente. invece se anche il ricevente stampa il numero di loop, noteresti che sì, il trasmittente smette di inviare il numero di loop, ma anche il ricevente smette di farlo..

la cosa ideale sarebbe da testare entrambi contemporaneamente: magari si impallano contemporaneamente!!!

E allora, stavolta quando ho provato i dati arrivavano normalmente. La differenza di collegamento sta solo in un condensatore(che era invertit polarmente) e nella mancanza dei piedini digitali 6 e 9 (troppa rabbia repressa, avrò tolto l'atmega dallo zoccolo con troppa violenza :D). Posso credere fossero quelli ? Io per sicurezza ho fatto un paio di prove perchè a volte me li faceva questi scherzetti ma sembra che si sia aggiustato :!

Edit: NON si è aggiustato:
Nel codice del tc ho aggiunto un "/"+numero che si incrementa ed ho notato questo:
a
0
b
0
/
4
2
7
a
0
b
0
/
a
0
b
0
/
4
4
5

Proprio quando riparte, in numero è incrementato di una ventina.. quindi lo standalone lavora nel frattempo.

Lesto, non ho ben capito la logica di quello che mi proponi tu..ma sul rx il numero che devo printare sul seriale deve essere lo stesso che ricevo dal tx oppure un altro long che creo ? Se la risposta è la seconda.. come faccio a capire da questo chi dei due smette di "funzionare" ?