Je ne sais pas si c'est toujours le cas mais il y a 2, 3 ans certains modèles de ST-Link chinois avait un circuit imprimé avec brochage différent de celui écrit sur le capot. Si on suit les indications du boîtier on provoque un court-circuit.
Comment les reconnaître si malheureusement il y en a encore qui traînent à la vente :
Méthode barbare : brancher et regarder si tout s'éteint c'est qu'il y a le court-circuit.
Méthode policée : (pour Linux)
Après connexion du St-Link regarder le résultat de
$dmesg | tail -10
Si vous lisez :
usb 2-4: SerialNumber: 9 c'est bon
Par contre si vous lisez :
usb 2-4: SerialNumber: PÿtQ\xffffffc2\xffffff87VSD3%g
Ce n'est pas bon, il faut ouvrir le capot et lire le brochage réel sur le circuit imprimé et après tout est est ok.
Information :
Les programmes ST-link et autres St-machin sont maintenant disponibles en paquet Debian. Pour Buster pas de problème, pour Stretch il faut activer les dépôts backport.
Dans l'ancienne méthode où il fallait télécharger les sources chez Texane la doc fournissait deux versions de règles Udev. La version qui fonctionne avec la bluepill à 2€ est la version pour les cartes discovery.
Il faut réserver la version Nucleo aux cartes Nucléo.
Ces petite machins qui n'ont l'air de rien fonctionnent :
riton@alpha:/mnt/sdc1/riton$ st-flash write /tmp/arduino_build_579822/Blink.ino.bin 0x8000000
2019-03-29T21:17:02 INFO src/stlink-common.c: Loading device parameters....
2019-03-29T21:17:02 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-03-29T21:17:02 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2019-03-29T21:17:02 INFO src/stlink-common.c: Attempting to write 12844 (0x322c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003000 erased
2019-03-29T21:17:02 INFO src/stlink-common.c: Finished erasing 13 pages of 1024 (0x400) bytes
2019-03-29T21:17:02 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id
2019-03-29T21:17:02 INFO src/stlink-common.c: Successfully loaded flash loader in sram
12/12 pages written
2019-03-29T21:17:03 INFO src/stlink-common.c: Starting verification of write complete
2019-03-29T21:17:03 INFO src/stlink-common.c: Flash written and verified! jolly good!
riton@alpha:/mnt/sdc1/riton$
Quelques fois la merde chinoise se cache bien sous des apparences trompeuses !
Je suis de plus en plus convaincu par l'IDE PlatformIO (Visuel Studio), sur ARDUINO, ESP8266 ou ESP32 et STM32, même MSP430 on dirait, et bien d'autres.
Sur STM32 le chargement est fait par OpenOCD.
Avec les cartes ST cela se passe très bien.
Mais sur la BLUE PILL apparemment le code est bien chargé mais il démarre au mauvais endroit.
Certainement un problème de vecteur de reset.
Avec l'utilitaire ST-FLASH de ST Microelecronics c'est correct.
Je travaille actuellement sur une F429ZI, une carte possédant 3 ADC 12bits :
Cette carte est époustouflante :
833333 échantillons par seconde et par canal en mode polling.
Si j'utilisais les interruptions ou la DMA ce serait encore plus fort, mais j'ai besoin de 100K/s, pas plus.
Actuellement j'exploite deux canaux.
A comparer avec les 38500 échantillons par seconde que l'on peut obtenir d'un ARDUINO sur lequel l'ADC est boosté. Il paraît que l'on peut le pousser à 77000.
Et l'ADC n'a que 10 bits.
Voici un petit retour d'expérience sur l'utilisation du STM32.
J'ai acheté, il y a quelques mois de cela, un clone maple mini embarquant un STM32F103C8, afin de l'utiliser dans l'environnement Arduino.
Je n'avais pas eu le temps de le mettre en oeuvre j'usqu'à hier.
Une fois les bibliothèques installées (stm32duino), le branchement de la carte créer dans windows (désolé linuxiens) un nouveau port série.
Pour tester la bébète, je compile sans problème un sketch style blink mais le téléversement est systématiquement en erreur " DFU not find".
Je télécharge depuis le site de St Micro le
stm32 loader demonstrator
et en utilisant un convertisseur usb vers série connecté aux ligne TX1 et RX1 du maple mini.
Je démarre la carte avec boot0 à Vcc.
Je constate que la mémoire du stm32 est protèger en écriture.
Pas de problème, le soft stm32 loader demo permet de dévérouiller la mémoire mais l'éfface en totalité.
Pour le rendre le maple de nouveau fonctionnel, il faut lui injecter un nouveau boot loader.
Détail : le stm32 loader demonstrator est une application Windows.
Dommage de flasher un bootloader alors que le STM32 en possède déjà un nativement, celui qui te permet d'ailleurs de charger le bootloader STM32DUINO par la ligne série.
Mais c'est vrai que cela oblige à utiliser un convertisseur USB / série.
Pas besoin de ST-LINK.
Ce boîtier est ce que j'utilisais au boulot pour charger à partir d'un Makefile en ligne de commande.
Avec l'IDE ARDUINO il y a plus simple : stm32f103c8t6-et-arduino. Voir 7. Chargement
PaltformIO donne le choix entre différentes librairies : Stm32Cube, Arduino (Stm32Duino), MBed, etc.
A ma connaissance stm32CubeIde n'offre pas ce choix. A la limite, installer Stm32Duino ne devrait pas être insurmontable, mais cela demandera un effort conséquent.
Oui, c'est sûre mais du coup on n'est pas non plus avec le même confort d'environnement.
Après je n'ai pas testé PaltformIO IDE, mai uniquement dans VSCode.
VSCode étant bien mieux selon mes gouts que Arduino IDE, mais ne vaut pas un "vrai" IDE
