L' électron en mouvement   



Une Introduction aux DSP




4.3. Structure matérielle de développement


Un environnement (ou système) de développement pour DSP peut être scindé en deux parties principales:




4.3.1. Le simulateur


Le simulateur est un programme particulier exécuté par un PC ou une station de travail. Son rôle consiste à simuler le plus exactement possible le fonctionnement du DSP cible. L’interface utilisateur du simulateur permet de consulter les mémoires, tous les registres internes du DSP, ses entrées/sorties, etc. Le simulateur exécute chaque instruction DSP comme le ferai le DSP lui-même, et en répercute les résultats dans les mémoires et les registres simulés.


L’avantage de ce moyen de développement est qu’il ne nécessite pas la mise en œuvre du DSP cible, le test d’un module logiciel peut donc se faire rapidement dès sa création. Comme l’indique la figure 9, l’écriture d’un logiciel DSP est un processus très itératif, la disponibilité d’un simulateur est donc toujours appréciable eu égard au gain de temps de développement qu’il génère.


L’inconvénient est que le logiciel DSP en cours de développement n’est pas du tout exécuté en temps réel. Les opérations d’entrées/sorties sont simulées en utilisant des fichiers sur le disque dur du PC. Le simulateur devient vite limitatif lorsqu’il s’agit de tester le code en charge des opérations d’entrés/sorties.





4.3.2. Le module d’évaluation


Le module d’évaluation se présente sous la forme d’une carte électronique incorporant le DSP cible et le minimum des ressources nécessaires à sa mise en œuvre, telles que des mémoires externes, un AIC, le cas échéant une liaison série RS232, et une alimentation. La partie matérielle est figée et n’est pas (ou alors très peu) évolutive. Un module d’évaluation s’utilise donc généralement « tel quel », et est surtout utile quand ses caractéristiques recouvrent celles de l’application à développer. Le module est piloté à partir d’un logiciel adéquat exécuté par un PC.


La communication avec le module d’évaluation s’effectue au travers d’une liaison série s’il s’agit d’un modèle autonome, ou à via un bus du PC s’il s’agit d’une carte à enficher. Le programme à tester est téléchargé dans le module pour être exécuté par le DSP.


Comme le simulateur, le module d’évaluation permet de consulter la mémoire et les registres du DSP à volonté. Il permet également de poser des points d’arrêts simples aux endroits stratégiques du code à déboguer.


Un problème posé par les modules d’évaluations est la non disponibilité de l’ensemble des ressources du DSP. En effet, en plus du code à tester, le DSP exécute également un mini moniteur de débogage, chargé de communiquer avec le PC et d’interpréter des commandes de bases. Une partie des interruptions et de la mémoire du DSP est donc attribué au moniteur de débogage.


Un module d’évaluation n’en reste pas moins un outil de développement approprié pour tester des parties de codes en temps réel. Il est disponible immédiatement, ce qui n’est pas toujours le cas du prototype de l’application à développer, et son faible prix en fait souvent un outil d’apprentissage apprécié.





4.3.3. L’émulateur temps réel


L’émulateur temps réel est l’outil privilégié pour développer des applications DSP. C’est l’outil le plus souple et le plus performant, car il ne souffre pas des limitations d’un simulateur ou d’un module d’évaluation. Son rôle consiste à émuler en temps réel le fonctionnement du DSP au sein même du prototype de l’application à développer. Toutes les ressources du DSP cible sont libres pour tester non seulement le code du programme de l’application, mais également le fonctionnement du prototype.


Tout comme le module d’évaluation, un émulateur est piloté par un PC, via lequel il est possible d’examiner la mémoire et les registres du DSP. Il est également possible de poser des points d’arrêts à déclenchements sophistiqués, basés par exemple sur des conditions logiques portant sur le contenu de registres, de mémoires, voire de ports d’entrées/sorties. Un émulateur permet en outre de garder une trace des instructions exécutées dans telle ou telle partie du code à tester, ce qui facilite grandement le débogage dans certains cas complexes.


Seul moyen vraiment sûr pour tester un programme et un prototype, un émulateur reste néanmoins handicapé par son prix élevé dont il faut tenir compte dans le coût global d’un développement. Il faut noter que les DSP récents incluent directement dans leurs coeurs des fonctions d’émulation (points d’arrêts, registres spéciaux, etc.) Cette approche permet de simplifier la conception des émulateurs et tends à les rendre moins chers.




Page Principale       Index Global du Site       Page Precedente       Page Superieure       Page Suivante

Page Principale    Index Site   Page Précédente   Page Supérieure  Page Suivante

Site créé et maintenu par laurent.battista@laposte.net

© 1998 - 2005 - Laurent Battista