STM32 Comment cela se programme ?

Bonjour,

Mon laboratoire veut concevoir une passerelle multi-protocoles qui convertit un certain nombres de protocoles de communication venant de différents équipements vers un protocole standardisé pour faire de la supervision. Le choix s'est porté sur une carte de processeur Stm32F107 avec 256 Kbytes de mémoire flash et 64 Kbytes de SRAM. je me demande si cette carte peut assurer l'acheminement des données vu que la passerelle est sensé récupérer un volumes de données importants provenant de différent compteurs d'énergie et de régulateurs.

J'ai besoin de l'avis d'un expert svp. Merci

Bonjour,

Je suis nouvelle dans ce groupe.Je viens de rencontrer des problèmes avec le logiciel MBED. En effet, je suis une étudiante en 3e année en électronique et mon projet de cette année consiste à prendre des mesures à distance avec le microcontrôleur nucléol L152RE.

De ce fait j'ai choisi le systeme GSM pour recupérer les mesures prises par le microcontrôleur. J'ai commencé a codé mais j'ai un problème de compilation, avec le logiciel MBED. A chaque fois que j'importe une libary, ça me fait "Error: Cannot open source input file "Storage_Libary/storage.h": No such file or directory in "main.cpp", Line: 5, Col: 37" par exemple.

Merci de m'aider car c'est la 1ere fois que je travaille avec ce microcontroleur. J'ai deja traité ce projet avec arduino mais cette fois-ci on m'a imposé le L152RE.

Merci d'avance

J'ai comme une idée que MBED est un système concurant d'Arduino.
Parler de MBED à titre d'information est naturel, transformer le forum Aruino, financé par Arduino, en forum d'entre-aide MBED ne me parait pas très naturel.

Je pense que tu devrais aller sur le forum mbed pour exposer tes soucis. C'est vrai qu'il n'est qu'en anglais, espagnol et japonais et plutôt orienté pour les professionnels mais cela sera plus conforme.

Bonjour à toutes et à tous,

il y a maintenant un peu plus d'un an, je me suis procuré une Nucleo 32 F303k8 (puis ensuite une NucleoF746 pour ses 144 IO puis une discovery F469).
Avant a Nucleo, je m’étais acheté à prix d’or une DUE, et je me suis très vite rendu compte que a librairie iquide crystal I²C ne fonctionnait pas, c’est ce qui m’a décidé de passer chez STM32.

Coté IDE j’ai SW4STM32 basé sur Eclipse CDT, développé et supporté par Open AC6 et STMicroelctronic. Cocorico !!
SW4STM32 est donc multiplateforme, ça aussi c’est cool.
Sur le site openAC6 il y a un forum en anglais ( pas cocorico…) très réactif sur les questions des librairies et de l’IDE
Pour la préconfiguration, il y le soft STMCubeMX pour faire ça sous forme graphique, parfait pour commencer.
Bon au début j’en ai ch**r, d’ailleurs toujours mais pu pour les mêmes raisons.
L’arbre des horloges c’est une dinguerie, c’est hyper souple.

Même en IO digital c’est assez riche, pull up ou pu down, drain ouvert ou push pull…
La librairie Cube HAL est assez compète aussi.
Coté doc, il faut s’y habituer, entre la datasheet, le RM, les UM,les AN… faut du temps pour trouver ses infos.
Pour l’instant les applications que j’ai réalisées sont assez basique, je suis encore très loin de pouvoir exploiter tout ce que je veux, mais petit à petit… En ce moment je suis sur les timers, c’est d’une puissance par rapport à un AVR.
Bref faut se faire mal, mais personnellement je suis très content d’avoir sauté le pas.
C’est vrai que pour les amateurs (dont je fais partie), c’est pas évidant, pour quelqu’un qui n’a jamais pratiqué l’Arduino et le C, c’est impensable. Une bonne base en Arduino est nécessaire.

@Super_Cinci
Alors, tu t’y es mis Super_Cinci ?
@68tjs
T’en es où, as-tu acheté une carte ?

Sinon n'hésitez pas à faire un tour sur le forum du CDM, on pourra échanger sur le sujet. Et puis ça fera plaisir à Skywodd !

Oui une carte basée sur STM32F103C8T6 qui peut se programmer à partir de l'environnement Mbed, il y a juste à faire attention ce modèle a la moîtié de la mémoire du modèle qui équipe la carte Nucleo .
La carte Ebay ne coûte que 3€ + ~5€ de programmeur STLink.

J'ai laissé tomber (provisoirement ? ) parce que sous Linux il me faut compiler moi même le programme de téléversement (STLink).
Cela à bien fonctionné mais j'ai bêtement effacé l'exécutable.
Quand j'ai voulu le recompiler j'avais une nouvelle version de GCC et les sources disponibles chez texane n'avaient pas été mises à jour. J'ai eu droit à une bordée d'erreurs que j'étais bien incapable de comprendre et donc de résoudre.

Je me dis qu'il faudrait que je vérifie si une mise à jour à été faite mais je suis parti à faire joujou avec un ESP32 qui sans parler du Wifi et du BT et sans être un ARM tout en étant 32 bits possède de grosses capacités. Seul défaut la documentation n'est pas aussi claire que celle d'Atmel ou STMicro
Pour le moment j'en suis à chercher qu'elles sont les fréquences d'horloge du bus qui gère les E/S et du bus qui gère les timers.
Sur ce point la doc STMicro est une merveille de clarté et si je ne l'avais pas regardé avant de passer au ESP32 je pense que je n'aurai pas imaginé que dans ces micros existent plusieurs pll et plusieurs bus chacun avec une fréquence d'horloge différente.

Pour récupérer ta carte, tu peux éventuellement... sous windows utiliser le soft ST-Link Utility, ->Target->full erase chip.

Sous Ubuntu, je faisais un simple glisser-déposer du binaire générer avec SW4STM32, ça marchait très bien.

Bon courage avec l'ESP32.

Cela je l'ai eu fait sans problème au début.

Pour bien se comprendre STMicro donne deux significations au terme STLink :

  1. C'est le programmeur qui utilise le bus spécifique à ST pour charger des programmes dans les micros.
  2. C'est aussi le nom du logiciel qui gère ce programmeur : un équivalent d'avrdude en quelque sorte.

Précision je n'ai pas et je n'aurais pas Windows où il est vrai que des exécutables existent pour STLink(logiciel).
Sous Linux j'ai compilé le logiciel STLink et cela fonctionnait parfaitement comme tu dit glisser/copié.
Je n'ai plus de version compilée pour des raisons de mauvaise manip et je n'arrivais plus à en compiler une nouvelle version.
C'est là que j'en suis : une difficulté pour compiler les sources de STLink et des messages d'erreurs que je ne comprends pas.
Quelqu'un ayant plus de connaissances que moi dans le domaine des compilations aurait sans doute réglé le problème depuis longtemps mais mes vieux neurones commencent à fatiguer.

Ah ok, c'est les sources du soft que que ne compile plus correctement... Aîe, ça craint...

Je suppose que tu as déjà essayé avec Wine...

Bonjour,
SW4STM32 ?

Est ce que cela comprend les utilitaires STLink sous linux ?

Pour un amateur peu chevronné la solution la plus simple d'usage et toujours disponible c'est Mbed dans un navigateur internet et ses très nombreuses bibliothèques.

La solution AC6 permet de garder la maîtrise de son compilateur.

Est ce que cela comprend les utilitaires STLink sous linux ?

une réponse trop facile serait : je n'ai vu personne se plaindre de l'inverse sur la toile ...

plus simple d'usage et toujours disponible c'est Mbed

oui, c'est l'esprit arduino. A savoir si ces bibliothèques peuvent s'importer facilement vers un autre IDE

La solution AC6

c'est utilisable dans SW4STM32

je ne puis en dire +, car je n'installerai SW4STM32 qu'à l'occasion du renouvellement de mon PC ...

J'ai un temps utilisé des microcontrôleur ST particulièrement pour faire du temps réel.
Leur utilisation est fastidieuse, je ne compte pas les XYZ IDE et compilateurs disponible.

Ces inconvénients m'ont tourné vers les PsoC qui sont sans les glorifier d'une flexibilité incroyable, tout est regrouper en un seul package, la programmation, un plombier pourrait la faire !

Bonjour à tous,

Je programme aussi avec des ARM (Tennsy3.2 et ST Nucleo,) en plus de la Mega2560. (pour info je travaille sous MacOS)

Tout d'abord en voici la raison:
Mon projet de domotique (en cours depuis… euh… quelques années déjà) nécessitant plus de ram que les 8ko de la mega de base, je m'étais procuré une carte d'extension (QuadRAM — Rugged CircuitsRugged Arduino), portant le tout à 64 ko.
C'était super ! Mais la carte n'était plus fabriquée au moment où il m'en fallait une autre…

Je me suis donc tourné vers la carte Teensy3.1 / 3.2 qui avait ces 64 ko de ram en interne. Quelques avantages:

  • compatible Arduino au niveau du code et de l'IDE
  • 64 ko de Ram
  • pas de progmem ni de read_byte_near etc, 'const' suffit pour placer les constantes en flash et pas de code de spécial pour y accéder - la mega2560 m'avait donné du fil à retordre dès que mes chaînes en flash ont basculé au-delà de la limite des 64 ko (ou 128 ? je ne sais plus)
  • petit format

Mais pas de debugger ! Mettre des serial.print partout ça va bien 5 minutes…

Et voici la série des carte Nucleo !!!

En deux mots: pour moi c'était ce que j'attendais !

  • pas cher (16 euros)
  • j'ai choisi la STM32F411 pour la ram (128 ko je crois)
  • environnement mbed: cepandant je l'utilise en local et pas online - en fait c'est facile, l'astuce consistait à créer un projet 'blink' quelconque dans l'editeur mbed online, puis de faire un export, ce qui m'a créé un projet complètement local. je ne sais plus cepandant d'où j'ai récupéré la toolchain gcc-arm (sûrement quelque part sur le site mbed). Donc la compilation se fait via make ou équivalent et l'upload via stlink. donc pas d'IDE arduino ici.

Là où ça devient vraiement intéressant, c'est que la sonde jtag hardware est intégrée à la carte nucléo, et openocd permet d'interfacer gdb avec la carte via STLink.
Au final j'ai le débugger au niveau source avec point d'arrêt et tout le tintouin…

Du côté des inconvénients:

  • du boulot pour adapter mon projet: j'ai dû reimplémenter l'API des classes Serial, SPI, I2C pour appeler l'API mbed, ainsi que les digitalRead, digitalWrite, pinMode etc.
    Ceci pour ne pas modifier mon code source partout, parce que je voulais le garder compatible avec les carte AVR mega2560.
    Mais le plus gros boulot était de modifier les blibliothèques Ethernet et SdFat: ces deux-là appellent le bus SPI directement pour des questions de performances. J'ai donc fait des modifs pour les rendre indépendantes de la plateforme (AVR, ARM…) et appeler simplement la class SPI (la standard pour AVR et la mienne pour ARM, qui se contente de faire le lien avec l'API mbed) partout où il y avait des appels directs aux registres SPI.
  • l'encombrement de la carte: un peu plus grande qu'une UNO, mais elle a la connectique pour les shields. Cepandant maintenant il y a des cartes au format Nano, mais que je n'ai pas encore testées.

Je perds probablement en performances par rapport à ce que j'aurais pû avoir avec le code optimisé, mais je gagne en portabilité…
Et le debugger me manquait, ayant l'habitude de développement sur micro-ordinateur…

edit: orthographe

@ 68Tjs :
Wine est un soft permettant de faire tourner des softs windows, donc avec Wine, tu installes STlink utiity (STink009).
@Trimarco et 68Tjs
Je testerai ça demain sous une Vm ubuntu et je vous ferais un retour.

[édit] L'installation de ST-Link-Utility n'a pas fonctionné avec Wine...

cbrandt:
Bonjour à tous,

Je programme aussi avec des ARM (Tennsy3.2 et ST Nucleo,) en plus de la Mega2560. (pour info je travaille sous MacOS)

Tout d'abord en voici la raison:
Mon projet de domotique (en cours depuis… euh… quelques années déjà) nécessitant plus de ram que les 8ko de la mega de base, je m'étais procuré une carte d'extension (QuadRAM — Rugged CircuitsRugged Arduino), portant le tout à 64 ko.
C'était super ! Mais la carte n'était plus fabriquée au moment où il m'en fallait une autre…

Je me suis donc tourné vers la carte Teensy3.1 / 3.2 qui avait ces 64 ko de ram en interne. Quelques avantages:

  • compatible Arduino au niveau du code et de l'IDE
  • 64 ko de Ram
  • pas de progmem ni de read_byte_near etc, 'const' suffit pour placer les constantes en flash et pas de code de spécial pour y accéder - la mega2560 m'avait donné du fil à retordre dès que mes chaînes en flash ont basculé au-delà de la limite des 64 ko (ou 128 ? je ne sais plus)
  • petit format

Mais pas de debugger ! Mettre des serial.print partout ça va bien 5 minutes…

Et voici la série des carte Nucleo !!!

En deux mots: pour moi c'était ce que j'attendais !

  • pas cher (16 euros)
  • j'ai choisi la STM32F411 pour la ram (128 ko je crois)
  • environnement mbed: cepandant je l'utilise en local et pas online - en fait c'est facile, l'astuce consistait à créer un projet 'blink' quelconque dans l'editeur mbed online, puis de faire un export, ce qui m'a créé un projet complètement local. je ne sais plus cepandant d'où j'ai récupéré la toolchain gcc-arm (sûrement quelque part sur le site mbed). Donc la compilation se fait via make ou équivalent et l'upload via stlink. donc pas d'IDE arduino ici.

Là où ça devient vraiement intéressant, c'est que la sonde jtag hardware est intégrée à la carte nucléo, et openocd permet d'interfacer gdb avec la carte via STLink.
Au final j'ai le débugger au niveau source avec point d'arrêt et tout le tintouin…

Du côté des inconvénients:

  • du boulot pour adapter mon projet: j'ai dû reimplémenter l'API des classes Serial, SPI, I2C pour appeler l'API mbed, ainsi que les digitalRead, digitalWrite, pinMode etc.
    Ceci pour ne pas modifier mon code source partout, parce que je voulais le garder compatible avec les carte AVR mega2560.
    Mais le plus gros boulot était de modifier les blibliothèques Ethernet et SdFat: ces deux-là appellent le bus SPI directement pour des questions de performances. J'ai donc fait des modifs pour les rendre indépendantes de la plateforme (AVR, ARM…) et appeler simplement la class SPI (la standard pour AVR et la mienne pour ARM, qui se contente de faire le lien avec l'API mbed) partout où il y avait des appels directs aux registres SPI.
  • l'encombrement de la carte: un peu plus grande qu'une UNO, mais elle a la connectique pour les shields. Cepandant maintenant il y a des cartes au format Nano, mais que je n'ai pas encore testées.

Je perds probablement en performances par rapport à ce que j'aurais pû avoir avec le code optimisé, mais je gagne en portabilité…
Et le debugger me manquait, ayant l'habitude de développement sur micro-ordinateur…

edit: orthographe

Bonsoir Cbrandt
merci ,pour "ton exposé" documenté 8)

Merci à Kaltom d'avoir relancé le sujet.
Du coup cela m'a réveillé et je suis reparti à la pêche aux informations.

Et je suis tombé sur le bon poisson :
Un auteur qui expliquait que l'organisation des fichiers Texanne n'était pas compatible avec celle de Debian, mais que c'était enfantin de faire les modif. Suivent quelques dizaines de lignes auxquelles je n'ai strictement rien compris, visiblement la notion " d'enfantin" n'est la même pour tout le monde.

Mais je me suis dit : si ce n'est pas problème Linux mais un problème Texanne/Debian, avec un peu de chance il existe des fichiers pré-compilés dans l'autre système de paquetage : RPM.
Et j'ai trouvé chez Fedora (version open source de Red Hat). Vite fait un coup d' "alien" et le paquet deb est disponible.
Bon il y a eu quelques manipulations supplémentaires mais tout est indiqué dans l'anti sèche que je m'étais préparé et que j'ai actualisé.

Et je peux de nouveau flasher mes STM32.

Nota : comme toujours le forum n'accepte pas l'odt, comme c'est mon jour de bonté j'ai fait un enregistrement doc 2003.

STLink.doc (96 KB)

Je relance un peu ce vieux sujet, car je découvre le boardmanager de l’IDE version 1.8.5, et toute la série de cartes Nucleo est couverte.
Du coup l’usage dans l’environnement arduino est simplifié, et ça marche plutôt bien (testé avec une Nucleo STM32L432KC au format Nano).
J’en n’ai plus qu’à adapter mon environnement de développement pour retirer ma surcouche Arduino->mbed...

Bonjour cbrandt,
je n'ai pas bien compris la dernière phrase ?

C’est en référence à mon post d’octobre 2017 un peu plus haut, où j’expliquais que pour porter un projet arduino sur la nucleo nouvellement acquise (qui ne fonctionnait que dans l’environnement mbed à l’époque), j’avais ré implémenté quelques appels de l’api arduino vers l’api mbed, histoire de garder la compatibilité arduino-mbed de mon projet