Re: [Avr-list] Problèmes d'UART

2009-06-29 Par sujet Antoine albertelli
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 information
> importante qui nous aurait fait gagner beaucoup de temps, à
> savoir le warning à la compilation:
>
> uart.c:90: warning: ‘SIG_UART_DATA’ appears to be a misspelled signal
> handler
> uart.c:133: warning: ‘SIG_UART_RECV’ appears to be a misspelled signal
> handler
>
> D'où l'intérêt de compiler en -Wall -Werror chaque fois que c'est
> possible !
>
> ++
> Olivier
>
>
>
> Antoine albertelli wrote:
> > 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 _vector_default() qui fait un JUMP 0x00. Or sur l'Atmega168 n'a
> > pas un UART mais un USART. le handler correct s'appelle
> > donc SIG_USART_RECV et pas SIG_UART_RECV. J'ai fait un test et ça marche
> > nickel. Par contre je connais pas assez bien Aversive et les Atmel pour
> > savoir comment faire un patch propre. Une idée ? J'ai vu qu'il y avait
> > une macro UART_IS_USART. je vais creuser de ce côté là.
> >
> > A+
> > Antoine
> >
> > Le 30 mai 2009 23:17, Olivier MATZ  > > a écrit :
> >
> > 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.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
>
___
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

2009-06-29 Par sujet Olivier MATZ
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: ‘SIG_UART_DATA’ appears to be a misspelled signal
handler
uart.c:133: warning: ‘SIG_UART_RECV’ appears to be a misspelled signal
handler

D'où l'intérêt de compiler en -Wall -Werror chaque fois que c'est
possible !

++
Olivier



Antoine albertelli wrote:
> 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 _vector_default() qui fait un JUMP 0x00. Or sur l'Atmega168 n'a
> pas un UART mais un USART. le handler correct s'appelle
> donc SIG_USART_RECV et pas SIG_UART_RECV. J'ai fait un test et ça marche
> nickel. Par contre je connais pas assez bien Aversive et les Atmel pour
> savoir comment faire un patch propre. Une idée ? J'ai vu qu'il y avait
> une macro UART_IS_USART. je vais creuser de ce côté là.
> 
> A+
> Antoine
> 
> Le 30 mai 2009 23:17, Olivier MATZ  > a écrit :
> 
> 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.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

Index: uart_defs.h
===
RCS file: /var/lib/cvs/aversive/modules/comm/uart/uart_defs.h,v
retrieving revision 1.2.4.12
diff -u -p -r1.2.4.12 uart_defs.h
--- uart_defs.h	20 Feb 2009 20:16:09 -	1.2.4.12
+++ uart_defs.h	29 Jun 2009 20:22:35 -
@@ -46,11 +46,21 @@
 
 /* For arch with only one UART, we consider that UART0 = UART */
 #if !defined(SIG_UART0_DATA) && !defined(SIG_USART0_DATA)
+#if defined SIG_UART_DATA
 #define SIG_UART0_DATA SIG_UART_DATA
+#elif defined SIG_USART_DATA
+#define SIG_UART0_DATA SIG_USART_DATA
 #endif
+#endif
+
 #if !defined(SIG_UART0_RECV) && !defined(SIG_USART0_RECV)
+#if defined SIG_UART_RECV
 #define SIG_UART0_RECV  SIG_UART_RECV
+#elif defined SIG_USART_RECV
+#define SIG_UART0_RECV  SIG_USART_RECV
 #endif
+#endif
+
 #ifndef UDR0
 #define UDR0 UDR
 #endif
___
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

2009-06-29 Par sujet Antoine albertelli
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 _vector_default() qui fait un JUMP 0x00. Or sur l'Atmega168 n'a pas
un UART mais un USART. le handler correct s'appelle donc SIG_USART_RECV et
pas SIG_UART_RECV. J'ai fait un test et ça marche nickel. Par contre je
connais pas assez bien Aversive et les Atmel pour savoir comment faire un
patch propre. Une idée ? J'ai vu qu'il y avait une macro UART_IS_USART. je
vais creuser de ce côté là.

A+
Antoine

Le 30 mai 2009 23:17, Olivier MATZ  a écrit :

> 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.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

2009-05-30 Par sujet Olivier MATZ

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.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

2009-05-30 Par sujet Olivier MATZ

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

2009-05-28 Par sujet Antoine albertelli
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  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  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 > > > 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 
>> > > 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

Re: [Avr-list] Problèmes d'UART

2009-05-26 Par sujet Antoine albertelli
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 é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  > > 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 
> > > 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://wi

Re: [Avr-list] Problèmes d'UART

2009-05-26 Par sujet Olivier MATZ
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  > 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 
> > 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


___
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-cor

Re: [Avr-list] Problèmes d'UART

2009-05-26 Par sujet Antoine albertelli
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  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
> > 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

2009-05-26 Par sujet Olivier MATZ
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