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 ---
- 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 ---
Modérateur : mazertoc
3eme UART avec un 18F46K22
heu pour l’émission
on peut faire cela c'est pareil
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
Expert- Messages : 2597
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour MAÏ et à tous
Merci de t'etre penché la dessus..
mais je suspecte un aleas ici, sur l'emission
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)
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.
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)
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.
3eme UART avec un 18F46K22
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
voila ce que cela donne vue par l'analyseur de la donnée 0xAA
Pour la lettre 'A'
A+
PS pour mettre penché, je suis tombé dans le code et j'aime cela
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
Pour la lettre 'A'
A+
PS pour mettre penché, je suis tombé dans le code et j'aime cela
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
3eme UART avec un 18F46K22
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
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
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
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 48 invités