Bonjour à tous !
J'aurais juste besoin d'un petit renseignement à propos d'un microcontroleur : Ce dernier à une fréquence CPU de 80 MHz, et une fréquence BUS de 40 MHz. J'essaye d'observer la fréquence maximum de changement d'état d'une pin. Je trouve seulement une fréquence de 5 MHz ! Cela vous parait-il probable ? Parce que j'aurais besoin d'une fréquence de 24 MHz ... et je suis loin de l'avoir !
Merci d'avance !
Julien.
Tu la pilotes par un soft qui met à "1" et à "0" ta pinoche ?Envoyé par jponnoua
Compte le nombre d'instruction et leurs temps d'exécution .......et tu auras la fréquence maximum.
PS: faire du 24 Mhz comme ça ........ un peu irréaliste !
J'aime pas le Grec
Voici le code :
while(1)
{
MCF_EPORT_EPDR = 0;
MCF_EPORT_EPDR = 128;
}
Et je regarde au scope la fréquence du changement. Par contre, comment puis-je faire pour compter le nombre d'instructions ? Le mode débuggage ne me le permet pas car il éxécute chaque ligne d'une seul traite, même en utilisant le "Step Into".
Mon pôvre ! tu n'as même pas dit de quel microcalculateur on cause ! Et on sait maintenant que tu écris en "C". Entre nous, pas génial si tu cherches la rapidité !
Tu désassembles ton programme compilé
Tu comptes le nombre d'instruction
Tu regardes le nombre de cycle par instruction sur la doc du µC
....... et tu auras 5 Mhz.
Ca t'avance à quoi? 24 Mhz, c'est de l'utopie !
J'aime pas le Grec
Je ne cherche plus à avoir les 24 MHz, je cherche juste à comprendre pourquoi j'obtiens 5 MHz. Le microcontroleur est le MCF5213R, et je programme en C.
Et bien tu as ma réponse #4 qui te donnes la solution
J'aime pas le Grec
Bonsoir,
Les PIC32 fonctionnent à 80MHz et sont capables de changer l'état des sorties à chaque cycle donc tu peux générer du 40Mhz sur une broche, mais le signal ne sera pas très joli....
Par contre si tu utilises un PIC24H ou dsPIC33 à 40 MIPS, tu peux changer une broche à la fréquence de 20MHz.
Tous les PICs sont capables de faire du bit toggling à la moitié de la fréquence du programme (Tcy).
En programmation en "C" aussi ?
Et en assembleur, il y a 3 instructions pour toggler un bit, pas 2 !
J'aime pas le Grec
Bonjour,
Et à part inverser une sortie, le µC ne fait rien d'autre.
Autant utiliser un oscillateur classique.
ICI:
bcf portB0
bsf portB0
goto ICI
3 instructions dont 1 saut
Pas possible de faire + simple, c'est accadémique et ne sert à rien.
Je me suis laisser dire que certains compilateurs C optimisait très bien la génération de code. (rapidité, taille du code)
Je me fais un film?
Moi ignare et moi pas comprendre langage avec «hasard», «réalité» et «existe».
Comme on ne connait pas le µC, ni le compilateur, il n'y a qu'une certitude :
Vitesse en "C" <= Vitesse en "assembleur" ...... mais pas mieux
J'ai mis le "=" par honnêteté
J'aime pas le Grec
Sur un problème simple, c'est évident.
Sur un problème complexe, je ne suis pas sûr qu'un programmeur en assembleur puisse encore lutter avec une machine. (Un bon compilateur)
Je me fais peut-être des idées, je suis cela d'assez loin.
Moi ignare et moi pas comprendre langage avec «hasard», «réalité» et «existe».
Bonsoir
Non il existe d'excellents compilateurs, Diabdata sur PPC est redoutable.
JR
l'électronique c'est pas du vaudou!
Bonsoir,
Dans le cas des 16bits (compilateur C30), il existe une astuce pour se passer des librairies _builtin pour conserver la compatibilité ANSI C : LATA ^= (1 << 0) ;
Cela génère une seule instruction assembleur et il faut bien sûr activer l'optimisation
Si on utilise LATA ^= 1 ; le résultat est bien moins bon...
Comme quoi une bonne connaissance du jeu d'instructions assembleur d'un micro permet d'optimiser le codage en C
Bonsoir
Le µC de jponnoua est un ColdFire dont la gamme commence avec des µC type MCF5213 à 80MHz et se termine avec des µP à 300 MHz et FPU intégrée, qui n'ont rien du tout à envier aux PICS de n'importe quelle sorte.
Pour revenir au problème initial, la traduction en assembleur par CodeWarrior est la suivante :
qui fait 5 cycles ( ce qui devrait faire 8Mhz) et pourrait effectivement être optimisé en sortant move.b #-128,d0 de la boucle. Il y a peut être encore une division de l'horloge par 2 quelque part - à vérifier dans les bitrs de configuration du port, de la distribution de l'horloge, ... etcCode:; 23: MCF_EPORT_EPDR = 0; ; 0x0000001E 0x423940130004 clr.b 0x40130004 ; ; 24: MCF_EPORT_EPDR = 128; ; 25: ; 26: ; 0x00000024 0x103C0080 move.b #-128,d0 ; '.' 0x00000028 0x13C040130004 move.b d0,0x40130004 ; ; 27: } ; 0x0000002E 0x60EE bra.s *-16 ; 0x0000001e
Quand au C vs assembleur, oui, cetains µC ont des instructions optimisées pour le C, par exemple DBNZ (Decrement and Branch if Not Zero), qui peuvent traduire des tests/branchements en C en une seule ligne d'assembleur, mais ce sont en général des instructions CISC...
Et quand aux pics qui sortent une fréquence F/2 sur leurs pins, il faudra aussi que l'on m'explique comment on peut :
- basculer un bit à 0
- basculer un bit à 1
- faire un branchement
en 2 cycles d'horloge.
Thierry
Un pic a besoin de 4 fronts montants du "clock" pour exécuter une instruction si j'ai bien compris ?
si je me plante pas, c'est donc électriquement impossible de faire du 24 Mhz avec une horloge a 80, quelque soit le code.
sinon, en C :
while(1){
RC5=!RC5
}
ça donne du code assembleur plutôt bourrin avec SDCC (enfin un gros pavé au début, mais la boucle est courte).
Dans la pratique a l'oscillo je vois pas la sortie changer d'état sur mon 16F877 a 20 Mhz, je sait pas si c'est a cause de mon oscillo trop lent ou si c'est que matériellement ça ne marche pas.
Enfin utiliser un microcontroleur pour fabriquer un signal carré "fixe" et sans conditions, c'est a mon avis une mauvaise solution. quelque soit la puissance du microcontroleur en question.
Finalement j'ai dit une connerie, ca fait du code "tout pourri" pas optimisé du tout.
en tous cas mon oscillo est quand même complètement dans les choux, je vois un signal tout plat bourré de transitoires.
Un programme en assembleur sera toujours plus rapide qu'un programme compilé en langage évolué. L'assembleur est le langage natif du'un µP. On ne peut pas être plus rapide !
PS: je parle "en exécution" ....... pas en temps de développement !
J'aime pas le Grec
Salut,
Tu as mal lu...
C'est bien la moitié de la fréquence programme, soit 2TCY (cycles)...
Maintenant, en reprenant l'exemple initial, en ASM PICs, c'est 3TCY avec le retour sur la boucle.
Mais comme dans l'ASM Coldfire le signal en sortie n'est pas carré du fait de l'exécution du branchement inconditionnel.
Si il faut impérativement un signal carré, c'est minimum 4TCY...
David.
Salut Gérard,
Si plus simple :
Ici
COMF PORTb
goto Ici
Soit 2 instructions et trois cycles en considérant 1 sortie et 7 entrées sur le portb.
David.
Salut,
Il n'existe pas une instruction d'inversion de bit en ASM?- basculer un bit à 0
- basculer un bit à 1
- faire un branchement
Ce qui donnerait:
-inversion de bit
-branchement
Soit 2 cycles
(Ça fait longtemps que je n'ai pas fait d'ASM, c'est une question)
Salut David,
Tu marques un point mais tu seras certainement d'accord avec moi pour dire que nos 2 solutions sont inutiles.
2 instructions, oui mais 3 cycles, le saut durant 2 cycles.
Salut,
Si l'instruction existe, mais le problème c'est le saut qui demande généralement deux cycles voir plus suivant les µC...
Gérard, c'est évident que cela ne sert à rien, mais bon, la question a été posée alors...
David.
OK, merci, mais alors:
Comment c'est possible?Les PIC32 fonctionnent à 80MHz et sont capables de changer l'état des sorties à chaque cycle donc tu peux générer du 40Mhz sur une broche, mais le signal ne sera pas très joli....
Par contre si tu utilises un PIC24H ou dsPIC33 à 40 MIPS, tu peux changer une broche à la fréquence de 20MHz.
Il y a une instruction "toggling"?
EDIT: Ou alors il faut remplir la mémoire d'inversion de bits et faire un saut à la fin(mais lá, c'est pire qu'inutile, c'est completement c**)
Oui...
Existe aussi sur les 18F(et tout un tas de µC) soit l'instruction BTG -> bit toggle.
David.
Et comment ca marche?
C'est une inversion de bit à répétition? Elle s'arrete quand?
En pratique cela ne sert à rien d'inverser un signal à la vitesse max du µC...
Si je prends l'exemple du PIC18, l'instruction BTG s'exécute en 1 cycle et inverse un bit x du port y.
Donc, elle ne l'inverse qu'une fois!
Si tu veux que ton programme face cela continuellement, il suffit de remplir l'intégralité de la mémoire avec cette instruction.
Le saut en fin de mémoire programme est inutile du fait que le compteur programme saute de façon hardware à l'adresse 0 après l'exécution de la dernière case mémoire programme, de plus ce saut induirait une erreur du signal en sortie de deux cycles à chaque exécution de ce saut.
David.
OK, merci, mais alors:
Comment c'est possible?
Il y a une instruction "toggling"?
EDIT: Ou alors il faut remplir la mémoire d'inversion de bits et faire un saut à la fin
MDR
ou comment réaliser un oscillateur, mais en beaucoup plus compliqué et plus cher
Bien sûr, à condition de trouver "à la main" la bonne optimisation en assembleur, ce qui n'est pas si évident que cela si les compilo C sont performants.
Ca me ferait une belle jambe de me dire que je pourrais faire mieux que le compilateur C mais que je n'y arrive pas...
<mode Roseline on>
Ah bon!?
<mode Roseline off>
Moi ignare et moi pas comprendre langage avec «hasard», «réalité» et «existe».
