Les pires pratiques en matière de systèmes embarqués ?

Question

Quelles seraient, selon vous, les "pires pratiques" à suivre lors du développement d'un système embarqué ?

Voici quelques-unes de mes idées sur ce qu'il ne faut pas faire :

• Évitez d'abstraire la couche matérielle et répartissez plutôt les accès au matériel dans le code.
• Ne pas avoir de type d'environnement d'émulation, n'avoir que le matériel réel pour exe/cuter.
• Éviter les tests unitaires, peut-être en raison des deux points précédents.
• Ne pas développer le système dans une structure en couches, de sorte que les couches supérieures puissent dépendre de la fonctionnalité des couches inférieures déboguée et fonctionnant.
• Choisir le matériel sans tenir compte des logiciels et des outils qui l'utiliseront.

• Utilisation de matériel conçu pour un débogage facile, par exemple pas de points de test, pas de LED de débogage, pas de JTAG, etc.

  Je suis sûr qu'il y a beaucoup de bonnes idées sur ce qu'il ne faut pas faire, écoutons-les !

Answer 1

• Vecteurs d'exception non initialisés (vous savez, pour ceux qui "ne seront jamais atteints")
• Dites-le avec moi : Les variables globales. Surtout celles partagées entre les ISR et les tâches (ou les boucles de premier plan) sans protection.
• Absence d'utilisation du terme "volatile" lorsque cela est nécessaire.
• Avoir des routines qui désactivent les interruptions() et ensuite activent les interruptions() jumelées. Vous avez compris ? Pas RestoreInterrupts() mais ENABLE . Oui, la nidification.
• Pas de GPIO à basculer lors des tests.
• Pas de points de test à bord.
• Pas de LED ou de port série pour visualiser l'état du système en cours d'exécution.
• Aucune mesure de l'activité ou de l'inactivité de l'unité centrale.
• Utilisation de l'assemblage en ligne pour tous les cas, sauf les plus graves. Rédigez une note de rappel rapide.
• En utilisant for (i = 0 ; i < 1000 ; i++) { } pour "retarder un peu". Ouais, ça ne va pas te mordre de cent façons différentes.....
• Ne pas utiliser de const partout où cela est possible pour préserver la RAM et réduire le temps de démarrage (pas de copie / init de variables)

J'en ai une tonne d'autres mais ça devrait nous permettre de commencer. ....

Answer 2

Que quelqu'un m'arrête avant que je ne me fasse du mal.

BTW, je me rends compte que tout ceci n'est pas strictement spécifique à incorporé mais je pense que chacun d'entre eux est au moins aussi important dans le monde embarqué que dans le monde réel.

• Lorsque vous établissez un programme, partez du principe que tout va fonctionner du premier coup.

• Approche du montage de la carte sans oscilloscope et/ou analyseur logique. L'oscilloscope, en particulier, n'est jamais utile.

• Ne tenez pas compte de l'alimentation électrique pendant la conception. Les questions telles que la chaleur, l'efficacité, les effets de l'ondulation sur les lectures ADC et le comportement du système, le rayonnement EMF, le temps de démarrage, etc. ne sont pas importantes.

• Quoi qu'il en soit, n'utilisez pas de contrôleur de réinitialisation (le type de circuit intégré à 5 cents), utilisez simplement un circuit RC (en espérant qu'il soit couplé à beaucoup de bruit alternatif à haute fréquence).

• ADOPTEZ LE BIG BANG ! !! Ne développez pas de petits morceaux de façon incrémentale et intégrez-les souvent, imbécile ! !! Il suffit de coder pendant des mois, avec des collègues de travail, et puis de tout mettre en place la nuit avant la grande démonstration du salon professionnel !

• N'instrumentez pas le code avec des instructions de débogage/traçage. La visibilité est mauvaise.

• Faites beaucoup de choses dans vos BVR. Tris à bulles, requêtes de base de données, etc... Hé, il y a des chances que personne ne vous interrompe, vous avez la parole, profitez-en mon pote ! !!

• Ignorer la disposition des cartes dans une conception. Laissez l'autorouteur s'occuper de ces traces à impédance adaptée et de cette alimentation à courant élevé et à haute fréquence. Hé, tu as des choses plus importantes à te préoccuper, partenaire !!!

• Utilisez du silicium tout neuf, bêta, non commercialisé, de première génération, en particulier s'il s'agit d'un produit critique pour la sécurité (aviation, médecine) ou d'un volume important (il est amusant de rappeler un million d'unités).

Answer 3

OK round 2.... juste un peu plus :

• N'utilisez pas de chien de garde (surtout s'il est intégré !).

• Utiliser des types et des routines en virgule flottante lorsque des calculs en nombres entiers échelonnés suffiraient.

• Utiliser un RTOS lorsque cela n'est pas justifié

• N'utilisez pas un RTOS quand il faudrait vraiment être sensé

• Ne jamais regarder le code assembleur généré pour comprendre ce qui se passe sous le capot.

• Écrire le micrologiciel de façon à ce qu'il ne puisse pas être mis à jour sur le terrain.

• Ne documentez pas les hypothèses que vous faites.

• Si vous voyez quelque chose d'étrange pendant que vous testez / déboguez, ignorez-le jusqu'à ce que cela se reproduise ; ce n'était probablement pas quelque chose d'important comme un brownout, une interruption manquée, un signe de corruption de la pile, ou tout autre problème fugace et intermittent.

• Lors du dimensionnement des piles, la meilleure philosophie est de "commencer petit et continuer à augmenter jusqu'à ce que le programme arrête de planter, alors nous sommes probablement OK".

• Ne pas profiter des outils de profilage d'exécution comme uC/Probe de Micrium (je suis sûr qu'il y en a d'autres).

• N'incluez pas d'auto-tests de mise sous tension du matériel avant de lancer l'application principale - si le code de démarrage est en cours d'exécution, qu'est-ce qui pourrait bien ne pas fonctionner ?

• N'incluez pas dans le POST (ci-dessus) un test de RAM que vous n'allez pas mettre en œuvre.

• Si le processeur cible possède une MMU, pour tout ce qui est sacré, n'utilisez pas cette effrayante MMU ! !! Surtout ne le laissez pas vous protéger des écritures dans l'espace de code, de l'exécution depuis l'espace de données, etc....

• Si vous avez testé, débogué et intégré avec un certain ensemble d'options de compilateur (par exemple, aucune/faible optimisation), ASSUREZ-VOUS D'ACTIVER L'OPTIMIZATION COMPLÈTE avant votre version finale !!! Mais n'activez l'optimisation que si vous n'avez pas l'intention de tester. Je veux dire, vous avez déjà testé pendant des mois - qu'est-ce qui pourrait mal tourner ? !??!

Answer 4

Allocation dynamique de la mémoire après l'initialisation. Le pool de mémoire doit rester statique après l'initialisation du système.

Answer 5

• Lésiner sur l'installation d'enregistrement. Les systèmes embarqués sont difficiles à déboguer et vous avez besoin de beaucoup de journaux.
• Ne pas avoir la possibilité d'autoriser des niveaux de journalisation. Un système sur plusieurs présentera des comportements étranges et vous devrez définir le niveau de débogage de la journalisation de ce système à un niveau plus verbeux.
• Ne pas autoriser une sorte de port de sortie pour permettre la journalisation vers une console, par exemple.
• Ne pas avoir la possibilité de "parcourir" le code.
• Ne pas avoir la possibilité de profiler le code pour voir quelles parties doivent être optimisées, par exemple en assembleur.
• Ne pas développer une sorte de "test de sanité" permettant de vérifier rapidement le fonctionnement d'un dispositif une fois chargé et avant l'expédition.
• Baser la conception sur un système d'exploitation "maison".