[mazertoc]

Bonjour tout le monde !

Sur un 16F1947 http://ww1.microchip.com/downloads/en/D ... 41414D.pdf la précision de l'horloge interne 32 MHz est insuffisante (+/- 5% entre -20°C et 100°C) pour utiliser l'UART.
Il me faut donc, pour une meilleur précision avec une horloge 32 MHz :
- connecter un quartz 8 MHz sur OSC1/OSC2
- positionner FOSC à 111
- positionner SCS à 00
- positionner PLLEN à 1

Est-ce que c'est bon ?

[Claudius]

Bonjour,

mazertoc a écrit:
... la précision de l'horloge interne 32 MHz est insuffisante (+/- 5% entre -20°C et 100°C) pour utiliser l'UART.

Mais quelle est donc cette vitesse de transmission qui nécessiterait une meilleure précision que celle donnée par le constructeur sachant que le protocole UART est "tolérant" (> 57 600 bauds ?)

Cf. § TABLE 25-5: BAUD RATES FOR ASYNCHRONOUS MODES de la datasheet pour confirmer / infirmer...

NB: D'ailleurs, je ne vois pas d'où sortent ces "+/- 5% entre -20°C et 100°C" ... pour utiliser l'UART.

[Jérémy]

Ou peut être ne longue distance de câble , il me semble que ca y joue aussi non ?.

[Claudius]

Les longueurs des câbles "jouent" mais alors il faut parler de la couche physique; l'UART à ne pas confondre avec le RS 432, 422 ou autre 485 n'étant qu'un protocole "logique" pouvant s'utiliser sur des liaisons ... radios

[mazertoc]

Bonjour,
Mais quelle est donc cette vitesse de transmission qui nécessiterait une meilleure précision que celle donnée par le constructeur sachant que le protocole UART est "tolérant" (> 57 600 bauds ?)

Cf. § TABLE 25-5: BAUD RATES FOR ASYNCHRONOUS MODES de la datasheet pour confirmer / infirmer...

NB: D'ailleurs, je ne vois pas d'où sortent ces "+/- 5% entre -20°C et 100°C" ... pour utiliser l'UART.

J'ai calculé dans le pire des cas pour 19200 bps (mais c'est pareil pour d'autres vitesses, vu que c'est relatif).
Si l'émetteur est à +N % et le récepteur à -N %, ça passe si N < 2,41.
La dérive de l'oscillateur interne en fonction de la température est donnée page 391.

[mazertoc]

Ou peut être ne longue distance de câble , il me semble que ca y joue aussi non ?.

Ben non, là on parle du fonctionnement intrinsèque de l'UART, pas des pertes d'informations dûes à la ligne.

[paulfjujo]

bonsoir,

Bonjour tout le monde !

Sur un 16F1947 http://ww1.microchip.com/downloads/en/D ... 41414D.pdf la précision de l'horloge interne 32 MHz est insuffisante (+/- 5% entre -20°C et 100°C) pour utiliser l'UART.
Il me faut donc, pour une meilleur précision avec une horloge 32 MHz :
- connecter un quartz 8 MHz sur OSC1/OSC2
- positionner FOSC à 111
- positionner SCS à 00
- positionner PLLEN à 1

Est-ce que c'est bon ?

L'utilisation d'un quartz ne me semble pas indispensable dans les cas "classiques" de fonctionnement
pour une vitesse de 19200 bauds.
Generated baud rate is 19231 bps (error = 0.16 percent) avec FOSC 8MHz

ne pas oublier OSCTUNE qui permet de recentrer/décaler la frequence FOSC ..

exemple testé :

FOSC interne 16MHz sortie Fosc/4 sur RA6
Tamb=18,1°C
action de OSCTUNE.TUN sur FOSC/4 +-3% ou +-12% sur FOSC interne
OSCTUNE value peut varier de 31 à -32
31 => 4.145 Mhz
0 => 4.006 MHz
32 => 3.873 Mhz

pour des temperatures ambiantes "normales" (dans un garage) 10 à 40°C , je n'ai jamais vu de problemes particulier à 19200 bauds
avec FOSC interne coté PIC et un terminal PC .. sans meme à avoir retoucher OSCTUNE VALUE (= 0)

Ensuite, on peut aussi avoir un terminal qui ne tolere pas le mondre ecart...
ou une application qui se ballade entre la Russie et le sahara..
et là, il n'y a pas que FOSC avec QUARTZ qui rentre en jeu.

Pour des applications industrielles exigeantes .. un Quartz ( éventuellemnt specifique : multiple rond ,de la vitesse en bauds.)
à moins que la notion de coût ne l'impose pas.

[Jérémy]

Ben non, là on parle du fonctionnement intrinsèque de l'UART, pas des pertes d'informations dûes à la ligne.

oK ! C'était pour essayé de participer
Histoire de me changer l'air avec mon I2c pourri

[Claudius]

mazertoc a écrit :
J'ai calculé dans le pire des cas pour 19200 bps (mais c'est pareil pour d'autres vitesses, vu que c'est relatif).
Si l'émetteur est à +N % et le récepteur à -N %, ça passe si N < 2,41.
La dérive de l'oscillateur interne en fonction de la température est donnée page 391.

Je suis d'accord avec toi mais je n'ai jamais rencontré de problèmes particuliers dans un équipement ou l'émetteur et le récepteur ne sont pas très éloignés l'un de l'autre, comme mon enregistreur de traces GPS que j'emporte dans mon sac à dos été comme hiver mais en gérant les erreurs de communication et tout cela à 9600 bauds, je te l'accorde.

Si tu as de telles exigences, passe à un protocole synchrone où l'horloge peut être "reconstruite" comme le Codage Manchester et tu n'auras vraiment mais vraiment aucun problème et qui fonctionne par exemple à 10 Mbit/s avec Ethernet et ce sur des distances de près de 100 mètres voire plus en fonction du support physique ...

[mazertoc]

Pour l'instant pas de problème, le µC est encore sur les chaines de fabrication (livraison semaine 11).
Mon UART doit pouvoir communique avec ça

APC220_Datasheet.pdf

ou ça

APC802.pdf

,
donc pas de problème de codage entre le PIC et l'émetteur.
Mon interrogation vient de ce que j'ai lu sur le datasheet.

Generated baud rate is 19231 bps (error = 0.16 percent) avec FOSC 8MHz

Le "0.16 percent error" s'applique à Fosc réelle (Fosc + N%).