Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---
Forum général sur l'Assembleur !

Modérateur : mazertoc

3eme UART avec un 18F46K22
Guest
Confirmé
Confirmé
Messages : 800
Enregistré en : mars 2017

#1 Message par Guest » mer. 28 sept. 2016 08:41

heu pour l’émission

on peut faire cela c'est pareil

Code : Tout sélectionner

bouclE   RLCF   Donnée
   BCF   LATB,2
   BTFSC   STATUS,C
   BSF   LATB,2

3eme UART avec un 18F46K22
paulfjujo
Avatar de l’utilisateur
Expert
Expert
Messages : 2589
Âge : 73
Enregistré en : juillet 2015
Localisation : 01800
Contact :

#2 Message par paulfjujo » mer. 28 sept. 2016 12:25

bonjour MAÏ et à tous


Merci de t'etre penché la dessus..

mais je suspecte un aleas ici, sur l'emission

Code : Tout sélectionner


bouclE 
   BCF   LATB
,2
   RLCF   Donnée
   BNC   suite
   BSF   LATB
,2
suite   MOVLW   0X68         
;ici tempo de 104µs la donnée
   CALL   Tempo
   DECFSZ   j
   BRA   bouclE


a chaque envoi de data bit , LATB2 est mis à zero pendant 3 cycles ?

Mais mon probleme reside surtout coté reception entre le temps écoulé
depuis l'apparition du front descendant RB0 correspondant au front Start bit
et le debut de traitement à l'interieur de l'interruption RB0

en mettant d'office un delay de 104µS sur le bit de start, le teste suivant, concernant les 8 bist data
par test pooling de RB0 se fera donc plus tard.. donc à l'interieur de l'etat du palier bit.
Ce n'est pas grave , mais il ne faut surtout pas le depasser !
un delay de 104µS entre les bits datas suivants est justifié.
mais ce dernier delay du 8em bit empiete donc sur le bit de stop ..
il faut donc un delay inferieur à 104µS pour le bit de stop..
sachant qu'il va s'ecouler quelques µS entre le stockage du byte recu dans le buffer , et le retour d'interrupt + contexte sauvegardé
Ce temps global doit rester inferieur à 104 µS , si les bytes emis par le terminal sont contigus..
pas de gap temporel entre les caracteres emis..

Ce dernier delay est un reglage un peu capillotracté !
Je n'ai pas étudié toute la partie ASM generée par MikroC concernant ceci ..
pour en deduire un nb de cycles et duree ..
mais simplement testé avec une tempo suffissament basse pour que cela
marche et soit reproductible.
(de plus j'utilise FOSC interne ! une FOSC avec quartz serait preferable)

Grrrr25.gif

Je concois aussi, que si l'appli globale MikroC ne concernait , en tant qu'interruption probable, que cet UART Soft via RB0,
il aurait été plus simple de ré-ecrire directement l'interruption RB0 tout en ASM
et aussi le stockage dans un buffer..
donc avec un timing bien mieux maitrisable..

Nota:
Je n'ai jamais douté que l'ASM peut etre plus performant que le C..
puisque j'ai fait mes debuts en ASM.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Aide toi, le ciel ou FantasPic t'aidera

3eme UART avec un 18F46K22
Guest
Confirmé
Confirmé
Messages : 800
Enregistré en : mars 2017

#3 Message par Guest » mer. 28 sept. 2016 13:09

bonjour Paul

Coté recepteur r

une liaison UART Hard, a l'horloge du recepteur par rapport a celle de l'émetteur est 16 a 64 fois plus rapide .C'est pour cela que je préféré être au milieu de la donnée émetteur Pour faire le test de changement d’état coté recepteur principe que j'adopte pour tout traitement de trame.

Coté recepteur, après déclenchement de INT ,j’attende 104µs largeur créneau start + 1/ 2 créneau septeme bit de la donnée je suis comme cela milieu de la première donnée et tout le long de la transmission

Cote émetteur
voici le code avec la modif proposé plus haut

Code : Tout sélectionner

;*********************** Emission **********************************************   
la   
   MOVLW   8
   MOVWF   j
   
   BCF   LATB,2
   MOVLW   0X68         ; ici tempo de 104µs
   CALL   Tempo
   BCF   STATUS,C
   
bouclE   RLCF   Donnée
   BCF   LATB,2
   BTFSC   STATUS,C
   BSF   LATB,2
   
suite   MOVLW   0X68         ;ici tempo de 104µs
   CALL   Tempo
   DECFSZ   j
   BRA   bouclE
   
   BSF   LATB,2
   MOVLW   0X68         ;ici tempo de 104µs
   CALL   Tempo


voila ce que cela donne vue par l'analyseur de la donnée 0xAA
Capture1.png


Pour la lettre 'A'
Capture .png

A+

PS pour mettre penché, je suis tombé dans le code et j'aime cela humour!!
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.

3eme UART avec un 18F46K22
Guest
Confirmé
Confirmé
Messages : 800
Enregistré en : mars 2017

#4 Message par Guest » ven. 30 sept. 2016 17:42

bonjour Paul

j'ai passé la partie réception au chrono.Pour recevoir un caractère,sous 4MHz.Il me faut 1082 cycles soit 1,082ms ,ce qui ne semble correct.

ici le code avec les bonnes valeurs pour le delay sous un 18F

Code : Tout sélectionner

   MOVLW   0X33         ; ici tempo de 104µs+ 104/2
   CALL   Tempo

   MOVLW   8
   MOVWF   j
   
bouclR   BCF   STATUS,C      ;on charge les 8 bits de la donnée
   BTFSC   LATB,0
   BSF   STATUS,C
   RLCF   Donnée
   MOVLW   0X22         ;ici tempo de 104µs
   CALL   Tempo
   DECFSZ   j
   BRA   bouclR
   
   BTFSC   LATB,0         ; c'est un stop(bit a 1)?
   
   RETFIE            ; c'est OK carac suivant
;   getion des erreurs
   RETFIE
   ;********************* Temporisation *******************************************   
Tempo   MOVWF   i           
delay1   DECFSZ   i     
   GOTO   delay1       
   RETURN


Avec une gestion d'erreur sur le stop au cas OU... je ne tombe pas sur tes valeurs de tempo ?????

A+ valises faites a une dizaines de jours :langue:


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 38 invités