Salut Olivier,Ton patch marche nickel ! Un bug de moins ;)
A+
Le 29 juin 2009 22:15, Olivier MATZ a écrit :
> Salut Antoine,
>
> Est-ce que tu peux tester ce patch ? Je pense que le problème
> est résolu. Merci pour ton analyse.
>
> Par contre, c'est dommage, on est passé à coté d'une informati
Salut Antoine,
Est-ce que tu peux tester ce patch ? Je pense que le problème
est résolu. Merci pour ton analyse.
Par contre, c'est dommage, on est passé à coté d'une information
importante qui nous aurait fait gagner beaucoup de temps, à
savoir le warning à la compilation:
uart.c:90: warning: ‘S
Hello,J'ai enfin trouvé la raison du "reset" de l'atmega ! Je mets reset
entre guillemet, parce que c'est pas vraiment un reset : le programme
sautait à l'adresse 0x00. C'est lié à l'avr-libc qui lorsque elle recoit une
interruption pour laquelle elle n'a pas de gestionnaire appelle la
fonction _v
J'ai pas vraiment trop d'idée non plus. Peut-être que tu peux
essayer de remplacer la ligne par:
UCSRB |= (1 << UDRIE);
Je voulais dire UCSR0B et pas UCSRB. Evidemment ça ne marche
que pour l'uart 0.
___
Avr-list mailing list
Avr-list@droids-corp.
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é...
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+
L
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 a écr
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
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 */
#
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() po
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
11 matches
Mail list logo
