Errore trasmissione USART byte valore 13

[simo85]

Compila con il flag per abilitare il debugging, esegui il programma con gdb e metti un breakpoint subito dopo lettura, per analizzare il buffer di ricezione.

Sai come si fa vero? Posta qui i risultati.

Altrimenti qui ho descritto brevemente i comandi di base da usare nel debugging, se ti trovi in difficoltà dillo.

Ciao,
Simo

[bobina]

Ho provato il tuo codice con raspberry 2.0 aggiornato all'ultima versione debian ed un PIC 18F27K53, a me è funzionante.
Lato PIC ho un ciclo for da 0 a 255 che scrive sulla seriale e lato raspberry ho questo:

Codice: Seleziona tutto

      #include <stdlib.h>
      #include <sys/types.h>
      #include <sys/stat.h>
      #include <fcntl.h>
      #include <termios.h>
      #include <stdio.h>
      #include <string.h>
      #include <errno.h>

      #define BAUDRATE B115200
      #define MODEMDEVICE "/dev/ttyAMA0"
      #define FALSE 0
      #define TRUE 1

      volatile int STOP=FALSE;

      main()
      {
        int fd,c, res,iNdx;
        struct termios tty,newtio;
        char buf[255];

        fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY );
        if (fd <0) {perror(MODEMDEVICE); exit(-1); }

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

cfsetospeed (&tty, BAUDRATE);                      // Set output speed
cfsetispeed (&tty, BAUDRATE);                      // 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
        tcsetattr(fd,TCSANOW,&tty);

        while (STOP==FALSE) {       /* loop for input */
          res = read(fd,buf,255);   /* returns after 5 chars have been input */

          for(iNdx=0;iNdx<res;iNdx++)
              printf("%x\n",buf[iNdx]);
          //printf(":%s:%d\n", buf, res);
          if (buf[0]=='|') STOP=TRUE;
        }
      }


Scusate se il codice non è indetato, ma ho preso un esempio su internet ed ho sostituito la parte di spivo per l'inizializzazione della seriale. Tutti i byte inviati vengono ricevuti senza nessuna conversione.
Su linux c'è la funziona cfmakeraw che inizializza la seriale per la scrittura/lettura in modalità raw, inizialmente avevo provato questa funzione e funzionava ma dopo provando esattamente il tuo codice ho capito che non era questa la differenza.
Questa parte

tty.c_iflag &= ~(IXON | IXOFF | IXANY);

conviene lasciarla se non implementi il controllo software del flusso dati lato PIC.
Una domanda hai disabilitato la seriale nel file cmdline.txt e inittab giusto? Anche se dovresti avere altri errori in caso contrario

[spivo]

Allora ho fatto qualche prova,
purtroppo non sono riuscito a capire bene come funziona gdb ma ho fatto qualche tentativo via softwere e ho capito che raspberry è proprio convinto di ricevere 10 al posto di 13, e non è un problema di visualizzazione.
Ho anche scoperto che questa è anche una funzione impostabile , l'ho trovato su questo sito http://www.vincenzov.net/tutorial/RaspberryPi/serial.htm dove parla di onlcr.
Il mio problema evidentemente è che non riesco a disattivarla.

ho provato il programma di bobina che funziona, ho anche cambiato PIC ora sto provando con PIERIN
ma l'errore rimane, per la precisione il programma di bobina mi fa ricevere i dati in esadecimale e il risulatto è questo:

Codice: Seleziona tutto

0
1
2
3
4
5
6
7
8
9
a
b
c
a
e
f
10


ricevo due a e nessuna d.

Grazie a tutti per l'aiuto.

[simo85]

Ho anche scoperto che questa è anche una funzione impostabile

Qui, nella man page, cerca per il flag ICRNL.

[bobina]

che distribuzione hai sul tuo raspberry? Lo chiedo per capire le differenze tra me e te. Il mio raspberry è molto base tranne la configurazione di rete il resto non lo mai toccato ed oggi per fare il test ho fatto i cambiamenti su cmdline.txt ed inittab.
Hai provato anche ad invocare cfmakeraw sulla struct tty? Che tra le varie configurazioni rimuove la conversione CR e LF in input.

EDIT
con che privilegi gira l'eseguibile che legge dalla seriale? Io ho usato root e non ho provato con utente con minori privilegi.

[spivo]

che distribuzione hai sul tuo raspberry? Lo chiedo per capire le differenze tra me e te. Il mio raspberry è molto base tranne la configurazione di rete il resto non lo mai toccato ed oggi per fare il test ho fatto i cambiamenti su cmdline.txt ed inittab.
Hai provato anche ad invocare cfmakeraw sulla struct tty? Che tra le varie configurazioni rimuove la conversione CR e LF in input.

EDIT
con che privilegi gira l'eseguibile che legge dalla seriale? Io ho usato root e non ho provato con utente con minori privilegi.

La mia versione è la 2014-12-24-wheezy-raspbian ed anche io non ho fatto molte modifiche

[spivo]

Ho anche scoperto che questa è anche una funzione impostabile

Qui, nella man page, cerca per il flag ICRNL.

Si, ho aggiunto questa riga alla configurazione di tty:
tty.c_iflag &= ~ICRNL
ed ora il programmino di bobina funziona.
GRAZIE

[simo85]

Bravo spivo !

Adesso capisci perché noi amanti del pinguino rompiamo sempre le scatole con sto cacchio di RTFM ?

[bobina]

Ormai il problema è risolto e forse non ha più senso continuare, ma a me è sempre piaciuto capire il perché delle cose. Così ho provato ad analizzare le differenze che c'erano.
Negli script di init la seriale ttyAMA0 non viene toccata così all'avvio la configurazione è questa:

Codice: Seleziona tutto

# stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
-brkint -imaxbel


dopo l'esecuzione del programma postato la situazione è questa:

Codice: Seleziona tutto

# stty -F /dev/ttyAMA0
speed 115200 baud; line = 0;
min = 0; time = 5;
-brkint -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke


Non c'è nessuna traccia del flag ICRNL, però a me non fa nessuna conversione. Sicuramente la differenza è nel kernel. Infatti eseguendo stty sotto strace si capisce che la configurazione viene estratta dal kernel con la syscall ioctl:

Codice: Seleziona tutto

# strace -f stty -F /dev/ttyAMA0
...
open("/dev/ttyAMA0", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3
dup2(3, 0)                              = 0
close(3)                                = 0
fcntl64(0, F_GETFL)                     = 0x20800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
fcntl64(0, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
...


La mia versione è

Codice: Seleziona tutto

# uname -a
Linux raspberrypi 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux


Al momenton non ho capito il perché della differenza però mi piaceva condividere queste informazioni.

[spivo]

Ciao bobina il mio kernel è: Linux raspberry 3.12.35+ #730 PREEMPT ..........
Si ho smanettato un po' con il mio raspberry ma non mi pare di aver mai modificato flag ICRNL.
Una curiosità dopo aver disattivato il flag dal programmino seriale poi posso eseguire lo stesso programmino senza disattivarlo, cioè il flag ICRNL resta disattivato.
Solo quando riavvio torna all'impostazione originaria del mio kerel cioè con ICRNL attivato.
Ciao Ivo