Performance ARM7TDMI (ADuC7024)...

[ATEXA électronique]

Bonjour,

je "bricole" sur un ADuC7024 (ARM7TDMI core) avec une version limitée
de Keil uVision3 et quelque chose me chagrine :
Pour faire passer une sortie de 1 à 0 et recommencer à l'infini, il faut
44 cycles d'horloge à ce µC.
Cela me semble plus qu'énorme pour un µC donné page 4 de la doc
à plus de 40 MIPS peak !?
N'importe quel µC 8 bits actuel me semble à priori bien plus performant !

La valeur du "CPU clock divider" me semble bien réglé (il y a 8 valeurs
possible et je vois bien une modification de temps d'exécution quand je
change cette valeur).

Tout est il dans le "40 MIPS peak" ?
Je pense à qq chose du genre qqs instructions en 1 cycle les autres en n
cycles...
Y a t il une autre explication ?

Si qq'un pouvait éclairer ma lanterne.

D'avance merci,
Alexandre.

[Robert Lacoste]

"ATEXA électronique" <hisawa(remplacer_par_@)wanadoo.fr> a écrit dans le message de news:
43aa2135$0$6677$8fcfb975(remplacer_par_@)news.wanadoo.fr...

Bonjour,

je "bricole" sur un ADuC7024 (ARM7TDMI core) avec une version limitée
de Keil uVision3 et quelque chose me chagrine :
Pour faire passer une sortie de 1 à 0 et recommencer à l'infini, il faut
44 cycles d'horloge à ce µC.
Cela me semble plus qu'énorme pour un µC donné page 4 de la doc
à plus de 40 MIPS peak !?
N'importe quel µC 8 bits actuel me semble à priori bien plus performant !

La valeur du "CPU clock divider" me semble bien réglé (il y a 8 valeurs
possible et je vois bien une modification de temps d'exécution quand je
change cette valeur).

Tout est il dans le "40 MIPS peak" ?
Je pense à qq chose du genre qqs instructions en 1 cycle les autres en n
cycles...
Y a t il une autre explication ?

Si qq'un pouvait éclairer ma lanterne.

Bonjour Alexandre,

Je n'ai jamais utilisé le ADuC7024 mais j'ai une bonne expérience des
ARM7TDMI via la gamme Philips LPC. Les performances que tu obtient sont
effectivement largement en dessous ce que tu devrais avoir. Disons qu'en
assembleur une telle boucle est possible avec 7-8 instructions, peut être le
double avec le compilateur Keil (qui n'est pas particulièrement le plus
efficace), mais surement pas 44...

Quelques pistes :
- as-tu verifié le code assembleur généré ?
- le code est-il en RAM ou en flash ? Dans le cas des chips Philips il y a
un module a activer spécificiquement (le MAM) pour avoir des performances
correctes en flash. Un test en ram devrait te permettre de verifier ce point

Cordialement,

--
Robert Lacoste
ALCIOM - The mixed signal experts
www.alciom.com

[JP]

ATEXA électronique wrote:

avec une version limitée
de Keil uVision3

Bonjour,

Désolé pour le hors sujet, je débute aussi avec les ARMs et je voudrais
savoir quelles sont les limitations de la version d'évaluation de uVision.

Merci d'avance,
JP

[ATEXA électronique]

Bonsoir Robert,

merci pour ta réponse.

je "bricole" sur un ADuC7024 (ARM7TDMI core) avec une version limitée
de Keil uVision3 et quelque chose me chagrine :
Pour faire passer une sortie de 1 à 0 et recommencer à l'infini, il faut
44 cycles d'horloge à ce µC.
....

Je n'ai jamais utilisé le ADuC7024 mais j'ai une bonne expérience des
ARM7TDMI via la gamme Philips LPC. Les performances que tu obtient sont
effectivement largement en dessous ce que tu devrais avoir. Disons qu'en
assembleur une telle boucle est possible avec 7-8 instructions, peut être
le
double avec le compilateur Keil (qui n'est pas particulièrement le plus
efficace), mais surement pas 44...

Quelques pistes :
- as-tu verifié le code assembleur généré ?

Je l'avais vu une fois mais impossible de retrouver la manip.
Mais de mémoire, il faisait une dizaine d'instructions.
Via le debugger j'obtiens bien un code mais il est très confu à mes yeux.
(mais je dirais tjs une dizaine de ligne).

- le code est-il en RAM ou en flash ? Dans le cas des chips Philips il y a
un module a activer spécificiquement (le MAM) pour avoir des performances
correctes en flash. Un test en ram devrait te permettre de verifier ce
point

Le code est en flash.
J'ai bien regardé la doc mais à priori il n'y a pas une telle fonction sur
les ADuc70xx.
Même rien qui y ressemble de loin.

Comme Keil ne te semble pas terrible, en aurais tu un autre à me conseiller
?
D'avance merci.

(remplacer_par_@)+
Alexandre.

[ATEXA électronique]

Bonsoir,

Désolé pour le hors sujet, je débute aussi avec les ARMs et je voudrais
savoir quelles sont les limitations de la version d'évaluation de uVision.

Dans ma version le code est limité à 32 Ko pour le debugger.
Pour le compilateur je ne sais pas (la limite semble au moins supérieure à
50 Ko).

(remplacer_par_@)+
Alexandre.

[Robert Lacoste]

"ATEXA électronique" <hisawa(remplacer_par_@)wanadoo.fr> a écrit dans le message de news:
43ab0c31$0$6688$8fcfb975(remplacer_par_@)news.wanadoo.fr...

Le code est en flash.
J'ai bien regardé la doc mais à priori il n'y a pas une telle fonction sur
les ADuc70xx.
Même rien qui y ressemble de loin.

C'est peut être l'une des raisons de la chose : Aucune flash ne doit
permettre de faire tourner un code à 40mips depuis la flash. S'il n'y a pas
d'"accelerateur" comme le module MAM du Philips alors le processeur attend
surement pas mal de temps ses instructions... Test facile : reconfigurer le
compilateur pour executer le code en RAM, et voir s'il y a une différence...

Comme Keil ne te semble pas terrible, en aurais tu un autre à me
conseiller

J'ai utilisé Keil, et j'ai utilisé CrossWorks for ARM de Rowley
(www.rowley.co.uk), les deux sont bien mais le second est significativement
moins cher (basé sur GCC).


Cordialement, et en en profitant pour souhaiter d'excellentes fêtes à tous
les participants de ce newsgroup !
Robert
www.alciom.com

[ATEXA électronique]

Bonjour Robert,

merci pour ta réponse.

Le code est en flash.
J'ai bien regardé la doc mais à priori il n'y a pas une telle fonction
sur les ADuc70xx.
Même rien qui y ressemble de loin.

C'est peut être l'une des raisons de la chose : Aucune flash ne doit
permettre de faire tourner un code à 40mips depuis la flash.

???
Les DSPIC c'est de la flash et ils tournent bien à 30 MIPS (et les nouveaux
tourneront à 40).
Une limitation à ce niveau me semble donc étrange.

S'il n'y a pas d'"accelerateur" comme le module MAM du Philips alors le
processeur attend surement pas mal de temps ses instructions...
Test facile : reconfigurer le compilateur pour executer le code en RAM,
et voir s'il y a une différence...

Cela semble possible mais pour l'instant je n'ai pas trouvé comment faire.

De toutes façons, faire tourner le programme en RAM (alors qu'il en a pas
beaucoup par rapport à la flash) et ceci pour atteindre les 40 MIPS cela
ne me semble pas "terrible".

Je pense qu'il a une astuce qq part ou alors ce µC a un intérêt plus que
limité par rapport à un simple µC 8 bits.

Comme Keil ne te semble pas terrible, en aurais tu un autre à me
conseiller

J'ai utilisé Keil, et j'ai utilisé CrossWorks for ARM de Rowley
(www.rowley.co.uk), les deux sont bien mais le second est
significativement moins cher (basé sur GCC).

Merci pour l'info.

(remplacer_par_@)+
Alexandre.