STM32F4 et HAL

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?

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é.

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)

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.