À propos de la qualité et des performances de STM32 HAL
Je suis sur le point de démarrer un nouveau projet sur un produit classique basé sur STM32L4. J'ai une bonne expérience en développement ARM mais pas en STM32 en particulier. Je me demande quelle est la qualité et les performances du STM32 HAL et des pilotes de bas niveau fournis par STmicro (dans le package STM32Cube). Je voudrais recueillir l'expérience et les commentaires des développeurs sur le sujet. En gros, j'aimerais savoir si vous êtes satisfait de ce code ou au contraire si vous rencontrez des problèmes, si certains d'entre vous ont développé leurs propres pilotes pour certaines raisons, etc ... Merci!
Après la transition des microcontrôleurs 8 bits plus petits vers ARM, j'ai tout de suite commencé à utiliser la bibliothèque HAL sur STM32 et j'ai eu une expérience plus ou moins satisfaisante. Mais il vient avec une surcharge comme déjà indiqué et un ensemble assez large de fonctionnalités mal documentées. Cela peut créer une certaine confusion.
Cependant, le gros avantage de l'utilisation de la couche HAL par rapport au code manuscrit à partir de zéro était le niveau d'abstraction qu'elle fournit. Cela m'a été utile lorsque j'ai eu besoin de passer d'un type de STM32 à un autre; et aussi quand j'avais besoin de faire fonctionner les choses rapidement. - J'ai utilisé un code assez similaire sur quelques types/familles de micros STM32 très différents (L0, L1, F1, F4, F7); cela a fonctionné la plupart du temps. L'utilisation de la bibliothèque HAL a rendu la transition beaucoup moins pénible que lorsque vous avez besoin de connaître la carte mémoire exacte et la disposition des registres du micro spécifique ...
Cela dit, je dois admettre que je suis toujours un novice en matière de logiciels embarqués modernes et j'apprends toujours, après environ 2 ans de travail de prototypage sur différents projets basés sur STM32 (passe-temps et professionnels). J'ai encore besoin d'en savoir plus sur le code LL fourni, par exemple.
Entrer dans le champ intégré avec un arrière-plan logiciel différent, en utilisant le code de niveau HAL au lieu de tourner des bits uniques de registres différents dans la bonne séquence, et en tenant compte de toutes les différentes restrictions pour obtenir par exemple de base UART/SPI/I2C fonctionnait, ce qui a beaucoup facilité les choses pour moi. À mon humble avis, le STM32 HAL se situe entre un code écrit à la main et ce que mbed fait par exemple (C++/vender- abstraction agnostique (pour autant que je sache). - Il apprivoise la bête complexe à un niveau acceptable, de sorte qu'un développeur de logiciel moyen comme moi puisse le gérer. Cela vient avec des compromis, comme déjà mentionné par d'autres ...
Après tout, le STM32 HAL sert également de référentiel de code de plaque de chaudière, qui peut parfois être plus facile à lire/à comprendre que le manuel de référence cryptique dans certains cas. - L'utilisation du code HAL généré par STM32CubeMX m'a toujours donné un départ beaucoup plus fluide au moment de la mise en place, lorsque j'avais besoin de tester rapidement une nouvelle carte. Cela peut également aider à expérimenter et à tester des choses. Et lorsqu'une pièce essentielle aux performances doit être optimisée manuellement plus tard, cela sera toujours possible après la configuration d'un projet, ou même l'ajustement incrémentiel avec STM32CubeMX. Vous pouvez mélanger le code manuscrit avec le code HAL.
Quelques problèmes reconnus depuis 2016:
Certaines constantes, structures et signatures de fonction ont changé lorsque de nouvelles mises à jour de code ont été publiées par ST. Les choses semblent être en constante évolution.
Manque de bonne documentation (commentaires dans les fichiers de code) et exemple de code propre (trop spécifique, pas bien documenté non plus).
Code alambiqué, parfois inefficace.
Fautes d'orthographe.
Je n'aime pas HAL pour plusieurs raisons:
- Cela donne aux faux développeurs un faux sentiment qu'ils n'ont pas à savoir comment fonctionne leur matériel.
- Le temps passé à apprendre HAL peut être plus long (et l'est généralement) que nécessaire pour comprendre le fonctionnement du matériel.
- Frais généraux horribles
- Beaucoup d'erreurs.
Mais d'un autre côté, j'utilise HAL (en fait profondément modifié par moi) pour contrôler deux périphériques USB et Ethernet car l'écriture peut prendre trop de temps. Mais comme je l'ai écrit avant, je sais comment cela fonctionne sur le matériel/bas niveau et l'ai modifié à mon goût.
Personnellement, je n'aime pas la bibliothèque HAL pour les raisons suivantes.
- Cela prend beaucoup de mémoire dans mon contrôleur, je n'ai vraiment pas d'espace où je pourrais rentrer dans Bootloader et Application et ici je dois également ajouter 2 frais généraux HAL (un dans Bootloader et un autre dans Application).
- Il utilise en interne des interruptions (je suis sûr que c'est le cas)
- Ce n'est pas sans bogue, j'ai essayé une fois la version 1.0 et j'ai échoué horriblement.
- Le débogage est pénible, vous ne savez jamais où se trouve le bogue, dans votre application ou dans HAL.
Ce que j'ai aimé par ST était la bibliothèque périphérique standard, c'était juste un convertisseur d'assemblage en C et très facile à utiliser.