Le logiciel embarqué est très différent.
Sur une application de bureau, les abstractions et les bibliothèques vous font gagner beaucoup de temps de développement. Vous avez le luxe de lancer un autre couple de mégaoctets ou gigaoctets de RAM ou des cœurs de processeur 64 bits 2 + GHz à un problème, et quelqu'un d'autre (les utilisateurs) paie pour ce matériel. Vous ne savez peut-être pas sur quels systèmes l'application fonctionnera.
Dans un projet intégré, les ressources sont souvent très limitées. Dans un projet sur lequel j'ai travaillé (processeurs PIC 17X), le matériel avait 2 000 mots de mémoire de programme, 8 niveaux de pile (dans le matériel) et 192 octets (<0,2 Ko) de RAM. Différentes broches d'E / S avaient des capacités différentes et vous avez configuré le matériel selon vos besoins en écrivant dans des registres matériels. Le débogage implique un oscilloscope et un analyseur logique.
En mode intégré, les abstractions gênent souvent et gèrent (et coûtent) les ressources que vous n'avez pas. Par exemple, la plupart des systèmes embarqués n'ont pas de système de fichiers. Les fours à micro-ondes sont des systèmes intégrés. Contrôleurs de moteur de voiture. Quelques brosses à dents électriques. Certains écouteurs antibruit.
Un facteur très important pour moi dans le développement de systèmes embarqués est de savoir et de contrôler ce que le code traduit en termes d'instructions, de ressources, de mémoire et de temps d'exécution. Souvent, la séquence exacte des instructions contrôle par exemple la synchronisation des formes d'onde de l'interface matérielle.
Les abstractions et la «magie» en arrière-plan (par exemple, un ramasse-miettes) sont idéales pour les applications de bureau. Les ramasse-miettes vous font gagner BEAUCOUP de temps à rechercher les fuites de mémoire, lorsque la mémoire est / peut être allouée dynamiquement.
Cependant, dans le monde intégré en temps réel, nous devons connaître et contrôler le temps nécessaire, parfois en nanosecondes, et nous ne pouvons pas jeter un couple de mégaoctets de RAM ou un processeur plus rapide en cas de problème. Un exemple simple: lors de la gradation logicielle des LED en contrôlant le rapport cyclique (le CPU n'avait que le contrôle on / off des LED), il n'est PAS OK pour le processeur de s'éteindre et de faire par exemple la collecte des ordures pendant 100 ms car l'affichage serait visiblement flash lumineux ou s'éteindre.
Un exemple plus hypothétique est un contrôleur de moteur qui déclenche directement des bougies d'allumage. Si ce processeur s'éteint et effectue la collecte des ordures pendant 50 ms, le moteur s'arrête un instant ou se déclenche à la mauvaise position du vilebrequin, ce qui pourrait caler le moteur (en passant?) Ou l'endommager mécaniquement. Vous pourriez faire tuer quelqu'un.