Écriture de logiciels embarqués sans matériel


8

Considérez que l'équipe matérielle prendra 2 mois pour développer du matériel, mais à ce moment-là, je devrai avoir le logiciel prêt.

Ma question est la suivante: comment puis-je écrire le logiciel et le tester sans avoir le matériel?

Y a-t-il des normes à suivre? Comment faites-vous?


Selon la complexité du matériel, vous pouvez essayer un simulateur. C'est tout à fait faisable si ce n'est qu'un micro-contrôleur avec des périphériques simples. Plus que cela et vous n'avez pas de chance sur cette route.
Mast

6
Essayez de trouver des cartes de développement pour le micro et tous les autres périphériques que vous utilisez, et essayez de les connecter tous de la manière qui ressemble le plus à la conception de votre équipe matérielle. Ce sera grand et moche, mais vous devriez être en mesure de mettre en place un système suffisamment proche de la réalité - du moins pour autant que votre firmware puisse le dire ...
brhans

Au pire, si vous ne pouvez pas simuler correctement le matériel, ayez un moyen de le désactiver. Il y a quelques semaines à peine, je voulais tester la communication réseau avec un autre programme, seulement pour le découvrir exit()car il essayait de mapper des adresses codées en dur dans / dev / mem.
isanae

1
Il est en fait préférable, dans de nombreux cas, d'utiliser un simulateur pour le développement de logiciels intégrés - beaucoup plus facile à déboguer. Le problème, bien sûr, est que vous avez besoin d'un simulateur décent. Parfois, il y en a un générique qui peut être adapté, parfois un stagiaire intelligent peut en écrire un dans une frénésie de codage alimentée à la caféine.
Hot Licks

Réponses:


34

Le fait de ne pas avoir de matériel pendant les étapes initiales du développement du firmware se produit. Les stratégies courantes pour y faire face sont les suivantes:

  1. Passez du temps à la conception du système avant d’écrire du code. Bien sûr, vous devriez le faire de toute façon, mais dans ce cas, c'est encore plus important que d'habitude. Il est beaucoup plus facile de déboguer un logiciel bien pensé qu'un désordre à base de pâtes.

  2. Modularisez tout correctement, en minimisant les interfaces entre les modules. Cela aidera à contenir les bogues des modules individuels et permettra de tester plus facilement les modules individuels.

  3. Écrivez le code de bas en haut, les pilotes touchant le matériel passent en premier, la logique d'application de haut niveau en dernier. Cela permet de découvrir très tôt les inconvénients imposés par l'architecture. N'ayez pas peur de changer l'architecture au fur et à mesure que les réalités matérielles se font jour, mais assurez-vous que toute la documentation est mise à jour en conséquence.

  4. Simuler. La plupart des sociétés de microcontrôleurs fournissent des simulateurs logiciels de leurs microcontrôleurs. Ceux-ci ne peuvent aller jusque-là, mais peuvent toujours être très utiles. La simulation des entrées et la mesure des sorties du matériel peuvent être difficiles, mais la vérification de la logique de niveau supérieur de cette façon ne devrait pas être trop difficile.

    C'est là que la conception modulaire aide à nouveau. Si vous ne pouvez pas raisonnablement simuler certaines interactions matérielles de bas niveau, vous utilisez une version différente du module qui touche ce matériel mais qui transmet ses propres actions simulées aux niveaux supérieurs. Les niveaux supérieurs ne sauront pas que cela se produit. Vous ne vérifierez pas le module de bas niveau de cette façon, mais presque tout le reste.

En bref, utilisez de bonnes pratiques de conception de logiciels, ce que vous devriez bien sûr faire de toute façon.


J'aimerais ajouter: obtenir des conseils de développement (oui, plusieurs, car vous en tuerez probablement au moins un ...) dans les plus brefs délais et mettre en place les pilotes de bas niveau. Testez autant que possible votre code unitaire. Oui, vous pouvez associer le code touchant le matériel. Non, vous ne pouvez pas simuler complètement le matériel, mais vous pouvez obtenir 90% des fonctionnalités correctes avant même de flasher pour la première fois. J'ai fait tout ce qui précède sur un projet récent, et nous avions 99% de fonctionnalités en place et fonctionnant lorsque le vrai matériel est entré. C'était magnifique.
CHendrix

13

Sans aucune idée de ce que vous développez ni de la famille de microcontrôleurs sur laquelle votre matériel sera éventuellement basé, la plupart des familles de microcontrôleurs disposent de systèmes de développement à faible coût qui disposent d'une suite de périphériques communs, ce qui peut vous permettre de simulez au moins une partie de votre matériel cible éventuel.


1
D'accord. Je le dirais plus fort. Dans une situation comme celle-ci, où le logiciel doit être terminé en même temps que le matériel, je n'utiliserais qu'un microcontrôleur doté d'une carte de développement ou d'évaluation appropriée.
Steve G

Même si vous aviez une idée de ce que le PO développe, la plupart des familles de microcontrôleurs ont toujours des simulateurs disponibles.
Olin Lathrop

J'utilise les deux méthodes. Cependant, je garde également un œil sur l'équipement de test de la ligne de production requis. Vous pouvez vous réunir avec les ingénieurs de production et concevoir le matériel pour tester vos pilotes qui peuvent ensuite faire partie des tests de production. Si vous êtes chanceux, ils peuvent même construire du matériel pour une carte de développement / prototype afin de prendre de l'avance sur le processus. Tout dépend de la façon dont vous lancez la demande d'aide ...
Spoon

C'est la meilleure réponse à cette question, car j'ai toujours une carte de développement pour programmer les fonctionnalités de base avant de l'essayer sur le PCB.
lucas92

2

Selon la façon dont l'application dépendra du matériel, vous pouvez simplement commencer à implémenter le projet sur un PC standard (Windows, Linux ...). La plupart des accès périphériques devraient de toute façon être abstraits, donc ce n'est pas un problème d'implémenter certaines fonctions factices, qui vont être remplacées plus tard. S'il n'est pas possible de simuler un comportement, vous pouvez au moins faire une maquette du système (API ...), donc l'implémentation réelle ira beaucoup plus vite et plus clairement, dès que le matériel sera prêt.

Il y a bien sûr beaucoup de choses qui ne peuvent pas être simulées, comme le comportement en temps réel ou les pilotes matériels complexes. D'un autre côté, un ADC piloté par interruption peut facilement être simulé à l'aide d'un thread qui lit les valeurs d'un fichier ou d'un port réseau.

Bien sûr, tout cela dépend fortement de divers facteurs:

  • Pouvez-vous utiliser la même chaîne d'outils / similaire sur le contrôleur et le PC (par exemple gcc)?
  • Le système dépend-il du matériel?
  • Quelle est votre expérience en programmation PC?

Pour ma part, je conçois à peu près tous les modules de micrologiciel sur un PC en premier.


Pareil ici. Certaines différences entre les compilateurs (intrinsèques, mots clés spéciaux, système d'exploitation à source fermée et pile réseau pas tout à fait compatible avec BSD) et les bogues (avec C ++) forçant une utilisation intensive de fichiers et de préprocesseur pré-inclus spécifiques au fichier, mais le code lui-même peut être presque identique entre DSP et PC. Pour la version PC, je peux utiliser une vérification des erreurs d'exécution forte et lourde (CodeGuard) et ses capacités de débogage ne peuvent pas être mises en correspondance sur les plates-formes intégrées. Le bonus supplémentaire est que je peux avoir quelques périphériques virtuels supplémentaires pour n'importe quel réseau et test de charge.
TMSZ

Avec la disponibilité de Raspberry Pi et BeagleBone, votre environnement de développement pourrait tout aussi bien être votre environnement d'exécution - aucun problème avec la chaîne d'outils, etc. De plus, vous pouvez utiliser valgrind / helgrind, gdb, etc.
jhfrontz

1

Essayez d'obtenir un simulateur pour votre puce. Vous devez simuler toutes les entrées attendues et certaines inattendues également. Modularisez / résumez autant que possible et écrivez des tests unitaires. Si vous le pouvez, ces tests peuvent faire partie de votre code réel et se transformer en fonctionnalité (autotest de la carte).

Si vous ne parvenez pas à obtenir un simulateur, faites le résumé autant que possible via une couche HAL (couche d'abstraction matérielle). Tous les pilotes sont derrière. Essayez d'abstraire tout assemblage spécifique à la plate-forme derrière un appel de fonction C et considérez-les également comme des pilotes. Écrivez le reste sous forme de code C / C ++ portable et créez un HAL fin pour x86 et exécutez-le sur votre machine avec tous les cas de test.

De cette façon, lorsque vous obtenez le matériel, vous n'aurez qu'à déboguer la couche HAL. Plus il est fin, plus vous le déboguerez rapidement et que tout fonctionnera. N'oubliez pas que si vous utilisez un assemblage spécifique à la plate-forme pour des opérations plus rapides, vous VOULEZ TRÈS BEAUCOUP pour obtenir des tests très précis .


La précision des bits est particulièrement importante si vous utilisez un DSP à virgule fixe.
Ronan Paixão

Elle peut s'appliquer ou non à un cas particulier, mais en général, l'exactitude des bits a son prix. QEMU a récemment (il y a 2 ans) décidé d'implémenter un FPU à bit exact, et devinez-vous ce qui est arrivé aux performances ?
Dmitry Grigoryev

L'exactitude des bits n'est pas très importante lors de l'utilisation d'un FPU. Cependant, il est extrêmement important si vous utilisez un point fixe. Surtout parce que les logiciels à virgule fixe nécessitent des vérifications supplémentaires partout.
Ronan Paixão

Ce qui est le résultat de mauvaises pratiques de codage. Les gens ont appris à prendre des précautions lors de l'utilisation de a == bcomparaisons avec des flotteurs, mais ils les utilisent toujours sans réfléchir avec des nombres à virgule fixe.
Dmitry Grigoryev

Bien que les mauvaises pratiques de codage soient un problème, il existe de nombreux autres problèmes, en particulier dans les cas marginaux. Les débordements viennent à l'esprit rapidement, tout comme la perte de précision , l' arrondi , la saturation et la largeur par rapport au décalage de bits . Avec tout cela, il est facile d'ignorer une perte de précision dans les cas de test courants. Le problème est lorsque votre application atteint des cas moindres et que les erreurs passent du fractionnaire aux bits entiers, ce qui se produit si la plage est mal calculée. Il suffit de consulter la page des fonctionnalités de MATLAB Fixed-Point Designer pour voir ce qui pourrait mal se passer en un clin d'œil.
Ronan Paixão

1

Votre question est un peu large. Le matériel (HW) pourrait signifier un développement ASIC / FPGA entièrement personnalisé, des DSP programmés par l'assembleur, ou "seulement" un système embarqué typique basé sur des microprocesseurs / microcontrôleurs / SoC etc. standard (bien sûr, un SoC peut également contenir un DSP que vous voudrez peut-être programmer ....). Pour des quantités de vente élevées, en faire un ASIC n'est pas rare.

Mais pour un projet de 2 mois, je m'attends à ce qu'il soit basé sur un microcontrôleur:

Dans tous les cas, vous devriez insister sur l'équipe matérielle pour vous donner un prototype que vous pouvez commencer à tester votre code avant la date limite absolue - cela pourrait simplement consister en une carte de développement générique, comme certaines personnes l'ont déjà mentionné, mais à mon avis, c'est leur travail pour vous fournir le bon, et éventuellement aussi certains périphériques requis / similaires pour les tests.

Les simulateurs sont également possibles dans une certaine mesure, mais vous devrez peut-être encore caractériser certains capteurs / données du monde réel que vous pourriez obtenir. Ici, l'équipe matérielle doit également vous aider au moins.

En dehors de cela, la conception du logiciel peut déjà être effectuée et tous les modules de haut niveau peuvent être (et devraient être) mis en œuvre et testés à l'unité sans le vrai matériel. Idéalement, vous définirez également une API avec l'équipe matérielle, et ils vous fourniront les fonctions de niveau le plus bas, donc tout changement qu'ils font du côté matériel là-bas (par exemple, redéfinissant simplement les broches de port qu'ils utilisent), ne sera pas toujours être critique pour vous.

Dans tous les cas, la communication est essentielle.


0

Oui, vous pouvez développer votre code pour votre carte cible avant que celle-ci ne soit fabriquée.

Comment ?

Vous devez d'abord connaître l'objectif principal de ce système. Ainsi, vous pouvez choisir le contrôleur de manière appropriée à partir d'une vaste source de disponibilité comme digikey, mouser.

Et choisissez un simulateur comme Proteus. Cela simulera le processeur / contrôleur exact maintenant vous pouvez commencer votre codage. Mais vous ne pouvez pas vous attendre à la précision comme dans le matériel.


Pourquoi downvote? Puis-je savoir quel est le problème avec cette réponse?
Photon001
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.