Assembleur et Compilateur Hi tech

[invite50cc55df]

Bonjour,

J'ai fais un programme en C que je dois compiler pour un PIC.
Le programme fonctionne mais n'a pas la réactivité souhaité. S'agissant d'un système temps réelle ça me pose problème...

Après recherche, il semble que le problème vient de cette instruction :

if(TMR0>=ts[0]) RB0=0;

L'instruction est très simple, elle compare la valeur du registre TMR0 à une valeur contenue dans un tableau. Si plus grand ou égal, je change l'état d'un port.

J'ai analysé le code ASM et voici ce que ça donne :

    bsf	status, 5	;RP0=1, select bank1
     bcf	status, 6	;RP2=0, select bank1

     bcf	status, 5	;RP0=0, select bank0
     bcf	status, 6	;RP2=0, select bank0

     movf	(1),w	;volatile

     movwf	(??_main+2+0)
     clrf	(??_main+2+0+1)
     bsf	status, 5	;RP0=1, select bank1
     bcf	status, 6	;RP2=0, select bank1
     movf	(208+1)^080h,w
     bcf	status, 5	;RP0=0, select bank0
     bcf	status, 6	;RP2=0, select bank0
     subwf	1+(??_main+2+0),w
     skipz
     goto	u2335
     bsf	status, 5	;RP0=1, select bank1
     bcf	status, 6	;RP2=0, select bank1
     movf	(208)^080h,w
     bcf	status, 5	;RP0=0, select bank0
     bcf	status, 6	;RP2=0, select bank0
     subwf	0+(??_main+2+0),w

u2335:
      skipc
      goto	u2331
      goto	u2330

u2331:
      goto	l22
u2330:
      bcf	(48/8),(48)&7

l22:
      [suite du programme ...]

Il y a une trentaine d'instructions ce qui me fait perdre 30us. Étant donné que je fais 7 autres comparaisons (8 en tout), je perds pratiquement 240us.
Or je ne dois pas dépasser 64us pour les 8 comparaisons, soit 8us par comparaisons.

Je ne connais pas l'assembleur, j'aurai besoin d'aide pour analyser ce code et l'optimiser.

Merci
-----

[Jack]

Tu as plus de chance d'avoir des réponses dans le forum électronique vers lequel je transfère cette discussion.

[invite29971eb1]

Il faudrait déjà définir ce qu'est du "temps-réel". En soit, ça n'existe pas, et ce n'est qu'un terme commercial pour se faire mousser.

Le "temps-réel", c'est le temps de réaction imposé par ton cahier des charges. Dans une application de chauffage, le temps de réaction pourra être de plusieurs minutes que ce sera encore du temps-réel, d'où l'intérêt de préciser...

Maintenant, plusieurs points:
- un PIC16 exécute une instruction en 4 temps de cycle, donc avec un quartz à 20MHz, tu tournes à l'équivalent de 5.
- il utilise des banks mémoire et un unique registre de travail, donc tu perds beaucoup de temps dans ton code à faire des sauts de banks (ou pages mémoire dans la langue de Lucchini) ou à switcher le contenu de W
- il utilise un unique vecteur d'interruption dans lequel tu dois comparer chaque bit du registre d'état d'interruption pour savoir d'où vient celle-ci.
- l'utilisation de l'interruption timer est fortement recommandée dans ce cas, permettant de réagir en une poignée de temps de cycle. Je ne sais pas pour ce PIC, mais certains micros proposent des sorties qui basculent automatiquement quand la valeur du timer atteint un seuil déterminé (sortie Output Compare).

Bref, il y a peut-être un mauvais choix de composant, mais il y a aussi surement une mauvaise méthode....

[invite50cc55df]

Il faudrait déjà définir ce qu'est du "temps-réel". En soit, ça n'existe pas, et ce n'est qu'un terme commercial pour se faire mousser.

Le "temps-réel", c'est le temps de réaction imposé par ton cahier des charges. Dans une application de chauffage, le temps de réaction pourra être de plusieurs minutes que ce sera encore du temps-réel, d'où l'intérêt de préciser...

Il me semble que je répond à cette question :

Il y a une trentaine d'instructions ce qui me fait perdre 30us. Étant donné que je fais 7 autres comparaisons (8 en tout), je perds pratiquement 240us.
Or je ne dois pas dépasser 64us pour les 8 comparaisons, soit 8us par comparaisons.

Je me suis certainement mal exprimé, donc je reprend et je rentre plus en détail.
J'ai un quartz de 4Mhz, donc j'ai 1 instruction = 1us (sauf certaines instructions qui prennent plusieurs cycles d'horloge).

J'utilise le timer0 pour générer 8 impulsions. J'ai un tableau Ts[8] comprenant les 8 valeurs de durée d'impulsions et je compare à tour de rôle ces 8 valeurs à la valeur de TMR0.

En gros j'ai ça :

while(1){

if(TMR0>=ts[0]) RB0=0;
if(TMR0>=ts[1]) RB1=0;
if(TMR0>=ts[2]) RB2=0;
if(TMR0>=ts[3]) RB3=0;
if(TMR0>=ts[4]) RB4=0;
if(TMR0>=ts[5]) RB5=0;
if(TMR0>=ts[6]) RB6=0;
if(TMR0>=ts[7]) RB7=0;

}

//si interruption sur depassement de TMR0 :
RB0=1;
RB1=1;
RB2=1;
[...]

Maintenant que je suis rentré dans le détail, j'en reviens à ma problématique :

Cette comparaison qui est extrêmement simple en langage C ( if(TMR0>=ts[0]) RB0=0; ) prend une trentaine d'instructions en Assembleur (qui est le langage de programmation du PIC généré automatiquement par mon compilateur).
30 instructions X 8 comparaisons = 240 us.

Pour que mon système soit optimal, il ne faut pas que je dépasse 8 instructions par comparaisons (64us au total c'est la résolution de mes 8 signaux et correspond au prescaler de TMR0).

Donc, sur la base du code ASM fourni, peux-tu me dire si le code te semble correcte, n'y a t-il pas moyen de le simplifier? 30 instruction pour comparer une valeur et modifier un port, ça ne te semble pas beaucoup?

Merci

[A voir en vidéo sur Futura]

[invitee05a3fcc]

Question idiote ? et avec un quartz 16 Mhz .....

[invite29971eb1]

Je me suis certainement mal exprimé, donc je reprend et je rentre plus en détail.
J'ai un quartz de 4Mhz, donc j'ai 1 instruction = 1us (sauf certaines instructions qui prennent plusieurs cycles d'horloge).

Je n'avais pas vu, mea culpa.

Donc, sur la base du code ASM fourni, peux-tu me dire si le code te semble correcte, n'y a t-il pas moyen de le simplifier? 30 instruction pour comparer une valeur et modifier un port, ça ne te semble pas beaucoup?

Tu peux déjà, comme le suggère Daudet78, augmenter la fréquence du quartz.

Ensuite, la plupart de ton code est bouffé par les changements de page mémoire (12 instructions sur les 30).

Il n'y a pas 36 solutions:
- augmentation de la fréquence du quartz
- choix d'un micro plus rapide et doté de plusieurs registres de travail
- meilleure utilisation du hardware (si assez de timers sont dispos sur ton micro)
- optimisation de l'utilisation de la mémoire pour limiter les changements de page (si c'est possible, je connais pas assez les PIC pour savoir)....

Mais c'est certain qu'avec un micro sans pagination et avec plusieurs registres de travail, ça serait une toute autre affaire, voire même avec un micro doté de 8 sorties "Timer Compare".

Que cherches-tu à faire? piloter des servomoteurs?

[Jack]

mmarc2007, tu ne dis pas de quel type sont les données du tableau. Si ce sont des entiers de 32 bits, ça prendra plus de temps qu'avec des entiers de 16 bits.

A+

[invitef26bdcba]

Salut,

n'y a t-il pas moyen de le simplifier?

Si, sur les 24 instructions du post#1, il est largement possible d'en supprimer 12...
Faut juste placer ton tableau au bon endroit (dans la même page que le TMR0)

Ensuite, une ligne C de ce type:

if(TMR0>=ts[0]) RB0=0;

c'est quatre lignes en langage d'Assembleur pour ton PIC16. Si tu organises ton test de manière intelligente,avec le test conditionnel qui va bien, il est possible d'économiser 1 cycle d'instruction.

Conclusion, suivant ce que tu souhaites faire, il est possible d'exécuter les 8tests en 40cycles minimum et maximum 48cycles.

Attention que le test et la soustraction c'est deux cycles, donc dans le pire des cas, cela va prendre 50 cycles avec l'entrée dans la routine. Cela rentre donc sans problème avec la limite des 64µSec que tu as, et pour le moment tu peux encore garder une vitesse de cycle lente d'1µsec.

Mais c'est certain qu'avec un micro sans pagination et avec plusieurs registres de travail, ça serait une toute autre affaire, voire même avec un micro doté de 8 sorties "Timer Compare".

Ben, cela marche parfaitement avec ce type de fonctionnement et µC sous-cadencé...

Sur une archi ancienne comme celle-là, ça ne parait presque pas aberrant que ça prenne 30 cycles.

Ben oui, une fois de plus c'est la faute du µC...
Là, la faute est clairement d'utiliser le C, sans se soucier de comment fonctionne le µC!

tu ne dis pas de quel type sont les données du tableau

Vu le listing Assembleur, c'est un nombre codé sur 8bits.

David.

[RISC]

Salut,

Plusieurs aspects à considérer....
1/ Le compilateur Hitech possède plusieurs versions : Lite / standard / Pro
2/ il existe 3 coeurs différents pour les PIC16 : PIC16 baseline / PIC16 middlerange / PIC16F1

Cela fait de multiples possibilités....

Si tu utilises un PIC16F1xxx avec la license PRO, ton code aura cette taille :

244:               	if(TMR0>=ts[0]) RB0=0;
  1D50    0020     MOVLB 0
  1D51    0820     MOVF 0x20, W
  1D52    0215     SUBWF 0x15, W
  1D53    1C03     BTFSS 0x3, 0
  1D54    2D56     GOTO 0x556
  1D55    2D57     GOTO 0x557
  1D56    2D59     GOTO 0x559
  1D57    100D     BCF 0xd, 0
  1D58    2D59     GOTO 0x559

De plus la famille PIC16F1xxx tourne à 32MHz...( 8 MIPS = 125ns / cycle )

Pour résumer :
1/ si on choisi un PIC16 récent (PIC16F1xxx), le coeur possède 49 instructions au lieu de 35. Résultat : une taille de code inférieure de 30% comparé aux coeurs PIC16 plus anciens
2/ les compilateurs HiTech avec license génèrent un code plus compact (c'est la différence principale entre un compilateur payant et gratuit)

a+

[invite50cc55df]

Tout d'abord merci à tous

Pour condenser un peu toutes les questions/réponses :

- J'utilise un Pic 16F628
- C'est un programme pour piloter 8 servomoteurs via le port RS232
- effectivement j'utilise le compilateur gratuit, j'ai vu sur d'autres sujets traités que le code est loin d'être optimisé :/
- Utiliser une fréquences plus importante permettrait de résoudre mon problème mais faudrait que je reprenne une bonne partie de mon code
- J'ai utilisé la vue "Disassembly Listing" qui permet de voir le code ASM en live. Au final si je fais :

temp=TMR0;
if(temp-test1<0) S1=0;
if(temp-test2<0) S2=0;

ça simplifie pas mal le code

113: if(temp-test1<0) S1=0;
   10F    087A     MOVF 0x7a, W
   110    0222     SUBWF 0x22, W
   111    00A4     MOVWF 0x24
   112    087B     MOVF 0x7b, W
   113    1C03     BTFSS 0x3, 0
   114    0A7B     INCF 0x7b, W
   115    0223     SUBWF 0x23, W
   116    00A5     MOVWF 0x25
   117    1FA5     BTFSS 0x25, 0x7
   118    291A     GOTO 0x11a
   119    291B     GOTO 0x11b
   11A    291C     GOTO 0x11c
   11B    1186     BCF 0x6, 0x3

Je vais tester tout ça et je fais un retour!

[RISC]

Salut,

Mon message précédent comporte une erreur...La compilation était en mode LITE sur un PIC16F1xxx

En mode PRO avec optimisation maximum ( 9 ) cela donne cela ;=) :

244:               	if(TMR0>=ts[0]) RB0=0;
  0843    0820     MOVF 0x20, W
  0844    0215     SUBWF 0x15, W
  0845    1803     BTFSC 0x3, 0
  0846    100D     BCF 0xd, 0

Généralement le mode PRO donne un code 40% plus petit que le mode LITE.
En utilisant la famille F1 même en mode LITE on gagne déjà en vitesse et aussi en taille de code

a+

[invite50cc55df]

Merci pour l'info!

En fait j'ai trouvé mon problème! le registre W est sur 8 bits et dans mon code j'utilisais des "int" qui sont codés sur 16 bits...
Ce qui explique dans le code ASM les accès registres répétitifs.

Donc dans un deuxième temps j'ai essayé avec le "char" qui est sur 8 bits, mais le code devenait beaucoup plus lourd avec l'utilisation de "bank de mémoire". Je suppose que c'est une méthode adapté au stockage des "char" sensés à la base contenir des caractères ascii...

Au final j'utilise le "unsigned" seul et le code devient encore plus simple :

98:                			if(tempTmr0>tempo0) S0=0;
   06E    0821     MOVF 0x21, W
   06F    027B     SUBWF 0x7b, W
   070    1D03     BTFSS 0x3, 0x2
   071    2874     GOTO 0x74
   072    0820     MOVF 0x20, W
   073    027A     SUBWF 0x7a, W
   074    1803     BTFSC 0x3, 0
   075    2877     GOTO 0x77
   076    2878     GOTO 0x78
   077    2879     GOTO 0x79
   078    1006     BCF 0x6, 0

J'ai 8 instructions c'est ce que je voulais

Résolu

[RISC]

Salut,

Les int sont effectivement souvent codés sur 16bits sur les compilateurs 8bits.
L'usage des char est recommandé autant que possible pour avoir un code compact.

a+