Bonjour
j utilise un pic 8 bit = pic16f627A sans horloge externe
Je souhaite utilise la communication UART mais je n arrive .
Je code en C .
Environement Wind7 avec MPLAB X.
Merci pour votre aide
-----
Bonjour
j utilise un pic 8 bit = pic16f627A sans horloge externe
Je souhaite utilise la communication UART mais je n arrive .
Je code en C .
Environement Wind7 avec MPLAB X.
Merci pour votre aide
bonjour,
extrait d'une appli à base de 16F1847 ecrite en C de MikroC..
donc à adapter..
Attention à la config et port/registre multi fonctions .
16F1847_UART_MC.zip
poste ce que tu as deja réalisé..
Bonjour,
Pas d'horloge externe, donc pas de quartz... l'horloge interne est calibrée à 1%, ce qui ne convient pas pour l'uart, il faut un quartz à 50ppm ou moins...
Leonardo était ingénieur "sans papier", et moi diplômé juste...technicien...
C'est alors la croix et la bannière pour calibrer le baud-rate generator...
Leonardo était ingénieur "sans papier", et moi diplômé juste...technicien...
j'ai pas mal d'applications ( à 19200 bds) avec FOSC interne qui se contente tres bien de cette precision...
domaine temperature 15-35°C
le probleme doit peut etre se manifester au dela 57600, 115200 bds !
au pire , il y a moyen d'apporter une correction via le OSCTUNE ..
Cela depend aussi
- du domaine de temperature ambiante concernant l'application
- de l'appli en face.La plupart des programmes "Terminal " PC sont assez tolerants .
Avec l'horloge interne il devrait fonctionner à 9,6 kbps, 19,2 kbps et . . . 250 kbps.
Salut a tous
Merci pour vos reponses . en effet ca marche .
j ai encore qqe petit soucis mais ca devrais le faire .![]()
Même si "ça tombe en marche" c'est bon pour bricoler chez soi ce type de choix, pour ceux qui compte retenir qu'il est bon ton de faire comme ça pour votre patron, n'oubliez pas que vous prendrez un risque qui n'en vaut pas la peine.
La tolérance à prendre est celle qui tient compte de la température et aussi des variations du VDD, soit plutôt +/-2%, c'est donc jouable mais pas sur une plage de température étendue et comme en général les découplages sont quasiment oubliés ou insuffisant sur ce qu'on voit trainer ici, les variations d'alim vont bien influencer tout ça.... Murphy fera le reste.
En plus, comme je l'ai lu plus hautsi vous voulez faire du 19200 et plus.... avec 4MHz d'oscillateur interne pour le 16F627 ça va pas bien le faire.
En laissant de côté la qualité de la réalisation . . . et en restant sur la doc µchip.
Pour Vdd entre 2 et 5,5 V et Ta entre 0° et 85 ° la précision INTOSC est de 2% (précision qui je crois me souvenir s'améliore avec la tension d'alim)
Un calcul littéral avec 8N1, émetteur à +2% et récepteur -2%, montre que la transmission marche sans tomber.
Mais j'ai pu me tromper.
Il n'y a pas que l'erreur de l'oscillateur à prendre en compte, il faut aussi intégrer l'erreur introduit par les paramètres de config des registres.
Tu n'obtiendras jamais 19200 bauds et encore moins au delà, c'était ça le sens de ma remarque.
Fais le calcul d'erreur pour t'en convaincre.
C'est ce que j'ai fait pour 250 kbps.Il n'y a pas que l'erreur de l'oscillateur à prendre en compte, il faut aussi intégrer l'erreur introduit par les paramètres de config des registres.
Tu n'obtiendras jamais 19200 bauds et encore moins au delà, c'était ça le sens de ma remarque.
Fais le calcul d'erreur pour t'en convaincre.
µchip donne une erreur pour le baud rate de 0 (les divisions tombent juste pour INTOSC à 4 MHz).
Exact, en relisant ton post je comprends que tes 3 petits points ne voulaient pas dire tous les bauds rate entre 19200 et 250k mais uniquement les 3 que tu indiques.
Je retire donc ce que j'ai dit car tu as raison.