Reprise du message précédent :
En comparaison le pico est encore plus friendly je trouve.

Le SDK du pico est moins usine à gaz à faire tourner que STM32Cube effectivement, mais un peu plus rustique. Après y'a peut être des machins magiques dans PlatformIO ou autre vu que je ne suis toujours en retard  

STM32Cube, faut l'utiliser pour la configuration des clocks et ensuite utilisé autre chose
Je me demande qui l'utilise pour développer en dehors de trucs rapides.
PlatformIO a un framework fonctionnel pour les STM, mais pas à jour pour les dernieres versions (entre autre openOCD)

La blackpill est quand même à 30€. Il y a une nucléo à 11€ (pour moi rapidement limité), ensuite sur AE c'est pas exactement compatible (n° de version erronnée) et faut rajouter le ST-Link à 10€ (ou plus et je conseille de prendre plus).

---

Ensuite faut voir l'utilisation, les STM avec leur histoire de clock permet d'optimiser énormément la conso. Si c'est pas un critère, c'est pas forcément un choix pertinent par rapport au prix.

Donc à part les AVR, toujours aucun micro avec une toolchain libre de qualité ?

Les cartes AE c'est des CI soit-disant compatibles ou clone ou quelque chose. J'ai vu que j'en ai une telle en stock ainsi qu'un ST-Link (de chez AE donc probablement clone ) acheté il y a loooongtemps, du coup je vais déjà bricoler un peu avec ça. Après il n'est pas exclu que je regarde le RP2040 aussi, surtout avec ses PIO.

STM32Cube y'a moyen de s'en passer il semble si on bricole un peu, chercher p.ex. "STM32 bare metal". Après bien sûr on aura pas le comfort d'une GUI pour configurer le micro, mais perso j'aimerais éviter les usines à gaz (pas FLOSS aussi non?)...  A priori tout ce qui est important est documenté (publiquement) par ST.

Un site qui pourrait être bien utile: https://stm32-base.org/

Les stlink si c'est un vieux il faut le mettre a jour et c'est vite la merde, j'en ai eu tellement marre que j'ai racheté une nouvelle version clone déjà à jours
 
Pour les boards de dev, des clones de f103 coutent une misère, littéralement 3e livrés. Par contre j'ai déjà eu des surprises sur des problèmes de compatibilités notamment sur l'usb, c'est réglé sur les nouvelles versions mais c'est à garder à l'esprit que ce n'est pas forcément "parfait".  
Perso pour me faciliter la vie je met des bootloader pour gérer le DFU et permettre la programmation en usb, typiquement katapult.
 
Sinon pour pas se prendre la tête il faut partir sur des chips intégrant un bootloader usb natif : esp32 ( certains) et toute la séries des RP.
Rien que pour ca je me sert de plus en plus du pico : tu branche, ca se monte tout seul , tu glisse ton DFU dessus et hop c'est programmé. Pas d'environnement super lourd, pas de logiciel merdiques, pas d'usine a gaz avec des prog proprio qui coutent un bras ou des clones qui nécessitent de mettre les mains dans le cambouis.  
 
En plus pour les RP/ESP il y a du support Arduino et du micro python, le premier est pas parfait mais en fonction de la destination du projet c'est un gros plus.  

Bon, j'ai une LED qui clignote sur mon "Bluepill" et sans le bazar officiel (STM32Cube). Par contre...

Ouais. Pour rappel, c'est juste une LED qui clignote! La va falloir creuser, au moins pour la RAM. Si quelqu'un a des pistes...
 

Ca dépend de ce que tu entend par "qualité". Le GCC supporte les STM32 et il fait bien son boulot, par contre si on veut se passer du Cube (FLOSS ou pas FLOSS? J'ai pas vérifié ) il faut visiblement vraiment mettre les mains dans le bazar. Perso ça ne me fais pas peur, mais c'est sûr que ça peut vite devenir chiant.

T'as un bout de code pour initialiser le micro, la pile etc. Et niveau mémoire pareil faut une pile donc ça doit être ça la consommation de base. Ça ne grossira pas bien plus une fois que tu rajoutera des fonctions.

Certes, m'enfin >2ko de base? Ca me paraît franchement trop. A priori une bonne partie de .data vient de je ne sais quel bazar newlib, à voir si y'a pas une option pour désactiver ça...

newlib c'est une bibliothèque C standard qui fournit les fonctions de base : https://cplusplus.com/reference/clibrary/
 
A vue de nez par exemple lors de l'initialisation y'a memset() qui peut être utilisé pour mettre du 0 partout dans la RAM, si tu demande pas la version minimaliste la fonction fait presque 50 lignes donc probablement 200 à 300 d'assembleur  

Ah ben c'est déjà mieux.  

Par contre pour y arriver j'ai recompilé newlib, donc faut vraiment vouloir.  
 
La valeur .bss me plaît pas encore, à creuser...

J'ai perdus presque une après-midi a cause d'un foutu OLED 1306.
Impossible de le faire redémarrer après coupure électrique de son alimentation, au final ca s'est soldé en soudant un câble pour piloter sa broche rst via un transistor et en jouant longuement sur les timings.
 
Bilan des courses : les clones pas chers souvent ca se passe bien, des fois pas du tout

Oui j'ai déjà eu des afficheurs qu'il fallait absolument remettre à zéro avec la broche dédiée pour pouvoir les faire fonctionner. Au pire un petit RC et une porte triggeur de Schmitt.

BSS tu t'en fout c'est l'espace virtuellement réservé en mémoire par le linker aux variables globales non initialisées, sachant que t'as des chances que 90% représentent la pile.

Ah ok, y'a la pile la dedans. Oui, dans ce cas osef. Merci pour la confirmation, j'avais un doute.

Bah juste gcc, une libc, et un outil pour flasher, le tout stable et inclus dans debian.

Pour le STM32 y'a libopencm3 qui fait le boulot à la place de la cube s'il faut  
https://github.com/libopencm3/libopencm3

STM32Cube est interessant pour la generation de la configuration des clocks et avoir le schéma pour tester. Sinon pas besoin, mais c'est rapidement galère. Cela aide aussi pour comprendre certains types de fonctionnement.
Je l'utilise assez rarement

Fallait pas utiliser chatgtp Fait voir ton programme

Quels CFLAGS as-tu utilisé ?

L'option -s permet de virer pas mal de choses inutiles hors debug, tout comme la commande strip.

Ensuite -Os permet de gagner pas mal de place.

Il y a aussi les libs qui manipulent des chaînes de caractères, comme celles qui fournissent printf() qui prennent énormément de place, et dont tu peux coder une version allégée, dans le même genre que Serial.print() dans l'environnement Arduino.

Si tu n'as pas besoin de ça pour faire clignoter une LED, autant inclure le minimum de headers et linker le minimum de bibliothèques .

Eh oh! Le code est basique (et sans le HAL STM), le seul truc crade est une boucle d'attente avec un "volatile" pour éviter que le compilateur optimise "trop".

Merci . Je connais (un peu ) les options gcc vu que je l'utilise très souvent pour x64 et avr aussi.
J'ai pas mis de -O exprès pour voir comment se débrouille le compilateur avec le réglage par défaut (-O2?). Si je rajoute -Os la valeur .text baisse légèrement, le reste ne change pas, comme on peut s'y attendre. Pour du code plus "fourni" ça a son importance par contre, c'est sûr.
-s et strip ne changent rien dans mon cas.
Comme disait Natopsi c'est le code d'init (que j'ai - pour l'instant du moins - pas envie de réinventer) et du code de chez newlib qui est à l'origine de la place occupée (merci objdump -d et le mapfile), mais là j'ai déjà bien optimisé, voir l'autre message. Pour ça j'ai notamment recompilé newlib en désactivant plein de trucs et j'ai instruit gcc pour utiliser cette version plutôt que la version fournie par défaut.
Je veux pas vraiment publier mes commandes exactes car 1) c'est encore "en cours d'élaboration" (et assez bordélique ) et 2) ça risque de finir sur mon github et je ne veux pas donner le pseudo / faciliter la reconnaissance XYZ==rat de combat.

arm-none-eabi-gcc est dispo, newlib vient avec et pour flasher j'utilise st-flash dispo aussi. Par contre ce dernier ne prend que du .bin, donc un coup de objcopy s'impose. J'ai pas réussi à faire fonctionner mon vieux STLink-clone avec openocd (qui sait lire les .elf). Donc en théorie il y a déjà "tout", en pratique non car il faut au moins télécharger les header voir le code HAL et puis si on tient à optimiser c'est assez galère comme tu as du le constater en suivant mes aventures. Pour AVR c'est plus simple en effet...

J'ai testé rapido : used 528 bytes de flash
Peu mieux faire =)

Ensuite faut utilise les drivers LL, c'est quand même plus pratique qu'en registre direct

Pour la LED ma main() ne fait que 48 octets ou du genre, donc y'a pas grand chose à optimiser, c'est le code "support" et là c'est beaucoup plus compliqué à optimiser/modifier/... Après c'est pas non plus la course à l'octet, mais il faut que ça reste raisonnable (à mon avis), donc exit() les 1724 octets .text (code complet) du début.

Plus pratique oui, mais mieux? Les avis divergent sur internet et c'était pas toi sur le sujet Arduino qui avait justement un soucis avec le HAL ou du genre et à dû mettre les mains dans le bazar pour régler un bug??

Edit: Outre les paramètres de compilation ça doit dépendre de la version de newlib aussi. Perso j'arrive pas à faire mieux que 632 octets .text avec la newlib-4.5.0.20241231. Enfin bref.

Après t'es quand même large en terme de place non ? Avant de vouloir se taper les optimisations de barbares attend peut-être d'être dans un cas de figure ou le besoin se fait sentir ?

Oui bien sûr, c'est pour ça que je ne vais pas y passer plus de temps à (pseudo-)optimiser.
 
Prochaine étape: Le UART.

Je vois pas de quel code supports tu parles

En faite tu as 2 types de surcouches, la couche HAL qui serait comparable à du haut niveau et la couche LL qui correspond à du bas niveau. En gros le HAL fait tout pour toi un peu comme l'arduino (bon pas aussi simple mais quasi) là où la couche LL fait en beaucoup plus simple. Le problème, c'est que le HAL bouffe une place de malade absolu pour pas grand chose dans mon cas de figure par contre le LL a une compatibilité discutable suivant les versions.

Par exemple :

Sinon tu te retrouves avec un truc illisible incompatible avec d'autres versions de type :

SAUF QUE, pour l'UART, la clock sera (à priori) dépendante du modèle que tu as. Donc en HAL (je suppose), tu as juste un truc genre ActiveUART() alors qu'en LL tu auras LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_USART2). Ce qui marche tant que c'est APB1 & GRP1

Pour l'UART, je peux te donner la soluce mais tu preferes peut etre chercher

Le code qui tourne avant main() notamment.
 
Le code low-level avec seulement #include <stm32f1xx.h> je le trouve pas illisible, au contraire. Ca ressemble à du vrai C quoi.  
 
Pour l'UART, il tourne depuis un moment; par contre printf() c'est pas gagné... Soit je me retrouve avec un code de taille "monstre", soit ça ne fonctionne pas.   Faut que je regarde ça, plus tard...
 
Je suppose que y'a personne qui connaît les entrailles de newlib ici?

Pour printf, je peux te donner la soluce, mais tu preferes chercher je suppose

Ensuite si tu donnes pas ton code, ca va pas etre facil

Salut à tous
j'ai besoin de votre aide
j'ai un court circuit entre les points TP14 et TP15
voici les schémas




j'ai désoudé les quatres puces BM1366 et le LTC3856 sans succés
j'ai donc désoudé tous les conesateurs en sortie de LTC3856 sur la ligne 1,2V et toujours en court circuit
il me reste a tester du coté de D2 et D3 (mais je doute)
 
Auriez vous une piste à me donner ?

Tu peux regarder si Q4 et Q6 ne sont pas en court-circuit.
 
Dessouder le LTC3856 ne fait pas grand chose vu qu'il n'est pas connecté directement au rail 1.2V, autant dessouder les composants entre U3 et le rail 1.2V .
 
Le court-circuit peut aussi venir du PCB ou d'une mauvaise soudure .
 
As-tu aussi regardé les capas de découplage du rail 1.2V vers U19, U20, U25 et U26 et sur le reste de la feuille "power" ?
 
Une technique de debug efficace est de brancher une alim de labo sur ton rail 1.2V, avec une limite de courant assez faible pour regarder ce qui chauffe sans tout casser .
 
La variante bourrine est d'augmenter la limite de courant, comme ça, le court-citcuit finit par ne plus en être un .

 
J'ai dessoudé tous les condensateurs autour de U19, U20, U25 et U26 sans succès  et sur la feuille "power" tous ceux entre TP14 et TP15
malheureusement j'avais toujours ce court circuit
 
Je vais regarder sur un autre PCB vierge que j'ai si je n'ai pas de "base" un court circuit
 
Je n'ai pas d'alim de labo ni de camera thermique mais depuis le tps qu'une telle alim me tente, je vais peut etre franchir le pas
edit : une alimentation de ce type va bien ? https://www.amazon.fr/Alimentation- [...] r=8-6&th=1
 
Merci pour tes pistes de recherche

La soluce s'appelle _write, c'est pas ça, c'est de trouver les bons paramètres en recompilant newlib pour ne pas bouffer genre 20-30ko de FLASH déjà... Mais entre-temps ça fonctionne.  
Avec l'initialisation PLL+GPIO+UART et un printf("ABC %u\n", 123); je me retrouve avec

Ca me va.

Je sais.

Déjà merci de virer tout le tracking du lien: https://www.amazon.fr/Alimentation- [...] B0B8S6CH3H
Ce genre d'alim "no name" ça peut fonctionner, mais il y a toujours un risque que le transfo (isolation primaire-secondaire) / le régulation (sauts de charge, ...) / le refroidissement soit mal fichu. Au pire si le transistor en sortie se met en CC tu vas griller ton montage branché sur l'alim. Après les alims plus "correctes" c'est tout de suite un autre prix, donc à voir. Dans tout le cas débrancher physiquement après utilisation et ne pas laisser tourner sans surveillance.
On a tout un sujet matos électronique aussi (dont je m'occupe, plus ou moins ).

 
7Ko pour du printf par UART ?
 
Pourquoi tu utilises newlib ?

Bah printf() ça bouffe un peu selon les fonctionnalités... Et newlib bah c'est la libc standard pour ARM... Tu utilises quoi toi?

désolé pour l'url, j'ai fait un bête copier/coller

jsais pas, c'est platformio qui a config le bousin
[edit]A si, à priori newlib aussi[/edit]

printf avec du %lu %u %x, ca fait moins de 7Ko chez moi (enfin beaucoup moins, j'ai pas testé un truc restreint)

Cette conversation n'aurait pas plutot sa place sur le thread arduino ?

Tiens si t as une solution pour savoir s'il reste des trucs dans le buffer je suis preneur. J'ai rien trouvé, c'est pas spécifique à STM mais cela me bouzille l'UART quand je change une clock.

Vu que ce n'est pas du Arduino je dirais non. Après j'avais pas l'intention de monopoliser ce sujet.

Pas vu Edith.

Je pourrais voir la config de PlatformIO, mais franchement pour l'instant je préfère avancer dans la compréhension du STM32 plutôt que de me taper des configs de lib'...

Je ne suis pas certain d'avoir bien compris. Tu parles de printf() avec du DMA ou sans ou autre chose?

Bah platformio c'est un peu un truc à la fonctionnelle direct.

Ce que j'ai constaté (mais pas trop cherché depuis) c'est que quand je modifie l'USART en court de route, cela coupe la chaine de chr qu'il était en train d'envoyer. D'où l'idée qu'il y a un buffer en parallèle du programme, géré par un interrupt par exemple.

[reditt]STM IDE utilise newlib_nano a priori[/]

Pour PlatformIO oui c'est un truc tout prêt, mais tu devrais savoir entre-temps que je fais les choses à la mano moi. Je parlais de regarder comment ce IO configure/compile Newlib car ce IO c'est FLOSS non? Enfin bref.
 
Pour ton USART, je ne sais pas si c'est une interruption ou simplement une boucle dans _write() ou du DMA, mais forcément si tu bricoles ton USART en cours de route ça crée le bazar. Faudrait vérifier si l'appel à printf() est bloquant ou pas déjà. J'ai pas de solution (pour l'instant), dans le doute il faudrait bricoler Newlib mais je suppose que tu veux pas toucher aux entrailles du truc IO? Après tu as souvent besoin de changer la config de l'USART en cours de programme? (Vu que Newlib est FLOSS on pourrait vérifier dedans, mais entre le code printf() affreusement compliqué et toutes les options de config j'ai pas trop envie la...)