STM32 Déception documentation?

[activmaker]

Bonjour,

Je suis récemment passé de microchip à STMH7 pour mes MCU. Manuel ici
STM Fournit plein de fct déja toutes prêtes pour faciliter l'utilisation de leur MCU, c'est pas trop compliqué.
Par contre, si on se plonge dans la documentation, c'est plus la même histoire. Un exemple pour le NVIC page 731:
la première chose dont parle la doc est le "Systick calibration value register", on se dit " ah ça doit être important" .
On nous explique alors comment calculer une valeur de Reload value avec un exemple :

For example, to achieve a timebase of 1 ms when the SysTick clock source is the 100 MHz
HCLK:
reload value = (FHCLK × SYST_CALIB) – 1
reload value = ((FHCLK ⁄ 8) × SYST_CALIB) – 1
reload value = (100 × SYST_CALIB) – 1 = 0x1869F

On apprend aussi que cette valeur de reload value doit être écrite dans SYST_RVR. Problème, la recherche de SYS_RVR dans les 3000 pages ne renvoi qu'une occurrence, celle que l'on vient de lire ! .
Puis la doc passe à autre chose.

Autre exemple, activation des interruptions sur front montant. Whouah. Meme par Cube c'est pas clair , car en fait il ne faut PAS choisir le mode input mais EXTI.
J'avais bien vu dans la doc que la notion de RE (Rising Egde) était lié au EXTI. Ca c'est clair , mais quand j'essaye de comprendre le lien entre GPIO et EXTI, c'est pas limpide. Je trouve des explications intéressante sur le net, mais pas dans la doc.
Pour commencer à comprendre , il a fallu que je fasse un exemple avec Cube , puis voir le code généré.
Ce que je comprends, c'est qu'il semble impossible d'utiliser la même pin sur plus de 1 ports en interruption .
Par exemple je ne vois pas comment configurer les interruptions pour avoir des interruptions sur A1,B1 ou C7,D7..Ca semble impossible. J'ai pas besoin de cette config, c'est pour un exemple, mais si quelqu'un peut infirmer ou confirmer ce que je pense, ça m'aiderait à savoir si j'ai compris ou non .
Dans le même genre, je ne comprend pas pourquoi on a 3 registres pour les RE, mais le code généré dans HAL_GPIO_Init n'utilise que RTSR1 ce que semble indiquer que seulement 16 interruptions en RE sont possible..
Si je compare avec Microchip, aucune question se pose. C'est limpide, logique, simple mais parfois buggué .
Je veux bien admettre avoir le cerveau lent, mais je trouve la doc tordue, pas claire..Faut lire parfois le datasheet , parfois le manuel de référence, parfois le manuel du programmeur etc..Environ 4000 pages !.
J'ai la sensation que même en lisant 40 fois la doc , il va toujours me manquer un "bout" pour faire le lien entre tous les éléments, et c'est très énervant.
Il y a peut être une autre source de documentation disponible et complète que je ne connais pas. Si un spécialiste peut aider je prends !

Cependant, les doc "hardware" sont plutôt bien faite, elle m'ont permis de réaliser une carte perso fonctionnelle, sans m'arracher les cheveux.

Si je passe sur du STM32H7 c'est pour utiliser la puissance du MCU pour mon code, pas pour appeler des fonctions qui font des boucles inutiles voir HAL_GPIO_Init . Bref je ne veux pas passer par HAL, je veux pouvoir exploiter le MCU directement.
Et pour ça j'ai besoin de comprendre.


Merci de m'avoir lu.
-----

[Murayama]

Bonjour!

De mon point de vue, c'est peut-être une question d'habitude, mais je trouve que le
système ST fonctionne bien avec un minimum d'effort. J'ai eu aussi cette impression
parce que je "venais de" MSP430 sur lequel on attaque directement les registres (1).
Donc oui, il y a un niveau d'abstraction qui peut paraître déroutant.

(1) Ceci dit, les versions récentes du code source impliquent des fonctions genre
HAL, ce qui brouille la simplicité que j'ai connue.

mais quand j'essaye de comprendre le lien entre GPIO et EXTI, c'est pas limpide

C'est pourtant la même chose. EXTI, c'est une interruption sur un port. Du point
de vue hardware, c'est défini autrement. Par exemple, sur les MSP430, il y a un
nombre limité de ports "interruptibles" (je ne sais as si c'est bien hallal comme
français...)
Sur STM32, il y a aussi un nombre limité d'interruptions, mais utilisables sur plus
de ports, avec la limitation dont vous parlez. Quelque soit le processeur, il y a
des limitations, il faut vivre avec.
En ce qui me concerne, je n'ai jamais eu besoin de 16 interruptions GPIO et ce n'est
pas ce que je trouve le plus frustrant.

D'autre part, les fonctions HAL effectivement sont un peu obscures, mais est-ce
vraiment un problème?

pas pour appeler des fonctions qui font des boucles inutiles voir HAL_GPIO_Init

HAL_GPIO_Init ne s'appelle qu'une seule fois au début du programme, ce qui fait
qu'il n'y a aucune pénalité en performance, par exemple.

J'ai aussi utilisé une DMA en audio. Le setup se fait par des fonctions HAL,
mais quand les interruptions half buffer et full buffer sont appelées, même chose.
On utilise du C ordinaire. Donc on perd peut-être un peu pendant la mise en place
des divers éléments, mais par contre le "runtime", on l'écrit soi-même, donc ça
ne change rien.

Une chose que je trouve un peu frustrante, c'est par exemple quant on utilise SPI.
J'utilise une horloge à 216 MHz (le maximum des F7), et pour définir la vitesse du
port, ce sont uniquement des sous-multiples de 108 en puissances de 2. 54, 27, 13.5,
6.75, etc...
Impossible par exemple de configurer de façon simple 10 MHz à moins évidemment de
changer l'horloge de 216 à 160 MHz. Ou alors peut-être en définissant un horloge annexe,
mais je ne sais pas si c'est possible. À propos, si quelqu'un a une idée...

Autre désavantage: on ne peut pas générer de C++, il n'existe pas, par exemple
de classe UART, classe GPIO, etc... Dommage.

Pascal

[activmaker]

Merci pour cette réponse.
Quelques précisions. Quand je compare la gestion des interruptions avec Microchip, je pense notamment à leur version E7,S7..Qui sont basés sur le même cpu (Cortex-M7).
Les NVIC sur STM et Micro sont les mêmes, je m'attendais à avoir des possibilités équivalentes. En réalité la gestion des interruptions et des GPIO est très différentes.

Exemple venant de chez micro

For each I/O Line (Whether Assigned to a Peripheral or Used as General Purpose I/O)
– Input Change Interrupt
– Programmable Glitch Filter
– Programmable Debouncing Filter
– Additional Interrupt Modes on a Programmable Event: Rising Edge, Falling Edge, Low-Level or High-Level
../..


Ils utilisent 5 ports GPIO de 32bits , chaque port à une entrée directe sur le NVIC. Et chaque GPIO possède des registres permettant de connaitre LA pin ayant provoqué l'interruption.
Ca me semble logique et souple.

En ce qui me concerne, je n'ai jamais eu besoin de 16 interruptions GPIO et ce n'est
pas ce que je trouve le plus frustrant.

Je suis d'accord. Cependant quelqu'un qui bosse en robotique à posé la question ..16 Interruptions peuvent être atteintes très rapidement.
Le datasheet STM ne mentionne pas cette limitation , pire il dit "Up to 128 I/O ports with interrupt" . Pas bien .

A mon niveau le vrai problème se pose sur la limitation que la pin x d'un port empêche l'interruption de cette même pin sur les autres ports. Ca complique le routage.
Pour l'instant, j'ai réalisé un PCB "générique" justement pour étudier le STM et commencer l'étude de plusieurs cartes qui devront "discuter" ensemble. Avec Microchip , je peux choisir n'importe qu'elle pin => routage simplifié.

HAL_GPIO_Init ne s'appelle qu'une seule fois au début du programme, ce qui fait qu'il n'y a aucune pénalité en performance, par exemple.

C'est pas faux, mais de mon coté ça pose quelques soucis , je dois être capable d'intercepter un pulse très court (5µs min) à la mise sous tension. Ca aussi ça va déterminer le PCB définitif , savoir si je dois détecter le pulse par du hard ou si le MCU est capable de le faire. Sur ce point je pense que le MCU est capable de le faire, à condition de ne PAS passer par HAL.

Pour la question du SPI, je dois aussi étudier les possibilités du MCU, je dois avoir pouvoir utiliser du master et slave en / +USART et eventuellement ETH et USB. Si j'ai une solution je me ferai un plaisir de poster une réponse.

@Murayama , quelle carte utilisez vous ? une carte venant de STM, ou une carte perso ?

[Murayama]

Re!

Je suis d'accord. Cependant quelqu'un qui bosse en robotique à posé la question ..16
Interruptions peuvent être atteintes très rapidement.

Ça doit dépendre de la façon d'implémenter le système, je n'ai vraiment jamais vu le
cas. Mais ceci dit, je suis plutôt dans les mesures de distances et d'angles, des sous
systèmes utilisés par des robots, et je ne conçois pas les robots eux-mêmes.
Enfin si un peu mais projet personnel. Un tour numérique. Parfois j'ai envie de faire
un tour.

pire il dit "Up to 128 I/O ports with interrupt"

Ce n'est pas faux dans la mesure où n'importe quel bit de ces ports peut être utilisé
en tant qu'interruption, mais c'est vrai qu'il vaut mieux être au parfum de l'astuce.

C'est pas faux, mais de mon coté ça pose quelques soucis , je dois être capable
d'intercepter un pulse très court (5µs min) à la mise sous tension.

C'est court, mais à 200 MHz, ça fait tout de même 1000 coups d'horloge.

Pour la question du SPI, je dois aussi étudier les possibilités du MCU, je dois avoir
pouvoir utiliser du master et slave en / +USART et eventuellement ETH et USB. Si j'ai
une solution je me ferai un plaisir de poster une réponse.

Ce serait bien, mais je ne me fais pas trop d'illusions. Sur Texas, on peut programmer
le diviseur de fréquence au bit près (et pas uniquement par puissances de 2). Bon, en
partant par exemple de 25MHz pour obtenir 10 MHz, on finit tout de même coincé parce qu'il
est possible d'avoir 12.5 en divisant par 2 ou 8.33 MHz en divisant par 3, mais rien de
vraiment proche de 10. Par contre, le même setup en partant de 216 MMHz pourrait permettre
quelque chose de très proche en divisant par 21.

@Murayama , quelle carte utilisez vous ? une carte venant de STM, ou une carte perso ?

Une carte maison, avec un F769.

Un autre inconvénient, l'ordre des pins. Chez TI, du moins pour le MSP430, on a toujours
un ordre assez logique des pins de sortie. Le bit4 du port 3 est quasiment toujours
placé entre les bits 3 et 5 du même port. Le CS du SPI est souvent sur le portx bit 0,
suivi par clk, miso et mosi, mais je ne sais plus dans quel ordre. Je ne comprends
pas pourquoi électriquement le STM32 a besoin d'être si bordélique. C'est pire que sur
mon bureau.

Bon, enfin il ne faut tout de même pas être trop négatif, il y a beaucoup de choses
qui me plaisent, et notamment la facilité de configurer un système complet avec CubeMX,
en 10 min alors que le même travail à la main prendrait des heures voire des jours.
La possibilité de rerouter une liaison, SPI par exemple du côté qui nous arrange
est bien pratique.

Pascal

[A voir en vidéo sur Futura]

[activmaker]

Re,

L'ordre des pins, oui c'est galère, mais en ce qui me concerne c'était déjà le cas avec MicroChip.
C'est vrai que CubeMX simplifie énormément les chose, notamment pour les gestions des horloges..Sur le H7 , c'est une usine à gaz, mais pour l'instant j'arrive à configurer ce que veux (SPI par ex).
Je vais peut être dire un bêtise concernant la sélection de fréquence du SPI sur le F7, mais en utilisant un USART en mode synchrone , on peut faire du SPI. Sur le F7 les USART semblent avoir une clk séparé du reste. Il y a peut être un truc à creuser de ce coté.

[umfred]

pour les docs, il faut consulter aussi les autres mentionnées au début du pdf (on retrouve par exemple le registre SYST_RVR dans la doc générique du Cortex M7 https://developer.arm.com/documentat...ysTick?lang=en

[Murayama]

Bonjour!

Je vais peut être dire un bêtise concernant la sélection de fréquence du SPI sur le F7, mais en utilisant un
USART en mode synchrone , on peut faire du SPI. Sur le F7 les USART semblent avoir une clk séparé du
reste. Il y a peut être un truc à creuser de ce coté.

Je viens de regarder, ce qui m'a aussi permis de mettre à jour MX, version 6.6.1. J'ai mis les horloges comme
sur ma carte, avec un quartz de 24 MHz (multiple de 12 à cause de USB), choisi USART1, configuré en synchrone.
Le fait est que je peux configurer quelque chose de proche de 10 MHz. Par contre il faudrait que je change une partie
du code et aussi probablement le layout du circuit parce que ce ne sont pas les mêmes sorties que SPI. Il faudrait
que j'étudie tout ça un peu mieux.

En tout cas, merci pour l'astuce, je crois que je vais essayer sur une carte ST de communiquer avec quelque chose
d'extérieur, un LCD ou une flash SPI par exemple. Mais pas maintenant, j'ai un sanglier sur le feu.

Pascal

J'ai un canard sur le feu.