• Survol des produits
• VectorCAST/C++
• VectorCAST/Ada
• VectorCAST/RSP
• Ressources techniques
• Licences et environnements
• Compilateurs supportés
• Exemples d'utilisation
• Témoignages
• VectorCAST/Cover
• VectorCAST/Manage
• VectorCAST/Requirements Gateway

Produits > VectorCAST/RSP

VectorCAST/RSP (Runtime Support Package)

• Harnais de test spécifique au compilateur croisé pour fins d'exécution sur processeur-cible ou sous simulateur
• Téléchargement automatique du harnais de test et des jeux de test pour l'exécution sur cible via l'interface du compilateur ou via un mécanisme tiers de téléchargement
• Exécution contrôlée depuis une interface graphique qui fournit une méthode simple et unique pour conduire des jeux de test sur une cible embarquée
• Des mécanismes de communication I/O spécifiques sont fournis au niveau de l'hôte et de la cible afin de permettre une communication bidirectionelle rendant possible la capture des résultats des tests

L'architecture du harnais de test VectorCAST

L'architecture VectorCAST est centrée sur un harnais de test exécutable construit via le générateur d'environnement VectorCAST. Le code source pour le harnais est regénéré chaque fois qu'une nouvelle version de votre application est créée, et celui-ci est entièrement basé sur le language de l'application testée (Ada, C/C++). Le harnais est alors compilé et lié en utilisant le même compilateur utilisé lorsque vous créez votre application. Le fichier exécutable ainsi produit peut dès lors être téléchargé sur n'importe quel processeur supporté par votre compilateur croisé. Le harnais est entièrement compatible avec le processeur et la carte sur laquelle l'application devra s'exécuter.

Le harnais de test VectorCAST est "orienté données" (data driven), ce qui veut dire qu'aucune modification du code source du harnais est nécessaire afin d'ajouter, de changer ou d'éliminer des jeux de test. VectorCAST sauvegarde les données des jeux de test dans des fichiers-textes qui sont par la suite utilisés par le pilote du harnais afin de stimuler le code sous test. Toutes les données obtenues comme résultat depuis le harnais sont également sauvegardées dans des fichiers-textes.

De plus, toutes les opérations de communication I/O du harnais sont gérées par les facilités I/O de VectorCAST.

Cette architecture permet à VectorCAST d'opérer sur une plateforme hôte alors que le harnais de test est exécuté sur le même système OU sur une plateforme cible autre. L'architecture de la plateforme cible n'est pas importante - ce qui importe, c'est qu'il y ait un mécanisme quelconque afin d'envoyer des données de test formattées ASCII vers la cible et récupérer les données de résultat depuis la cible. Sous VectorCAST/RSP, ce mécanisme est le lien I/O qui est utilisé afin de télécharger des données sur la cible depuis l'hôte.

À propos de la personalisation de VectorCAST/RSP

Les sections suivantes expliquent chaque composant de l'architecture de la cible qui affectent la personalisation de VectorCAST/RSP. Le terme "architecture de la cible" réfère à toute l'information sur la carte utilisée, le compilateur, et l'ordinateur-hôte qui jouent un rôle dans le module VectorCAST/RSP. Pour chaque composant listé ci-dessous, nous analyserons sommairement l'interraction entre le composant et VectorCAST/RSP.

Les capacités de téléchargement de la cible

VectorCAST doit s'intégrer à tout outil ou mécanisme qui existe afin de télécharger un programme exécutable sur le processeur cible. Toutes les commandes sont intégrées à VectorCAST afin d'automatiser le plus possible la communication avec la cible. Dans certains cas, il peut y avoir quelques étapes manuelles, telles que la réinitialisation de la carte. Cependant, toutes les opérations manuelles sont clairement indiquées à l'utilisateur par l'outil et sont également explicitées dans la documentation du produit. L'intégration de VectorCAST/RSP avec les capacités de téléchargement de la cible permet d'exécuter les jeux de tests sur cible aussi facilement que sur hôte. La seule étape additionelle est le téléchargement sur la carte cible.

Facilités de communications I/O

Ce composant est le plus critique en ce qui concerne la personalisation. Suivant le noyau exécutable, il peut y avoir des fonctions complètes ou simples d'entrée et de sortie (I/O). Une fonction complète permet la lecture et l'écriture d'un ficher-hôte depuis la cible. Une fonction simple ne fournit qu'un moyen d'envoyer à la cible et de recevoir sur l'hôte des chaînes de caractères ASCII. Certaines cibles n'ont pas de fonction I/O. Chacune de ces situations requiert une solution différente.

Parce que toutes les opérations I/O prennent place au sein de nos fonctions de communication I/O, la solution à apporter pour chaque cible se doit d'être modulaire, en remplaçant les fonctions I/O standards de l'outil avec celles appropriées pour la cible.

Dans le cas d'une fonction I/O complète, il suffit de modifier légèrement les facilités standard de l'outil. Les opérations de lecture et d'écriture seront effectuées directement sur l'hôte. Dans le cas d'une fonction I/O simple, VectorCAST placera les données en mémoire-tampon au niveau de l'hôte et de la cible et enverra les données sous forme de rafales (bursts) de données ASCII au moment opportun. Ici, les fonctions I/O de l'outil seront remplacées par les fonctions I/O primitives de la cible. Finalement, s'il n'y a aucune capacité I/O sur la cible, une solution au niveau assembleur est requise afin de pouvoir communiquer avec la cible.

Processeur cible

Il n'y a pas d'impact, en ce sens que notre harnais de test est basé sur des constructions de haut niveau du langage utilisé, et qu'il peut donc être compilé et lié pour tous les processeurs qui sont supportés par votre compilateur.

Architecture de la carte-cible et génération du harnais

Ici, l'impact est minimal. L'utilisation de processeurs spéciaux tels qu'un co-processeur mathématique peut vouloir dire que certaines composantes haut niveau du language ne sont pas disponibles. Dans de tels cas, le code du harnais VectorCAST peut être adapté afin de s'assurer que celui-ci n'inclut aucune des constructions non-supportées.