Une Tanche

Note sur les moteurs électriques synchrone

Fri, 10 Jul 2026 00:00:00 +0000

Attention

Cet article est amené à évoluer et être complété.

Intro

Dans le cadre pro, j’ai réalisé une veille conséquente quant au pilotage de moteurs synchrones, du coup j’écris cet article comme un mémo. Je ne suis pas un spécialiste du contrôle moteur, encore moins de la conception de moteurs électriques, donc si vous trouvez une erreur n’hésitez pas à m’en faire part.

Je me suis intéressé à trois technologies de moteur synchrone:

Les moteurs à reluctance variable (SynRM)
Les moteurs à aimants permanents (PMSM)
Les moteurs à reluctance variable assistés par aimants permanents (PMa_SynRM)

Attention, ne pas confondre les machines à reluctance variable (SynRM) avec les machines à double saillance (SRM).

Pour rédiger ce mémo, je me suis appuyé sur les travaux suivants:

la thèse High-Performance Nonlinear Control for Permanent Magnet Assisted Synchronous Reluctance Motor (HAL Id: tel-03699829) de Songklod Sriprang publiée en 2022 (Université de Lorraine)
la thèse Modélisation et commande avancées d’une génératrice synchrone à réluctance variable auto-excitée (HAL Id: tel-04142255) de Laurent Schuller publiée en 2023 (INSA Lyon)
la thèse Contribution à la commande vectorielle sans capteur mécanique des machines synchrones à aimants permanents (MSAP) (HAL Id: tel-00814276) de Amor Khlaief publié en 2013 (Aix-Marseille Université)
le papier de recherche Vector control strategies for synchronous reluctance motor: constant current control, MTPA, MTPW and MPFC (HAL Id: hal-04887233) de Yassine Zahraoui, Mohamed Moutchou, Souad Tayane publiée en 2025 (Hassan II University)

Dénomination des différents type de moteur

Type de moteur	Anglais	Français
Moteur synchrone à reluctance variable	SynRM, SynRel ou SynR	MSRV
Moteur synchrone à reluctance variable assisté par aimants permanents	PMa-SynRM ou IPM-SynRM	??
Moteur synchrone à aimants permanents	PMSM	MSAP
Moteur synchrone à aimants permanents intérieurs	IPMSM	??
Moteur synchrone à aimants permanents en surface	SPMSM	??

Architecture des moteurs synchrone

Ces moteurs, qu’ils soient à aimants permanents ou à reluctance variable possèdent un rotor non bobiné et un stator composé de N phases. Dans mon cas, je ne m’intéresse qu’aux machines à trois phases (triphasé). Ces technologies se distinguent de part la constitution de leur rotor:

Composition d’un moteur synchrone

Illustration de la composition des rotors (thèse de Songklod Sriprang)

Sur le schéma ci-dessus, on retrouve les aimants permanents en violet et les barrières de flux sont indiquées par les zones blanches à l’intérieur du rotor. Comme on peut le voir, les machines MSAP ont un rotor avec N aimants permanent et sans aucunes barrières de flux. À l’inverse les machines à reluctance variable ne possèdent pas d’aimants mais ont N barrières de flux réparties tout autour du rotor. Entre les deux on trouve différentes nuances de ces deux technologies.

Je n’ai pas trouvé de tableaux détaillant exactement les avantages/inconvénients de chacune de ces technologies. Voici les informations que j’ai pu regrouper:

Type de moteur	Avantages	Inconvénients
SynRM	absence d’aimant, robustesse, indépendance à la température	encombrement, facteur de puissance, ondulation couple
PMSM	Très bon couple, rendement, encombrement, rapport poids/puissance	coûts, aimants permanents, sensible à la température, désaimentation
PMa_SynRM	Haut rendement à haute et basse vitesse, moins oscillation de couple que SynRM pure	aimants permanents

Équations et Models

Les équations suivantes, sont exprimées dans le repère dq0 obtenu à partir de la transformée de Park conservant les amplitudes (basée sur la transformée de Clarke).

Ces différentes technologies de moteurs sont régies par les mêmes équations:

$\omega_e = npp \times \omega$ $V_d = R \times i_d + L_d \times \frac{d}{dt} i_d - \omega_e \times L_q \times i_q$ $V_q = R \times i_q + L_q \times \frac{d}{dt} i_q + \omega_e (L_d \times i_d + \Psi_m)$ $C_{em} = \frac{3}{2} npp (\Psi_m i_q + (L_d - L_q)i_d i_q)$ $C_m = C_{em} - B_m \omega - J_m \frac{d}{dt}\omega - C_r$

avec:

$\omega$ : la vitesse de rotation mécanique du rotor (rad/s)
$\omega_e$ : la vitesse de rotation électrique du rotor (rad/s)
npp: le nombre de paires de pôles du rotor
$\Psi_m$ : Le flux maximum de l’aimant (Wb) (Max Flux Linkage)
lié aux aimants permanents (égal à 0 pour les machines SynRM)
Bm: frottements visqueux liés au rotor
Jm: Moment d’inertie du rotor
Cr: Le couple résistant externe

Important

On trouve un lien entre $\Psi_m$ et Ke (backEMF constant) la constante de tension liée à la fem tel que:

$\Psi_m = \frac{K_e}{npp}$

Ke doit être référencé entre phase et neutre.

Source: mathworks au chapitre “Alternative Flux linkage parametrization”.

On peut réécrire ces équations pour les mettre sous la forme dx/dt = … afin de pouvoir facilement les exploiter dans un modèle de représentation d’états:

$\frac{di_d}{dt} = \frac{1}{L_d}(V_d - R i_d + \omega_e * L_q i_q)$ $\frac{di_q}{dt} = \frac{1}{L_q}(V_q - R i_q + \omega_e L_d i_d - \omega_e \Psi_m)$ $\frac{d\omega_e}{dt} = \frac{3}{2}\frac{1}{J_m}(npp^{2} (\Psi_m i_q + (L_d - L_q) i_d i_q) - B_m \omega_e - C_r npp)$

Particularité MSAP

Dans le cas d’une machine à aimants permanents montés en surface, la saillance est nulle, c’est-à-dire que Ld = Lq. Dans ce cas l’équation de couple devient:

$\frac{d\omega_e}{dt} = \frac{3}{2}\frac{1}{J_m}(npp^{2} (\Psi_m i_q) - B_m \omega_e - C_r npp)$

On remarque que le couple est directement lié à Iq et que le courant Id ne fera que générer des pertes.

Particularité SynRM

En ce qui concerne les machines à reluctance variable, elles ne possèdent pas d’aimants donc $\Psi_m = 0$ . Ce qui nous donne l’équation de couple suivante:

$\frac{d\omega_e}{dt} = \frac{3}{2}\frac{1}{J_m}(npp^{2} ((L_d - L_q) i_d i_q) - B_m \omega_e - C_r npp)$

Donc le couple est proportionnel à Id x Iq.

Note: Changement de repère

Pour passer du repère triphasé au repère dq0 (repère du rotor), on utilise la transformée de Park, mais on peut décomposer ça en deux étapes:

abc (triphasé) –> $\alpha \beta$ (stator) –> dq0 (rotor)

En fonction de la transformée utilisée pour passer de abc vers $\alpha \beta$ :

concordia: conservation des puissances
Parke: conservation des amplitudes

Dans le cadre de la mise au point d’algorithme de régulation, il est plus intéressant de conserver les amplitudes que les puissances. Ainsi on a: $V_{d_{max}} = \frac{V_{abc_{max}}}{2}$

Attention:

Ces transformées ne sont utilisables que si les courants sont équilibrés. Ce qu’on suppose être le cas pour les moteurs cablés en étoile (le courant du neutre fictif est null).

Note: Les signaux PWM

Pour générer ces signaux, deux possibilités:

la méthode sinus: on génère trois signaux sinusoïdaux déphasés de 120° chacun
la méthode du vecteur spatial (SVPWM): on génère un signal qui ressemble à un sinus mais avec deux lobs. Cette méthode permet de réduire d’environs 15% la tension de bus maximum requise.

Commande des moteurs synchrone

Dans ce chapitre j’essaie de répertorier les différents modes de pilotage des moteurs synchrones. Il existe deux grandes familles de “méthode de contrôle”, la méthode scalaire et vectorielle.

Les différentes méthodes de commande

Pour l’instant, je ne me suis intéressé qu’aux méthodes scalaire et FOC. Mais la méthode DTC semble aussi intéressante, en particulier par le fait qu’elle ne nécessite pas de connaitre la position du rotor (on travaille dans le repère du stator).

Je ne me suis intéressé qu’à la commande en vitesse de ces moteurs.

Moteur à Aimants Permanents

J’ai trouvé deux manières de piloter les MSAP:

En boucle ouverte via la méthode Vbyf constant
En boucle fermée en contrôlant Id et Iq

Scalaire: VbyF

Le principe de cette commande est de maintenir un ratio constant entre l’amplitude et la fréquence de la tension de chacune des phases. Ce post sur le forum NXP explique de manière détaillée les principes de ce mode de commande pour un moteur synchrone à aimants permanents.

Schéma de la commande scalaire

Remarque suite à mes essais en simulation

J’ai fait de nombreux essais de simulation sur un moteur MSAP avec ce mode de pilotage.

La stabilité du moteur n’est pas garantie et atteindre sa vitesse nominale sans connaitre la position du rotor peut être impossible. En effet, si la différence entre la position estimée du rotor et sa position réelle est trop grande, le moteur devient instable. Il est possible d’améliorer nettement la stabilité de ce dernier en utilisant la position réelle du rotor (nécessite un capteur) pour la transformée dq0 inverse à la place de la position souhaitée.
Ce mode de pilotage ne permet pas de contrôler les courants Id et Iq. De ce fait, si on ajoute un couple résistant sur le rotor, le courant Id s’envole et Iq plafonne à des valeurs assez faibles. Or le couple d’un MSAP est directement proportionnel à Iq. Donc on se retrouve avec un rendement désastreux.

Iq & Iq SynRM VbyF

Commande vectorielle FOC

La commande vectorielle FOC consiste à asservir Id et Iq afin de minimiser les pertes dans le moteur. Comme on l’a vu précédemment, dans le cas d’une machine à aimants montés en surface, seul Iq permet de générer un couple. On va donc chercher à minimiser Id et maximiser Iq.

Commande FOC

Commande vectorielle DTC

Sujet à creuser. Mais pour faire simple d’après Wikipedia:

- pas besoin de connaitre la position du rotor
- algorithme de contrôle très simple
- nécessite une fréquence d’exécution très élevée (~100kHz)
- La fréquence de découpage est variable.

Moteur à Reluctance Variable

Commande scalaire VbyF

J’ai trouvé assez peu d’informations sur ce mode de pilotage pour une MSRV. Le peu que j’ai trouvé indique que ce mode de pilotage entraine d’importantes oscillations du couple et donc de possible instabilités du moteur.

Commande vectorielle FOC

Comme pour le moteur MSAP on cherche, avec ce mode de contrôle, à asservir les courants Id & Iq. Mais contrairement à la MSAP pour les machines à reluctance variable, le couple est proportionnel à Id & Iq.

Note

On note $\delta$ l’angle correspondant à $tan(\delta)=\frac{i_q}{i_d}$

Il existe donc différentes méthodes de régulation de ces courants:

MTPA: Maximum Torque Per Ampere
Cette méthode consiste à fixer l’angle $\delta = \pm \pi/4$ . Elle fonctionne pour les vitesses de rotation inférieures ou égales à la vitesse nominale.
MTPW: Maximum Torque Per Weber (parfois aussi noté MTPV –> V pour volt)
En mode MTPW on fixe $\frac{i_q}{i_d}=\pm\frac{L_d}{L_q}$ soit $\delta = atan(\frac{L_d}{L_q})$ . Ce mode de pilotage permet de piloter le moteur à une vitesse supérieure à sa vitesse nominale.
MPFC: Maximum Power Factor Control
Je ne suis pas entré dans les détails de ce mode de pilotage qui consiste à calculer Id & Iq de façon à obtenir le facteur de puissance désiré.

Bilan

Ces trois techniques ont des performances similaires. MTPW et MTPC permettent de réduire légèrement l’oscillation de couple par rapport à MTPA.

Commande vectorielle DTC

Idem MSAP.

PMa-SynRM

Commande scalaire

Je n’ai encore rien trouvé à ce sujet.

Commande vectorielle FOC

Je n’ai trouvé qu’un exemple basé sur MTPA. Attention, MTPA pour un moteur PMA-SynRM ne correspond pas à la même méthode que pour les moteurs à reluctance variable!

Pour résumer, cette méthode vise à maximiser le couple et minimiser les pertes par effet Joule:

$Maximiser: C_em = \frac{3}{2}npp(\Psi_m i_q + (L_d-L_q)i_di_q)$ $Minimiser: Pertes = R(i_d^2 + i_q^2)$

On peut donc exprimer les pertes en fonction de Iq:

$Pertes(i_q) = R(\frac{2}{3}\frac{C_em}{npp((L_d-L_q)i_q+\Psi_m)}+i_q^2)$

Ensuite à partir de la dérivée de cette fonction par rapport à Iq et grâce à la méthode de Newton-Raphson, on peut déterminer la valeur optimale de Iq en fonction du couple souhaité.

Enfin on calcule Id à partir du Iq optimal via:

$i_d = \frac{2}{3}\frac{C_em}{npp((L_d-L_q)i_q+Ke)}$

Pour l’implémentation sur cible, soit on arrive à mettre le résultat sous forme polynomiale, soit on fait une table de référence.

Position du rotor

Comme on a pu le voir dans les précédents chapitres, la connaissance de la position exacte du rotor est cruciale dans les algorithmes FOC. Il faut donc répondre aux deux problématiques suivantes:

Comment calibrer le capteur de position
Comment faire pour se passer de capteur de position

Calibration de la position du rotor

TODO

Rotor sans capteur

TODO

Rust sur mcu: Écriture d'un driver

Tue, 12 May 2026 00:00:00 +0000

Intro

Suite à l’article précédent où j’ai mis en place l’environnement de développement et pris en main les crates de base, je continue m’a découverte de RUST avec à la conception d’un driver très simple.

Les objectifs sont:

utiliser les interruptions
Créer une interface permettant d’utiliser un périphérique matériel

Pour ce faire je vais implémenter une api de délai non bloquant utilisant le périphérique SYSTICK.

L’idée est de créer une api qui ressemble à:

 let mut mon_timer = delay::new();

 mon_timer.start(250);

 loop{
     if mon_timer.expired() == true {
         mon_timer.start(543);   
         led_toggle();
     }
 }

Configuration du Systick

Pour la suite j’utiliserai le crate hal stm32l0-hal.

En partant du fichier main.rs suivant:

use cortex_m;
use cortex_m_rt::entry;
use panic_abort as _;
use stm32l0xx_hal::{pac, prelude::*, rcc::Config};

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();

	// On configure le quartz interne en source d'horloge
    let mut rcc = dp.RCC.freeze(Config::hsi16());

	// init du GPIO de la LED
    let gpiob = dp.GPIOB.split(&mut rcc);
    let mut led = gpiob.pb3.into_push_pull_output();
    led.set_high().unwrap();

	loop{}

Je commence par configurer le périphérique systick pour que son compteur déborde tout les 1ms. Ce qui donne la fonction “main” suivante:

use cortex_m;
use cortex_m_rt::entry;
use panic_abort as _;
use stm32l0xx_hal::{pac, prelude::*, rcc::Config};

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();
    let mut cp = cortex_m::Peripherals::take().unwrap();

    // On configure le quartz interne en source d'horloge
    let mut rcc = dp.RCC.freeze(Config::hsi16());

    // configuration du systick via l'api HAL
    // On le configure pour qu'il ait une cadence de 1ms
    cp.SYST.set_clock_source(cortex_m::peripheral::syst::SystClkSource::Core);
    cp.SYST.set_reload(16_000);
    cp.SYST.enable_counter();
    cp.SYST.enable_interrupt();
    cp.SYST.clear_current();
    while !cp.SYST.has_wrapped() {}

    // init du GPIO de la LED
    let gpiob = dp.GPIOB.split(&mut rcc);
    let mut led = gpiob.pb3.into_push_pull_output();
    led.set_high().unwrap();

    loop{}

Cette configuration me permet d’utiliser l’interruption du systick comme repère temporel.

Création de l’interface

Maintenant que le systick est prêt, je peux implémenter le driver. Pour cela, j’ai besoin de deux choses:

une base de temps
une consigne de temps limite

Pour ce qui est de la base temps, j’utiliserai l’interruption du systick. Et pour le temps limite, je propose d’utiliser la structure suivante:

pub struct Delay{
	end_tick: u32,
}

Cette structure permet de stocker la consigne de limite temporelle. Pour faciliter son utilisation j’ajoute les fonctions suivantes:

impl Delay {
    pub fn new() -> Delay {
        return Delay { end_tick: 0 };
    }

    pub fn is_elapse(&self) -> bool {
		// reach error not implemented
        return false;
    }

    pub fn start(&mut self, tick_to_wait: usize) {
		// reach error not implemented
        self.end_tick = tick_to_wait;
    }
}

Maintenant, passons à l’implémentation de la gestion du temps via l’interruption de systick.

Interruption de SysTick

Si je devais écrire ce code en C, je me contenterai sans doute de déclarer une variable globale et de l’incrémenter dans l’interruption. En utilisant une variable de type u32 on s’assure d’un accès atomique (pour notre cible) donc pas de risque de concurrence d’accès.

#include <stdint.h>

static volatile uint32_t tick  = 0u;

void Systick_IRQHandler(void){
	tick++;
}

Ce que je traduis naïvement en rust part:

pub use cortex_m_rt::exception;

static mut COUNT:u32 = 0;

pub struct Delay{
	end_tick: u32,
}

impl Delay {
    pub fn new() -> Delay {
        return Delay { end_tick: 0 };
    }

    pub fn is_elapse(&self) -> bool {
        return unsafe{self.end_tick >= COUNT};
    }

    pub fn start(&mut self, tick_to_wait: usize) {
        self.end_tick = unsafe{COUNT + tick_to_wait};
    }
}

// Interruption de SysTick. Pour que la fonction soit identifier
// comme une interruption, on utilise la directive *exception*
// de cortex-m-rt
#[exception]
fn SysTick() {
    unsafe {
        COUNT += 1_u32;
    }
}

En rust, la manipulation de variable globales nécessite de passer par des sections unsafe. Attention, il est cependant strictement interdit de déréférencer la variable COUNT. Il s’agit d’un comportement non définit en rust (UB).

Explications et détails

De plus, je ne sais pas si cette implémentation garantie que le compilateur n’optimisera pas l’accès à la variable COUNT (l’équivalent du volatile en C) mais une fois compiler et flasher sur le microcontrôleur, tout semble fonctionner. Sans doute un coup de chance…

Il existe cependant d’autres options permettant de ne pas passer par des sections unsafe. La première est d’expliciter l’atomicité de l’accès en utilisant: core::sync::atomic::{AtomicU32, Ordering}. Une autre est d’utiliser la structure mutex du crate cortex_m.

Mutex

Voici une implémentation de l’accès à une variable globale via le crate cortex_m::interrupt::Mutex. Vous trouverez un exemple officiel ici.

pub use core::cell::RefCell;
pub use cortex_m::interrupt::Mutex;
pub use cortex_m_rt::exception;

static COUNT: Mutex<RefCell<u32>> = Mutex::new(RefCell::new(0));
pub struct Delay {
    end_tick: u32,
}

impl Delay {
    pub fn new() -> Delay {
        return Delay { end_tick: 0 };
    }

    pub fn is_elapse(&self) -> bool {
        let mut count: u32 = 0;
        cortex_m::interrupt::free(|cs| {
            count = *COUNT.borrow(cs).borrow();
        });
        return self.end_tick <= count;
    }

    pub fn start(&mut self, tick: u32) {
        cortex_m::interrupt::free(|cs| {
            self.end_tick = *COUNT.borrow(cs).borrow() + tick;
        });
    }
}

#[exception]
fn SysTick() {
    cortex_m::interrupt::free(|cs| {
        let mut count = COUNT.borrow(cs).borrow_mut();
        *count += 1;
    });
}

Cette solution offerte par le crate cortex_m est fonctionnel. Cependant, je trouve quelle alourdie pas mal le code. Pour quelqu’un qui vient du C, c’est même assez déroutant.

Atomic

Une autre solution consiste à passer par le type Atomic proposé par le crate core::sync::atomic. Il nous permet d’indiquer au compilateur que la variable qu’il manipule est accédée atomiquement. Ce qui nous donne le code suivant:

pub use core::sync::atomic::{AtomicUsize, Ordering};
pub use cortex_m_rt::exception;

static COUNT: AtomicUsize = AtomicUsize::new(0);
pub struct Delay {
    end_tick: usize,
}

impl Delay {
    pub fn new() -> Delay {
        return Delay { end_tick: 0 };
    }

    pub fn is_elapse(&self) -> bool {
        return self.end_tick <= COUNT.load(Ordering::Relaxed);
    }

    pub fn start(&mut self, tick: usize) {
        self.end_tick = COUNT.load(Ordering::Relaxed) + tick;
    }
}

fn SysTick() {
    COUNT.store(COUNT.load(Ordering::Relaxed) + 1, Ordering::Relaxed);
}

Je trouve cette solution bien plus facile à lire que celle utilisant le mutex.

Bilan

La première implémentation est certainement la plus intuitive pour quelqu’un ayant l’habitude du C, mais elle reste à éviter à cause de l’utilisation de sections unsafe. La troisième solution (atomic) est celle que je trouve la plus explicite et facile à lire. Cependant, ces deux solutions ne permettent de travailler qu’avec une variable à accès atomic. Si l’on souhaite éditer une variable plus complexe comme une structure, il faudra alors se tourner vers la solution mutex.

Enfin, un autre avantage des méthodes unsafe et atomic, est quelles ne sont pas dépendants de la cible. Contrairement à la méthode à base de mutex qui impose de compiler pour une cible cortex_m. Pour l’instant on s’en moque un peu mais lorsque l’on voudra utiliser la directive #cfg[test] afin de valider le fonctionnement des fonctions par des tests unitaires, ça prendra une tout autre importance.

Rust sur mcu: Découverte

Fri, 06 Mar 2026 00:00:00 +0000

Intro

J’ai déjà pu expérimenter l’utilisation du langage rust et de son environnement dans le cadre du dev d’outil cli, mais pas encore pour de l’embarqué bare metal. Cet article va donc me servir de mémo quant à ces essais.

Pour ces tests, j’utiliserai une carte de dev ST nucleo stm32l031k6. Pour ce qui est de la toolchain rust, j’utilise la version 1.89.0. Vous pouvez retrouver le répertoire du projet ici.

Premièrement petit tour de la doc:

Système de recette

Première bonne surprise, cargo (l’utilitaire de construction rust), gère nativement la cross-compilation. Pour cela, on peut soit lui passer l’option --target avec le code triple de la cible. Soit créer un fichier .cargo/config.toml à la racine de notre projet, dans lequel on spécifie lui indique la cible.

Donc pour le stm32l032k6, on utilse soit:

cargo build --target thumbv6m-none-eabi
le fichier de config cargo avec:
```
[build]
target = thumbv6m-none-eabi
```
Ainsi lorsqu’on appellera cargo build il utilisera la cible spécifier dans le fichier de config

Description du matériel

Contrairement au C, st ne fournis pas de HAL ou de LL rust. En revanche, la communauté rust étant très active, on trouve des crates faisant un travail équivalent.

On distingue trois niveaux d’intégration

les crates cortex-m et cortex-m-rt réalisant l’abstraction des périphériques standard des coeur arm cortex-m
les crates de description matériel (PAC pour Peripherals Abstraction Crate). Ils gèrent le mapping des périphériques du microcontrôleur. Ils sont donc spécifique à la cible. ils nous permettent d’accéder aux registres de chaque périphérique par un ensemble de fonction/structure de données plutôt qu’en spécifiant des adresses mémoire.
Les crates d’abstraction matériel (HAL pour Hardware Abstraction Layer). Ils sont basés sur les PAC et offrent une interface haut niveau et standardisée pour configurer et intéragire avec les périphériques.

Dans cette première partie, nous n’utiliserons pas de HAL.

Les crates

Les crates est le nom donné en rust aux dépendances du projet. Elles sont la plupart du temps disponibles sur le site crates.io, mais on peut aussi spécifier des dépendances locales ou des répertoires git.

Pour utiliser une crate, il y a deux possibilités:

via cargo avec cargo add le_nom_du_crate Cargo va alors chercher le crate en question sur crates.io et s’il existe, il va ajouter la dépendance dans le fichier Cargo.toml et la télécharger dans le cache local.
En éditant le fichier Cargo.toml.

Dans le cas de notre mcu, il s’agit d’un coeur cortex M0+, nous allons donc utiliser les crates suivant:

cortex-m pour la description des périphériques liés au coeur arm.
cortex-m-rt pour la gestion de la compilation et de l’édition de liens.
panic-abort pour avoir une implémentation par défaut de la gestion des erreurs non recouvrable.
stm32l0 pour la description des périphériques du stm32l031.
stm32l0xx-hal pour la HAL (nous l’utiliserons dans un second temps).

Pour les crates cortex-m, stm32l0 nous devons spécifier des options pour pouvoir les utiliser.

Ce qui nous donne la liste de dépendance suivante:

[dependencies]
cortex-m-rt = "0.7.5"
panic-abort = "0.3.2"
cortex-m = { version = "0.7.7", features = ["critical-section-single-core"] }
stm32l0 = { version = "0.16.0", features = ["stm32l0x1", "rt"]}

Édition de liens

Le crate *cortex-m-rt fournis un script d’édition de liens par défaut. Il nous réclame simplement de créer un fichier memory.x à la racine du projet indiquant la configuration de la RAM et la FLASH. Pour ce qui est de la configuration de la table des vecteurs d’interruption, le crate cortex-m-rt offre un mécanisme permettant à l’utilisateur ou à d’autre crate d’insérer leur définition. Dans notre cas c’est le crate stm32l0 qui s’en charge via la feature rt.

En ce qui concerne la configuration mémoire, notre micro (stm32l031k6) dispose de 32ko de flash et 8ko de ram. On va donc créer un fichier memory.x contenant:

MEMORY
{
  RAM  (rwx) : ORIGIN = 0x20000000, LENGTH = 8K
  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 32K
}

Il ne nous reste plus qu’à éditer le fichier de config de cargo (.cargo/config.toml) pour ajouter un flag de compilation indiquant à rustc d’utiliser le script d’édition de liens du crate cortex-m-rt nommé link.x.

[build]
target = "thumbv6m-none-eabi"

# flag pour l'édition de lien
[target.thumbv6m-none-eabi]
rustflags = ["-C", "link-arg=-Tlink.x",]

Pour aller plus loin

Si on le souhaite, on peut aussi utiliser un script de liens personnel (doc).
Si on souhaite analyser le fichier elf avec objdump ce morceau de doc explicite les différentes sections.
script de liens par défaut: link.x

Un simple clignotement

Commençons par le hello world de l’embarqué: faire clignoter une led…

On commence par créer un dossier: mkdir rust_stm32l031 && cd rust_stm32l031.

Ensuite on initialise le projet avec cargo: cargo init --bin. Cette commande va créer les fichiers de config (Cargo.toml et Carlo.lock) ainsi qu’un répertoire src et le fichier main.rs.

Mise en place de la fonction main

Pour pouvoir compiler notre projet pour la cible stm32l0, on doit spécifier que le programme n’utilise pas la bibliothèque standard. Pour cela on utilise la directive: #![no_std]

On doit aussi indiquer au compilateur que l’on souhaite utiliser une fonction de démarrage custom (fonction qui initialise les variables et appelle la fonction main). En effet, notre main() sera appelée depuis la fonction Reset implémentée par cortex-m-rt. Pour ce faire on utilise la directive: #![no_main].

De son côté, le crate cortex-m-rt expose la directive #[entry] pour spécifier la fonction d’entrée.

Enfin, on doit indiquer au compilateur comment la programme doit réagir en cas de détection de comportement interdit (panic). Pour ce faire, le compilateur attend une fonction:

#[panic_handler]
fn panic( info: &PanicInfo ) -> !{}

Plutôt que de créer notre propre implémentation, on utilise le crate panic_abort afin qu’en cas d’erreur on déclenche un hardfault.

On va donc avoir un fichier main.rs qui ressemble à ça:

#![no_main]
#![no_std]

use cortex_m_rt::entry;
user panic_abort as _;

#[entry]
fn main() -> ! {
 loop{}
}

Voila vous pouvez maintenant compiler et flasher ce programme sur votre carte électronique. Ça n’a aucun intérêt puisque ce programme ne fait rien mais ça fonctionne!

configuration des périphériques

Nous avons mis en place notre chaîne de compilation, nous pouvons maintenant attaquer la configuration des périphériques. Pour cela, nous allons utiliser deux crates:

cortex-m pour l’accès aux périphériques arm, par exemple: systick, nvic …
stm32l0 pour l’accès aux périphériques stm32, par exemple: adc, gpio …

Les objectifs sont:

configurer l’horloge pour utiliser le HSI 16MHz comme source
configurer le GPIO B3 en sortie pour faire clignoter une led
configurer le Systick pour cadencer le clignotement de la led

Ce qui donne le fichier main.rs suivant:

#![no_std]
#![no_main]

use cortex_m::{Peripherals, delay};
use cortex_m_rt::entry;
use panic_abort as _;
use stm32l0::stm32l0x1;

#[entry]
fn main() -> ! {
    // acces aux périphériques
    let peripherals = stm32l0x1::Peripherals::take().unwrap();
    // on récupère le périphérique d'horloge et on configure le HSI
    let rcc = peripherals.RCC;
    rcc.apb2enr().write(|w| w.syscfgen().enabled());
    rcc.cr().write(|w| w.hsi16on().enabled());
    while rcc.cr().read().hsi16rdyf().bit_is_clear() {}
    rcc.cfgr().write(|w| w.sw().hsi16());

    // configuration du Systick pour une clock à 16 MHz et
    // utilisation de la structure delay de cortex-m
    let peripheral = Peripherals::take().unwrap();
    let mut delay = delay::Delay::new(peripheral.SYST, 16_000_000);

    // on active l'horloge pour le GPIOB
    rcc.iopenr().write(|w| w.iopben().enabled());

    // On configure le GPIOB3 en sortie push-pull
    let gpiob = peripherals.GPIOB;
    gpiob.moder().write(|w| w.mode3().output());

    loop {
        // on commence par lire l'état de la sortie via 'r' -> r.od3().bit()
        // On inverse la valeur à écrire par rapport à la valeur lu via '!'
        // et on écrit met à jour la sortie 'w' -> w.od3().bit(x)
        gpiob.odr().modify(|r, w| w.od3().bit(!r.od3().bit()));
        // attente de 500 ms
        delay.delay_ms(500);
    }
}

Et voilà un clignotement de led en bonne et due forme.

Linker scripts

Sun, 01 Dec 2024 00:00:00 +0000

Intro

Dans les grandes lignes, le linker script (fichier .ld) permet d’indiquer au programme “ld” comment le contenu des fichiers objet (.o) doit être assemblé pour créer le fichier ELF.

Dans le cas qui m’intéresse - les firmwares ciblant des microcontrôleurs - le fichier elf sera soit converti en fichier hexa ou binaire soit directement utilisé par openocd pour programmer le MCU.

Un exemple de linker script est disponible ici sample.ld.

Architecture du fichier .ld

Les fichiers .ld sont de simples fichiers texte. On peut y écrire des commentaires via la syntaxe /* mon commentaire */.

Pour indiquer à l’éditeur de liens comment agencer les objets en mémoire, nous avons à disposition quelques mots-clés (liste non exhaustive, je me contente ici des mots-clés qui me sont utiles):

MEMORY Déclare les zones mémoire utilisables, leurs adresses et leurs tailles.
SECTIONS Permet de déclarer les différentes sections, où les ranger et dans quel ordre.
. Le point n’est pas un mot-clé à proprement parler mais une variable spéciale. Elle enregistre la dernière adresse mémoire utilisée durant l’assemblage des objets. Elle nous permet donc de récupérer la position actuelle de *l’assemblage en mémoire: _myvar = .. Elle permet aussi de forcer la position d’une section: . = 0xFF (semblable à l’instruction AT(x)).
KEEP Indique à l’éditeur de liens de garder cette section même si elle est vide. Ce mot-clé a toute son importance lorsque l’on passe l’option --gc-sections à l’éditeur.
AT(x): Est un attribut de section (optionnel) qui permet de spécifier l’adresse à laquelle doit être placé la section.
> Y AT > X: Cette utilisation de AT diffère de la précédente. Dans ce cas, on l’utilise pour indiquer la zone mémoire de stockage (Y) et la zone mémoire dans laquelle la section doit être chargée (X).
ALIGN(x) spécifie l’alignement en mémoire, x étant le nombre d’octets
NOLOAD Indique au sein du fichier ELF que la section n’a pas besoin d’être chargée au démarrage du système. Ce mot-clé ne semble pas pertinent dans notre cas puisque le démarrage n’est pas fait à partir du fichier ELF mais cela nous permet de décrire les sections.
LOADADDR permet de récupérer l’adresse d’une section en mémoire.
PROVIDE Il y a deux manières de définir un symbole, soit par un assignement, soit via PROVIDE. PROVIDE permet de définir le symbole s’il n’est pas déjà défini dans les fichiers objets à assembler.
PROVIDE_HIDDEN Permet de définir une variable mais sans l’exporter ; donc définir une variable locale plutôt que globale.
ASSERT assertion classique permet de déclencher une erreur si le résultat du test est égal à zéro.
SIZEOF permet de récupérer la taille d’une section.
SORT permet de trier une liste

De manière naïve, nous pouvons dire que ces scripts sont découpés en trois parties:

La déclaration des variables Via l’assignation = ou PROVIDE, on peut assigner une valeur à une variable que l’on pourra réutiliser plus tard dans le script. Dans notre exemple, on s’en sert pour définir la taille maximale de la stack.
La description de la mémoire du périphérique. Grâce au mot-clé MEMORY, on indique l’adresse des zones mémoire à utiliser et leurs tailles.
La description de comment ranger le code en mémoire

Description de la mémoire

Cette section permet de décrire la zone mémoire utilisable. Dans notre exemple, nous avons trois zones, la RAM, le BOOTLOADER et la FLASH.

FLASH_SIZE = 0x10000000
RAM_SIZE = 0x30000

MEMORY{
    FLASH(rx) : ORIGIN = 0x00000000, LENGTH = FLASH_SIZE
    RAM(rwx) : ORIGIN = 0x20000000, LENGTH = RAM_SIZE
}

On remarque que la déclaration de variable et leur assignement nous permet de facilement séparer une même mémoire physique en deux mémoires virtuelles (BOOTLOADER et FLASH).

La déclaration des zones mémoire nous permet aussi d’indiquer les droits d’accès pour chacune de ces zones.

La gestion des sections

Le mot-clé SECTIONS{} permet de définir plus finement l’organisation du code dans les différentes zones mémoire.

La table des vecteurs d’interruption

Dans le cas d’un MCU basé sur l’architecture ARM Cortex-M, la première section doit être la table des vecteurs d’interruption.

Nous allons donc commencer le script avec:

SECTIONS{
  /* force la position à l'adresse relative 0 */
  . = 0x0;
  .vectors : {
  /* indique que les données doivent être
     alignées sur 4 octets */
  . = ALIGN(4);
    KEEP(*(.vectors))
  } > BOOTLOADER;
}

Attention, il ne faut pas oublier d’ajouter __attribute__ ((section(".vectors"))) à la déclaration de la table des vecteurs d’interruption afin de spécifier son lieu de stockage.

En ce qui concerne l’appellation des objets et des sections, GCC génère trois formes de “section” différentes:

mysection: la classique
mysection.mafonction mysection.mydata : générée automatiquement si l’on compile le programme avec les options -ffunction-sections ou -fdata-sections. Ces options permettent de générer une section par fonction/data. Cela peut être pratique pour placer précisément une donnée ou une fonction dans une zone particulière : par exemple en SRAM pour réduire les temps d’accès.
gnu.linkonce.{type}.{nom} : liée au Vague Linkage Cette section ne semble concerner que le code C++

Les sections usuelles

Les sections usuelles servent à stocker le code et les variables. On y retrouve :

.text: le code
.rodata: les données en lecture seule
.data: les données en lecture/écriture initialisées avec une valeur
.bss: les données en lecture/écriture non initialisées

Notons que les sections .data et .bss doivent être, respectivement, copiées et initialisées en RAM au démarrage du MCU. Dans notre cas de figure, cette opération est réalisée dans la fonction de démarrage (fonction appelée par l’interruption de Reset).

Ce sont les quatre sections que l’on retrouve systématiquement. Nous pouvons aussi y ajouter nos propres sections pour stocker une partie spécifique du programme à un emplacement donné.

Par exemple on pourrait vouloir que certaines fonctions soient exécutées depuis une autre zone mémoire (ex: SRAM) afin d’optimiser la vitesse d’exécution. On aurait alors le linker script suivant:

SECTIONS{
    .text : {
     
    } > FLASH
    .data : {
     
    } > RAM
    .bss : {
     
    } > RAM

    .superImportanteSection {
      speed_function.o
    } > SRAM AT > FLASH
}

L’indication > SRAM AT > FLASH permet d’indiquer que ces données sont stockées en FLASH mais doivent être chargées en SRAM au démarrage. Attention, ce n’est pas fait automatiquement : il faut adapter la fonction de démarrage (dans le cas d’un MCU) pour copier la section (cf: bss et data).

Les sections spécifiques

On retrouve ici les sections utilisées par le compilateur pour stocker les constructeurs et destructeurs d’objets (new et delete en C++ et __attribute__((constructor)) en C). N’utilisant pas le C++ en embarqué, l’étude de ce fonctionnement n’a pas été poussée.

Ce que j’ai pu en comprendre, c’est que ces sections sont utilisées par le compilateur pour stocker des pointeurs de fonction permettant d’initialiser/déinitialiser des variables.

Ces fonctions sont appelées via __libc_init_array durant la phase de démarrage et via __libc_fini_array à la fin de l’exécution (ce qui n’arrive jamais en embarqué). (cf picolibc).

Les sections d’initialisation et destruction sont:

preinit_array : générer par le compilateur pour les classes C++ (vtable) (je n’ai pas creusé davantage)
init_array : les fonctions avec l’attribut constructor. ATTENTION les constructeurs sont initialisés avec un ordre de priorité. Donc init_array doit être trié avec SORT.
fini_array : les fonctions avec l’attribut destructeur
ctors: déprécié
dtors: déprécié

Les sections ARM Debug

Pour pouvoir utiliser la fonction backtraces en debug, if faut fournir deux sections:

exidx : qui contient l’index permettant de décoder la stack
extab : qui contient le nom des sections contenant des infos sur les exceptions en cours ??? pas clair

Ressource:

Il semble que ces sections permettent d’analyser et restaurer la stack sans passer par le frame_pointer (fp). Ils parlent - sur so - d’utilisation pour les fonctions asynchrones. Freertos need it ?

Organisation de la RAM

Une des raisons m’ayant poussé à comprendre plus finement le fonctionnement des scripts de liens et de leurs éditeurs est de pouvoir modifier l’agencement de la RAM pour éviter que la pile déborde sur la stack ou que la stack descende sur la pile. Ces bugs sont particulièrement pénibles à résoudre…

L’idée ici est d’organiser la RAM de la manière suivante:

ram orga

Ainsi, la pile, qui est descendante sur ARM Cortex-M, viendra déborder sur la section “NoMansLand”. Donc en configurant le périphérique de protection mémoire (MPU) correctement, on pourra “normalement” détecter le débordement de la stack.

Idem pour la HEAP, qui elle est croissante et viendra déborder sur une adresse non accessible en écriture et nous permettra de détecter le dépassement rapidement.

Cet article explique clairement l’intérêt de cette configuration.

Autre linker

J’ai voulu voir s’il était possible de remplacer ld par mold mais mold ne supporte qu’un tout petit sous-ensemble de la syntaxe des linker-scripts. Il est donc impossible de l’utiliser pour l’embarqué en none-eabi.

Il me reste à tester avec lld de clang.

Une Tanche

Note sur les moteurs électriques synchrone

Attention

Intro

Dénomination des différents type de moteur

Architecture des moteurs synchrone

Équations et Models

Important

Particularité MSAP

Particularité SynRM

Note: Changement de repère

Attention:

Note: Les signaux PWM

Commande des moteurs synchrone

Moteur à Aimants Permanents

Scalaire: VbyF

Remarque suite à mes essais en simulation

Commande vectorielle FOC

Commande vectorielle DTC

Moteur à Reluctance Variable

Commande scalaire VbyF

Commande vectorielle FOC

Note

Bilan

Commande vectorielle DTC

PMa-SynRM

Commande scalaire

Commande vectorielle FOC

Position du rotor

Calibration de la position du rotor

Rotor sans capteur

Rust sur mcu: Écriture d'un driver

Intro

Configuration du Systick

Création de l’interface

Interruption de SysTick

Mutex

Atomic

Bilan

Rust sur mcu: Découverte

Intro

Système de recette

Description du matériel

Les crates

Édition de liens

Pour aller plus loin

Un simple clignotement

Mise en place de la fonction main

configuration des périphériques

Linker scripts

Intro

Architecture du fichier .ld

Description de la mémoire

La gestion des sections

La table des vecteurs d’interruption

Les sections usuelles

Les sections spécifiques

Les sections ARM Debug

Organisation de la RAM

Autre linker

Références