J'ai récemment acheté un kit de développement STM32 NUCLEO et je me suis demandé si c'était ce qu'un véritable ingénieur en systèmes embarqués utiliserait dans l'industrie lors du développement d'un produit?
J'utilise Kiel Uvision 5, STMCubeMX et STM32 ST-LINK Utility pour développer certains projets. Comme je suis habitué à utiliser PIC et à utiliser des registres comme PORTA, OSCCON, TIMER0 etc., je vois que Kiel Uvision 5 utilise des fonctions prêtes à l'emploi comme HAL_GPIO_TogglePin (.........) etc. Est-ce la façon habituelle de le faire cela dans l'industrie ou travailler plus directement avec les registres?
4 Réponses :
Il est fortement basé sur l'opinion et je ne serais pas surpris si cette question était close pour cette raison. Cette réponse ne touche que quelques aspects de ce que vous demandez. C'est un sujet très vaste et il va être difficile - voire impossible - de tout inclure dans un seul article qui ne finirait pas par faire plusieurs pages. Cependant, pour vous donner mon point de vue sur le sujet, tout en essayant de rester impartial, la réponse courte est ... cela dépend.
Si vous demandez ce qui est utilisé dans la plupart des cas, il s'agira probablement des fonctions HAL (anciennement StdPeriph) que vous avez mentionnées. La raison est - ils font le travail dans la plupart des cas courants. Après tout, cela dépend toujours du coût de création d'un produit. Si les fonctions HAL sont "assez bonnes" pour le but, elles seront utilisées simplement parce qu'elles sont plus rapides à développer avec. Plus le coût de développement est élevé, plus vous aurez envie de le réduire (ou de le déplacer ailleurs) et utiliser des abstractions est une façon de le faire.
Cependant, même si je pense qu'il est prudent de supposer que HAL / Std Periph / toute autre couche d'abstraction (y compris propriétaire) est généralement utilisée, ce n'est pas toujours le cas pour au moins deux raisons que je peux pensez à:
Les fonctions existantes peuvent ne pas convenir à votre objectif. Donnant HAL à titre d'exemple, cela fonctionne plutôt bien pour la plupart des cas courants, mais parfois vos besoins peuvent être si spécifiques que vous devrez aller gâcher "sous le capot", finissant souvent soit par écrire votre propre variation des fonctions de construire quelque chose de nouveau sur HAL. Personnellement, je peux penser à au moins quelques exemples où les fonctions HAL n'étaient pas exactement ce dont j'avais besoin. Cela ne signifie pas nécessairement que la bibliothèque est mauvaise, c'est juste parfois que les exigences sont très spécifiques.
La manipulation directe des registres peut parfois être nécessaire pour des raisons de performances. HAL et similaires sont une couche d'abstraction et, comme toute abstraction, leur exécution prend plus de temps que l'utilisation directe des registres. Si vous essayez de tirer le maximum absolu d'un périphérique donné, vous devrez parfois descendre au niveau du registre.
Passons maintenant à une partie plus partiale de ma réponse. Je peux comprendre pourquoi vous posez cette question. Venant du monde PIC où les horloges Flash ou CPU étaient plus précieuses, il est logique d'utiliser des registres directement là-bas. Dans le cas de STM32, ce n'est plus aussi critique. Cela dit, vous tomberez parfois sur des opinions selon lesquelles "l'utilisation des registres est la seule vraie manière", mais personnellement, je trouve que de telles discussions finissent par être purement théoriques. Je vois des registres ou toute abstraction construite dessus comme des outils et vous devriez utiliser les bons outils pour le bon travail. Deux exemples de PAS en utilisant les bons outils:
Vous n'utilisez que les registres comme "la seule bonne manière" soit parce que vous le croyez vous-même, soit parce qu'on vous l'a dit. Vos produits prennent deux fois (sinon plus) de temps à se développer, votre code prend moins de place en flash (vous utilisez donc maintenant 46% de 1 Mo de flash au lieu de 48%). Le code qui est essentiel aux performances atteint ses objectifs. Un code qui a assoupli les contraintes de temps d'exécution est également très efficace, mais il n'affecte pas beaucoup, voire pas du tout, le client final. Votre code est également moins réutilisable - vous vous retrouvez à réécrire les mêmes portions de code à chaque fois que vous lancez un nouveau produit pour une nouvelle famille de MCU.
Vous n'utilisez HAL / aucune autre abstraction similaire parce que "vous n'avez pas choisi un MCU si puissant pour devoir descendre au niveau du registre", ou parce qu'on vous dit que vous ne devriez jamais toucher aux registres. Vous développez beaucoup plus rapidement et vous êtes en mesure de publier deux produits au lieu d'un seul en utilisant des registres. Cependant, lorsqu'il y a des contraintes de temps d'exécution / vitesses de transmission que vous devez atteindre, vous vous retrouvez à choisir des MCU plus puissants que ce qui devrait théoriquement être nécessaire. Parfois, vous vous retrouvez à écrire des wrappers autour de HAL parce qu'ils ne vous donnent pas exactement les fonctionnalités dont vous avez besoin - cela donne l'impression de le rendre plus compliqué qu'il ne devrait l'être.
Donc, après tout, s'il y avait quelque chose à retirer de ce que j'essaie de dire, c'est que vous devriez utiliser ce qui convient au travail au cas par cas. Dans le cas de STM32, vous avez actuellement 3 options: HAL (niveau d'abstraction supérieur), HAL LL (abstraction de bas niveau - souvent de simples fonctions de wrapper autour des accès aux registres) ou en utilisant directement les registres. Celui que vous choisissez doit provenir de vos besoins.
J'utilise des cartes Nucleo tout le temps. Cela me permet de commencer à écrire des logiciels avant d'avoir le matériel prêt.
HAL & register way est plutôt le choix du programmeur que le "standard de l'industrie". J'utilise personnellement des pilotes HAL lorsque je programme des périphériques plus complexes comme USB et Ethernet pour éviter de câbler les piles complètes à partir de zéro.
Je viens de terminer mon diplôme et nous avons largement utilisé la plateforme STM32 avec CMSIS et HAL.
C'est une question de préférence. Les bibliothèques HAL offrent une abstraction plus élevée mais comportent quelques bizarreries qui ne sont pas très intuitives. Le HAL (was /) est parfois bogué. Nous avons rencontré des bogues de transfert SPI qui ont rendu les taux de transfert plus élevés de SPI inutilisables en raison d'un retard dans le transfert par octet.
CMSIS offre un accès de niveau inférieur, mais évite toujours la simple manipulation de bits. Je ne pense pas que l'accès direct au registre soit plus un excellent moyen de programmer et au moins CMSIS devrait être utilisé. Mais c'est toujours une question d'opinion, de préférence et de ce qui convient au travail à accomplir. Si vous avez besoin de quelque chose de rapide: HAL. Si vous avez besoin d'un contrôle très précis: CMSIS.
(sidenote, je crois que CMSIS a été progressivement abandonné en faveur de HAL mais il est toujours utilisable pour le moment)
Toutes les autres réponses sont valides. Je voulais juste intervenir et dire que j'utilisais régulièrement STM32 à mon travail (et dans deux entreprises différentes). Nous avons utilisé les pilotes HAL dans les deux sociétés. Il y a évidemment des problèmes avec eux, mais ils sont utilisés assez régulièrement par d'autres pour que vous puissiez facilement trouver de l'aide en ligne. De plus, CubeMx fait un travail décent avec eux, au moins assez pour vous permettre de commencer à utiliser les périphériques. Ainsi, l'étape 0-> quelque chose semble plus petite. Mais pour obtenir un code et une conception vraiment optimisés, vous voudrez peut-être aller plus loin pour vraiment comprendre ce que fait chacun des pilotes HAL et décider quelle méthode fonctionne pour votre projet, vos objectifs et vos exigences.
Bienvenue dans StackOverflow, ajoutez plus de description et de code si nécessaire pour comprendre la réponse, car cela résoudra le problème de quelqu'un d'autre dès que possible
choix des développeurs, vous pouvez développer à, et il y a de vrais développeurs qui exploitent tous les différents niveaux, du roll your own, aux rtos et aux bibliothèques intermédiaires. En tant que professionnel, vous êtes responsable de votre part du produit. Si la plupart de votre code est une tierce partie, votre patron / entreprise ne se souciera pas que les bogues dans le code qui relève de votre responsabilité n'aient pas été vérifiés / validés par vous. si vous passez quelques secondes à regarder certaines de ces bibliothèques, vous commencerez à avoir l'image que je présente.
la plupart des gens utiliseront simplement les bibliothèques par aveugle, paresseux ou quelque part entre les deux. mais cela ne veut pas dire que tout le monde le fait. vous devez choisir votre chemin. vous pouvez utiliser testing pour couvrir le code que vous n'avez pas écrit ou que vous n'avez pas demandé d'écrire. Je recommande vivement pour l'une de ces plates-formes d'essayer chacune des approches disponibles et de trouver celle qui correspond à ce produit, à ce calendrier, à ce coût, à ce risque, etc. et ne vous en tenez pas à cette approche pour la vie, en tant que professionnel, vous devez être en mesure de développer sous l’une des options.
Les fournisseurs de mcu auront généralement au moins deux ensembles de bibliothèques, l'un étant le nouveau génie du marketing, l'autre étant le plus ancien, fiable, fatigué, en cours d'élimination. de nombreuses raisons non seulement le marketing et les ventes. Les puces basées sur arm sont actuellement affectées par ARM lui-même d'une manière intéressante, faisant une troisième approche, et puis il y a les rtoses portées qui peuvent reposer sur l'un des éléments ci-dessus. donc pas seulement pour le bras mais pour d'autres produits, ce sont des choix typiques et vous devez choisir. lorsque vous obtenez le premier emploi, ce sera généralement dicté et non votre choix. pendant de nombreuses années.