Configurateur de STM32

Vue d'ensemble

  • Ce projet a pour but de faciliter le démarrage avec un STM32:
    Chaine de compilation
    outils pré-packagés, compilation "dans le nuage"
    Configuration du chip
    sélection des entrées/sorties, nommage des I/O et périphériques
    Code 'glu'
    génération automatique du code d'initialisation et de contrôle des I/O (sur la base de la configuration ci-dessus)

Délivrables:

  • Page wiki de documentation: DemarrageRapideSTM32
  • Scripts d'initialisation de l'environnement de compilation
  • Packages de compilation
  • Serveur de compilation sur V12 (?)
  • outil graphique de sélection des I/O
    • Capture des besoins et du chip cible
    • Génération des configurations possibles par propagation de contraintes
    • Assignation graphique des fonctions et propagation des contraintes
    • Génération de la configuration (fichier .cfg par exemple)
  • Script de génération de code
    • Cible C++ avec stm32lib
    • Cible Ada + Ravenscar
    • ?

Participants

Ressources

depot git
http://git.telecom-robotics.org/?p=stm32_base_config.git;a=summary
exemple de frontend graphique (sur v12)
TODO

Développement

J'ai découpé le projet en 3 parties:
  1. L'allocateur de ressources permet d'exprimer les besoins en termes de périphériques, et d'allouer les periphériques aux différents besoins. L'allocation est exportée vers le générateur de code. Voir plus bas.
  2. Le générateur de code génère les stubs C, C++, Ada et (Mentor?) depuis l'allocation de périphériques
  3. L'éditeur de composants permet d'entrer les stubs d'initialisation standard, et décrit la topologie du composant en termes de périphériques et pattes de sortie.

Allocateur de ressources

L'allocateur suppose que le composant est constitué d'un certain nombre de périphériques (timers, UART...) avec certaines capacités.
  • Un timer peut avoir deux sorties en polarité opposées, ou avec des seuils différents.
    • On peut allouer deux PWM au même timer,
    • ou utiliser deux timer différents
  • Un UART peut servir seulement de contrôleur SPI, l'autre de SPI ou de port série avec contrôle matériel.
    • Si on a besoin d'un port série matériel et d'un SPI, on allouera le premier au second périphérique, et le second au premier.
    • Si on a besoin de 2 SPI mais pas de port série matériel, alors les deux allocations sont interchangeables.

L'allocateur suppose également que ces périphériques ont besoin de certaines pattes d'entrée/sortie; il arrive qu'un même signal puisse sortir par deux pattes, ou requiert une patte spécifique. On décrit à l'allocateur:
  • Les signaux requis par chaque périphérique
  • Sur quelles pattes chaque signal peut sortir.

Modélisation du problème d'allocation

On modélise le problème d'allocation par un graphe avec 4 types de noeuds:
  • Les noeuds besoin décrivent la demande de périphérique
  • Les noeuds périphériquedécrivent les périphériques disponibles;
    • on décrit les options sur un périphérique (par exemple, les signaux de contrôle matériels RS-232) par des périphériques distincts et une contrainte de non-utilisation simultanée
  • Les noeuds signal décrivent les signaux requis par chaque périphérique
  • Les noeuds I/O décrivent les blocs I/O

Les segments du graphe décrivent les connexions possibles entre les différents niveaux:
  • De besoin à périphérique: quels périphériques remplissent exactement le besoin
  • De périphérique à signal: quels signaux sont requis pour le signal
  • De signal à I/O: quels I/O peuvent être connectés au signal.
  • De périphérique a périphérique: quels périphériques (y compris variantes) sont exclusifs.

Le graphe initial est alors étudié pour trouver les arbres disjoints partant de chaque besoin. On utilise pour cela une classe d'algorithmes de recherche opérationnelle par propagation de contraintes. La bibliothèque employée est la bibliothèque CSP - Constraint Solving Programming.

Modélisation sous forme de variables / contraintes

Modélisation des I/O

  • Chaque I/O est représenté par un entier (type énuméré). L'unicité est assurée par construction.

Modélisations des Signaux

  • Chaque signal est représenté par une variable de type produit {non-connecté|numéro d'I/O} indiquant la connexion du signal à une I/O, si le signal est actif.
  • Contraintes:
    • Entre I/O et signal: matrice de routage des signaux: les connections possibles sont décrites par une restriction du domaine de la variable aux seuls signaux connectables
    • Entre signaux: unicité du signal connecté à la patte: chaque signal doit avoir une valeur différente, ou être à "Non Connecté" ( $ \frac{n \times (n-1)}{2} $ contraintes)
      • Avec 64 signaux ça veut dire potentiellement 2016 contraintes
      • La plupart de ces contraintes sont inopérantes, peu de signaux ont plusieurs chemins de sortie
    • Entre signal et périphérique: contrainte de connexion des signaux: si le périphérique est actif, alors le signal doit être connecté. Si le périphérique est inactif, le signal doit être non-connecté

Modélisation des Périphériques

  • Chaque périphérique est représenté par
    1. une variable de type produit {non-connecté|numéro de demande} indiquant la connexion du périphérique à une demande
    2. un entier (type énuméré): l'identifiant du périphérique
  • Contraintes:
    • Entre signal et périphérique: voir ci-dessus
    • Entre périphériques:

Modélisation des Demandes

  • Chaque demande est représenté par
    1. une variable de type produit {numéro de périphérique} indiquant la connexion du périphérique à une demande
    2. un entier (type énuméré): l'identifiant de la demande
  • Contraintes:
    • Entre demandes: chaque variable demande doit être différente de toutes les autres (un seul périphérique par demande; toutes les demandes doivent être satisfaites)
    • Entre périphérique et demande: si la demande est égale au numéro de périphérique, alors le périphérique est égal au numéro de demande (et est actif).

-- JeanBaptisteMayer - 2013-07-02