Test du logiciel pour un système nu-métal [fermé]

Question

J'écris un projet en C ++ pour un système intégré ne prenant pas en charge le système d'exploitation; presque pas de support de bibliothèque. Très métal nu. Par conséquent, une bonne partie de mon code est étroitement couplée (par exemple, des interruptions déclenchées par le logiciel et la couche directement au-dessus d’elles).

Une partie de ce que je fais consiste à modifier la configuration du port série, entraînant ainsi des modifications simultanées du côté PC (le côté UI) et du microprocesseur (le côté activité). Je me débrouille très bien jusqu'à présent dans un développement de type incrémentiel extrêmement minutieux (pièce par pièce le contenant). Cependant, je voudrais être plus confiant quant à l’efficacité de mon code.

Quels types de méthodologies / cadres recommanderiez-vous pour ce type de situation?

Modifier:

J'utilise l'AMD186 ES sur une carte ACore86 fabriquée par Tern, Inc. Compilateur: Paradigm, édition gratuite (livrée avec la carte). Je n'ai malheureusement pas la possibilité de changer mon travail.

Answer 1

Le manque d’infrastructures dans un environnement «bare metal» est assez difficile. Je vous recommande de vous concentrer sur les outils de débogage. Même avec beaucoup de soin et une excellente méthodologie, vous aurez besoin de la capacité de déboguer des choses.

Il vous incombe de faire fonctionner gdbagent. Vous devrez l'implémenter vous-même, mais il s'agit d'un protocole simple basé sur du texte. Vous exécutez gdb sur une machine externe et communiquez avec gdbagent sur votre cible.   Vous pouvez certainement exécuter le protocole gdbagent sur le port série, mais cela devient rapidement fastidieux lorsque de grandes quantités de données doivent être examinées. Si vous disposez d’une interface plus rapide, profitez-en.

Je ne sais pas quel est votre budget, mais vous devez également planifier un débogueur JTAG. gdbagent est génial tant que votre gdbagent sur la cible est capable de s'exécuter. Si tout se bloque dur, vous êtes toast. Les débogueurs JTAG sont extrêmement coûteux, mais peuvent être loués. J'ai déjà utilisé des produits Corelis , et j'ai entendu de bonnes choses sur Abatron .

Answer 2

Je pense que vous avez intérêt à travailler avec le fournisseur de votre compilateur pour obtenir un simulateur de périphérique.

Tessy est censé fonctionner avec cette puce. Découvrez: http://www.hitex.us/products.html?con_186 .html ~ contenu

Answer 3

Lorsque le minutage est important, j'aime utiliser une ou deux broches d'E / S libres et une portée pour instrumenter le code. Je suis également fan du port JTAG pour le débogage au niveau source. Vous pouvez également demander au microprocesseur de stocker un vecteur de données et de le renvoyer sur un deuxième ordinateur (le cas échéant) au PC pour analyse.

Answer 4

Quelque chose que j'ai vu faire dans ce genre de domaine est le test unitaire.

Non, je ne plaisante pas.

Les tests unitaires sont exécutés sur le périphérique, sous le contrôle du PC hôte.

Vous écrivez un wrapper pour charger des programmes dans SRAM sous contrôle de test unitaire.

Ensuite, votre ordinateur peut envoyer un programme, l'exécuter et vérifier le résultat.

Si vous avez besoin d’exercer votre board, procurez-vous un labjack ou une carte d’interface USB similaire.

Voilà le matériel d'un gabarit de test, exécuté depuis votre PC hôte.

Answer 5

J'ai réussi à concevoir un environnement PC où le code peut être compilé avec C ++ pour le PC et testé, puis compilé ultérieurement avec "straight". C pour fonctionner sur le système embarqué. Les références de port d'E / S sont #définies pour être des accès de propriété pour un objet d'E / S, qui sont ensuite envoyées via le socket à une "émulation matérielle". programme. Certaines parties du système ont fini par être plus encombrantes que je ne l'aurais souhaité, mais je m'attends à ce que les versions suivantes le soient moins.