Re: [Avr-list] Problèmes d'UART
Salut Antoine, J'ai pas vraiment trop d'idée non plus. Peut-être que tu peux essayer de remplacer la ligne par: UCSRB |= (1 UDRIE); (UDRIE = Data Register Empty Interrupt Enable) Ca permettra de tester que le tableau uart_reg est bien initialisé, mais j'imagine que c'est bon de ce coté... Une autre possibilité est que le vecteur d'interruption pour Data Register Empty est mal initialisé. Il faut regarder dans la doc pour vérifier à quel numéro ça correspond, et s'assurer que: 1- le numéro est bien le même dans le .h de la libc 2- dans le fichier compiler_files/main.lss, les adresses des vecteurs sont bien initialisés vers la bonne fonction. Si ça aide toujours pas, il faut débugger à la LED et au while(1) avec les interruptions verouillées, mais j'avoue que ça doit pas être terrible... Tiens moi au courant. ++ Olivier Le 28 mai 09 à 17:31, Antoine albertelli a écrit : J'ai ouvert un rapport de bug sur le bugzilla. Après un peu de debug, j'ai trouvé que la ligne qui causait le reset est celle-ci (dans uart_send_nowait.c, ligne 61) : sbi(*uart_regs[num].ucsrb, UDRIE); //FIXME: Apparement le bug est ici T'aurais pas une idée, parce que là je sèche un peu... A+ ___ Avr-list mailing list Avr-list@droids-corp.org CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive WIKI : http://wiki.droids-corp.org/index.php/Aversive DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/ BUGZILLA : http://bugzilla.droids-corp.org COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
Re: [Avr-list] Problèmes d'UART
J'ai ouvert un rapport de bug sur le bugzilla.
Après un peu de debug, j'ai trouvé que la ligne qui causait le reset est
celle-ci (dans uart_send_nowait.c, ligne 61) :
sbi(*uart_regs[num].ucsrb, UDRIE); //FIXME: Apparement le bug est ici
T'aurais pas une idée, parce que là je sèche un peu...
A+
Le 26 mai 2009 22:58, Antoine albertelli antoinea...@gmail.com a écrit :
En fait, à l'émission, le 1er caractère passe, mais les suivants ne passent
jamais et le uc fait un reset. Bon sinon c'est pas trop grave, de toute
façon je passe bientôt au 128, parce que le 168, pour faire tourner un
asserv, c'est chaud quand même :D
A+
Le 26 mai 2009 22:44, Olivier MATZ z...@droids-corp.org a écrit :
hmmm j'ai pas trop d'idée là comme ça...
je pensais d'abord à un dépassement de pile : le uC a
1024 octets de RAM et 128 sont utilisés pour les fifo
d'émission / réception. Celà dit s'il n'y a que ça
comme code, je n'y crois pas trop.
Que se passe-t-il exactement lorsque tu émets ? Est-ce
que tu vois quelques caractères sortir avant le reset ?
Est-ce que tu peux reproduire le problème en émettant
juste un seul caractère ?
J'ai testé le module UART sur atmega8, 32, 128 et 2560.
Il se peut que ça déconne sur un 168... Jette à tout
hasard un coup d'oeil aux valeurs des vecteurs
d'interruptions dans iom168.h. Tu peux aussi essayer
de configurer l'uart à la main, et comparer les valeurs
des registres. Il est possible qu'il y ait un bug dans
le module...
Oliv
Antoine albertelli wrote:
le voilà :
#ifndef UART_CONFIG_H
#define UART_CONFIG_H
/*
* UART0 definitions
*/
/* compile uart0 fonctions, undefine it to pass compilation */
#define UART0_COMPILE
/* enable uart0 if == 1, disable if == 0 */
#define UART0_ENABLED 1
/* enable uart0 interrupts if == 1, disable if == 0 */
#define UART0_INTERRUPT_ENABLED 1
#define UART0_BAUDRATE 38400
/*
* if you enable this, the maximum baudrate you can reach is
* higher, but the precision is lower.
*/
#define UART0_USE_DOUBLE_SPEED 0
//#define UART0_USE_DOUBLE_SPEED 1
#define UART0_RX_FIFO_SIZE 64
#define UART0_TX_FIFO_SIZE 64
//#define UART0_NBITS 5
//#define UART0_NBITS 6
//#define UART0_NBITS 7
#define UART0_NBITS 8
//#define UART0_NBITS 9
#define UART0_PARITY UART_PARTITY_NONE
//#define UART0_PARITY UART_PARTITY_ODD
//#define UART0_PARITY UART_PARTITY_EVEN
#define UART0_STOP_BIT UART_STOP_BITS_1
//#define UART0_STOP_BIT UART_STOP_BITS_2
/* same for uart 1, 2, 3 ... */
Le 26 mai 2009 22:21, Olivier MATZ z...@droids-corp.org
mailto:z...@droids-corp.org a écrit :
Salut Antoine,
Tu pourrais envoyer ton fichier uart_config.h aussi ?
Olivier
Antoine albertelli wrote:
Hello,
Voilà, j'ai faits quelques tests du module UART de Aversive, et
j'ai des
petits bugs. Tant que je n'active pas les interrupts, tout va très
bien.
Mais dés que je mets un sei() pour utiliser le scheduler, le
module UART
déclenche ce que je pense être un reset du processeur... une idée
?
Merci pour votre attention
Antoine
P.S. : Je travaille sur Atmega168, et voici mon code (tiré en
grande
partie du code microb 2009) :
int main(void) {
sbi(DDRB,5);
/* Met la LED en sortie. */
uart_init();
fdevopen(uart0_dev_send, NULL);
sei(); /* BUG. */
for(counter = 0;counter 5;counter++) { // chenillard pour le
reset
BIT_TOGGLE(PORTB,5);
wait_ms(500);
}
for(;;) printf_P(PSTR(Dass das Gluck deinen Haus
setzt.\r\n));
return 0;
}
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB :
http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Re: [Avr-list] Problèmes d'UART
Salut Antoine,
Tu pourrais envoyer ton fichier uart_config.h aussi ?
Olivier
Antoine albertelli wrote:
Hello,
Voilà, j'ai faits quelques tests du module UART de Aversive, et j'ai des
petits bugs. Tant que je n'active pas les interrupts, tout va très bien.
Mais dés que je mets un sei() pour utiliser le scheduler, le module UART
déclenche ce que je pense être un reset du processeur... une idée ?
Merci pour votre attention
Antoine
P.S. : Je travaille sur Atmega168, et voici mon code (tiré en grande
partie du code microb 2009) :
int main(void) {
sbi(DDRB,5);
/* Met la LED en sortie. */
uart_init();
fdevopen(uart0_dev_send, NULL);
sei(); /* BUG. */
for(counter = 0;counter 5;counter++) { // chenillard pour le reset
BIT_TOGGLE(PORTB,5);
wait_ms(500);
}
for(;;) printf_P(PSTR(Dass das Gluck deinen Haus setzt.\r\n));
return 0;
}
___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
Re: [Avr-list] Problèmes d'UART
hmmm j'ai pas trop d'idée là comme ça...
je pensais d'abord à un dépassement de pile : le uC a
1024 octets de RAM et 128 sont utilisés pour les fifo
d'émission / réception. Celà dit s'il n'y a que ça
comme code, je n'y crois pas trop.
Que se passe-t-il exactement lorsque tu émets ? Est-ce
que tu vois quelques caractères sortir avant le reset ?
Est-ce que tu peux reproduire le problème en émettant
juste un seul caractère ?
J'ai testé le module UART sur atmega8, 32, 128 et 2560.
Il se peut que ça déconne sur un 168... Jette à tout
hasard un coup d'oeil aux valeurs des vecteurs
d'interruptions dans iom168.h. Tu peux aussi essayer
de configurer l'uart à la main, et comparer les valeurs
des registres. Il est possible qu'il y ait un bug dans
le module...
Oliv
Antoine albertelli wrote:
le voilà :
#ifndef UART_CONFIG_H
#define UART_CONFIG_H
/*
* UART0 definitions
*/
/* compile uart0 fonctions, undefine it to pass compilation */
#define UART0_COMPILE
/* enable uart0 if == 1, disable if == 0 */
#define UART0_ENABLED 1
/* enable uart0 interrupts if == 1, disable if == 0 */
#define UART0_INTERRUPT_ENABLED 1
#define UART0_BAUDRATE 38400
/*
* if you enable this, the maximum baudrate you can reach is
* higher, but the precision is lower.
*/
#define UART0_USE_DOUBLE_SPEED 0
//#define UART0_USE_DOUBLE_SPEED 1
#define UART0_RX_FIFO_SIZE 64
#define UART0_TX_FIFO_SIZE 64
//#define UART0_NBITS 5
//#define UART0_NBITS 6
//#define UART0_NBITS 7
#define UART0_NBITS 8
//#define UART0_NBITS 9
#define UART0_PARITY UART_PARTITY_NONE
//#define UART0_PARITY UART_PARTITY_ODD
//#define UART0_PARITY UART_PARTITY_EVEN
#define UART0_STOP_BIT UART_STOP_BITS_1
//#define UART0_STOP_BIT UART_STOP_BITS_2
/* same for uart 1, 2, 3 ... */
Le 26 mai 2009 22:21, Olivier MATZ z...@droids-corp.org
mailto:z...@droids-corp.org a écrit :
Salut Antoine,
Tu pourrais envoyer ton fichier uart_config.h aussi ?
Olivier
Antoine albertelli wrote:
Hello,
Voilà, j'ai faits quelques tests du module UART de Aversive, et
j'ai des
petits bugs. Tant que je n'active pas les interrupts, tout va très
bien.
Mais dés que je mets un sei() pour utiliser le scheduler, le
module UART
déclenche ce que je pense être un reset du processeur... une idée ?
Merci pour votre attention
Antoine
P.S. : Je travaille sur Atmega168, et voici mon code (tiré en grande
partie du code microb 2009) :
int main(void) {
sbi(DDRB,5);
/* Met la LED en sortie. */
uart_init();
fdevopen(uart0_dev_send, NULL);
sei(); /* BUG. */
for(counter = 0;counter 5;counter++) { // chenillard pour le
reset
BIT_TOGGLE(PORTB,5);
wait_ms(500);
}
for(;;) printf_P(PSTR(Dass das Gluck deinen Haus setzt.\r\n));
return 0;
}
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
Re: [Avr-list] Problèmes d'UART
En fait, à l'émission, le 1er caractère passe, mais les suivants ne passent
jamais et le uc fait un reset. Bon sinon c'est pas trop grave, de toute
façon je passe bientôt au 128, parce que le 168, pour faire tourner un
asserv, c'est chaud quand même :D
A+
Le 26 mai 2009 22:44, Olivier MATZ z...@droids-corp.org a écrit :
hmmm j'ai pas trop d'idée là comme ça...
je pensais d'abord à un dépassement de pile : le uC a
1024 octets de RAM et 128 sont utilisés pour les fifo
d'émission / réception. Celà dit s'il n'y a que ça
comme code, je n'y crois pas trop.
Que se passe-t-il exactement lorsque tu émets ? Est-ce
que tu vois quelques caractères sortir avant le reset ?
Est-ce que tu peux reproduire le problème en émettant
juste un seul caractère ?
J'ai testé le module UART sur atmega8, 32, 128 et 2560.
Il se peut que ça déconne sur un 168... Jette à tout
hasard un coup d'oeil aux valeurs des vecteurs
d'interruptions dans iom168.h. Tu peux aussi essayer
de configurer l'uart à la main, et comparer les valeurs
des registres. Il est possible qu'il y ait un bug dans
le module...
Oliv
Antoine albertelli wrote:
le voilà :
#ifndef UART_CONFIG_H
#define UART_CONFIG_H
/*
* UART0 definitions
*/
/* compile uart0 fonctions, undefine it to pass compilation */
#define UART0_COMPILE
/* enable uart0 if == 1, disable if == 0 */
#define UART0_ENABLED 1
/* enable uart0 interrupts if == 1, disable if == 0 */
#define UART0_INTERRUPT_ENABLED 1
#define UART0_BAUDRATE 38400
/*
* if you enable this, the maximum baudrate you can reach is
* higher, but the precision is lower.
*/
#define UART0_USE_DOUBLE_SPEED 0
//#define UART0_USE_DOUBLE_SPEED 1
#define UART0_RX_FIFO_SIZE 64
#define UART0_TX_FIFO_SIZE 64
//#define UART0_NBITS 5
//#define UART0_NBITS 6
//#define UART0_NBITS 7
#define UART0_NBITS 8
//#define UART0_NBITS 9
#define UART0_PARITY UART_PARTITY_NONE
//#define UART0_PARITY UART_PARTITY_ODD
//#define UART0_PARITY UART_PARTITY_EVEN
#define UART0_STOP_BIT UART_STOP_BITS_1
//#define UART0_STOP_BIT UART_STOP_BITS_2
/* same for uart 1, 2, 3 ... */
Le 26 mai 2009 22:21, Olivier MATZ z...@droids-corp.org
mailto:z...@droids-corp.org a écrit :
Salut Antoine,
Tu pourrais envoyer ton fichier uart_config.h aussi ?
Olivier
Antoine albertelli wrote:
Hello,
Voilà, j'ai faits quelques tests du module UART de Aversive, et
j'ai des
petits bugs. Tant que je n'active pas les interrupts, tout va très
bien.
Mais dés que je mets un sei() pour utiliser le scheduler, le
module UART
déclenche ce que je pense être un reset du processeur... une idée ?
Merci pour votre attention
Antoine
P.S. : Je travaille sur Atmega168, et voici mon code (tiré en
grande
partie du code microb 2009) :
int main(void) {
sbi(DDRB,5);
/* Met la LED en sortie. */
uart_init();
fdevopen(uart0_dev_send, NULL);
sei(); /* BUG. */
for(counter = 0;counter 5;counter++) { // chenillard pour le
reset
BIT_TOGGLE(PORTB,5);
wait_ms(500);
}
for(;;) printf_P(PSTR(Dass das Gluck deinen Haus
setzt.\r\n));
return 0;
}
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB :
http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org mailto:Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
___
Avr-list mailing
