ElectroYou

Ciao a tutti,
Scrivo perché mi succede qualcosa di strano che non riesco a capire.

L'intenzione è di far leggere dei valori a un pic18f46k22 e trasmetterli via usart a un Raspberry, questi valori sono inviati all'interno di byte e quindi variano da 0 a 255.

Se io invio dal PIC un byte con valore decimale 5, raspberry riceve un byte con valore 5, e così per tutti i valori possibili da 0 a 255;

TRANNE per il valore 13, se io invio un byte con valore 13 raspberry lo riceve con valore 10 !!!

A voi è masi successo? Avete qualche consiglio Ciao Ivo

Che strano !

Hai programmato la ricezione in C ?
Posta il codice magari.

Ciao.
Simo

Uhm ...
il 13 è il <CR>
il 10 è <LF>
<CR><LF>
mi dice qualcosa ...

Ciao,

Questo è uno stralcio del codice in c di raspberry

Codice: Seleziona tutto

// ************************** Dichiarazioni per trasmissione SERIALE

#define PORT "/dev/ttyAMA0"   // Device name
#define SPEED B115200         // Velocità banda
int Seriale;         // Serial handler
unsigned char buffer[50];   // Data buffer (Rx)
unsigned char ch_out[20];   // Dati in uscita

//**************************** CONFIGURAZIONE

int Configura_e_apri_seriale(void)
{struct termios tty;          // Device descriptor
 
Seriale = open (PORT, O_RDWR);    // Apre collegamento seriale

if (Seriale < 0)
          {printf ("Error %d opening %s: %s\n", errno, PORT, strerror (errno));
           return (-1);
          }

memset (&tty, 0, sizeof tty);
if (tcgetattr (Seriale, &tty) != 0)
        {printf("ERROR! %s\n", strerror(errno));
         return (-1);
        }

cfsetospeed (&tty, SPEED);                      // Set output speed
cfsetispeed (&tty, SPEED);                      // Set input speed
tty.c_cflag = (tty.c_cflag & ~CSIZE) | CS8;     // 8-bit chars
tty.c_iflag &= ~IGNBRK;                         // Disable break processing
tty.c_lflag = 0;                                // No signaling chars, no echo, no canonical processing
tty.c_oflag = 0;                                // No remapping, no delays
tty.c_cc[VMIN]  = 0;                            // Read doesn't block
tty.c_cc[VTIME] = 5;                            // 0.5 seconds read timeout
tty.c_iflag &= ~(IXON | IXOFF | IXANY);         // No xon/xoff ctrl
tty.c_cflag |= (CLOCAL | CREAD);                // Ignore modem controls, enable reading
tty.c_cflag &= ~(PARENB | PARODD);              // No parity
// tty.c_cflag |= 0;
tty.c_cflag &= ~CSTOPB;                         // Set bit stop
tty.c_cflag &= ~CRTSCTS;                        // No gandshake

if (tcsetattr (Seriale, TCSANOW, &tty) != 0)
        {printf("ERROR! %s\n", strerror(errno));
         return (-2);
        }
sleep(1);                                       // Kernel bug workaround - see text       
return (0);
}

//**************************** LETTURA DI 50 CARATTERI
   read (Seriale, buffer, 50);


Questo invece è parte del codice del pic18f46k22 che invia i dati

Codice: Seleziona tutto

void ConfigureUSART1(void)
{
    BAUDCON1bits.BRG16 = 1;
    // 11 520 bps 8 bit + 1 stop
    Open1USART( USART_TX_INT_OFF &
            USART_RX_INT_OFF &      //interrupts su ricezione
            USART_ASYNCH_MODE &
            USART_EIGHT_BIT &
            USART_CONT_RX &
            USART_BRGH_HIGH,
            138 );
}

void InviaDati(void)
{

   for (i=0;i<50;i++){
       Write1USART(ch_out[i]);
       while (Busy1USART());
   }
}


Anche io ho pensato che potesse centrare qualcosa anche il fatto che il tasto invio su certi sistemi vale 10 su altri 13 ma perché dovrebbe variare?

Ciao Ivo

leva ~IXON
Tredici comunque è speciale per read() un po come per Gregory House in House MD

Visto che non hai postato tutto il codice e neanche la parte di stampa è difficile analizzare il problema.
Ma penso che tu invoca una printf con "%s\n" quel \n è il valore 0x0A = 10 LF, il 13 che corrisponde al CR o \r in C.
Se invece la tua printf è "%x\n" e %x stampa un 10 al posto del 13 è molto strano.
Nei sistemi unix (Raspberry è un linux di conseguenza basato su unix) il terminatore di riga è composto da un solo carattere LF 0x0A 10, nei sistemi Mac invece il terminatore di riga è il carattere CR 0x0D 13, nei sistemi dos e windows è composto da 2 caratteri ed è la sequenza \r\n o CR LF.
Ma visto che windows per fortuna non è presente non credo sia questo il caso.
La variazione ci può essere solo se tui hai implementato qualche conversione, comunque senza la parte di codice che stampa la ricezione è un po' difficile dirlo.

Ciao spivo provo anch'io a scrivere la mia anche se, in parte, bobina mi ha anticipato.
Nel codice ci sono solo output(s) per gli errori ma non si vede quello del buffer (mi pare).
I caratteri spediti dal PIC, dalla parte del lampone come vengono visualizzati/riscontrati ?
Hai veramente provato a spedire "tutti" i valori, da 0 a 255, e altrettanti ne hai riscontrati (a parte l'eccezione) ?

Saluti

Ciao,
ho provato sia ad eliminare IXON | che a commentare tutta la riga

Codice: Seleziona tutto

tty.c_iflag &= ~(IXON | IXOFF | IXANY);         // No xon/xoff ctrl

il programma funziona lo stesso ma l'errore rimane.

La visualizzazione di raspberry è questa:

Codice: Seleziona tutto

   // visualizza lettura SERIALE
   printf("\x1b[5;1H>>");   
   for(ii=0;ii<50;ii++)
   {
   printf("%i ",buffer[ii]);
   }


comunque non è solo un errore di visualizzazione perché se metto un controllo del tipo if(buffer[ii] == 13) la condizione non si verifica anche se il PIC invia il valore 13.
Viceversa ho provato ad inviare una sequenza di byte da raspberry al PIC e se condiziono l'accensione di un led con la ricezione del valore 13 questa funziona, ma se imposto una specie di echo il byte che ritorna a raspberry è 10

WALTERmwp ha scritto:Hai veramente provato a spedire "tutti" i valori, da 0 a 255, e altrettanti ne hai riscontrati (a parte l'eccezione) ?

Si con molta calma li ho provati tutti e 256, ma l'errore è solo per il 13 che con printf("%i"....) viene visualizzato 10

La print, per i 50 valori, prevede solo uno spazio (mi pare) da interporre rispetto al valore che segue quindi, quando esegui l'output del valore 0x0D (cioè 13, cioè <CR>) cosa vedi ?
C'è un ritorno a capo sulla medesima linea ?
Sembrerebbe una questione relativa all'output a video (immagino) e quindi di "interpretazione" che non dovrebbe operare, quantomeno se non intenzionalmente cercata.
Presumo che il valore 13 gli arrivi correttamente; per confermare questo bisognerebbe posizionare un analizzatore sulla seriale.

Saluti

p.s.
avevo erroneamente riportato 0x0C invece di 0x0D