[MontelLUG] I misteri del reindirizzamento [WAS:] Programma per openwrt
Samuele
samuele.zanin a tiscali.it
Dom 4 Maggio 2014 15:01:51 CEST
On 07/04/2014 22:33, Samuele wrote:
> On 03/04/2014 15:59, Diego wrote:
>
> Per catturare i dati, vedo che basta un
>
> cat /dev/ttyACM0 > /tmp/fuffa.bin
[cut].
> 3 file su 4 li ho letti senza problemi, sul primo, ogni tanto leggevo
> dati assurdi. Io sparo una sequenza di interi da 4 byte. Alcuni numeri
> sono coerenti, altri sono del tutto sballati.
> Mercoledì sera spero di non avere casini extra e poter fare ulteriori prove.
Sono approdato ad una soluzione che sembra stare in piedi, ma ci sono
delle cose strane, che forse i "veteran *nix adminin" sanno spiegare.
Dopo un mese di prove, riprove ecc. (thread su ml degli arduinisti che
dovrò completare con gli ultimi 4 giorni di prove) con dati corrotti che
venivano loggati sul file sono arrivato a:
# cat /dev/ttyATH0 > /tmp/rawdata.bin
File rawdata.bin con ogni tanto qualche byte mancante.
Ho gestito in un modo molto banale la ritrasmissione di eventuali byte
mancanti, per capire quali byte mancavano, risparavo indietro
all'arduino il flusso che ricevevo:
# cat /dev/ttyATH0 | tee /dev/ttyATH0 > /tmp/rawdata.bin
Dati corrotti ancora. Il fatto che l'arduino non si impallasse, [1] vuol
dire che riceva indietro il byte trasmesso. Quindi c'è qualche problema
nel salvataggio.
Ho provato ad invertire:
# cat /dev/ttyATH0 | tee /tmp/rawdata.bin > /dev/ttyATH0
Stessa solfa. E stessi numeri corrotti.
Con caratteri ascii alfabetici e numerici (da 0 a 9 e da A a z) nessun
problema. Io invece sparavo byte grezzi, corrispondenti ad interi.
Ad un certo punto noto che i byte mancanti avvengono quando il programma
sta trasferendo certe sequenze di numeri:
tentativo 1:
135106
Dato corrotto.
135704
Dato corrotto.
136503
...
201222
Dato corrotto.
201828
...
266340
Dato corrotto.
266932
...
331702
Dato corrotto.
332500
Dato corrotto.
333099
...
462948
Dato corrotto.
463536
...
528461
Dato corrotto.
529049
tentativo 2 (durato meno):
135176
Dato corrotto.
135923
Dato corrotto.
136482
tentativo 3:
70150
Dato corrotto.
70891
...
135161
Dato corrotto.
135909
Dato corrotto.
136470
...
201279
Dato corrotto.
202022
...
266373
Dato corrotto.
286720
...
331839
Dato corrotto.
332386
Dato corrotto.
333119
...
397856
Dato corrotto.
398585
Qui c'è puzza di caratteri di controllo interpretati.
Scritto così sembra funzionare:
# cat /dev/ttyATH0 | tee /tmp/rawdata.bin | tee /dev/ttyATH0 > /dev/null
Tra i vari tentativi, non ho spento e riacceso l'ap, né toccato i fili
del collegamento seriale.
Qualcuno ha una spiegazione razionale?
Stasera farò ulteriori prove più esaustive per confermare/smentire
quanto scritto.
[1]
void ScriviSeriale(byte Carattere)
{
int x;
int IncomingByte;
boolean Letto = false;
//Svuoto il buffer in ricezione
while (Serial.available() > 0)
{
IncomingByte = Serial.read();
}
//Continuo a scrivere fintanto che non leggo il carattere;
while (!Letto)
{
x = 0;
while (x == 0)
{
//Ritorna il numero di byte scritti
x = Serial.write(&Carattere, 1);
}
Serial.flush();
delay(50);
if (Serial.available() > 0)
{
IncomingByte = Serial.read();
Letto = true;
//Per essere veramente paranoico, dovrei controllare di leggere
//lo stesso byte che scrivo. Per il momento mi può bastare.
}
}
}
More information about the montellug
mailing list