Interruptions UART PIC18 ... Je craque !
Répondre à la discussion
Affichage des résultats 1 à 19 sur 19

Interruptions UART PIC18 ... Je craque !



  1. #1
    Poutch10

    Exclamation Interruptions UART PIC18 ... Je craque !


    ------

    Bonjour,

    Depuis 2 jours j'essaye de faire en sorte que mon pic18f45k22 reçoive des données envoyées depuis l'ordinateur par connexion série.

    J'arrive a envoyer du pic vers le PC sans soucis, mais l'inverse est impossible.
    Je pense avoir mal configurer les interruptions car en mettant une sonde sur le port RX1 du pic je reçois bien les données, je n'arrive simplement pas à les traiter dans le code ...

    Ce que j'utilise :
    - PIC16F45K22 (datasheet)
    - Compilateur C18 (avec bibliothèque uart.h)
    - MPLAB ICD 3
    - Convertisseur Serie-USB (pour connecter a mon PC) USB-COM485-PLUS1
    - Horloge interne (tant pis pour la précision pour l'instant)

    Maintenant voici mon code :

    Code:
    #include <p18cxxx.h>
    #include <string.h>
    #include <usart.h>
    #include <delays.h>
    
    void SYS_InterruptHigh (void);
    void SYS_InterruptLow  (void);
    
    /*-----------------------------------------------------------
    *
    *               Vecteurs d'Interruptions
    *
    -----------------------------------------------------------*/
    #pragma code HIGH_INTERRUPT_VECTOR = 0x1008
    void High_ISR(void) {
        _asm goto SYS_InterruptHigh _endasm
    }
    #pragma code LOW_INTERRUPT_VECTOR = 0x1018
    void Low_ISR(void) {
        _asm goto SYS_InterruptLow _endasm
    }
    #pragma code
    #pragma interrupt SYS_InterruptHigh
    void SYS_InterruptHigh() {
    
    	if(PIR1bits.RC1IF)
    	{
                    // Je veut simplement allumer une LED pour le moment :)
    		LATDbits.LATD2	= 1; // Allume LED
    	}
    	if(RCSTAbits.OERR)
    	{
    		RCSTAbits.OERR	= 0;
    	}
    	if(RCSTAbits.FERR)
    	{
    		RCSTAbits.FERR	= 0;
    	}
    } 
    #pragma interruptlow SYS_InterruptLow
    void SYS_InterruptLow() {
    
    } 
    
    /*-----------------------------------------------------------
    *
    *               Initialisation
    *
    -----------------------------------------------------------*/
    void init(void)
    {
    	// *** CONFIG I/O *** 
    
    	TRISDbits.RD2		= 0;	// LED (une led de test)
    	LATDbits.LATD2		= 0;	// LED OFF
    
    	TRISCbits.RC6		= 0;	// TX1
    	TRISCbits.RC7		= 1;	// RX1
    
    	
    	// *** CONFIG OSCILLATOR (4Mhz) ***
    	OSCCONbits.IRCF0 	= 1;
    	OSCCONbits.IRCF1 	= 0;
    	OSCCONbits.IRCF2 	= 1;
    
    	// *** INTERRUPTS CONFIG ***
    	RCONbits.IPEN   	= 1;	//En priority
    	INTCONbits.GIE  	= 1;	//autorisation IT
    	INTCONbits.GIEL  	= 1;
    	INTCONbits.PEIE 	= 1;	//autorisation IT peripheriques
    	PIE1bits.RC1IE     	= 1;	// autorisation des flags des IT Tx
    	IPR1bits.RC1IP     	= 1;	// High Priority
    
    	
    	// *** CONFIG USART ***
    	baud1USART(BAUD_8_BIT_RATE & BAUD_AUTO_OFF & BAUD_WAKEUP_OFF);
    
    		// Open the USART configured as
    		// 4MHz, 9600 baud
    	Open1USART (
    		USART_TX_INT_OFF &
    		USART_RX_INT_ON &
    		USART_ASYNCH_MODE &
    		USART_EIGHT_BIT &
    		USART_CONT_RX &
    		USART_BRGH_HIGH, 25);
    	
    	BAUDCON1bits.CKTXP 	= 0; 	// Tx not inverted
    
    }
    
    void main (void)
    {
    	init();		
    	while(1)
    	{		
    	}
    }
    Voilà, dites moi si vous voyez une erreur monumentale ...

    -----
    Dernière modification par Poutch10 ; 15/12/2014 à 10h53.

  2. #2
    terriblement

    Re : Interruptions UART PIC18 ... Je craque !

    Salut,

    - essaie de faire tourner ton PIC a 8MHz pour voir (pense a adapter les vitesses de transmissions/facteurs de synchro)
    - peux tu poster ton code complet ? je ne sais pas ce que "Open1USART" permet de faire par exemple (le mieux étant de bosser sans biblio au début pour les fonctions basiques)

  3. #3
    paulfjujo

    Re : Interruptions UART PIC18 ... Je craque !

    bonsoir,

    il faut lire le registre de reception, pour RAZER le bit RCIF !


    Code:
    void SYS_InterruptHigh() {
    
    	if(PIR1bits.RC1IF)
    	{
                    // Je veut simplement allumer une LED pour le moment :)
                    c=RCREG;    // syntaxe à verifier
    		LATDbits.LATD2	= 1; // Allume LED
    	}
    	if(RCSTAbits.OERR)
    	{
    		RCSTAbits.OERR	= 0;
    	}
    	if(RCSTAbits.FERR)
    	{
    		RCSTAbits.FERR	= 0;
    	}
    }

    interrupt high à 0x1008 ?
    est-ce parcequ'il y a un bootloader ?
    0x0008 pour un 18F46K22

  4. #4
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    Merci pour vos réponses.

    Finalement ça a fonctionné "tout seul", je pense que le USB-COM485-PLUS1 ou Putty avait planté. Quand j'ai réessayé plus tard ça a marché direct.

    Je sais bien qui faut vider le RCIF mais j'avais juste mit l'allumage d'une led pour vérifier que l'interruption se faisais au moins une fois.
    Par contre, je n'arrive pas à faire un echo (renvoyer ce que je reçois) :

    Code:
    c=RCREG;
    while(USART Occupé); (je ne sais plus le nom de la variable)
    TXREG = c;
    Lorsque j'envoie par exemple 'a' (0x61), je récupère 'O' (0x4F). Je vois pas d'où cela peut venir.

    Merci.

  5. A voir en vidéo sur Futura
  6. #5
    paulfjujo

    Re : Interruptions UART PIC18 ... Je craque !

    on ne voit pas de lien evident entre 'a' et 'O'

    et si tu testes avec d'autres valeurs remarquable
    comme
    A,B,C,D,E,a,b,c,d,e,0,1,2,3
    tu obtiens quoi , respectivement ?

    probleme de
    Parité ?
    7 bits ?
    ou vitesse en baud insuffisament précise?

  7. #6
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    Je n'ai pas le materiel sous la main actuellement. J'envoie quelques exemples demain et je regarde pour la parité.

    Merci

  8. #7
    RISC

    Re : Interruptions UART PIC18 ... Je craque !

    Salut,

    Tu as oublié 2 choses très importantes :

    1/ Contrairement à ce que tu as mentionné
    - Horloge interne (tant pis pour la précision pour l'instant)
    C'est justement très très important. Si tu vérifies la précision des différents oscillateurs internes dans la datasheet (table 27-9), tu verras que leur fréquence est garantie à +/-2% dans la gamme 0 a 60C si Vdd est > 2.5V. Si jamais ton système doit fonctionner dans la gamme -40 à +85C il te faudra impérativement utiliser un quartz externe.

    2/ Si tu choisis 4 MHz, tu vas avoir une erreur important sur la vitesse et tu dois toujours faire un calcul d'erreur sur la vitesse. Si ton erreur n'est pas de 0% et que tu ajoutes les +/-2% dont j'ai parlé en 1/ tu vas t'apercevoir que tu vas dépasser les +/- 2% qui sont la limite extreme d'erreur pour une liaison RS232.
    Pour limiter l'erreur, je te conseille de faire tourner le PIC à la fréquence la plus élevée 64MHz ou moins si une des fréquences te donne une erreur de vitesse nulle.

    Je ne suis pas certain que ton PB vienne de cela (je suppose que tu travailles pour l'instant à température ambiante (20C)) mais l'socillateur est un paramètre vital à toujours vérifier dans le cas de applications utilisant un UART.
    Si c'est une application perso, je te recommande de mettre un quartz.

    a+

  9. #8
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    Je te remercie pour ton conseil, je vais le mettre en 64 Mhz demain pour voir ce que ça donne, avec ma config actuelle j'ai 0.16% d'erreur: est-ce suffisant pour avoir une telle erreur dans l'echo que j'essaye de mettre en place ?

    En regardant la page 282 de la data sheet du pic (SYNC =0, BRGH =1, BRG16 =0), même en 64 MHz et SPBRG de 207 j'ai 0.16% d'erreur. J'essaye avec les fréquences proposées qui donnent une erreur nulle (genre 16.000 MHz avec un SPBRG de 95) ?


    Je ne peut pas actuellement mettre de quartz externe, j'utilise un produit de mon entreprise pour faire mes tests, une carte avec le pic soudé dessus et d'autre composants que je n'utilise pas (peut-être qu'il y a un osci externe dans la plaque, je demanderais).

    Le quartz externe a une erreur lui aussi ? Dépendante du type, marque, qualité, fréquence... ?

    Encore merci

  10. #9
    RISC

    Re : Interruptions UART PIC18 ... Je craque !

    Salut,

    Ne confond pas l'erreur sur la vitesse de l'UART et l'erreur de l'oscillateur interne...
    La spécification montre que la fréquence de l'oscillateur interne est garantie à +/-2% de la fréquence nominale dans la gamme 0 à 50C. Donc, au pire ton oscillateur à une erreur de -2% ou +2% et tu ajoutes 0,16% donc tu as 2,16% ou -2,16%. Tu es donc hors spec pour l'UART...
    Si ta carte possède un oscillateur à quartz, il faut juste changer les bits de configuration en utilisant la commande :
    #pragma config ... dans ton programme.
    Si cette carte doit fonctionner dans une gamme de température plus étendue que 0 à 60C il faut impérativement un quartz.

    Même si la carte n'a pas de quartz, je te recommande d'en mettre un (16MHz) avec 2 capas (voir datasheet) sinon tu risques de perdre des heures et des jours à chercher un problème soft qui est dans le hard...

    a+

  11. #10
    terriblement

    Re : Interruptions UART PIC18 ... Je craque !

    d'ou ma proposition de faire tourner le PIC à 8MHz pour tests, l'erreur étant faible à cette vitesse.
    et +1 pour le quartz pour le projet final, pour éviter un fonctionnement erratique de ton UART

  12. #11
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    Bon, j'ai fini par faire fonctionner le truc Enfin à moitier, j'ai une erreur de framing à chaque envoie mais j'ai bien mon echo. Peut-être du à cette fameuse horloge.
    Je n'ai pas de quartz externe sous la main donc pas de test possible pour le moment.

    J'ai modifié le code pour utiliser au minimum la bibliothèque usart.h, seule la fonction putsr1USART est toujours présente.

    Merci à tous de m'avoir aidé, pour ceux que ça intéresse voici le code final:

    Code:
    #include <p18cxxx.h>
    #include <string.h>
    #include <usart.h>
    
    // Protoypes
    void SYS_InterruptHigh (void);
    void SYS_InterruptLow  (void);
    
    // Global variables
    char *ferr = "ferr";
    char *oerr = "oerr";
    
    
    /*-----------------------------------------------------------
    *
    *               Interrupts
    *
    -----------------------------------------------------------*/
    #pragma code HIGH_INTERRUPT_VECTOR = 0x1008
    void High_ISR(void) {
        _asm goto SYS_InterruptHigh _endasm
    }
    #pragma code LOW_INTERRUPT_VECTOR = 0x1018
    void Low_ISR(void) {
        _asm goto SYS_InterruptLow _endasm
    }
    #pragma code
    #pragma interrupt SYS_InterruptHigh
    void SYS_InterruptHigh() {
    
    	if(PIR1bits.RC1IF)
    	{
    		char c;
    		c = RCREG; // recupere les données
    		TXREG = c; // renvoie les données recuperées
    		while(!TXSTAbits.TRMT); // 1 = empty
    
    		LATDbits.LATD2	= !LATDbits.LATD2; // Clignotement LED
    	}
    	if(RCSTAbits.OERR)
    	{
    		RCSTAbits.CREN		= 0;	// Continuous receive disable  : reset de OERR (voir datasheet)
    		putrs1USART(oerr); // renvoie "oerr"
    	}
    	if(RCSTAbits.FERR)
    	{
    		char c;
    		c= RCREG; // reset du framing error (voir datasheet)
    		putrs1USART(ferr); // renvoie "ferr"
    	}
    } 
    #pragma interruptlow SYS_InterruptLow
    void SYS_InterruptLow() {
    
    }
    /*-----------------------------------------------------------
    *
    *               Initialisation
    *
    -----------------------------------------------------------*/
    void init(void)
    {
    	// *** CONFIG I/O *** 
    		// rappel :
    		// TRISx  : tristate,      0 output  1 input
    		// ANSELx : analog select, 0 digital 1 analog
    		// PORTx  : read pin   or write latch
    		// LATx   : read latch or write latch
    	ANSELC = 0x00;
    
    	TRISDbits.RD2		= 0;	// LED as output
    	LATDbits.LATD2		= 0;	// LED OFF
    
    	TRISCbits.RC6		= 0;	// TX1 as output
    	TRISCbits.RC7		= 1;	// RX1 as input
    
    	
    	// *** CONFIG OSCILLATOR (64 Mhz avec PLL) ***
    	OSCCONbits.IRCF0 	= 1; 
    	OSCCONbits.IRCF1 	= 1;  
    	OSCCONbits.IRCF2 	= 1;  
    	OSCTUNEbits.PLLEN	= 1; // PLL enable
    
    	// *** INTERRUPTS CONFIG ***
    	// General / Periph interrupts
    	RCONbits.IPEN   	= 1;	//En priority
    	INTCONbits.GIE  	= 1;	//autorisation IT
    	INTCONbits.PEIE 	= 1;	//autorisation IT peripheriques
    	// UART interrupts
    	PIE1bits.RC1IE     	= 1;	// Interruption reception UART
    	IPR1bits.RC1IP     	= 1;	// High Priority
    
    	
    	// *** CONFIG UART ***
    	TXSTA1bits.TXEN 	= 1;	// Transmit enabled
    	TXSTA1bits.SYNC 	= 0;	// Asynchronous mode
    	TXSTA1bits.BRGH 	= 1;	// High Speed
    	TXSTA1bits.TX9 		= 0;	// No 9th bit
    	BAUDCON1bits.BRG16 	= 0; 	// 8-bit Baud Rate Generator
    	BAUDCON1bits.CKTXP 	= 0; 	// Tx not inverted
    	BAUDCON1bits.WUE 	= 0; 	// Wake-up disable
    	BAUDCON1bits.ABDEN 	= 0; 	// Baud-auto off
    	RCSTAbits.SPEN 		= 1; 	// Serial port enable
    	RCSTAbits.CREN		= 1;	// Continuous reveive enable
    	RCSTA1bits.RX9 		= 0;	// No 9th bit
    	SPBRG 				= 207;	// 19200 bauds, 64 Mhz
    }
    /*-----------------------------------------------------------
    *
    *               Main function
    *
    -----------------------------------------------------------*/
    void main (void)
    {
    	init();		
    	while(1)
    	{	
    
    	}
    }

  13. #12
    paulfjujo

    Re : Interruptions UART PIC18 ... Je craque !

    bonjour,


    J'ai de multiple applications ou je me sers de la FOSC interne du PIC à 8 ou 16MHz
    et meme avec une erreur de 0,16% ..no problemo
    De plus tu as la possibilité d'agir enventuellement sur OSCTUNE....
    ou meme , avec le terminal VBRAY on peut aussi definir une vitesse en baud NON NORMALISEE.

    Par contre dans le traitement d'erreur, il faut revalider CREN
    et ne renvoyer le caractere lu , en echo, que si il n'y a pas eu d'erreur


    Code:
    #pragma interrupt Traite_ISR
    void Traite_ISR(void)	// reception d'une interruption
    {
        char c1;
    
     if ((PIE1bits.RCIE == 1)&&(PIR1bits.RC1IF==1)) // si une interruption arrive
      {
       c1 =Read1USART(); // le lire => RAZ  RCIF   
      if(RCSTA1bits.FERR==1 )
       {
         RCSTA1bits.SPEN = 0 ;
         RCSTA1bits.SPEN= 1 ;
         c1 =Read1USART();  // vide le buffer
         c1=0;
          }
       if (RCSTA1bits.OERR==1)    // voir parag 16.1.26 p273
       {
           RCSTA1bits.CREN = 0 ;
           RCSTA1bits.CREN = 1 ;
             c1=0;
         } 
        if (c1>0)
        {
           while( Busy1USART()) ; // par sécurite
           Write1USART(c1); // echo
        }
    }

  14. #13
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    Salut,

    Pourquoi désactiver et réactiver le port série en cas de framing error ? Je n'ai pas vu ça dans la doc.

    C'est vrai que je ne devrait renvoyer l'echo que s'il n'y a pas eu d'erreur. Cependant je ne comprend pas pourquoi une erreur est détectée alors que lorsque j'envoie un caractère, il me le renvoie bien. Une erreur de bit de délimitation ? De taille ? Je ne vois pas du tout.

    Concernant le registre OSCTUNE, ce que tu me proposes de modifier c'est TUN<5:0> ? Si oui, de quelle façon car je ne vois pas comment avoir le baud rate non-normalisé voulu.
    Par contre, dans les paramètre de mon port USB je n'ai que des valeur normalisées, cela a-t'il un impact sur le fonctionnement du système ou le paramétrage de ce port est inutile ?

    Merci.

  15. #14
    terriblement

    Re : Interruptions UART PIC18 ... Je craque !

    Oui ca marche sans quartz, jusqu'a ce que ca ne marche plus. RISC a deja décris le pourquoi du comment.

  16. #15
    paulfjujo

    Re : Interruptions UART PIC18 ... Je craque !

    A propos de OSCTUNE


    Config FOSC interne avec sortie Fosc/4 sur Osc2 soit RA6 pin 14 d'un 18F46K22
    J'ai connecté un frequencemetre (à PIC16F84 !) sur la pin RA6 via un condo de 22pF.
    et ma sortie UART configuré pour 19200 bauds .. RS232 sur PC avec Vbray terminal
    sur lequel j'utilise le clavier pour modifier OSCTUNE de 0 32 via les touches + ou -

    Datasheet donne pour Osctune.TUN
    000000=Reglage d'usine
    011111= 31=Valeur Maxi Fosc
    100000= 32=Valeur Mini Fosc

    1er test avec U alim PIC18 =5.01V
    OSCTUNE=31=> 4.164 => 16.656 Mhz
    OSCTUNE=0 => 4.026 => 16.104 Mhz
    OSCTUNE=32 =>3.890 => 15.56 Mhz

    delta maxi de reglage= 16.656-15.560=1.096 Mhz sur 16 nominal
    soit 6.8% !

    et pourtant , je peux toujours lire les valeurs sur mon terminal !
    sans toucher au Baud rate terminal fixé à 19200 bauds.

    Quel est le degré de liberté acceptable ,en terme d'ecart de vitesse (bauds) , d'un logiciel Terminal ...

    Un autre forumeur pourrait-il faire une manip semblable pour correler ou pas ,ces resultats ?

  17. #16
    RISC

    Re : Interruptions UART PIC18 ... Je craque !

    Salut,

    Je ne peux pas croire que tu aies pu lire les caractères avec 6% d'erreur...
    Prends un fréquencemètre pour mesurer car c'est à mon avis totalement impossible de ne pas avoir d'erreur avec une telle déviation

    Tu peux faire tous les tests que tu veux...mais n'oublie pas que dans les applications industrielles ou automobiles les gammes de fonctionnement à garantir sont -40 à +85 et -40 à +125C voire 150C. La température et la tension Vdd agissent de façon importante sur la déviation de l'oscillateur interne. C'est un fait.
    La norme est claire...au delà de +/-2% on ne peux plus garantir que la communication pourra être effectuée sans erreurs.
    Il y a des centaines d'articles sur internet à ce sujet.
    Donc si l'oscillateur interne n'est pas capable de rester dans la zone +/-2%, il faut mettre un quartz. Pour les applis perso à température ambiante on peut s'en passer si on reste dans le zone de température réduite ou cette variation est mineure...

    a+
    Dernière modification par RISC ; 16/12/2014 à 23h32.

  18. #17
    terriblement

    Re : Interruptions UART PIC18 ... Je craque !

    Les PC ont peut etre du hard/soft un peu plus tolérant, variant d'une machine à l'autre. possible ?

  19. #18
    paulfjujo

    Re : Interruptions UART PIC18 ... Je craque !

    Citation Envoyé par RISC Voir le message
    Je ne peux pas croire que tu aies pu lire les caractères avec 6% d'erreur...
    Prends un fréquencemètre pour mesurer car c'est à mon avis totalement impossible de ne pas avoir d'erreur avec une telle déviation
    Je vois que tu es un peu comme moi , St Thomas sur les bords..
    Javais bien un frequencemetre connecté sur RA6, meme si celui ci peut etre sujet à contestation quand à la precision
    l'ecart en relatif reste le meme.
    Fais la manip par toi-meme ...

    Je viens de refaire ce test ce matin
    FOSC interne 16MHz sortie Fosc/4 sur RA6
    Tamb=18,1°C
    action sur OSCTUNE.TUN
    31 => 4.145 Mhz
    0 => 4.006 MHz
    32 => 3.873 Mhz

    et toujours un affichage correct à 19200 bauds à ces 3 valeurs de FOSC/4.
    sur terminal VBRAY PC...OK
    test aussi avec Realterm Serial Capture Programm 2.0.0.57 ==> OK


    Tu peux faire tous les tests que tu veux...mais n'oublie pas que dans les applications industrielles ou automobiles les gammes de fonctionnement à garantir sont -40 à +85 et -40 à +125C voire 150C. La température et la tension Vdd agissent de façon importante sur la déviation de l'oscillateur interne. C'est un fait.
    La norme est claire...au delà de +/-2% on ne peux plus garantir que la communication pourra être effectuée sans erreurs.
    Il y a des centaines d'articles sur internet à ce sujet.
    Donc si l'oscillateur interne n'est pas capable de rester dans la zone +/-2%, il faut mettre un quartz. Pour les applis perso à température ambiante on peut s'en passer si on reste dans le zone de température réduite ou cette variation est mineure...
    Je n'oublie pas que le contexte dans le monde Industriel (et commercial) implique de suivre
    des normes pour garantir un fonctionnement dans des conditions extremes.
    On est tout à fait d'accord sur cela .

    J'ai repondu à ce post de cette façon, parce que le soupcon de l'origine du probleme était sur la vitesse en bauds imprecise.
    Ce qui depend de l'utilisation finale, surtout lorqu'on passe par un interface USB/serie
    En jouant sur TUN, la frequence FOSC passera forcement par une valeur exacte ,à l'interieure de la gamme de +-2%
    (en supposant qu'on est pas au pole nord à -40°C)
    Si cela n'aboutit pas, le probleme est AILLEURS..


    un petit detail : la tension d'alim est de combien ?

  20. #19
    Poutch10

    Re : Interruptions UART PIC18 ... Je craque !

    J'ai une tension 12 ou 15V il me semble qui est ensuite baissée à 5V pour entrer dans le pic (la carte comprend d'autres modules qui ont besoin du 12V).

    Enfin c'est pas grave, c'était un exercice pour me familiariser avec les liaisons séries avec un pic. Je reçois un caractère, je le renvoie bien, j'ai une erreur FERR qui vient se coller mais je récupère bien les données en entières ... Je me pencherai plus sur le problème quand j'aurais de quoi mieux trifouiller le pic et y mettre un quartz externe.

    Merci à tous de m'avoir aidé. Il y a moyen de passer le sujet en résolu ?

    PS : J'ai ouvert un autre sujet (qui n'est pas un problème cette fois-ci ) : Kit débutant uC - electronique donc si ça vous intéresse et si vous avez des suggestion n'hésitez pas, répertorier un kit de débutant serai sympa je trouve.

    A bientôt !

Discussions similaires

  1. [PIC18] Problème de réception uart: Framing Error: FERR
    Par bonhommr dans le forum Électronique
    Réponses: 15
    Dernier message: 27/08/2012, 22h06
  2. problème lecture UART (PIC18, C18)
    Par gogott dans le forum Électronique
    Réponses: 3
    Dernier message: 13/04/2011, 19h17
  3. J'ai craqué...
    Par invitefb6ff7ed dans le forum Matériel astronomique et photos d'amateurs
    Réponses: 18
    Dernier message: 18/03/2008, 17h30
  4. J'ai craqué !!!!
    Par invite88239e6a dans le forum Matériel astronomique et photos d'amateurs
    Réponses: 4
    Dernier message: 26/04/2007, 14h04
  5. Je craque !!!!!!!!!!!!
    Par invite1c95ee9c dans le forum Logiciel - Software - Open Source
    Réponses: 4
    Dernier message: 23/01/2005, 13h29
Découvrez nos comparatifs produits sur l'informatique et les technologies.