C/C++, programmation, stm32, test, tutoriel

[Test] STM32F4 la nouvelle génération d’ARM cortex M4 est dans la place !

Posté par Skywodd ⋅ 8 mars 2012 ⋅ 23 Commentaires

Classé dans arm, cortex M4, stm32f4

Bonjour tout le monde !

Aujourd’hui je vais vous présenter une carte qui a beaucoup fait parler d’elle et qui tend à devenir le « futur » des microcontrôleurs ARM Cortex.
Le sujet du jour : la STM23F4 Discovery et son ARM Cortex M4 de derniére génération.

Tout d’abord niveau packaging on reste trés classique.
Comme pour toutes les cartes de la série Discovery de ST, la STM32F4 Discovery est livré dans un blister plastique sans autre accessoires.
Restez sobre n’est pas plus mal finalement vu qu’un blister plastique protège trés bien des chocs et permet de mettre en valeur le produit qu’il contient.

Alors qu’est ce que ça peut bien être ces STM32F4 dont toute la webOsphére parle ?
La série Cortex-M4 est une série de microcontrôleurs ARM hyper amélioré, reprenant les caractéristiques des ARM Cortex M3 classique, avec en plus, tout un systéme de DSP (digital Signal Processing, aka « Manipulation de signaux numérique ») et des caractéristiques / performances de D I N G U E !

Pour ne citer que les caractéristiques générale les plus intéréssante :
– unité de calcul à virgule flottante de haute précision
– cœur 32 bits pouvant atteindre 1,25 DMIPS/MHz
– unité de protection mémoire (MPU)
– mode de débogage/traçage économique
– consommation (dynamique) du processeur inférieure à 40 µW/MHz
– compatible avec la derniére version de la couche « Cortex Microcontroller Software Interface Standard » (CMSIS)
Et bien plus !

(cf: http://www.arm.com/products/processors/cortex-m/cortex-m4-processor.php)

Quoi vous bavez déja devant cette carte ? 🙂
Gardez de la salive pour tout à l’heure vous en aurez besoin 😉

La STM32F4 Discovery en elle même reprend les éléments « classique » des cartes de la série Discovery.
Ainsi on ne sera pas étonné de voir qu’il y a un ST-Link V2 embarqué, en plus du STM32F4 et d’un certain nombre de petits périphériques bien sympa qui gravitent autour.

Avant de parler des périphériques externe, intéressons nous d’abord au plus intéréssant, le STM32F4 !

On a pu déja voir les caractéristique général pour la norme Cortex-M4 mais que possède réellement le STM32F4 ?
Et bien il possède un nombre hallucinant de chose, tellement qu’il serait impossible de tout lister ici !

En voici les caractéristiques principal :
Core: ARM 32-bit Cortex™-M4 CPU with FPU, Adaptive real-time accelerator (ART Accelerator™) allowing 0-wait state execution from Flash memory, frequency up to 168 MHz, memory protection unit, 210 DMIPS/1.25 DMIPS/MHz (Dhrystone 2.1), and DSP instructions -> une vitesse Max de 168MHz !! Avec un rendement de 1.25DMIPS/MHz soit un total de 210DMIPS à pleine puissance !! (MIPS = Million d'Instructions Par Seconde)


Up to 1 Mbyte of Flash memory -> avec 1Mo de flash pour le programme vous ne risquez pas d'être à cours de place !

Up to 192+4 Kbytes of SRAM including 64-Kbyte of CCM (core coupled memory) data RAM -> 192Ko de SRAM dont 64Ko de mémoire couplé et 4Ko de mémoire réservé au mode Sleep

Flexible static memory controller supporting Compact Flash, SRAM, PSRAM, NOR and NAND memories -> bus pour mémoire CM, NAND, ... autant dire que n'importe quelle puce mémoire est utilisable

LCD parallel interface, 8080/6800 modes -> interface hardware pour un afficheur lcd paralléle
1.8 V to 3.6 V application supply and I/Os -> Entrées/Sorties aux niveaux TTL 1v8 jusqu'à 3v3

4-to-26 MHz crystal oscillator -> utilisable avec des quartz de 4 à 16MHz

Internal 16 MHz factory-trimmed RC (1% accuracy) -> Oscillateur interne de 16MHz

32 kHz oscillator for RTC with calibration -> oscillateur RTC interne (pour gérer une horloge Real Time Clock)

Internal 32 kHz RC with calibration -> Réseau oscillant RC pour l'oscillateur RTC en hardware = pas de matériel externe requis

Sleep, Stop and Standby modes -> supporte la mise en mode "sleep" (mode économie d'énergie)

VBATsupply for RTC, 20×32 bit backup registers + optional 4 KB backup SRAM -> broche d'entrée pour batterie 3v pour l'horloge RTC interne

3×12-bit, 2.4 MSPS A/D converters: up to 24 channels and 7.2 MSPS in triple interleaved mode -> 24 convertisseurs Analogique/Numérique 12bits haute vitesse

2×12-bit D/A converters -> 2 convertisseurs Numérique/Analogique 12bits

General-purpose DMA: 16-stream DMA controller with FIFOs and burst support -> Interface DMA (Direct Access Memory) avec mémoire tampon de type FIFO (First In First Out)

Up to 17 timers: up to twelve 16-bit and two 32-bit timers up to 168 MHz, each with up to 4 IC/OC/PWM or pulse counter and quadrature (incremental) encoder input -> 17 timers dont 12 16bits et 2 32bits, chaque timer pouvant contrôler 4 sortie PWM, ou fonctionner en compteur d'impulsions ou encore en compteur de vitesse (avec un encodeur en quadrature (encodeurs pour roue))
Serial wire debug (SWD) & JTAG interfaces -> debug par SWD (via le ST-Link par exemple), ou par JTAG

Up to 140 I/O ports with interrupt capability -> Jusqu'à 140 entrées/sorties selon le modèle, dans notre cas il y en aura un peu moins de 100 (je n'ai pas le nombre exacte)

Up to 136 fast I/Os up to 84 MHz -> sur ces 140 I/O, 136 sont capable de supporter le mode haute vitesse, et donc de commuter à une fréquence max de 84MHz

Up to 138 5 V-tolerant I/Os -> et 138 sont tolérantes au 5v

Up to 3 × I2C interfaces (SMBus/PMBus) -> 3 bus I2C (aka TWI / SmBus suivant le nom qu'utilise les fabricants) Up to 4 USARTs/2 UARTs (10.5 Mbit/s, ISO 7816 interface, LIN, IrDA, modem control) -> 4 port UART pouvant faire office de port série classique, de port pour module infrarouge, de port modem, ... Up to 3 SPIs (37.5 Mbits/s), 2 with muxed full-duplex I2S to achieve audio class accuracy via internal audio PLL or external clock -> 3 bus SPI dont 2 avec le support des flux I2S pour interfacer un convertisseur numérique/analogique de qualité audio 2 × CAN interfaces (2.0B Active) -> 2 bus CAN SDIO interface -> 1 bus pour gérer une carte SD/MMC USB 2.0 full-speed device/host/OTG controller with on-chip PHY -> support de l'usb haute vitesse 2.0 en maitre / esclave / OTG 10/100 Ethernet MAC with dedicated DMA: supports IEEE 1588v2 hardware, MII/RMII -> contrôleur ethernet intégré, il "suffit" d'ajouter un PHY ethernet pour pouvoir utiliser un réseau ethernet (comme par exemple un DP83848) 8- to 14-bit parallel camera interface up to 54 Mbytes/s -> possède un interface pour caméra parallèle True random number generator -> générateur de VRAI nombres aléatoire hardware

Maintenant vous pouvez bavez 🙂

Comme je le disait plus haut la carte est fourni avec un debuggeur ST-Link V2 intégré qui permet de debugger/programmer la carte en usb sans avoir besoin de matériel externe.
Il peut aussi être utilisé pour debugger/programmer un microcontrôleur STM32 sur une autre carte au moyen du connecteur SWD sur le coté.

La partie « target » est à la fois simple et compléte, elle comporte bien évidement le STM32F4 mais aussi un nombre important de périphériques gravitant autour et permettant de tirer profit des fonctionnalités de l’architecture M4.

Ainsi on se retrouve avec un accéléromètre 3 axes, un capteur de température, une sortie audio haute qualité, un micro intégré, 4 led de couleurs, 1 boutons libre pour l’utilisateur et un bouton de reset, et un port micro usb (qui est fixé solidement, d’habitude je râle quand je vois un micro-usb sur une carte de dev, mais là c’est du solide !) avec deux led d’indication d’état.
De quoi faire mumuse pendant un bon moment !

On remarquera que le quartz présent sur la carte est non démontable, contrairement à celui de la carte STM32VL Discovery.
Il va donc falloir jouer avec les registres de configuration du STM32F4 pour arriver aux 168MHz tant désiré (mais c’est pas un gros probléme).

Au niveau du pcb, rien à redire, le skillscreen vert « simple » est d’une qualité irréprochable, et la gravure des pistes est impeccable, du trés bon bouleau !

C’est presque énervant de voir qu’il est possible de faire des pistes aussi fine, alors qu’un amateur ne peut pas descendre en dessous du demi millimètre avec une graveuse de pcb maison 🙂

Bon passons sur un point qui risque de faire déchanter certain, à savoir les connecteurs DIL …
Contrairement à la STM32 (VL & L) Discovery, ici avec le STM32F4 il y a plus de 100 broches à router, autant dire qu’il est inenvisageable d’utiliser des connecteurs SIL classique.
C’est pourquoi la carte comporte des connecteurs DIL (dual in line), qui vous vous en doutez, ne peuvent pas être cablé sur une breadboard de par leur forme.

Cela risque donc d’être un probléme, il faudra savoir jouer habillement avec des câbles M/F pour câbler la carte à la main, ou alors graver un adaptateur DIL vers SIL, mais ce serait une solution trés lourde et encore moins pratique.

L’exemple de base quand on branche la carte pour la première fois est trés sympa.
Les led de couleurs clignotent en cercle et la carte se faire reconnaitre comme une souris hid via l’usb, de la il est possible de contrôler la souris sur l’écran en inclinant la carte grâce à l’accéléromètre.

Petit probléme auquel je fait fasse pour le moment, c’est au niveau de la toolchain gcc.
Pour pouvoir utiliser la série Cortex-M4 il faut une version trés récente de gcc, la toolchain yagarto est je pense la solution la plus viable.
Je suis actuellement en train de regarder comment l’utiliser pour compiler des programmes simple, en attendant que CoIDE supporte la série STM32F4xx (c’est prévu, il faut juste attendre).

Edit: Voici une petite vidéo de démonstration de l’exemple « wav player » qui montre la puissance du codec audio I2S.

Ma conclusion :
Puissante, pas chère, avec un « potentielle hack » énorme, cette carte (et plus généralement la série M4) a tout pour plaire.
Reste juste la partie software encore un peu complexe mais ça promet de beaux bidouillages !
La guerre entre les fabricants de microcontrôleurs fait rage et franchement je suis au anges !
La STM32F4, la STM32L Discovery, la Launchpad, etc etc … c’est que du bon pour le marché du hack/bidouillage hardware, prions pour que cela dure encore longtemps 🙂

Discussion

23 réflexions sur “[Test] STM32F4 la nouvelle génération d’ARM cortex M4 est dans la place !”

J’adore se genre de carte, comme tu le dit c’est que du bon pour le marché du hack / bidouillage le plus fou c’est le prix…

Y auras t’il une suite sur la STM32F4 ? 😉

Sa fait baver ..

Publié par Biloute | 10 mars 2012, 20 h 07 min
- La suite (je l’espère) : ARM Cortex A8 et autre µc 32bits ARM9 ou ARM11, au prix d’un STM32F4 d’aujourd’hui 🙂
  
  Publié par skywodd | 10 mars 2012, 20 h 31 min
Yep, géniale cette board. En plus les GPIO sont à 100mhz (si bien configurés) ! De quoi faire du SPI software (pour du multi canaux) en bit bang sans gêner les autres tâches outre mesure.

Par contre un bémol : le moindre court-jus et les ldo crament, ils ont pas mis de protections.

Tiens, tu saurais si on peut utiliser le stlink embeddé pour programmer d’autres chips ? Et si il y a quelque part un descriptif de la conf mini sur une board pour mettre un chip comme ca ? (genre pullups, etc) J’ai pas trouvé ces infos dans la datasheet (ou alors j’ai mal cherché).

Histoire de faire ses propres board à base de stm32f4 🙂

Sinon, pour faire des pistes aussi fines, j’y arrive sans pb en pcb home made… Avec du toner transfer, une lamineuse (plastifieuse bon marché un peu tunée mais à peine) et une graveuse en bac vertical. J’arrive à faire du 6 mil avec ça, sur une taille jusqu’à du A4 sans aucun pb (il m’a fallu moultes essais avant de trouver la combinaision papier, chauffe, etc qui me convenait mais maintenant que je l’ai, ça roule !).

Publié par jon1012 | 4 avril 2012, 9 h 31 min
- >> Par contre un bémol : le moindre court-jus et les ldo crament, ils ont pas mis de protections.
  C’est bon à savoir je ferais encore plus attention.
  
  >> Tiens, tu saurais si on peut utiliser le stlink embeddé pour programmer d’autres chips ?
  Oui tu peut, il suffit d’enlever les deux jumpers sur la droite du ST-Link et de câbler ton STM32xx sur le connecteur SWD.
  
  >> Et si il y a quelque part un descriptif de la conf mini sur une board pour mettre un chip comme ca ?
  >> (genre pullups, etc) J’ai pas trouvé ces infos dans la datasheet (ou alors j’ai mal cherché).
  J’ai pas vraiment cherché, il faudrait regarder dans les exemples d’applications ça doit être précisé quelque pars.
  
  >> Sinon, pour faire des pistes aussi fines, j’y arrive sans pb en pcb home made… Avec du toner transfer,
  >> une lamineuse (plastifieuse bon marché un peu tunée mais à peine) et une graveuse en bac vertical.
  >> J’arrive à faire du 6 mil avec ça, sur une taille jusqu’à du A4 sans aucun pb (il m’a fallu moultes essais
  >> avant de trouver la combinaision papier, chauffe, etc qui me convenait mais maintenant que je l’ai, ça roule !).
  J’ai pas fait assez d’essai pour arriver à un telle résultat …
  Perso par sécurité je rend les pistes les plus grosse possible (dans la limite des .40″).
  Utiliser une lumineuse modifié c’est pas bête faudra que je regarde ça !
  
  Publié par skywodd | 4 avril 2012, 13 h 14 min
Bonjour,

Je ne sais pas si vous avez remarqué, mais ça ne se passe jamais comme on imaginerait que ça devrait se passer… J’ai donc ma carte Cortex-M4, j’ai installé GCC via la distribution de yagarto pour avoir une distri plus récente, puis CooCox qui a l’air assez sympa (du moins quand j’aurais un truc qui fonctionne)
Bon, j’installe les trucs, je fais select Components, je sélectionne celui de la carte discovery STM32F407VG, et là je pensais avoir un tas de header pour les machins super portable de la mort qui tue CMSIS, genre iotruc.h timerquifaittout.he, etc. Ben non… j’ai en tout et pour tout :
– C ibrary
– Semihosting
– M4 CMSIS Core
– CMSIS Boot
Je ne sais pas trop si ça suffit ou pas, à priori je me méfie un peu des trucs sensés me simplifier la vie au départ et qui me la complique à l’arrivée, aussi un header avec les déclarations des registre, et basta, m’irait bien.
Au fait pour le chemin vers gcc, dois-je prendre yagardo/bin, ou yagardo/arm-none-eabi/bin ? J’ai pris le premier, mon main avec while(1){} à l’air de compiler, mais je ne suis pas trop sûr…

Voulant essayer quelque chose de plus pertinent qu’une boucle vide, je télécharge les exemples de st.
Certains semble vouloir s’ouvrir avec CooCox, mais me balancent une boite de dialogue avec :
Problem Occurred
» has encountered a problem
An internal error occured during: «  »,

Le bouton détail m’indique :
An internal error occurred during: «  ».
java.lang.NullPointerException

sympa… une autre boite de dialogue me propose de regarder la « conversion log » :
(…)
[12/04/21 15:39:33:290] -[Specification]: MDK’s compiler is different from CoIDE’s compiler(GCC).
So, there may be some problems in the converted project which need to be solved by yourself!

C’est vrai que startup_Cortex_M0.c semble un peu incongru pour un Cortex M4… Bon je me suis peut-être gouré en chargeant les exemples… non non, c’est bien STM32F4-Discrovery_FW_V1.10. La vie de développeur est un long fleuve tranquille. Pas grave, je m’en fout de leur exemple à la gomme, j’en prends un autre. Allez, DAC_SignalsGeneration, ça ne devrait pas être trop compliqué…

Toujours
An internal error occurred during: «  ».
java.lang.NullPointerException

Bon, je m’en fout, je compile :
build failed
Output filename conflict: system_stm32f4xx.o would be produced from C:\CooCox\workspace\DAC_SignalsGeneration\cmsis_boot\system_stm32f4cc.c and system_stm32f4xx.c…

bon, on ne s’énerve pas… je recommence en créant le projet ex nihilo, sans faire d’import à la gomme :
idem, même erreur.

J’essaie de changer l’emplacement de gcc par celui qui me semblait aussi possible:
idem, même erreur.

Je subodore que les cochonerie qui sont rajoutées pour me simplifier la vie sont en train de me la pourrir, je recommence en mettant juste C Library dans « Select Components »

Là; ça change :
GCC HOME: C:\yagarto\arm-none-eabi\bin
compile:
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\DAC\Debug\bin
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\DAC\Debug\obj
[cc] 4 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb -Wall -ffunction-sections -O0 -g -c -DSTM32F407VG -IC:\CooCox\CoIDE\workspace\DAC C:\CooCox\CoIDE\workspace\DAC\main.c C:\CooCox\CoIDE\workspace\DAC\stm32f4xx_it.c C:\CooCox\CoIDE\workspace\DAC\system_stm32f4xx.c C:\CooCox\CoIDE\workspace\DAC\syscalls\syscalls.c

BUILD FAILED
Could not launch C:\yagarto\arm-none-eabi\bin\arm-none-eabi-gcc: java.io.IOException: Cannot run program « C:\yagarto\arm-none-eabi\bin\arm-none-eabi-gcc » (in directory « C:\CooCox\CoIDE\workspace\DAC\Debug\obj »): CreateProcess error=2, Le fichier spécifié est introuvable
Total time: 0 seconds

Si je comprends bien un coup il voit deux fichiers, un coup il manque un fichier…

Je rajoute au hasard « Semihosting » dans select component:
pareil

je rajoute CMSIS BOOT
je me retrouve avec le conflit… grrr ces p!!! de f!!! de m!!!! qui sont là pour faire des virtual truc pour foutre un port à un ou à 0 commencent à me gaver….

En cherchant, je vois qu’il y a deux system_stm32f4xx.c, un dans le répertoire du projet, un dans un sous répertoire du projet \cmsis_boot\
Dans le premier, le Xtal est à 8MHz, dans le second (qui est ajouté, je suppose par l’IDE sympa, le Xtal est à 25MHz, ce qui ne doit pas convenir, puisque ma carte a un Xtal à 8MHz…
Bon, je vire le deuxième fichier du projet, ouste.

Bon, ça coince aussi

Je ne m’énerve pas, j’ouvre le build.xml pour essayer de virer tout ce qui est ajouté et que je n’ai pas demandé…

Pareil, il y a des trucs qui m…

Bon, j’en ai (un peu) marre… (surtout que c’est quasiment chaque fois la même galère quand on teste un nouveau processeur). La « out of the box » experience, comme ils disent…

Quelqu’un a-t-il faut un truc basique (clignoter la led, par exemple) avec le moins de machins inutiles possible ?

Merci
Jean-Louis VERN

P.-S. au fait les IO sont-elles si fragiles que ça ? J’ai toujours fait des cours jus avec des IO sur des tas de processeurs sans qu’il ne se passe jamais rien (du moins tant que l’on ne dépasse pas le Vio)

Publié par Jean-Louis VERN | 21 avril 2012, 17 h 40 min
- Désolé …
  Je comptai faire un explication en détails, mais ça aurait été beaucoup trop long, donc je passe en mode télégraphique 🙂
  
  >> Bon, j’installe les trucs, je fais select Components, je sélectionne celui de la carte discovery STM32F407VG, et là je pensais
  >> avoir un tas de header pour les machins super portable de la mort qui tue CMSIS, genre iotruc.h timerquifaittout.he, etc. Ben
  >> non… j’ai en tout et pour tout :
  Les STM32F4 sont supporté par CoIDE depuis même pas 1 mois, pour le moment le support des Cortex-M4 est en développement expérimental donc rien ne sera dispo avant les prochaines versions de CoIDE.
  Il y a un topic complet sur les M4 sur le forum de Coocox.
  
  >> Je ne sais pas trop si ça suffit ou pas, à priori je me méfie un peu des trucs sensés me simplifier la vie au départ et qui me
  >> la complique à l’arrivée, aussi un header avec les déclarations des registre, et basta, m’irait bien.
  Dans la librairie CMSIS il ya toute les définitions requise pour utiliser les périphériques du Cortex-M4.
  
  >> Au fait pour le chemin vers gcc, dois-je prendre yagardo/bin, ou yagardo/arm-none-eabi/bin ? J’ai pris le premier, mon main avec
  >> while(1){} à l’air de compiler, mais je ne suis pas trop sûr…
  Il faut installer la toolchain GCC à la main dans un dossier racine de C:\ ne contenant pas d’espace.
  L’installateur de yagarto utilise C:\yagarto de base, normalement ça va trés bien.
  
  >> Voulant essayer quelque chose de plus pertinent qu’une boucle vide, je télécharge les exemples de st.
  >> Certains semble vouloir s’ouvrir avec CooCox, mais me balancent une boite de dialogue avec :
  >> Problem Occurred
  Il y a deux grandes régles à respecter pour utiliser CoIDE :
  1 – ne JAMAIS importer quoi que ce soit, CoIDE n’as jamais correctement importer le moindre format de fichier de projet autre que celui de CoIDE lui même
  2 – Ne pas créer le projet dans le workspace par défaut C:\…\CoIDE\workspace c’est un dossier fantôme
  
  >> C’est vrai que startup_Cortex_M0.c semble un peu incongru pour un Cortex M4… Bon je me suis peut-être gouré en chargeant les
  >> exemples… non non, c’est bien STM32F4-Discrovery_FW_V1.10. La vie de développeur est un long fleuve tranquille. Pas grave, je
  La librairie CMSIS de ST est générique à TOUS les Cortex-Mx de ST, il est donc normal qu’elle contiennent les fichiers pour Cortex-M0 et M3.
  Fichiers qui ne seront pas utilisé lors de la compilation par contre.
  
  >> BUILD FAILED
  >> Could not launch C:\yagarto\arm-none-eabi\bin\arm-none-eabi-gcc: java.io.IOException: Cannot run program
  >> « C:\yagarto\arm-none-eabi\bin\arm-none-eabi-gcc » (in directory « C:\CooCox\CoIDE\workspace\DAC\Debug\obj »): CreateProcess
  >> error=2, Le fichier spécifié est introuvable
  Régle N°2 citée plus haut, compiler dans C:\CooCox\CoIDE\workspace\ ne marchera jamais.
  
  >> Je rajoute au hasard « Semihosting » dans select component:
  Le semihosting n’est pas suporter par la newlib C/C++ pour les STM32F4 (enfin si j’en crois le topic dédié sur CoIDE)
  
  >> je rajoute CMSIS BOOT
  >> je me retrouve avec le conflit… grrr ces p!!! de f!!! de m!!!! qui sont là pour faire des virtual truc pour foutre un port à un
  >> ou à 0 commencent à me gaver….
  Régle N°1 ne jamais rien importer, CoIDE inclut tous ce qu’il faut pour compiler, donc au minimum la librairie CMSIS.
  Les exemples de ST sont conçu pour IAR ou pour un compilateur en ligne de commande qui n’ajoute rien eux, donc lib CMSIS local + lib CMSIS inclut par CoIDE = conflit
  
  >> Bon, j’en ai (un peu) marre… (surtout que c’est quasiment chaque fois la même galère quand on teste un nouveau processeur). La >> « out of the box » experience, comme ils disent…
  Il ne faut jamais tenter de lancer un truc « out the box » il faut étudier le hardware, puis le foncitonnement du software et seulement aprés tenter de compiler quelque chose.
  « Run out the box » c’est valable uniquement avec un des IDE sponsorisé par ST, pour le reste c’est DIY, datasheet, google, makefile, console et gcc en ligne de commande, puis quand tout va bien, création d’un projet CoIDE vide, copier / collage des fichiers et tentative de compilation qui normalement marchera vu que la phase de test à la main en console a été faite.
  Et si les régles 1 et 2 sont respecté CoIDE devrait retourner un jolie « BUILD SUCCESS ».
  Et aprés c’est configuration de ST-link et là bonjour les prises de tête vu que ST ne supporte pas les logiciels de debug tiers.
  
  >> Quelqu’un a-t-il faut un truc basique (clignoter la led, par exemple) avec le moins de machins inutiles possible ?
  Blink compatible STM32VL, STM32L et STM32F4 Discovery même pas besoin de librairie CMSIS
  https://github.com/texane/stlink/tree/master/example/blink
  
  >> P.-S. au fait les IO sont-elles si fragiles que ça ? J’ai toujours fait des cours jus avec des IO sur des tas de processeurs
  >> sans qu’il ne se passe jamais rien (du moins tant que l’on ne dépasse pas le Vio)
  D’aprés ce que j’ai pu lire ici même et de ce que l’on m’as rapporter sur IRC les I/O des STM32F4 sont trés sensible au court circuit et au décharge d’électricité statique.
  
  Publié par skywodd | 21 avril 2012, 18 h 38 min
Merci pour votre réponse rapide.

J’ai ré essayé de créer un projet dans un répertoire qui va bien, en utilisant les sources correspondant au test du DA.
Il a fallu que j’inclue un certain nombre de headers (normal) mais curieusement après avoir inclus les .h nécessaires, il a encore fallu faire dans le main des includes d’autres .h en l’occurrence :
dans main.c
#include « stm32f4xx_dac.h »
#include « stm32f4xx_gpio.h »
#include « stm32f4xx_rcc.h »
#include « stm32f4xx_tim.h »
#include « stm32f4xx_dma.h »
et dans stm32f4xx_it.c :
#include « stm32f4xx_exti.h »
(je suppose que dans les config normale, il doit y avoir un define et un #ifdef qui doit inclure ces .h, et le define initial manquant dans ma config, les .h ne sont pas chargés…)

Bref ça compile et sa linke, donc, c’est déjà bien, en revanche il me sort une taille de code 0, ce qui ne me semble pas très catholique…

GCC HOME: C:\yagarto\bin
compile:
[mkdir] Created dir: C:\test_CoIde\DA\Debug\bin
[mkdir] Created dir: C:\test_CoIde\DA\Debug\obj
[cc] 3 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb -Wall -ffunction-sections -O0 -g -c -DSTM32F407VG -IC:\test_CoIde\DA C:\test_CoIde\DA\main.c C:\test_CoIde\DA\stm32f4xx_it.c C:\test_CoIde\DA\system_stm32f4xx.c
[cc] Starting link
[cc] arm-none-eabi-gcc -O0 -nostartfiles -Wl,-Map=DA.map -mcpu=cortex-m4 -mthumb -LC:\test_CoIde\DA -Wl,–gc-sections -Wl,-TC:\test_CoIde\DA\link.ld -g -o DA.elf ..\obj\main.o ..\obj\stm32f4xx_it.o ..\obj\system_stm32f4xx.o
Program Size:
text data bss dec hex filename
0 0 0 0 0 DA.elf

BUILD SUCCESSFUL
Total time: 0 seconds

Je lance le debug qui n’est pas très content, mais après avoir sélectionné max clock = 2MHz, ça semble aller mieux, A la commande flash erase, il me répond :
C:\CooCox\CoIDE> »C:/CooCox/CoIDE/bin\coflash.exe » erase STM32F407VG –adapter-name=ST-Link –port=SWD –adapter-clk=2000000 –driver= »C:/CooCox/CoIDE/flash/STM32F4xx_1024.elf »
Erase: Done

(et le programme de démo dégage 🙂

Download to flash me répond :
C:\CooCox\CoIDE> »C:/CooCox/CoIDE/bin\coflash.exe » program STM32F407VG « C:/test_CoIde/DA\Debug\bin\DA.bin » –adapter-name=ST-Link –port=SWD –adapter-clk=2000000 –erase=affected –driver= »C:/CooCox/CoIDE/flash/STM32F4xx_1024.elf »

Erase: Done
Program: Done
Verify: Done

Je lance debug, il me répond sur la page sur laquelle il devrait y avoir le code c à debugger :
No source available for « »
avec en dessous un bouton « View Disassembly… »
et, dans la fenêtre Disassembly : Unable to retrieve disassembly data from backend.
(mais si le code =0, c’est peut-être normal)

Je regarde DA.hex :
:0400000508000000EF
:00000001FF
oups… il semblerait qu’effectivement il ne produise pas grand chose..

Bon, j’ai été peut-être trop ambitieux, j’essaie avec le source de led qui clignote qui correspond au lien que vous avez posté…

J’ai ajouté (pour fixer les defines qui étaient définis dans le makefile) :
#define CONFIG_STM32F4_DISCOVERY 1
#define CONFIG_STM32L_DISCOVERY 0
#define CONFIG_STM32VL_DISCOVERY 0
puis j’ai compilé :

GCC HOME: C:\yagarto\bin
compile:
[mkdir] Created dir: C:\test_CoIde\blk\Debug\bin
[mkdir] Created dir: C:\test_CoIde\blk\Debug\obj
[cc] 1 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb -Wall -ffunction-sections -O0 -g -c -DSTM32F407VG -IC:\test_CoIde\blk C:\test_CoIde\blk\main.c
[cc] C:\test_CoIde\blk\main.c:55:2: warning: implicit declaration of function ‘main’ [-Wimplicit-function-declaration]
[cc] C:\test_CoIde\blk\main.c: At top level:
[cc] C:\test_CoIde\blk\main.c: In function ‘_tmain’:
[cc] C:\test_CoIde\blk\main.c:85:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
[cc] C:\test_CoIde\blk\main.c:85:6: warning: conflicting types for ‘main’ [enabled by default]
[cc] C:\test_CoIde\blk\main.c:55:2: note: previous implicit declaration of ‘main’ was here
[cc] Starting link
[cc] arm-none-eabi-gcc -O0 -nostartfiles -Wl,-Map=blk.map -mcpu=cortex-m4 -mthumb -LC:\test_CoIde\blk -Wl,–gc-sections -Wl,-TC:\test_CoIde\blk\link.ld -g -o blk.elf ..\obj\main.o
Program Size:
text data bss dec hex filename
0 0 0 0 0 blk.elf

BUILD SUCCESSFUL
Total time: 0 seconds

Tout semble normal (à part les bricoles classiques du main qui n’est pas comme il voudrait) avec toujours une taille de code 0 (???)
Le debugger ne voit pas de code lisible…

Le fichier blk.hex :
:0400000508000000EF
:00000001FF
Cool, le même hex pour tous les programmes, ça va me simplifier la vie…

Les flags de compilation par défaut ne sont pas les mêmes que ceux présents dans le makefile :
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb -Wall -ffunction-sections -O0 -g
et dans le makefile :
-g -O2 -mlittle-endian -mthumb -ffreestanding -nostdlib -nostdinc
plus
-mcpu=cortex-m4 -DCONFIG_STM32F4_DISCOVERY=1
le flag little-endian m’interpelle un peu…

Tout ça ne me dit pas pourquoi ça génère 0 code…

Bon voilà voilà… il y a un mieux mais ça ne fonctionne toujours pas… (mais ça efface :!)

Concernant les remarque que vous faites sur la nécessité de lire es docs du hard du soft, etc. Vous avez évidement raison, sauf que cela devient de plus en plus difficile, si ce n’est impossible, surtout quand il s’agit d’évaluer un nouveau processeur, avec un nouvel IDE…
Quand j’ai commencé à travailler (sur un Exorciser Motorola avec des disquettes 8″) on pouvait raisonnablement lire toute la doc. A l’heure actuelle, lire toute la doc des processeurs, des compilateurs, des linkers, des IDE, sans oublier le plus important, les release et autres errata hardware devient quasiment impossible. Sans oublier que pour comprendre ce qu’il se passe vraiment, il faut aussi éplucher tous les headers, comprendre quels sont les defines actifs à un moment donné et connaitre leurs valeurs, etc. Il faut aussi comprendre les méandres du portage de gcc sur windows, bien sûr. De plus la doc est éparpillée chez une multitude d’acteurs. La doc des processeurs, par exemple, se trouve en parti chez le fondeur, et en parti chez le designer (MIPS ou ARM, par exemple) sans que l’on sache clairement chez qui on peut la trouver, ni même quelle doc on peut trouver…

Donc maintenant, je fais comme tout le monde… n’importe quoi… ou comme le dit Nike « Just do it ». Je branche et je prie 2 secondes pour que ça compile vaguement après quoi je modifie pour arriver à ce que je veux. Dans un premier temps, j’aimerais ne pas avoir à me soucier de savoir comment ça marche, et juste constater que ça marche. Dans un deuxième temps, une fois que la led clignotera, je regarderai en détail le pourquoi du comment.
Je n’ai pas trop envie de regarder exactement si le flag truc de la pll doit être comme-ci ou comme ça, du moins pas tout de suite..

Bref, là j’aurais bien aimé, vite fait bien fait, voir si le cortex-m4 pouvait remplacer le Blackfin avec lequel je travaille actuellement (je tourne à 50Mhz de temps de cycle). Je subodore que oui, mais c’est juste du pifomètre. Et j’aurais aimé le faire (peut-être n’est-ce pas possible, comme vous le dites) sans lire 50000 pages, parce que je n’ai pas trop le temps de lire les 50000 pages en question.

Cela dit, encore un fois vous avez raison, il faudrait lire toute la doc avant de commencer… et je ne devrais pas être trop critique envers CooCox (je ne le suis d’ailleurs pas) qui met gratuitement à notre disposition des outils pour développer, mais je commence un peu à fatiguer. Ces derniers mois, j’ai travaillé sur des PIC24, PIC32 PSOC3 et 5 TMS320 et Blackfin, sans oublier un petit Xilinx en verilog. Je commence à caler un peu au niveau de la doc…

Aussi… votre aide est bienvenue pour faire tourner ce Cortex-M4 qui semble au demeurant très sympathique

Cordialement
Jean-Louis VERN

Publié par Jean-Louis VERN | 23 avril 2012, 0 h 14 min
- Lire l’intégralité de la doc n’est pas obligatoire, il faut juste regarder les quelques sujets épinglé sur le forum Coocox qui résume les problème les plus courant.
  
  Le fait que les programmes compile puis finissent avec une taille de 0 octets n’est absolument pas normal !
  Pour être sur ce n’est pas un problème de compilateur il faudrait exécuter un « make » avec le makefile d’origine.
  L’idéal étant d’avoir MinGW d’installer pour profiter des commandes linux les plus courantes.
  
  A mon avis il s’agit d’un problème de configuration, ou peut être un problème du au stade encore expérimental du support des Cortex-M4 par CoIDE.
  Pourtant c’est très étrange les commandes de compilation on l’air juste …
  
  Publié par skywodd | 23 avril 2012, 9 h 18 min
Merci pour votre réponse…

J’ai l’impression que je ne suis pas le seul a avoir quelques difficultés. Je vais attendre que ce soit un peu plus mature.
Il y a vraiment des tas de trucs vraiment sympa sur ce micro, en plus de la FPU et des instructions DSP, comme un vrai générateur aléatoire analogique, un AD rapide, ou la possibilité de faire du DMA sur l’I2C…

J’espère que l’on pourra faire fonctionner tout ça sereinement bientôt.

Publié par Jean-Louis VERN | 24 avril 2012, 15 h 20 min
- Pour moi tout marche au poil sous linux, vraiment… Mais avec GCC et des Makefiles 🙂
  Du coup j’utilise Eclipse comme ide pour le C/C++ et ça marche assez bien.
  
  Publié par Jonathan de HackSpark | 25 avril 2012, 10 h 59 min
  - Ho! un collégue utilisateur de Eclipse et des makefile 🙂
    Eclipse c’est vraiment LE logiciel pour faire du développement C/C++ (et java).
    
    Publié par skywodd | 25 avril 2012, 18 h 45 min
J’ai essayé de faire make avec les fichiers tests que vous avez communiqué (sous Seven), j’obtiens ceci :
25-Apr-2012 11:29:00 819 makefile
25-Apr-2012 11:29:44 2,354 main.c
25-Apr-2012 11:31:24 34,868 blink_32L.elf
25-Apr-2012 11:31:24 34,872 blink_32VL.elf
25-Apr-2012 11:31:24 35,123 blink_F4.elf

Y a-t-il un machin dans le package gcc sous zindows, ou dans CooIde ou ailleurs qui permette de transformer ça en bon hex intel des familles ?

Je cogite depuis un certain temps à passer sous Linux, juste pour pouvoir compiler avec gcc correctement. Ca ne m’enchante guère, mais bon.

Par ailleurs, je me demande si, effectivement, on n’a pas plus vite fait de faire un makefile et taper make, plutôt que de se coltiner une usine à gaz comme Eclipse. Le seul hic c’est le debug. Je ne connais rien aux outils libres… Y a-t-il un debugger indépendant qui pourrait être utilisé avec un bon éditeur de texte ?

Actuellement (et depuis 20ans) j’utilise Epsilon de Lugaru Software (http://www.lugaru.com/lugaru.html) qui est un clone de xemacs, mais avec un langage de paramétrage proche du C (je vous le recommande vivement, il tourne sous toutes les plateformes). Je me verrais bien debuger sous mon editeur favori, ou à défaut sous (X)emacs (s’il fallait vraiment passer sous Linux avec des outils linux pur et dur -pas sous vi il ne faut tout de même pas déconner-) et me passer de ces IDE qui rajoutent des couches pas toujours faciles à maîtriser…

Publié par Jean-Louis VERN | 25 avril 2012, 12 h 00 min
- >> Y a-t-il un machin dans le package gcc sous zindows, ou dans CooIde ou ailleurs qui permette de transformer ça en bon hex intel des familles ?
  
  arm-none-eabi-objcopy -I elf -O ihex xxxx.elf xxxxx.hex
  
  >> Je cogite depuis un certain temps à passer sous Linux, juste pour pouvoir compiler avec gcc correctement. Ca ne m’enchante guère, mais bon.
  
  A pars les utilitaires purement linux tu aura la même chose qu’avec MinGW 😉
  
  >> Par ailleurs, je me demande si, effectivement, on n’a pas plus vite fait de faire un makefile et taper make, plutôt que de se coltiner une usine à gaz comme Eclipse. Le seul hic c’est le debug.
  
  Eclipse fait usine à gaz au premier coup d’œil mais avec un peu d’expérience c’est un (pour ne pas dire le) meilleur environnement de développement.
  Entièrement pensé pour faciliter et accélérer la tache du développeur.
  
  >> Je ne connais rien aux outils libres… Y a-t-il un debugger indépendant qui pourrait être utilisé avec un bon éditeur de texte ?
  
  Tu as gdb (gnu debugger) sous la nom de arm-none-aebi-gdb qui permet de aire du debug mais c’est pas trés pratique en console !
  
  >>Actuellement (et depuis 20ans) j’utilise Epsilon de Lugaru Software (http://www.lugaru.com/lugaru.html) qui est un clone de xemacs, …
  
  Sauve qui peut !! On as trouvé un utilisateur de (x)emacs !! 🙂
  
  Développer en console c’est simple, mais pour un gros projet je me verrais mal sans eclipse + compilation incrémentielle + serveur subversion + écran 24″ 😉
  (1 écran pour le debug, 1 écran pour le code, et 1 écran pour l’exécution, les stats, et les rapports de test unitaire)
  
  Publié par skywodd | 25 avril 2012, 19 h 05 min
Merci pour de prendre du temps pour répondre à un dinosaure qui ignore l’existence même des serveurs subversion (mais à qui il ne viendrait pas à l’idée de faire quelque chose avec un 16F84 de l’âge de pierre, quand bien même il en aurait avec ses silex 🙂

Juste pour le plaisir de justifier l’injustifiable, j’aime bien epsilon pour plusieurs raisons :
1) Il est (très) rapide : je clique et hop ça s’ouvre, même sur une machine avec un 286 🙂
2) ça gère les expressions régulières aussi bien pour la recherche que pour le remplacement, ce qui permet de bricoler des fichiers (de stimuli, par exemple) pour changer ceci ou cela.
3) ça fait un grep convenable
4) la moitié de l’espace de travail n’est pas bouffé par les cadres les menus, etc.
5) on peut tagger les fichiers sur lesquels on travaille de manière à sauter directement au définitions de ceci ou cela
6) il me ré-indente comme je veux ce que je veux
7) bref ça fait un tas de truc que je pourrais certes faire autrement, mais qui là sont rassemblés dans un seul et même outil, rapide de surcroît. J’ajoute que epsilon n’a pas été écrit par un programmeur qui portait des moufles, et donc on n’a pas besoin de 10Go pour l’installer, qu’il est stable et multiplateforme.

Humm… si j’ai bien compris (mais peut-être n’ai-je pas compris) la dernière version de compilo prévue pour MinGW est la 4.4 (http://www.mingw.org/wiki/GCCStatus) et le CORTEX-M4 est supporté à partir de la version gcc 4.6(.3)(http://gcc.gnu.org/gcc-4.6/changes.html) ; J’en déduis donc que pour pouvoir travailler avec des versions pas trop vieilles de gcc, il vaut mieux être sous Linux…

La commande arm-none-eabi-objcopy -I elf -O ihex blink_F4.elf blink_F4.hex me renvoie
Invalid bfd target 😦

Pour moi, il y a deux sorte de système de développement :
– ceux que l’on peut installer en moins d’une heure
– ceux que l’on ne peut pas installer en moins d’une heure.
Les premiers ont ma préférence… Si j’avais du pognon, j’achèterais Keil, direct…

Bon, je vais regarder éclipse… soupir…

Publié par Jean-Louis VERN | 26 avril 2012, 12 h 59 min
- >> (mais à qui il ne viendrait pas à l’idée de faire quelque chose avec un 16F84 de l’âge de pierre,
  >> quand bien même il en aurait avec ses silex
  Nan mais ho ! C’est pas si mal les PIC 16F84 =P
  J’ai fait des petites cartes pour programmer dessus en assembleur.
  C’est pas trés performant, ya pas de périphériques intégré, mais j’aime bien 🙂
  
  >> 4) la moitié de l’espace de travail n’est pas bouffé par les cadres les menus, etc.
  … C’est vrai qu’avec eclipse … le dual screen (trial screen c’est mieux) est fortement recommandé …
  
  >> 7) bref ça fait un tas de truc que je pourrais certes faire autrement, mais qui là sont rassemblés dans un seul
  >> et même outil, rapide de surcroît. J’ajoute que epsilon n’a pas été écrit par un programmeur qui portait des
  >> moufles, et donc on n’a pas besoin de 10Go pour l’installer, qu’il est stable et multiplateforme.
  Fait 200Mo eclipse (c’est pas lourd vu ce qu’il y a dedans), compilateur inclut, après faut installer la jvm java, … et là … hummm java quoi 🙂
  
  >> Humm… si j’ai bien compris (mais peut-être n’ai-je pas compris) la dernière version de compilo prévue pour
  >> MinGW est la 4.4 (http://www.mingw.org/wiki/GCCStatus) et le CORTEX-M4 est supporté à partir de la version
  >> gcc 4.6(.3)(http://gcc.gnu.org/gcc-4.6/changes.html) ; J’en déduis donc que pour pouvoir travailler avec des
  >>versions pas trop vieilles de gcc, il vaut mieux être sous Linux…
  STOP ! Le compilateur gcc de MinGw est fait pour compiler sur PC.
  
  Il faut avoir le compilateur arm-none-eabi-gcc pour compiler sur des ARM.
  La toolchain la plus à jour du moment (4.6.2) c’est Yagarto (http://www.yagarto.de/).
  MinGW c’est juste pour avoir les utilitaires unix de base (grep, cat, rm,mv, …).
  
  >> La commande arm-none-eabi-objcopy -I elf -O ihex blink_F4.elf blink_F4.hex me renvoie
  >> Invalid bfd target
  Hummm essaye -I elf32-littlearm ou -I elf32-little je sait plus quel format accepte objcopy pour ARM.
  
  >> Les premiers ont ma préférence… Si j’avais du pognon, j’achèterais Keil, direct…
  Moi j’ai pas beaucoup de pognon (contrairement à ce que pourrais laisser penser mon blog), et si j’en avais plus je ferais des dons aux projets opensource que j’utilise.
  
  Les IDE proprio, dont on ne peut rien faire à 100% même avec la licence ça me donne des boutons …
  (Keil + licence = limitation en taille du debug, sauf à payer une somme astronomique … non merci, vive l’opensource !)
  
  Publié par skywodd | 26 avril 2012, 13 h 33 min
« On remarquera que le quartz présent sur la carte est non démontable, contrairement à celui de la carte STM32VL Discovery. Il va donc falloir jouer avec les registres de configuration du STM32F4 pour arriver aux 168MHz tant désiré (mais c’est pas un gros problème). »
Est-il possible d’avoir quelques explications ? 🙂 Pourquoi faut-il toucher des registres pour monter à 168Mhz ? (pourquoi ce n’est pas la fréquence par défaut ?) et comment est-ce possible de changer la fréquence par un simple jeu de registre ? Merci pour l’éclairage !

Publié par Absurdev | 22 octobre 2012, 18 h 05 min
- >> (pourquoi ce n’est pas la fréquence par défaut ?)
  
  C’est bien 168MHz par défaut, mais tout dépend de comment la lib CMSIS configure les registres (en théorie elle peut bien utiliser la fréquence de son choix).
  Il y a une variable qui contient la fréquence réel du CPU : SystemCoreClock.
  
  >> et comment est-ce possible de changer la fréquence par un simple jeu de registre ?
  
  En modifiant le « prescaler » = coeff diviseur/multiplicateur de l’horloge.
  
  Publié par skywodd | 22 octobre 2012, 18 h 56 min
  - A condition de set up le bon niveau de power, sinon bridé à moins de 120 (ou 140) mhz… 🙂
    
    Publié par Jonathan from HackSpark | 23 octobre 2012, 14 h 05 min
  - « A condition de set up le bon niveau de power, sinon bridé à moins de 120 (ou 140) mhz… »
    Tu veux dire qu’il faut que ce soit alimenté en 5V et non seulement 3.3V si on veut atteindre la fréquence max ?
    
    Publié par Absurdev | 23 octobre 2012, 22 h 35 min
J’ai reçu la carte (en 24h, merci RadioSpares) et je suis chaud pour tester tout ça ! La carte est vraiment monstrueuse, il n’y a qu’un défaut comme tu l’a fait remarquer : la connectique des pins !! Pourquoi avoir mis des pins mâle et pas des headers femelles ?! Parce que là c’est relativement inutilisable en l’état ne rien mettre du tout aurait été mieux… et je vois pas comment faire simplement, à part avec des jumper wires femelle (http://dx.com/p/single-port-female-to-female-jumper-wire-set-50-pack-20cm-length-55454?item=3) mais ce n’est pas la panacée non plus 😦 Aurais-tu trouvé une astuce depuis ?

Publié par Absurdev | 23 octobre 2012, 22 h 33 min
bonjour s’il vous plais est ce que vous pouvez me donner le code d’un capteur gaz MK9 avec stm32L descovery et merci d’avance 🙂

Publié par ben Ouanes | 4 mars 2014, 18 h 57 min
jai besoins d aide pour faire mon tp je doit programme les elctrovannes et les test sur stm32f4discovry

Publié par malika | 6 novembre 2018, 18 h 19 min