macro dans une macro pour un microcontrôleur Pic

[invite5396f733]

bonjour,

à la suite d'un disfonctionnement (aléatoire !) lors du déroulement d'un programme je me demandais s'il était posssible d'écrire une macro dans une macro ?

Arzew
-----

[Jack]

A ma connaissance, les microcontrôleurs n'exécutent pas de macro, mais des instructions.

Ou alors ta question manque énormément de précision.

[invited3dcf66c]

Comme le dit Jack, un microcontrôleur ne sait que travailler avec des instructions. Le reste... Les macros, en C (je suppose), c'est le préprocesseur qui les traite. Et si c'est de cela dont tu te parles, alors oui, une macro peut en appeler une autre. Peut-être peux tu publier un bout de code pour qu'on voit le problème?

[invite5396f733]

je suis très étonné de vos doutes étant donné que le fameux cours de bigonnof parle, lui, de macro pour les micro-contrôleurs Pic .
Une macro est une suite d'instructions, elle permet au programmateur de l'insérer dans un programme afin d'éviter de la réécrire chaque fois ...

un exemple:

tempo macro
movlw .239
movwf T1
call tempo
endm

allumage_led macro
bsf GPIO,0
call tempo
bcf GPIO,0
endm

[A voir en vidéo sur Futura]

[Jack]

Afin de ne plus être étonné la prochaine fois, essayez d'être plus précis. Les macro sont destinées aux compilateurs et assembleurs, pas aux microcontrôleurs. De plus la syntaxe diffère évidemment entre les macro pour compilateurs et assembleurs.

Je voulais juste attirer votre attention sur le manque d'éléments de la question qui ne pouvait donc conduire à une réponse directe.

Pour répondre plus directement au problème, une macro est une substitution de texte, donc pas de problème à en imbriquer une dans une autre.

[paulfjujo]

bonjour,

tempo macro
movlw .239
movwf T1
call tempo
endm

l'assembleur doit avoir du mal à s'y retouver si la macro s'appelle elle-eme
call tempo
appelle un sous programme qui se termine par un retour
à moins de changer le nom de la macro

tempo1 macro
movlw .239
movwf T1
call tempo
endm

ce qui pourrait donner

allumage_led macro
bsf GPIO,0
tempo1
bcf GPIO,0
endm

[Jack]

Ah bin oui, si la macro s'appelle elle-même, ça na va pas marcher.

[invitef86a6203]

Les macros ne s'appellent pas avec un call ce sont les procédures qui s'appellent avec call
De plus un call entraine un empilage d'adresse de retour , avec un pic le stack est vraiment petit...
Une macro qui contient sa propre macro est à priori impossible , ou le compilateur gère le cas ou il finit par un truc du genre "stack overflow" ou "out memory" mais bon, il sera planté s'il ne le gère pas.

Il existe des fonctions (procédures) récursives qui s'appellent elles mêmes, mais dans ce cas la fonction ne doit pas empiler plus que ce que la pile le permet avec un pic16F876 c est 8 max ça fait très court !
Donc au bout de 8 empilages max la condition de retour doit être vrai sous peine de gros plantage.
Avec le tout petit pic12C509 2 niveaux seulement autrement dit , c est même pas jouable...

De toutes façons c'est toujours très risqué, surtout avec seulement 8 niveaux max.

*Un exemple totalement inutile mais juste pour illustrer
(noter que si count contient plus que le nombre de pile utilisable on est planté ! )

De plus s'il s'agit de compilateur C , certains comme SDC, ont tendance à copier les gros compilateurs qui appellent le main avec un call comme s'il était sous un OS, donc méfiance...

; count variable global

main:
  movlw 6
  movwf count
  call MyRecurs
goto main

MyRecurs;
  decf count,f
  btfss STATUS,z
  call MyRecurs
return

[invite5396f733]

bonjour,

tempo macro
movlw .239
movwf T1
call tempo
endm

l'assembleur doit avoir du mal à s'y retouver si la macro s'appelle elle-eme
call tempo
appelle un sous programme qui se termine par un retour
à moins de changer le nom de la macro

tempo1 macro
movlw .239
movwf T1
call tempo
endm

ce qui pourrait donner

allumage_led macro
bsf GPIO,0
tempo1
bcf GPIO,0
endm

exacte, ceci n'est qu'un exemple, et non pas celui que j'utilise
Je vois que tu as corrigé par toi-même

[invite5396f733]

Afin de ne plus être étonné la prochaine fois, essayez d'être plus précis. Les macro sont destinées aux compilateurs et assembleurs, pas aux microcontrôleurs. De plus la syntaxe diffère évidemment entre les macro pour compilateurs et assembleurs.

Je voulais juste attirer votre attention sur le manque d'éléments de la question qui ne pouvait donc conduire à une réponse directe.

Pour répondre plus directement au problème, une macro est une substitution de texte, donc pas de problème à en imbriquer une dans une autre.

la réponse est donnée ... elle était donc simple et ma question était comprise

[Jack]

Tu ne peux pas savoir le nombre de fois ou on a du attendre 20 ou 30 message afin d'identifier exactement quel était le problème parce que plusieurs interprétations possibles conduisaient à des solutions différentes.

Dans ton cas, j'avais compris a quoi tu faisais allusion. D'autres aussi et tu as obtenu ta réponse et c'est tant mieux.

Je persiste toutefois à dire que la question n'était pas suffisamment précise puisque d'après le code qui tu donnais tu voulais savoir si une macro pouvais s'appeler elle-même (ce qui n'est pas possible) alors que la question était de savoir si on pouvait écrire une macro dans une macro (ce qui est possible)

A+

[invite5396f733]

oui tu as raison, en plus l'exemple que je donnais n'était pas le mien
C'est vrai qu'en lisant ma routine on a du mal à s'imaginer que cela fonctionne, je me mets à ta place

En fin de compte je cherchais dans la mauvaise direction car en insérant le Pic dans une plaquette d'essai je me rends compte que mon programme fonctionne comme il se doit .
Conclusion : sur ma carte il a un fonctionnement aléatoire , sur la plaque d'essai il fonctionne !
J'ai testé les pistes de carte et n'ai trouvé aucune défaillance, y aurait-il quelque chose du côté des parasites ?
Une capa de 220nF est en // sur le Pic (au plus prés du Pic), une capa de 100uF polarisée est aux bornes de régulateur 7805 entre le 12Volts et la masse, les relais commandés par GPIO,1 et GPIO,5 via des transistors ont une diode 1N4148 à leurs bornes.
Y aurait-il quelques choses à faire ?

Arzew

[Jack]

Il faudrait effectivement commencer par jeter un œil du côté des alim avec un oscilloscope:
- vérifier si la tension est bien continue et stable quelque soient les sorties activées
- vérifier s'il n'y a pas de pulses parasites temporaires lors de la commutation des I/O (scope en mode monocoup)

A+

[invite5396f733]

un oscilloscope serait effectivement le bien venu
Mais quand on regarde la platine d'essai, les éléments sont plaçés exactement comme sur la carte !!!
et pourquoi sur la carte il y aurait des perturbations ?
Cela fait la 3° carte que je fais et même problème ... c'est le premier circuit avec lequel j'ai ce genre de problème

[invite5396f733]

mon alimentation est une batterie 12V, les seules perturbations possibles sont celles des relais qui possèdent eux-même une diode de protection

[Jack]

L'alim 5V est-elle la même sur la platine d'essai et sur la carte?

[invite5396f733]

bonsoir,

je reviens avec mon problème ... qui n'en est plus un !
Si cela peut servir à quelqu'un c'est toujours ça ... j'ai remarqué, par curiosité, que la tension d'alimentation, même passant par le régulateur, variait de 4.88 à 5.02 V lorsque les relais belges s'alimentaient ou lorsqu'une entrée du Pic se trouvait au zéro logique (détection pour une interruption) .
Le fait de coupler un condensateur le processus était atténué.
Le plus fort c'est que sur la platine d'essai le montage fonctionnait sans ce condensateur de forte valeur : 2200uF
J'en ai mis un sur le 12V et le 5V.

Arzew