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
appel aux specialistes ASM decalage 96 bits
Bonjour Temp-x et autres,
Je suis de l'avis de satinas (post #19) ; c'est donc toujours 2 cycle puisqu'on saute toujours, ce n'est pas si faux .
Je verrais bien là les effets de bord d'un copier/coller abusif du rédacteur du datasheet. à qui n'est-ce pas arrivé ?
Je suis de l'avis de satinas (post #19) ; c'est donc toujours 2 cycle puisqu'on saute toujours, ce n'est pas si faux .
Je verrais bien là les effets de bord d'un copier/coller abusif du rédacteur du datasheet. à qui n'est-ce pas arrivé ?
appel aux specialistes ASM decalage 96 bits
- paulfjujo
Expert- Messages : 2598
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour à tous et merçi pour votre aide
YES ! j'ai trouvé où est mon bleme !
avec _Carry initialisé à 1 ( bit à 1 dans le poids 0)
je testais le MAUVAIS BIT avec btfss _Carry,1,0 1=> N° de bit de poids 2 !
Le but d'utiliser une variable C appelé Carry (mnemotechnique) , c'est juste pour pouvoir recuperer le report du bit sortant ,
d'un precedent decalage du BIGWORD de 96 bits ..
à la fin d'un declage
_Carry=L2>>31;
des qu'on poussera à nouveau un bit dans le registre BIGWORD , on recuperera d'abord le Carry
à réinjecter ,pour avoir une registre CIRCULAIRE.
Avant decalage et Carry= 0
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00100010 <-- 0x22
Apres 1 seul decalage à gauche
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-01000100 0x44
Avant decalage et Carry= 1
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00100010 <-- 0x22
Apres 1 seul decalage à gauche
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-01000101 <- 0x45
YES ! j'ai trouvé où est mon bleme !
avec _Carry initialisé à 1 ( bit à 1 dans le poids 0)
je testais le MAUVAIS BIT avec btfss _Carry,1,0 1=> N° de bit de poids 2 !
Le but d'utiliser une variable C appelé Carry (mnemotechnique) , c'est juste pour pouvoir recuperer le report du bit sortant ,
d'un precedent decalage du BIGWORD de 96 bits ..
à la fin d'un declage
_Carry=L2>>31;
des qu'on poussera à nouveau un bit dans le registre BIGWORD , on recuperera d'abord le Carry
à réinjecter ,pour avoir une registre CIRCULAIRE.
Code : Tout sélectionner
_asm {
bsf STATUS,C // set bit C => C=1 bit CARRY du registre STATUS
btfss _Carry,0,0 // si le bit de position 0 de la variable _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ bit C => C=0
nop
rlcf _Depart+0,1,0 // rotate left through carry de _Depart[0] (rlcf _Depart,F,ACCESS)
rlcf _Depart+1,1,0
rlcf _Depart+2,1,0
rlcf _Depart+3,1,0
rlcf _Depart+4,1,0 // rotate left through carry de _Depart[1]
rlcf _Depart+5,1,0
rlcf _Depart+6,1,0
rlcf _Depart+7,1,0
rlcf _Depart+8,1,0 // rotate left through carry de _Depart[2]
rlcf _Depart+9,1,0
rlcf _Depart+10,1,0
rlcf _Depart+11,1,0
}
Avant decalage et Carry= 0
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00100010 <-- 0x22
Apres 1 seul decalage à gauche
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-01000100 0x44
Avant decalage et Carry= 1
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00100010 <-- 0x22
Apres 1 seul decalage à gauche
00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-00000000-01000101 <- 0x45
appel aux specialistes ASM decalage 96 bits
Si ça tourne, c'est que ça marche :)
Au post #7 j'avais mis un exemple de rotation circulaire des 96 bits, avec des rotates récupérant le bit b95, pour rester dans le ton.
Là tu traites une ligne de pixel, pour les boucles de plus haut niveau, tu restes en C ?
Parce que j'ai un peu regardé le listing désassemblé après compilation C18 sans optimisation, et ça fait peur tellement c'est bavard, il y a des tas d'instructions en trop de partout.
Au post #7 j'avais mis un exemple de rotation circulaire des 96 bits, avec des rotates récupérant le bit b95, pour rester dans le ton.
Là tu traites une ligne de pixel, pour les boucles de plus haut niveau, tu restes en C ?
Parce que j'ai un peu regardé le listing désassemblé après compilation C18 sans optimisation, et ça fait peur tellement c'est bavard, il y a des tas d'instructions en trop de partout.
appel aux specialistes ASM decalage 96 bits
Bonsoir satinas,
je m'excuse auprès de paulfjujo de m'écarter un peu de son sujet, mais je fais juste une parenthèse liée au post de satinas.
J'au toujours eu la flemme d'installer un compilateur C18, mais je me demande depuis que je m'intéresse aux pics, quel code peut générer un compilateur.
pour quelqu'un qui écrit directement en assembleur, mais pour un automate qui traduit du C ? sans même une pile j'admire.
J'ai eu plusieurs fois l'occasion de faire la chose suivante pour gagner en performance :
je m'excuse auprès de paulfjujo de m'écarter un peu de son sujet, mais je fais juste une parenthèse liée au post de satinas.
J'au toujours eu la flemme d'installer un compilateur C18, mais je me demande depuis que je m'intéresse aux pics, quel code peut générer un compilateur.
et ça fait peur tellement c'est bavard, il y a des tas d'instructions en trop de partout.
pour quelqu'un qui écrit directement en assembleur, mais pour un automate qui traduit du C ? sans même une pile j'admire.
J'ai eu plusieurs fois l'occasion de faire la chose suivante pour gagner en performance :
- écrire une séquence de code en C
faire cracher au compilateur l'assembleur généré
optimiser ce code
et le réinjecter dans le programme C
appel aux specialistes ASM decalage 96 bits
Bonsoir,
Ben, c'est pas moi qui le dit, c'est Monsieur bigonoff (Voir cours Chapitre 5, pages 58)
De plus il dit ceci :
Autrement dit, pour sauter à l’étiquette « label », vous aurez le choix entre :
goto label
Et
bra label
Ces deux instructions donneront le même résultat à condition que le bra saute à un emplacement compris dans les limites expliquées.
Dans le cas contraire MPASM vous signalera simplement une erreur de limite de saut. Il vous suffira alors de remplacer le bra par un goto
Alors, autant utiliser le goto Et bien non, car le goto utilise 32 bits pour être codé, et le bra n’en utilise que 16.
Bon j'espère que ça fonctionne paulfjujo, après il te faudra faire une boucle de 8 passages, je suis passé par là
avec le programme que j'ai écrit, donc je connais tas galère.
A+
JJE a écrit :Source du message Je verrais bien là les effets de bord d'un copier/coller abusif du rédacteur du datasheet. à qui n'est-ce pas arrivé ?
Ben, c'est pas moi qui le dit, c'est Monsieur bigonoff (Voir cours Chapitre 5, pages 58)
De plus il dit ceci :
Autrement dit, pour sauter à l’étiquette « label », vous aurez le choix entre :
goto label
Et
bra label
Ces deux instructions donneront le même résultat à condition que le bra saute à un emplacement compris dans les limites expliquées.
Dans le cas contraire MPASM vous signalera simplement une erreur de limite de saut. Il vous suffira alors de remplacer le bra par un goto
Alors, autant utiliser le goto Et bien non, car le goto utilise 32 bits pour être codé, et le bra n’en utilise que 16.
Bon j'espère que ça fonctionne paulfjujo, après il te faudra faire une boucle de 8 passages, je suis passé par là
avec le programme que j'ai écrit, donc je connais tas galère.
A+
appel aux specialistes ASM decalage 96 bits
- paulfjujo
Expert- Messages : 2598
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonsoir à tous,
mes test registre à decalage 96 bits ont été PRESQUE concluant
au passage j'ai pu remarquer que je ne pouvait pas forcer le bit STATUS
Depart=L10;
_asm {
bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
j'ai donc utilisé une autre voie pour recuperer le bit de sortie du registre 96 bits, pour pouvoir le reinjecter comme Carry=1 à
l'entree ( registre circulaire)
CarryX=Carry[0];
_asm {
movlw 0
btfsc _CarryX,0,1
movlw 1
RRCF W,0,0
nop
d'ou le code
pour 1 seul registre de 96 bits composé de 3 long
L10,L11,L2
depart absolu en 0x40
j'ai donc 7 autres registres , tous contigus depuis 0x0040
L20,21,L22
.....
L80,L81,L82
lors de mes test ,
ça marche tres bien avec 1 seul registre .. mon pixel se deplace bien sur la 1ere ligne
Avec 2 registres et donc 2 lignes ... OK aussi
mais à partir de 3 ... des problemes apparaissent , desynchronisation du balayage
ce n'est donc pas fiable .... la raison m'en echappe
La cohabitation ASM / C parait pourtant correcte.. j'ai pu verifier avec le debugger mikroC
car quand j'affiche sur terminal le binaire des 3 regitres, la progression des bits est correct
apres ça se passe dans les max7219 ..
nota: l'affichage de texte fixe est OK ...
In fine, les MAX7219 forme aussi 8 registres FIFO à decalage
j'abandonne donc cette piste
qui me paraissait pourtant assez logique à suivre .
j'ai essayé aussi la librairie FC16 ..
Library for using the FC-16 display module (based on MAX72xx) with ESP8266 (NodeMCU) and Arduino IDE.
sans succes
je vais laisser decanter pendant 1 semaine ou 2 ...
A+
mes test registre à decalage 96 bits ont été PRESQUE concluant
au passage j'ai pu remarquer que je ne pouvait pas forcer le bit STATUS
Depart=L10;
_asm {
bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
j'ai donc utilisé une autre voie pour recuperer le bit de sortie du registre 96 bits, pour pouvoir le reinjecter comme Carry=1 à
l'entree ( registre circulaire)
CarryX=Carry[0];
_asm {
movlw 0
btfsc _CarryX,0,1
movlw 1
RRCF W,0,0
nop
d'ou le code
Code : Tout sélectionner
CarryX=Carry[0];
_asm {
movlw 0
btfsc _CarryX,0,1
movlw 1
RRCF W,0,0
nop
rlcf _Depart+0,1,0 // rotate left through carry de _Depart[0] (rlcf _Depart,F,ACCESS)
rlcf _Depart+1,1,0
rlcf _Depart+2,1,0
rlcf _Depart+3,1,0
rlcf _Depart+4,1,0 // rotate left through carry de _Depart[1]
rlcf _Depart+5,1,0
rlcf _Depart+6,1,0
rlcf _Depart+7,1,0
rlcf _Depart+8,1,0 // rotate left through carry de _Depart[2]
rlcf _Depart+9,1,0
rlcf _Depart+10,1,0
rlcf _Depart+11,1,0
bcf _CarryX,0,1
btfsc STATUS,0,1
bsf _CarryX,0,1 // memorise report si C=1
nop
nop
}
Carry[0] = CarryX ;
pour 1 seul registre de 96 bits composé de 3 long
L10,L11,L2
depart absolu en 0x40
j'ai donc 7 autres registres , tous contigus depuis 0x0040
L20,21,L22
.....
L80,L81,L82
lors de mes test ,
ça marche tres bien avec 1 seul registre .. mon pixel se deplace bien sur la 1ere ligne
Avec 2 registres et donc 2 lignes ... OK aussi
mais à partir de 3 ... des problemes apparaissent , desynchronisation du balayage
ce n'est donc pas fiable .... la raison m'en echappe
La cohabitation ASM / C parait pourtant correcte.. j'ai pu verifier avec le debugger mikroC
car quand j'affiche sur terminal le binaire des 3 regitres, la progression des bits est correct
apres ça se passe dans les max7219 ..
nota: l'affichage de texte fixe est OK ...
In fine, les MAX7219 forme aussi 8 registres FIFO à decalage
j'abandonne donc cette piste
qui me paraissait pourtant assez logique à suivre .
j'ai essayé aussi la librairie FC16 ..
Library for using the FC-16 display module (based on MAX72xx) with ESP8266 (NodeMCU) and Arduino IDE.
sans succes
je vais laisser decanter pendant 1 semaine ou 2 ...
A+
appel aux specialistes ASM decalage 96 bits
- Gérard
Expert- Messages : 1661
- Âge : 65
- Enregistré en : septembre 2015
- Localisation : Alsace - Haut-Rhin
Bonjour à tous,
C'est bien dommage que ça ne fonctionne pas.
Moi aussi j'aimerais pouvoir piloter plus de 4 matrices. J'espérais trouver une solution dans cette discussion que j'ai suivi sans intervenir.
En tous cas, merci à Paul pour son travail.
C'est bien dommage que ça ne fonctionne pas.
Moi aussi j'aimerais pouvoir piloter plus de 4 matrices. J'espérais trouver une solution dans cette discussion que j'ai suivi sans intervenir.
En tous cas, merci à Paul pour son travail.
appel aux specialistes ASM decalage 96 bits
Bonjour Paulfjujo et autres suivant ce sujet
sans être au clair, loin de là, sur le jeu d'instructions des extended mid-range, les lignes ci-dessus me posent deux problèmes :
paulfjujo a écrit :Source du message Depart=L10;
_asm {
bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
sans être au clair, loin de là, sur le jeu d'instructions des extended mid-range, les lignes ci-dessus me posent deux problèmes :
- 1-
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
je suppose qu'une variable C d'au moins un octet a été déclarée sous le nom Carry1 et que l'assembleur y accède sous le nom _Carry1
au deuxième Carry, je dois lire "_Carry1"? je sais bien que c'est du commentaire, mais c'est pour être sûr.
2 -
bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
Cette différence d'écriture entre le bsf et le bcf n'a-t-elle pas d'influence ? est-elle souhaitée (able) ou accidentelle ?
appel aux specialistes ASM decalage 96 bits
Bonsoir à tous,
Beaucoup de faut MAX7219 circule, ce qui fait qu'il fonctionne pas correctement voir ICI
A+
paulfjujo a écrit :Source du message les MAX7219 forme aussi 8 registres FIFO à decalage
j'abandonne donc cette piste
qui me paraissait pourtant assez logique à suivre .
Beaucoup de faut MAX7219 circule, ce qui fait qu'il fonctionne pas correctement voir ICI
A+
appel aux specialistes ASM decalage 96 bits
- paulfjujo
Expert- Messages : 2598
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
JJE a écrit :Bonjour Paulfjujo et autres suivant ce sujetpaulfjujo a écrit :Source du message Depart=L10;
_asm {
bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
sans être au clair, loin de là, sur le jeu d'instructions des extended mid-range, les lignes ci-dessus me posent deux problèmes :1-
Tu vas bien finir par gagnerbtfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
je suppose qu'une variable C d'au moins un octet a été déclarée sous le nom Carry1 et que l'assembleur y accède sous le nom _Carry1
au deuxième Carry, je dois lire "_Carry1"? je sais bien que c'est du commentaire, mais c'est pour être sûr.
2 -bsf STATUS,C // C=1
btfss _Carry1,0,0 // si le bit 0 de _Carry==1 on saute la RAZ de C , donc C reste à 1
bcf STATUS,0,0 // RAZ C => C=0
Cette différence d'écriture entre le bsf et le bcf n'a-t-elle pas d'influence ? est-elle souhaitée (able) ou accidentelle ?
effectivement CarryX, C (le symbole du vrai Carry du registre STATUS) et "C' ( pour langage C )
= coince neurone
au post #26 , j'ai indiqué que j'avais abandonné ce test , qui ne peut pas marcher
car on ne peut pas FORCER le bit C du registre STATUS par programme !
j'utilise donc ceci :
Code : Tout sélectionner
CarryX=Carry[0] ;
_asm {
movlw 0 ; W=0
btfsc _CarryX,0,1 ; variable langage "C" CarryX accessible en asm via _CarryX
movlw 1 ; W=1
RRCF W,0,0 ; rotation a droite de W -> bit 0 de W tombe dans C (Carry du STATUS)
nop
.. etc ...
le precedent report de bit C , en sortie du registre à decalage de 96 bits a été stocké précedement dans Carry[0]
donc au tour suivant , je veux reinjecter ce report , forcer le C (carry du registre STATUS)
dans l'état ou il etait au moment de la sortie du registre 96 bits.
je charge W avec 0
je teste l'etat du bit 0 de _CarryX
* si il vaut 0 ,je saute l'instruction movlw 1
donc W reste à 0 ,puis rotation à droite de W via C -> Carry C=0
* si il vaut 1, je ne saute pas l'instruction et donc W =1
rotation à droite de W via C -> Carry C=1
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 127 invités