J'ai plus de 20 ans de systèmes embarqués, principalement 8 et 16 micros. La réponse courte à votre question est la même que pour tout autre développement logiciel - n'optimisez pas avant de savoir que vous en avez besoin, puis n'optimisez pas tant que vous ne savez pas ce que vous devez optimiser. Écrivez votre code afin qu'il soit fiable, lisible et maintenable en premier. L'optimisation prématurée est autant, sinon plus, un problème dans les systèmes embarqués
Lorsque vous programmez «sans gaspiller aucune ressource», considérez-vous votre temps comme une ressource? Sinon, qui vous paie pour votre temps, et si personne, avez-vous quelque chose de mieux à faire avec cela. Une fois que le choix d'un concepteur de système embarqué est le coût du matériel par rapport au temps d'ingénierie. Si vous expédiez 100 unités, utilisez un micro plus gros, à 100 000 unités, une économie de 1,00 $ par unité équivaut à 1 année-homme de développement logiciel (en ignorant le temps de mise sur le marché, le coût d'opportunité, etc.), à 1 million d'unités, vous commencez obtenir un retour sur investissement pour être obsédé par l'utilisation des ressources, mais soyez prudent car de nombreux projets intégrés n'ont jamais atteint le million car ils ont conçu pour vendre 1 million (investissement initial élevé avec un faible coût de production) et ont fait faillite avant d'y arriver.
Cela dit, les choses que vous devez prendre en compte et prendre en compte avec les (petits) systèmes embarqués, car ceux-ci arrêteront son fonctionnement, de manière inattendue, et pas seulement le ralentiront.
a) Pile - vous n'avez généralement qu'une petite taille de pile et des tailles de cadre de pile souvent limitées. Vous devez être conscient de l'utilisation de votre pile à tout moment. Soyez averti, les problèmes de pile provoquent certains des défauts les plus insidieux.
b) Tas - encore une fois, de petites tailles de tas, donc faites attention à l'allocation de mémoire injustifiée. La fragmentation devient un problème. Avec ces deux, vous devez savoir ce que vous faites lorsque vous manquez - cela ne se produit pas sur un grand système en raison de la pagination fournie par le système d'exploitation. ie quand malloc retourne NULL, vérifiez-vous cela et que faites-vous. Chaque mauve a besoin d'un chèque et d'un gestionnaire, un bloat de code ?. À titre indicatif - ne l'utilisez pas s'il existe une alternative. La plupart des petits systèmes n'utilisent pas de mémoire dynmaique pour ces raisons.
c) Interruptions matérielles - Vous devez savoir comment les gérer de manière sûre et en temps opportun. Vous devez également savoir comment créer un code de retour sécurisé. Par exemple, les bibliothèques standard C ne sont généralement pas réentrantes, elles ne doivent donc pas être utilisées dans les gestionnaires d'interruption.
d) Assemblage - optimisation presque toujours prématurée. Au plus, une petite quantité (en ligne) est nécessaire pour réaliser quelque chose que C ne peut tout simplement pas faire. Comme exercice, écrivez une petite méthode dans un assemblage artisanal (à partir de zéro). Faites de même en C. Mesurez les performances. Je parie que le C sera plus rapide, je sais qu'il sera plus lisible, maintenable et extensible. Maintenant, pour la partie 2 de l'exercice - écrivez un programme utile dans l'assemblage et C.
Comme autre exercice, regardez combien de Linux kernal est assembleur, puis lisez le paragraphe ci-dessous sur le noyau linux.
Il vaut la peine de savoir comment le faire, il peut même être utile de maîtriser les langues pour un ou deux micros communs.
e) "register unsigned int variable_name", "register" est, et a toujours été, un indice pour le compilateur, pas une instruction, au début des années 70 (il y a 40 ans), cela avait du sens. En 2012, c'est un gaspillage de frappes car les compilateurs sont si intelligents et les instructions micros sont si complexes.
Revenons à votre commentaire Linux - le problème que vous avez ici est que nous ne parlons pas d'un simple million d'unités, nous parlons de centaines de millions, avec une durée de vie de toujours. Le temps et le coût d'ingénierie pour l'obtenir aussi optimal que possible humainement en valent la peine. Bien que ce soit un bon exemple de la meilleure pratique d'ingénierie, ce serait un suicide commercial pour la plupart des développeurs de systèmes embarqués d'être aussi pédants que l'exige le noyau Linux.