Écriture de logiciels embarqués sans matériel

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?

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.

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.

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.

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 .

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.

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.