Pic 18f26k20 eusart tx test

[invite51e48a05]

Bonjour à tous,

Je pensais avoir fait depuis longtemps le tour des difficultés avec la configuration de l'oscillateur et de l'usart, mais le programme ci-dessous (le plus simple du monde) ne fonctionne pas :


compilateur MCC18 V3.40 sous MPLAB:

/**         PIC EUSART TEST                *

/** C O N F I G U R A T I O N   B I T S ******************************/
#pragma config FOSC = INTIO67, FCMEN = ON, IESO = OFF                        // CONFIG1H
#pragma config PWRT = OFF, BOREN = ON, BORV = 18                             // CONFIG2L
#pragma config WDTEN = OFF, WDTPS = 32768                                    // CONFIG2H
#pragma config MCLRE = OFF, LPT1OSC = OFF, PBADEN = ON, CCP2MX = PORTC       // CONFIG3H
#pragma config LVP = OFF, STVREN = ON, XINST = OFF, DEBUG = ON     // CONFIG4L
#pragma config CP0 = OFF, CP1 = OFF, CP2 = OFF, CP3 = OFF                    // CONFIG5L
#pragma config CPB = OFF, CPD = OFF                                          // CONFIG5H
#pragma config WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF                // CONFIG6L
#pragma config WRTB = OFF, WRTC = OFF, WRTD = OFF                            // CONFIG6H
#pragma config EBTR0 = OFF, EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF            // CONFIG7L
#pragma config EBTRB = OFF                                                   // CONFIG7H

/** I N C L U D E S ***************************************************/
#include <p18f26k20.h> // SFR for PIC.
#include <stdio.h>  // printf()...

/** P R O G R A M *****************************************************/
void main (void)
{
 OSCCONbits.IRCF = 5;     // Oscillator internal 4Mhz
 TRISCbits.RC6 = 1;      // RC6 (TX) is output
 TRISCbits.RC7 = 0;      // RC7 (RX) is input
 TXSTAbits.BRGH = 1;      // High speed baud rate
 BAUDCONbits.BRG16 = 1;     // 16 bit generator is used (SPBRH:SPBRG)
 SPBRG = 103;       // 4 000 000 / (4(103 + 1)) = 9615.38 -> 0.16% error (OK)
 RCSTAbits.SPEN = 1;      // USART enabled
 TXSTAbits.TXEN = 1;      // Transmitter enabled
 while (1)
 {
  printf("TEST\r");
 }
}

/** D E B U G  R E S U L T *****************************************************
result in tera term pro 9600 8/N/1 :

@PP@@PT
   TE@PDST@@PT
@@P           T@PTES@@PT
   TEPDRT@@PT
@@P          T@TDS@@PT
   TE@PDRT@@PT
@P            T@@TDS@@PT
  TEP@RT@PP
@PPES@@RT  TE@PDST@@PT
@@PES@@PTT@@PT
   TEPDRT@PT
@P          T@@TDS@@PT
  TE@PDRT@PP
@PPESP@PT   T@PDS@@PT
   TE@PDST@@PT
@@P           T@TESP@PT
@@PDS@@PTT@@PT
   TE@PDRT@PT
@P           T@@TDS@@PT
  TEPDRT@PP
@PPESP@PT  TE@PDST@@PT
@@PESP@PTT@@PT
   TE@PDST@PT
@@P          T@@TDS@@PT
   TE@PDRT@@PT
@P            T@@TDS@@PT
  TEPDRT@PT
@@PESP@RT  T@PDS@@PT
@PPESP@PTT@@PT
@P@TDS@@PT@@PT
  TEPDRT@@PT
@TEPDRT@@PP T@@TDS@@PT
@PPSP@PT   T@PDS@@PT
@@PESP@PTT@@PT
@@PTESP@PT@@PT
   TEPDST@PT
@TE@PDRT@@PTTTDS@@PT
@@P         T@@PDS@@PT
   TE@PDRT@PT
@PPESP@PT    T@PDS@@PT
@PTDS@@PTT@@PT
  TEPDRT@PT
@@P        T@@TDS@@PT
   TEPDRT@PT
            T@TDS
...
*/

Mis à part le fait que j'utilise l'oscillateur interne qui n'est pas très stable (mais je teste à 25°, donc je ne vois pas le souci). Je ne comprends pas ce résultat.

Merci d'avance.
Eki
-----

[vincent66]

Bonjour
L'oscillateur interne est précis à 1%, calculez l'erreur que ceci peut engendrer... En général pour un uart on utilise des quartz précis à 50ppm...
Vincent

[invite51e48a05]

Merci Vincent, oui, je connais ce besoin de précision pour la communication série, mais j'ai déjà eu mon PIC fonctionnel pendant de longues périodes avec un code similaire et l'oscillateur interne sans avoir ces soucis...!? J'ai l'impression d'oublier quelque chose de plus fondamental mais je ne vois pas ou...

[invite51e48a05]

Ca fonctionne bien jusque 2400 bauds @ 4Mhz, mais à 9600 ca dérappe!

Ce qui m'inquiètes le plus, c'est que le même pic a fonctionné dans les mêmes conditions de température et de tension à des fréquences de communication plus élevées auparavant (cela signifie t'il que l'oscillateur interne des PIC est si peu fiable? je n'y crois toujours pas!)

Je n'ai pas malheureusement pas d'oscilloscope sous la main pour mesurer la vitesse réelle et la stabilité de l'oscillateur interne, cela m'aurait pourtant bien plu de surveiller son comportement à titre d'information... Peut-être connaissez-vous des techniques permettant de mesurer/surveiller cela logiciellement?

Je pourrais tenter de modifier osctune, mais je crains de pires résultats...
Je devrais peut être aussi me pencher sur la vérification du fonctionnement du récepteur...

[A voir en vidéo sur Futura]

[invite51e48a05]

hummmmm...

Encore rien d'épatant, j'ai poussé le PIC à 16Mhz et joué sur OSCTUNE dans une boucle de printf mais j'ai toujours un taux d'erreur de transmission inacceptable! Zut, je vais devoir modifier mon proto pour lui intégrer un crystal de qualité suffisante...

Si vous avez d'autres idées pour ajuster le baudrate, je suis quand même prenneur

[RISC]

Salut,

As-tu comparé ton programme avec l'exemple de code pour l'UART des PIC18 : http://www.microchip.com/codeexamples ?

L'oscillateur des PIC est calibré à +/1% à 25C en usine donc quand tu le reçois cela devrait fonctionner à température ambiante.
Cependant, ne prend jamais le risque de ne PAS utiliser un quartz pour une application industrielle (-40 à +85C) car tu vas au carton...
Il suffit de lire la datasheet qui montre l'erreur en fréquence vs température pour s'en convaincre.

Il existe une note d'application pour recalibrer la valeur d'usine (vérifier si elle est applicable pour ce PIC).

Tu peux aussi, si tu en as un sous la main, utiliser la sortie CLOCK du PIC pour vérifier au fréquencemètre l'erreur sur la fréquence .

a+

[invite51e48a05]

Hello cher ami,

Oui ,l'idée du fréquencemètre est sympa économiquement parlant. Pour la variation j'ai même lu +2 / -2 en écart maximum dans des températures extrêmes pour ces PICS...
Cependant, j'ai aussi constaté que mon problème principal est ailleurs, j'utilise un cable CA-42 qui est un convertisseur TTL-RS232 (conçu à la base pour des téléphones) pour sniffer la com, mon pic fonctionne en 2.00V, donc mes signaux de communication sont aussi à cette tension, ce qui ne respecte pas les valeurs logiques minimales du "1", j'ai donc une quantité d'erreur qui provient de ce "défaut de débogage". Après quelques tests, je constate que mon µC comprend très bien ce que raconte mon pic, même si mon terminal lit souvent du charabia à travers mon convertisseur gadget et ceci même à 57600 bauds! (je suis idiot mais je me soigne)

A bientôt

[invite36492e34]

salut,

Juste pour apporter une petite précision
On peut très bien utiliser l'oscillateur interne des PIC même pour une liaison série (module uart interne ou uart soft) et ceci sans avoir besoin de le recalibrer. Pour des vitesse de 9600, 19200 voir plus..
Donc à fortiori si c'est une application perso, je trouve qu'il n'y a pas de réticence à avoir...

A+

[RISC]

Salut Eki,

Si tu avais donné tes conditions de fonctionnement on aurait de suite identifié l'erreur...
Peux-tu faire voir ton schéma ?
Si le PIC fonctionne en 2V quel circuit as-tu connecté pour faire la translation de niveau derrière entre le connecteur RS232 et le PIC ?
As-tu des raisons spéciales pour utiliser 2V ?

IL existe des translateurs de niveaux comme les MAX3222E/MAX3232E/MAX3237E/MAX3241E/MAX3246E qui fonctionnent de 3V à 5V.

Le PIC18F26K20 est un peu ancien...et posséde par mal de bugs car c'était le premier PIC18 version K.
Préferres lui le PIC18LF26K22 plus récent, et plus riche en périphériques ;=)

a+