test della porta seriale

[Marco Clocchiatti]

ho scritto questo script minimale per testare la porta seriale:

/* test porta seriale */

void setup()

{

  Serial.begin(115200);

}

void loop()

{

  int serialBuffSize;

  char incomingByte;

  if (serialBuffSize=Serial.available()>0) {

    incomingByte = Serial.read();

    Serial.print("dimensione buffer: ");

    Serial.println(serialBuffSize);

    Serial.print("Ho ricevuto: ");

    Serial.println(incomingByte);

    Serial.flush();

    Serial.print("Serial.available: ");

    Serial.println(Serial.available());

  }

  delay(1000);

}

Nelle mie intenzioni, lo sketch dovrebbe ciclare a vuoto fino alla ricezione di un input, poi stampare secondo le istruzioni del blocco if fino allo svuotamento dell'input seriale, quindi rimettersi in attesa.

come test, dopo l'upload, ho aperto un cat:

[code]

cloc3@dell ~/arduino/serial $ cat /dev/arduino &

[2] 4630

cloc3@dell ~/arduino/serial $ echo "a" >/dev/arduino

cloc3@dell ~/arduino/serial $ dimensione buffer: 1

Ho ricevuto: f

Serial.available: 33

dimensione buffer: 1

Ho ricevuto: f

Serial.available: 63

dimensione buffer: 1

Ho ricevuto: e

Serial.available: 63

dimensione buffer: 1

Ho ricevuto: r

Serial.available: 62

dimensione buffer: 1

....

[/code]

tutto questo mi sembra molto strano: la porta seriale sembra non svuotarsi e cambiare continuamente contenuto.

è corretto che questo accada?

come si dovrebbe fare, per ottenere il comportamento che mi aspetterei?

[Bissa Orboea]

NOn sono un esperto, ma temo che il significato di Flush sia cambiato:

http://arduino.cc/en/Serial/Flush

Attende la trasmissione de dati in uscita (prima di arduino uno puliva il buffer in entrata).

Bye

--
--
----
Per mandare un messaggio al gruppo "Treviso Arduino User Group", invialo a:
treviso_ardui...@googlegroups.com
Per annullare l'iscrizione a questo gruppo, invia un'email a:
treviso_arduino_use...@googlegroups.com
Per altre informazioni, visita la url:
http://groups.google.com/group/treviso_arduino_user_group
 
---
You received this message because you are subscribed to the Google Groups "Treviso Arduino User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treviso_arduino_use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Marco Clocchiatti]

grazie.

ma l'istruzione flush che ho inserito non è essenziale.

la mettevo lì per sicurezza e per mostrare che, comunque, non funziona ai miei scopi.

da quello che capisco (sono nuovo anche io al mondo di Arduino), il buffer in uscita dovrebbe svuotarsi spontaneamente dopo ogni singolo accesso in lettura, un carattere alla volta. io inoltro con echo un singolo carattere, dunque mi attendo che il buffer si svuoti dopo un solo ciclo, riprendendo a ciclare fuori dal blocco if..

al contrario, il buffer non si svuota, ma assume addirittura valori variabili di cui non capisco l'origine.

da cosa dipende tutto ciò?

treviso_arduino_user_group+unsub...@googlegroups.com

Per altre informazioni, visita la url:
http://groups.google.com/group/treviso_arduino_user_group
 
---
You received this message because you are subscribed to the Google Groups "Treviso Arduino User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to treviso_arduino_user_group+unsub...@googlegroups.com.

[Mirco Piccin]

Marco,

>>> tutto questo mi sembra molto strano: la porta seriale sembra non
>>> svuotarsi e cambiare continuamente contenuto.
>>> è corretto che questo accada?
>>> come si dovrebbe fare, per ottenere il comportamento che mi aspetterei?

guarda che tutto funziona a dovere (2009 e UNO):

mirco@pinta64:~$ cat /dev/ttyUSB0 &
[1] 17633
mirco@pinta64:~$ echo "a" > /dev/ttyUSB0
mirco@pinta64:~$ dimensione buffer: 1
Ho ricevuto: a
Serial.available: 1

dimensione buffer: 1
Ho ricevuto:

Serial.available: 0

Quel che guarderei bene è che Serial.available() torna i byte in coda
sulla seriale, e ti torna un sacco di byte.
Inoltre quel che ti passa sono: "ffer" il che mi fa pensare che stai
passando via seriale della schifezza.
"ffer" magari è "buffer": con tutti i byte che ti passa, che viene fuori?

Fai la stessa prova con il monitor seriale di Arduino e con screen.
(screen /dev/arduino 115200)

M

[Marco Clocchiatti]

Il giorno giovedì 5 dicembre 2013 13:37:18 UTC+1, pictux ha scritto:

Marco,

guarda che tutto funziona a dovere (2009 e UNO):

uffa. sono ancora alle prese con le misconfigurazioni della porta seriale da cui combatto da qualche tempo.
per cortesia, puoi postarmi i valori dei seguenti comandi, nella configurazione che a te funziona (con arduino UNO)?

stty -F /dev/arduino -a
stty -F /dev/arduino -g
 

[Marco Clocchiatti]

chissà. forse qui c'è quello che mi serve:

http://playground.arduino.cc/Interfacing/LinuxTTY
stty -F /dev/ttyUSB0 cs8 115200 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts

a prima vista sembra andare.
sono due settimane che mi ci sbatto. speriamo regga.
:)

[Marco Clocchiatti]

ecco. me lo aspettavo.
anche la riga postata sotto funziona solo in certe condizioni.
non era la prima volta, infatti, che adottavo da internet una riga di stty e poi scoprivo che qualche volta si incastra lo stesso.

se, ad esempio, provo ad accedere a /dev/arduino con un programma diverso da cat (stavo utilizzando miniterm.py), scopro che, all'uscita, la seriale viene impostata in un modo che non si sblocca con il comando precedente. alla fine sono arrivato a un'altra riga, che sembra più efficente, almeno per me:

stty -F /dev/arduino 1:0:1cb2:80:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

[Mirco Piccin]

Ciao Marco,
di seguito quanto richiesto:

stty -F /dev/ttyACM0 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke

stty -F /dev/ttyACM0 -g
10:0:18b2:0:3:1c:7f:8:4:0:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Scusa la domanda, ma le modifiche alle porte seriali erano state fatte
volontariamente? A che pro?

M


2013/12/5 Marco Clocchiatti <ziapan...@gmail.com>:

> --
> --
> ----
> Per mandare un messaggio al gruppo "Treviso Arduino User Group", invialo a:
> treviso_ardui...@googlegroups.com
> Per annullare l'iscrizione a questo gruppo, invia un'email a:

> treviso_arduino_use...@googlegroups.com

> Per altre informazioni, visita la url:
> http://groups.google.com/group/treviso_arduino_user_group
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Treviso Arduino User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to treviso_arduino_use...@googlegroups.com.

[Marco Clocchiatti]

Il giorno giovedì 5 dicembre 2013 22:56:24 UTC+1, pictux ha scritto:

Scusa la domanda, ma le modifiche alle porte seriali erano state fatte
volontariamente? A che pro?

no no. mi sono spiegato male.
io ho problemi di stabilità con le porte seriali da quando ho cominciato a lavorare con arduino (cioè non da molto, per la verità).

D'altra parte, al momento della connessione della seriale sull'ingresso usb, il sistema non si autoconfigura in modo automatico, ma assume addirittura una velocità di 9600 byte, per cui il cat non funziona.

in un primo momento, avevo affrontato questo problema cercando nuovi programmi, anziché curarlo alla base studiando l'uso di stty.
così sono arrivato a pyserial, un pacchetto che installa un programma chiamato miniterm.py. miniterm.py ha la capacità di consentire di consentire conemporaneamente sia l'input che l'output verso la seriale, un po' come screen.
questo, però, programma maledettamente la vita al povero nubbio, perché interviene sui parametri della seriale in un modo ancora più invasivo, lasciandola in uno stato che rende apparentemente impossibile utlizzare successivamente cat.

mi sono trovato a lungo, di conseguenza, a trafficare con situazioni di instabilità, come quella che descrivo in questo post, che mi tenevano in costante imbarazzo.
adesso mi sembra che le cose vadano meglio.

ho creato un programmino di shell con la riga di stty postata sopra, lo ho agganciato a una regola di udev e lo posso lanciare ogni volta che un miniterm.py fa qualche danno (ok: fra poco lo disinstallo, il miniterm.py, così impara) per ripristinare le cose in modo stabile.
almeno in apparenza, perché non sono proprio sicuro che, domani, non possa incappare in qualche interferenza diversa. il numero dei parametri gestibili con stty è troppo elevato per fare chiarezza assoluta con strumenti empirici. il fatto che la mia riga sia diversa da quella che tu usi con soddisfazione fa sospettare che, ragionevolmente, almeno uno di noi due abbia un problema di cui non è ancora consapevole.

:)

[Mirco Piccin]

Ciao,

> io ho problemi di stabilità con le porte seriali da quando ho cominciato a
> lavorare con arduino (cioè non da molto, per la verità).

son più di 4 anni che "gioco" con Arduino e Linux, penso di aver visto
parecchie persone usarlo e di averne iniziate altrettante
(personalmente o nel gruppo), ma ti assicuro che mai, dico mai, ci son
stati problemi del genere con la seriale.. anzi solitamente il
connubio Arduino + Linux è il più semplice rispetto agli altri OS :D

Ti dirò poi che la configurazione a basso livello della porta seriale
non l'ho mai fatta e credodi continuare così (funziona as-is di
default).
Una domanda: l'IDE Arduino l'hai installato da repository o lo hai
scaricato dal sito?

M

[Stefanoxjx]

Confermo, anch'io uso arduino+linux e non ho mai avuto problemi.

Il 06/12/2013 09:17, Mirco Piccin ha scritto:
> Ciao,
>

>> io ho problemi di stabilit� con le porte seriali da quando ho cominciato a
>> lavorare con arduino (cio� non da molto, per la verit�).
> son pi� di 4 anni che "gioco" con Arduino e Linux, penso di aver visto

> parecchie persone usarlo e di averne iniziate altrettante
> (personalmente o nel gruppo), ma ti assicuro che mai, dico mai, ci son
> stati problemi del genere con la seriale.. anzi solitamente il

> connubio Arduino + Linux � il pi� semplice rispetto agli altri OS :D
>
> Ti dir� poi che la configurazione a basso livello della porta seriale
> non l'ho mai fatta e credodi continuare cos� (funziona as-is di

> default).
> Una domanda: l'IDE Arduino l'hai installato da repository o lo hai
> scaricato dal sito?
>
> M
>

--
Stefano

[Marco Clocchiatti]

Il giorno venerdì 6 dicembre 2013 09:17:24 UTC+1, pictux ha scritto:

son più di 4 anni che "gioco" con Arduino e Linux, penso di aver visto
parecchie persone usarlo e di averne iniziate altrettante
(personalmente o nel gruppo), ma ti assicuro che mai, dico mai, ci son
stati problemi del genere con la seriale.

leggendo il link che ho postato sopra, però:

 http://playground.arduino.cc/Interfacing/LinuxTTY

si ritrova un paragrafo dedicato ai troubleshootings nel quale sembra proprio che si possa essere risucchiati in problemi simili al mio.

adesso sto giocando con screen, che funziona molto bene e non mi dà nessun problema, ma osservo che l'output del comando:

stty -f /dev/arduino -g

cambia dopo l'accesso a screen.

anche screen, quindi, in qualche modo, modifica lo stato della porta seriale a basso livello in un modo che non è ovvio da controllare per l'utente ingenuo.

per quanto riguarda l'Ide di arduino, non la uso proprio.

uso scons: git://github.com/suapapa/arscons

anche arscons si appoggia a pyserial (quindi non posso disinstallare miniterm.py, come avevo detto prima) come dipendenza.

se il mio problema sta lì, quindi, credo che ci dovrò convivere, perché non mi piace proprio usare la ide di arduino.

[Mirco Piccin]

Ciao,
quanto mi dici conferma quanto detto sopra :)

L'utente "ingenuo" usa IDE Arduino, monitor seriale o al max
putty/gtkterm/screen - e a questi livelli non si incontrano problemi.
Io non mi ritengo un utente ingenuo e con Arduino + Seriale + altro sw
/ hw ho avuto modo di "giocarci" , senza mai riscontrare problematiche
segnalate.

Quando avrai fixato la tua situazione, segnalalo su forum ufficiale o
anche qui, se ti va di condividerlo.

Saluti
M

[Marco Clocchiatti]

Il giorno venerdì 6 dicembre 2013 10:24:13 UTC+1, pictux ha scritto:

Ciao,
quanto mi dici conferma quanto detto sopra :)

L'utente "ingenuo" usa IDE Arduino, monitor seriale o al max
putty/gtkterm/screen - e a questi livelli non si incontrano problemi.

:) hai ragione  lo confesso: voglio tenere i piedi in due staffe.
essere utente ingenuo e scegliere l'ambiente di sviluppo che preferisco, cioè la linea di comando.

al momento, arscons è l'unico software che conosco capace di istruire avrdude a scaricare gli sketch sulla porta seriale, senza usare la ide.
quando lo scelto, non mi aspettavo certo di incappare in simili pasticci.

una parte della colpa è sicuramente mia, ma forse questa ide ufficiale di arduino e un po' un accrocchio pensato male.
lo stesso utente ingenuo, per utilizzarla, è costretto a configurare a mano il file nascosto delle preferenze.

non dovrebbe essere così: arduino dovrebbe offrire un insieme di regole di udev capaci di configurare in modo stabile la seriale all'atto del plugin, mettendo alla pari tutti i software che vi accedono, siano scritti in java, in python o siano semplici tool di base del sistema, impedendo l'insorgere di fastidiosi conflitti.

come tu dici, dovrei postare queste idee direttamente sul forum ufficiale, ma prima avrei bisogno di capire meglio i fenomeni che mi accadono, perché li si espone in lingua proprietaria e bisogna avere idee ben chiare per essere capiti. intanto vi ringrazio dell'ascolto che mi avete offerto.

[Mirco Piccin]

Ciao

> al momento, arscons è l'unico software che conosco capace di istruire avrdude a scaricare gli sketch sulla porta seriale, senza usare la ide.
> quando lo scelto, non mi aspettavo certo di incappare in simili pasticci.

..potresti usare direttamente avrdude.

> una parte della colpa è sicuramente mia, ma forse questa ide ufficiale di
> arduino e un po' un accrocchio pensato male.

uhm

> lo stesso utente ingenuo, per utilizzarla, è costretto a configurare a mano
> il file nascosto delle preferenze.

ovvero? Mi sembra una affermazione falsa, l'utente non deve fare
NIENTE per usare Arduino, se non collegarlo alla porta USB.

> arduino dovrebbe offrire un insieme di regole di udev capaci di configurare in modo stabile la seriale all'atto del plugin,
> mettendo alla pari tutti i software che vi accedono, siano scritti in java, in python o siano semplici tool di base del sistema,
> impedendo l'insorgere di fastidiosi conflitti.

arduino rilascia i driver per Windows (dove servono), dopodichè
utilizza o convertitori FTDI (standard) o convertitori usb2serial
anch'essi standard per cui paga oltretutto licenze per VID/UID,
I conflitti credo te li sia creati tu :)
Io uso Arduino con Java, php, bash script e forse ne dimentico
qualcuno, non ho mai avuto bisogno di accrocchiare alcunchè.

> come tu dici, dovrei postare queste idee direttamente sul forum ufficiale, ma prima avrei bisogno di capire meglio i
> fenomeni che mi accadono, perché li si espone in lingua proprietaria e bisogna avere idee ben chiare per essere capiti.

credo che avresti prima dovuto usare i tools forniti, e una volta
acquisita esperienza e familiarità (con Arduino ma anche con la porta
seriale), appronfondire il tale direzione.

Guarda, davvero in anni di esperienza non ho visto o vissuto
situazioni che tu descrivi, e mi dispace che il tuo primo approccio
con questa scheda sia stato questo.
Spero tu possa ricrederti.
Quando vuoi vieni a trovarci (o passa da Hacklab Udine, che ti
dovrebbe essere più vicino), così puoi confrontarti *live* e con il
pezzo sotto gli occhi!

M

[Marco Clocchiatti]

riprendo questa discussione per segnalare che credo di essere riuscito a trovare una modalità soddisfacente di accedere alla porta seriale di arduino direttamente dalla linea di comando di bash.

fino ad ora, avevo concentrato tutta la mi attenzione sulla configurazione della porta seriale, che è sicuramente un elemento importante, ma non strategico.
in fondo, esistono più configurazioni equivalenti della porta seriale che permettono di lavorare bene con arduino.
un volta individuata una di esse, si può fissarla attraverso il seguente comando:
stty -F /dev/arduino -g
la stringa di ouput permette di creare uno script, attivabile attraverso una istruzione di udev.
da quando mi sono stistemato in questo modo, non ho avuto nuovi problemi di configurazione.

tuttavia, una gestione corretta dell'input output non si ferma a questo unico problema.
il fatto è che per interagire con arduino è necessario fare una certa attenzione alla sequanza dei comandi che devono essere utilizzati.
in genere, l'utente desidera inoltrare una richiesta ad arduino e succesivamente acquisire una risposta.

lato terminale, la richiesta è una operazione di scrittura, cioè un echo.
la risposta, invece, corrisponde a una lettura, cioè un cat (o meglio ancora un head ).

per scambiare dati con arduino, però, è necessario invertire l'ordine di queste due operazioni.
l'utente deve mettersi in ascolto prima di effettuare la richiesta, altrimenti riceve una risposta vuota.
non mi è ben chiaro perché questo accada. probabilmente, il buffer seriale viene svuotato in automatico se l'utente esterno non è attivo in ascolto, allo scopo di non intasare le risorse limitate del sistema.
ne viene che un'operazione di input output deve essere realizzata in questo modo:

head -n 10 </dev/arduino & echo "stringa di richiesta" >/dev/arduino
prima leggere, e poi scrivere!!!

anche così, l'effetto è poco soddisfacente e si ottengono risultati instabili.
il guaio è che l'operazione di lettura (cioè l'head) non funziona allegramente come la lettura di un qualunque file del disco rigido.
in questo caso, è necessario aprire una porta verso un dispositivo esterno, che ha delle latenze di sincronizzazione fisiche, non riproducibili.

il modo corretto di operare, quindi, richiede di separare l'operazione di lettura, in due fasi.
l'apertura della porta fisica e l'ascolto successivo.
la prima fase è quello che in molti linguaggi di programmazione corrisponde a un open. su bash è gestito dal comando nativo exec, con la creazione di un file descriptro dedicato.

exec 5<>/dev/arduino #apre la porta fisica /dev/arduino in lettura e in scrittura, abbinandola al descrittore di file numero 5 (arbitrario, di solito il 5 è libero).
sleep 5 #è necessaria una attesa abbstanza lunga. nel mio sistema 2 secondi è un tempo breve.

successivamente, l'interazione con arduino avverrà in un modo stabile e reattivo:

head -n10 <&5 & echo "stringa di richiesta" >&5

aggiungo uno script elementare di bash con il quale sono riuscito a trasmettere su web in modo efficente i dati della porta seriale di arduino:

$ cat adxlWEb.sh
#!/bin/bash

handle_req()
{
        #read req file proto #inutile con netcat6

        # la risposta deve contenere un header per indurre il browser di includere il contenuto della risposta in una pagina web.
        timestamp=$(date +%s)
        echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nAccess-Control-Allow-Origin: *\r\nKeep-Alive: timeout=2, max=100\r\nConnection: Keep-Alive\r\nTimestamp: ${timestamp}\r\n\r\n"
        head -n 50 <&5 & echo 50 >& 5 #prima leggere e poi scrivere!!!
}

exec 5<>/dev/arduino # aprire la porta in lettura e scrittura.
sleep 5 # attesa, deve essere abbastanza lunga.
typeset -fx handle_req
while  true;do nc -l -p 8000 -e "handle_req" -q1;done # apertura di un servizio web in ascolto
exec 5<&- # chiusura corretta del descrittore di file. in questo script, che è acerbo, è sistemata nel posto sbagliato, perché il while precedente apre un ciclo infinito.