STM32F4 et HAL

23

J'ai donc expérimenté un certain temps avec le STM32F407 (je suis nouveau dans ARM) et j'ai décidé d'écrire une application simple en utilisant les bibliothèques HAL car il semble que ST ait abandonné les bibliothèques de périphériques standard. Donc ma question est, quel est le point dans HAL? StdPeriph ne faisait-il pas son travail? Pourquoi l'interrompraient-ils pour HAL? Pour moi, il semble que HAL est un gâchis complet.

La documentation est AWFUL, au moins pour StdPeriph il y a une référence complète assez bien organisée pour trouver facilement ce que vous voulez ( http://stm32.kosyak.info/doc/ ). Pour HAL, il existe un PDF merdique ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ) qui a une structure apparemment aléatoire. En lisant n'importe quelle section, par exemple concernant un périphérique, je n'arrive pas à comprendre les exigences pour le configurer et le personnaliser correctement. Cela ressemble plus à des notes personnelles de quelqu'un qui ne veut pas oublier des choses, qu'à une référence.

Je sais que je peux utiliser CubeMX pour initialiser GPIO et configurer des périphériques, mais mon objectif est de le faire moi-même afin de mieux comprendre leur fonctionnement, pas de logiciel pour tout faire pour moi. Est-ce que je fais quelque chose de mal? Est-ce le débutant ARM en moi qui me déroute? Ou la documentation disponible est-elle si mauvaise?

John
la source
Est-ce que quelque chose comme ChibiOS pourrait mieux vous convenir? Ils ont un RTOS mais aussi un très bon HAL que vous pouvez utiliser sans le RTOS.
IgorEE
ST n'a pas exactement abandonné les bibliothèques de périphériques standard, mais ils n'en publieront pas de nouvelles versions pour les familles plus récentes. Ils ont déclaré (quelque part sur leur forum mais je n'arrive pas à le trouver) qu'ils continueraient à soutenir le SPL pour les familles pour lesquelles il a été publié (y compris STM32F4). Puisque vous êtes nouveau sur ARM, il est probablement préférable d'utiliser HAL. J'ai un grand nombre de modules déjà écrits en utilisant SPL, donc la transition sera pénible et je l'ai retardée. C'est mauvais car une fois que j'ai décidé d'utiliser une nouvelle famille, il y aura d'autant plus de code à porter sur HAL
Tut
Cet ebook: leanpub.com/mastering-stm32 est une bonne introduction pour les débutants (mais aussi pour les professionnels) au monde STM32.
Lorenzo Melato

Réponses:

13

La création de vos propres bibliothèques est assez simple. La documentation de leurs spécifications de registre est assez bonne, la plupart sinon tous les périphériques sont faciles à configurer. Je trouve beaucoup plus pénible d'utiliser leurs bibliothèques. mais c'est peut-être juste moi. Cela est vrai pour st, nxp, ti, atmel pour n'en nommer que quelques-uns (pas tellement pour Intel et Microchip).

Pourquoi changent-ils de bibliothèques, cela pourrait être dû à un certain nombre de raisons, un nouveau patron a pris le relais, une division a été fermée, un autre a pris le relais. Le marketing voulait une nouvelle image pour le produit. Comme l'a mentionné ElectronS, cela pourrait être une tentative de s'éloigner davantage du matériel pour attirer des utilisateurs qui ne veulent pas ou ne peuvent pas faire du métal nu. Je voudrais aller plus loin et dire qu'ils essaient probablement de concurrencer le phénomène Arduino. Ce que mbed et tout le monde a toujours essayé de faire et a échoué (même avant Arduino).

Dans tous les cas, plus le matériel est éloigné, plus il est gonflé et lent, donc plus vous devez dépenser par unité pour le rom, le ram et le mhz. Juste pour que vous puissiez passer le même temps à programmer? Le faire différemment?

Vous dites que vous venez du monde PIC, maintenant ils ont fait du bon travail avec les outils, leurs docs de puce étaient pourtant terribles, certains des pires. ils ont compensé avec des bibliothèques et des bacs à sable.

À la fin de la journée, essayez les différentes options, essayez les produits concurrents pour voir comment leurs outils se comparent. Vous pouvez faire beaucoup de choses gratuitement juste pour voir si cela a du sens et vous pouvez compiler des trucs. Peut-être même utiliser un simulateur de jeu d'instructions. Trouvez celui qui vous correspond.

Remarque, l'option sans bibliothèques prédéfinies est TOUJOURS disponible pour vous. Vous n'êtes pas limité quant à la chaîne d'outils que vous pouvez utiliser, quel système d'exploitation hôte, quelle idée, éditeur, etc. ou fournisseur si vous le pouvez.

Pour vendre un produit à puce comme celui-ci, ils doivent fournir un environnement de développement, que ce soit le leur ou des trucs gratuits qu'ils ont collés ensemble. Et ils ont tendance à mettre en place une bibliothèque quelconque. Il suffit de regarder juste assez bien et le clignotement de l'exemple mené fonctionne assez bien pour que votre direction ou votre équipe matérielle conçoive leur produit, puis lorsque votre produit de carte est jeté par-dessus le mur vers le logiciel, c'est lorsque la douleur arrive ou n'arrive pas. Si cela fonctionne presque, mais pas tout à fait, c'est une grande victoire pour le vendeur de puces, car vous allez maintenant payer le support technique pour ce dernier petit morceau. Il est donc dans leur intérêt d'être presque là, mais pas tout à fait.

Les fournisseurs de puces doivent seulement avoir une apparence suffisamment bonne pour obtenir la victoire du design. Ils doivent continuer à améliorer (? Changer) le produit pour attirer les nouveaux et les anciens clients. Ils devront donc faire des dépassements, la distance et le nombre de bibliothèques antérieures qui continuent de prendre en charge, varient. Donc, presque toutes les bibliothèques auxquelles vous vous habituez disparaîtront éventuellement. Apprenez donc à vous adapter (ou n'utilisez pas leurs trucs et essayez les vôtres, que vous pouvez soutenir indéfiniment). Certes, idéalement, vous n'avez besoin de développer l'application qu'une fois par produit, de rendre votre firmware parfait (bonne chance si vous utilisez des bibliothèques tierces), et vous n'aurez pas besoin de revenir en arrière et de trouver un ordinateur qui chargera leur chaîne d'outils si vous pouvez trouver un copie et rappelez-vous comment utiliser cette ancienne bibliothèque. N'oubliez pas que non seulement vous devez enregistrer votre code source, mais vous devez également enregistrer tous leurs outils et documents.

Leurs bibliothèques ne sont prises en charge que sur une seule chaîne d’outils, sous un ou deux IDE et parfois uniquement sous Windows et certaines versions. Encore une fois, vous n'avez aucune de ces limitations, certainement pas pour ARM, si vous faites votre propre truc. Vous pouvez toujours lire toutes / toutes leurs bibliothèques pour voir comment elles font les choses. Mais c'est souvent très effrayant, ils n'utilisent pas les développeurs de leur équipe A pour les bibliothèques, j'ai extrait quelques lignes de code pour demander aux candidats aux entrevues ce qui ne va pas avec ce code.

pour gagner du temps et des efforts à la fois du côté silicium et du côté logiciel, ils recyclent très souvent la même ip, donc une fois que vous voyez comment le périphérique fonctionne sur l'une de leurs puces, il fonctionne souvent de la même manière sur beaucoup d'autres de leurs puces. Oui, les systèmes d'horloge peuvent être délicats avec ou sans leurs bibliothèques. Forte chance de bricking la puce, c'est là que la plupart de mes briques de chip / board se sont produites. Aide à comprendre comment leurs puces fonctionnent, par exemple les AVR, la plupart sinon tous, peuvent être reprogrammés pendant que la puce est réinitialisée, donc tout mauvais code qui gâche les broches nécessaires pour reprogrammer, ou bloque la logique nécessaire pour reprogrammer, ne fonctionne pas importe, vous pouvez reprogrammer ces puces. Certains de ces fournisseurs (st is one) ont un chargeur de démarrage interne que vous pouvez sélectionner à l'aide d'une sangle (BOOT0 par exemple dans le monde st),

Une taille unique convient à tous. Particulièrement vrai pour les logiciels. Donc, toute tentative d'abstraire le matériel le rend lent et gonflé. Autant obtenir une plus grande puce et exécuter Linux dessus, si c'est ce que vous recherchez vraiment. Cela est dû en grande partie au fait que les développeurs ne veulent pas se salir les mains, nous avons donc essentiellement demandé cela, et ils essaient de le fournir.

Encore une fois, ne vous enfermez pas dans st ou dans un autre fournisseur (à moins qu'il ne soit trop tard et que la direction et que l'équipe matérielle ne vous l'aient collé, notez que les produits stm32 sont agréables et faciles à utiliser). Comparer les prix. TI met beaucoup d'oeufs dans le panier cortex-m4. Vous pouvez faire la chose mbed sur un certain nombre de ces produits d'armement ainsi que sur les solutions prises en charge par le fournisseur.

Une chose sur laquelle vous pouvez toujours compter, c'est qu'ils changeront de bibliothèque de temps en temps et cesseront éventuellement de prendre en charge celle à laquelle vous vous êtes habitué.

old_timer
la source
Grand argument sur le développement de vos propres bibliothèques, presque convaincu et j'aimerais essayer, que pensez-vous que j'aurais besoin d'autre que le manuel de référence stm32fxx? devrais-je également lire le manuel de base du bras? utiliserai-je le CMSIS? comment accéder aux registres et à la mémoire? pourriez-vous élaborer plus ou fournir un exemple sur la façon de commencer
ElectronS
d'autres choses à penser. chaque ligne de code augmente les risques. expliquer à votre patron que vous envisagez d'utiliser des dizaines à des centaines de milliers de lignes de code elses de quelqu'un, sans en revoir chaque partie que vous utilisez. des couches de code, en particulier lors de l'abstraction, entraînent une augmentation des binaires et une baisse des performances. Encore une fois, expliquant à votre patron que les 10 millions d'unités de produit coûteront 35 centimes par ou 3,5 millions de dollars parce que vous avez choisi d'utiliser une bibliothèque parce que vous êtes paresseux.
old_timer
votre patron pourrait embaucher une armée de gens pour vous remplacer pour ce genre d'argent, faire réviser chaque ligne de code afin qu'ils n'obtiennent pas 10000 unités et constater qu'ils doivent les jeter partout dans un bug logiciel causé par l'utilisation d'un logiciel risqué. et utilisez une pièce plus petite qui coûte moins cher à une fréquence d'horloge plus lente qui utilise moins d'énergie et fonctionne plus longtemps avec une seule charge de batterie. parfois, cela en vaut la peine. et bien sûr, parfois non.
old_timer
merci pour le plus de points que vous avez déclaré, mais pourriez-vous répondre à ma question, sur la meilleure façon de commencer? en utilisant les fichiers CMSIS et HAL .h pour les noms de registre et les emplacements de mémoire ??
ElectronS
Il n'y a pas de «meilleur», utiliser ce mot en fait une opinion personnelle, pas un fait. Choisissez-en un et commencez, ou faites comme je pourrais, essayez-en un jusqu'à ce que vous atteigniez un barrage routier, puis essayez-en un autre et un autre, et repoussez chaque barrage routier jusqu'au barrage routier suivant jusqu'à ce qu'un ou tous les traversent.
old_timer
14

Permettez-moi de vous dire que beaucoup d'entre nous partagent la même déception que vous avez avec les bibliothèques HAL, elles sont en effet mal et vaguement documentées et encore nouvelles contiennent de nombreux bugs.

Donc, pour répondre à votre question, pourquoi ST a-t-il décidé de HAL est simple:

  1. Ils veulent créer une couche d'abstraction matérielle qui signifie en clair qu'ils veulent que le développement logiciel et le code soient indépendants du micro-contrôleur, donc si vous écrivez un code aujourd'hui pour stm32f4 et que vous avez besoin après quelques années de migrer vers stm32f7, il sera facile et le code sera hautement modulaire.

  2. Cela permet également à davantage de développeurs comme un programmeur de logiciels de travailler avec le microcontrôleur sans vraiment comprendre ou entrer dans les détails de la façon dont le matériel accomplit une tâche. Des entreprises comme ST et TI (qui commencent maintenant sur cette voie) essaient de rendre le développement intégré similaire au développement de code PC où vous utilisez des pilotes de haut niveau pour développer du code FAST. La maladresse et le manque d'optimisation de leurs pilotes et bibliothèques sont compensés par les performances élevées des périphériques ARM.

  3. Je pense que STM32cubeMX est un excellent outil si vous utilisez des bibliothèques HAL, car le travail le plus long est l'initialisation des périphériques et maintenant vous pouvez le faire en très peu de temps, avec une interface visuelle qui peut être facilement modifiée sans affecter le code utilisateur (si vous écrivez votre code à l'endroit approprié) Vous pouvez utiliser Stm32cubeMx, puis examiner le code et essayer de comprendre comment et pourquoi ils utilisent chaque fonction, de cette façon, vous essayez de résoudre un exercice et d'avoir un manuel de solution à proximité pour correction, ce qui est grand OMI.

  4. Le noyau ARM est complexe et silencieux, donc les anciennes méthodes que nous utilisions sur les microcontrôleurs 8 bits comme la gestion directe des registres (écriture C en mode assembleur) ne sont pas réalisables, elles prennent du temps et rendent le code difficile à maintenir en raison d'une architecture complexe (vérifiez la réglage de l'horloge par exemple)

ElectronS
la source
6
Tout cela est très compréhensible, mais tout cela s'applique également à StdPeriph, n'est-ce pas? Je veux dire, c'est déjà une bibliothèque d'abstraction matérielle, alors à quoi bon en créer une nouvelle au lieu d'améliorer l'ancienne? Je suis vraiment curieux, je suis très nouveau dans ARM, j'utilise les PIC depuis de nombreuses années.
John
Encore plus pour les bibliothèques compatibles CMSIS
Scott Seidman
1
@john, pour autant que je sache, la couche HAL est plus abstraite et moins dépendante du matériel que les bibliothèques standard.
Electrons
12

Je sais que cela va être long et subjectif, mais comme nous venons de lancer (avec succès) notre nouveau produit en utilisant le HAL, je pense que cela vaut la peine d'être considéré. De plus, je ne travaille pas pour ST, j'ai détesté chaque bit de la HAL, j'ai presque redémarré le projet avec StdPeriph, j'ai ressenti la douleur - mais maintenant je comprends pourquoi.

D'abord, un peu de contextualisation. Nous développons des systèmes de télémétrie ultra basse consommation et notre produit est alimenté par un STM32L1. Lorsque nous avons commencé à travailler sur le firmware, nous avions les choix habituels pour les appareils ST (bare metal): tout faire à la main, utiliser les bibliothèques StdPeriph, ou opter pour le HAL. Les gars de ST nous ont convaincus d'aller avec le HAL - nous l'avons donc fait. C'était douloureux, nous avons dû contourner des bogues dans le logiciel (la partie I2C nous a rendus fous pendant un certain temps) et je n'aime toujours pas l'architecture globale. Mais ça marche.

Lorsque je suis passé du bureau à l'intégration, il y a un peu plus d'un an, j'ai été stupéfait par quelque chose d'étrange que je ne pouvais pas nommer ni même saisir. Au fil du temps, j'ai pu comprendre ce qui se passait - ou plutôt ce qui se passait: le monde intégré est en transition. Le silicium devient moins cher tous les jours et les MCU sont plus puissants et polyvalents. De plus en plus d'appareils, quelle que soit leur taille, leurs besoins en énergie, s'appuient sur des microcontrôleurs génériques. De plus en plus d'entreprises se joignent au jeu, apportant une horde de nouveaux développeurs d'horizons divers. La culture «moyenne» dérive du «gars EE traditionnel avec des compétences de sorcellerie en programmation» au «gars SW avec une connaissance vague du matériel».

Que ce soit bon ou mauvais est sans importance. Ça arrive juste. En fait, cela est également arrivé au monde du logiciel, plus d'une fois. Le boom du web en 2000 a attiré les débutants en PHP / MySQL - allez leur dire qu'il y a des registres dans le CPU, ils répondront "j'utilise Linux, donc il n'y a pas de registre dans mon OS". Auparavant, les systèmes d'exploitation multi-utilisateurs fonctionnant en mode protégé permettaient aux développeurs paresseux de ne jamais configurer un ISR au cours de leur carrière et de s'en sortir . Même plus tôt, les claviers et les perforateurs de cartes et les fabricants d'imprimantes sont devenus fous.

Et oui, les tendances actuelles me font personnellement triste, car je vois des développeurs ignorants impressionnés par les dernières technologies brillantes, tout en étant totalement incapable de les relier à l'histoire. Quand je vois un plus jeune moi coder un jeu en Javascript avec WebGL en 2015, je veux crier "Il n'y a rien de nouveau! J'ai fait la même chose avec C ++ et le SDK 3Dfx en 1995!". Ce que l'histoire ne dit pas, c'est que son jeu fonctionne sur mon téléphone mobile, alors que le mien avait besoin d'un PC de joueur (et d'un installateur, et je ne pouvais pas pousser les mises à jour par le Web). La vérité est qu'il a pu développer son jeu en un mois, où j'ai fait de même en six ou douze.

De toute évidence, ni ST, ni TI, ni Intel, ni celui qui fabrique des puces, ne veut manquer le tour. Et ils ont raison. Le HAL est la réponse de ST, et est en fait assez solide, non seulement sur le plan commercial ou marketing, mais également sur le plan technique. La raison pour laquelle il est sain réside dans le nom:

Matériel Abstraction couche

Au moins, c'est ce dont vous devez vous souvenir. Le HAL est un effort pour s'éloigner du matériel. C'est une bonne ingénierie car elle nous permet de découpler la fonctionnalité des détails. La superposition est ce qui permet de développer des programmes complexes - une abstraction au-dessus d'une autre, jusqu'au matériel. L'abstraction est en fait l'outil le plus puissant dont nous disposons pour gérer la complexité . Je doute fort que quiconque sur cette planète puisse programmer un navigateur Web en assemblage pour un processeur spécifique.

Le changement culturel est en effet difficile à digérer, mais comme je dois penser qu'il n'est pas nécessaire d'avoir lu l' art de la programmation informatique de Knuth pour développer des applications Web, le monde de l'EE doit admettre qu'il existe de nouveaux arrivants qui peuvent (et vont!) Développer du code intégré sans avoir lu le Fucking Holy Reference Manual.

La bonne nouvelle est que les nouveaux joueurs ne signifient pas moins de travail pour les joueurs plus âgés - bien au contraire, à mon humble avis. Qui vont-ils appeler lorsque les choses "ne fonctionnent pas?". Si vous avez RTFM (contrairement à eux), et si vous savez ce que fait chaque bit de ce registre de configuration obscur, vous avez un avantage.

Entre vos lectures et expériences, rendez-vous avec le HAL. Nouveau MCU? Aucun problème. Nouvelle ligne MCU? Pas de problème non plus (j'ai codé un test sur un Nucleo STM32F4 en seulement une journée avec CubeMX, puis je l'ai simplement porté sur notre appareil ... ça me semblait juste ). Se moquer des tests unitaires? Aucun problème. La liste s'allonge encore et encore, car l'abstraction est bonne.

Bien sûr, le HAL lui-même n'est pas 100% OK. Sa documentation est horrible (mais vous avez RT F HRM, n'est-ce pas?), Il y a des bugs, ST vient de nous envoyer une version bêta (semble assez standard ces jours-ci) et leur support public est une blague. Mais ne pas avoir libéré le HAL aurait été encore pire.


la source
Je vois d'où tu viens. Si je comprends bien, les choses vont (malheureusement) dans le sens d'Arduino, essayant de cacher autant de réalité au programmeur pour attirer plus de personnes logicielles de haut niveau dans la programmation matérielle, et c'est la raison derrière des bibliothèques telles que HAL. Voyant cependant à quel point c'est mal documenté et un gâchis complet aussi, je ne pense pas qu'ils réussiront à le faire de si tôt.
John
@John: HAL ne cache aucune "réalité". Tout est là pour vous. Toutes les parties sont facultatives - par exemple, vous souhaiterez peut-être utiliser uniquement les macros pour accéder aux registres, ou uniquement un pilote spécifique (par exemple I2C) ou tout, y compris les ISR et la configuration de l'horloge. Votre choix. Cependant, je conviens que la documentation est très chiante. (J'ai dit à ST et ils ont promis qu'ils y travaillaient BTW)
Nous répétons la même chose avec de nouveaux outils. Parce que les nouveaux outils promettent de rendre le travail plus facile et plus rapide, donc rentable. Mais nous faisons toujours la même chose, car les êtres humains sont toujours les mêmes, que ce soit en 2095 ou 1995. Le choix qui nous reste est de suivre les nouveaux outils ou de rester avec nos outils déjà familiers.
Jony