Go Down

Topic: STM32 Comment cela se programme ? (Read 34266 times) previous topic - next topic

68tjs

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.

trimarco232

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

Quote
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

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

-Standby

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 !
The Mind is like a parachute it works best when opened.

cbrandt

#78
Oct 26, 2017, 10:35 am Last Edit: Oct 26, 2017, 11:34 am by 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 (https://www.rugged-circuits.com/new-products/quadram), 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



weetoz

#79
Oct 28, 2017, 10:32 am Last Edit: Oct 29, 2017, 03:05 am by weetoz
@ 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...

Artouste

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 (https://www.rugged-circuits.com/new-products/quadram), 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)

68tjs

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.

Go Up