3 Avancement du projet¶

Dans cette partie est expliqué l'avancement du projet dans sa globalité. Cela commencera donc par les différentes tâches effectuées dans la partie logicielle et la partie matérielle et on finira par parler de la sous-traitance.

3.1 Partie Software¶

Cette partie décrira nos avancées faites sur la partie logicielle, nous avons utilisé les ressources présentes dans ce tableau avec les versions mentionnées :

3.1.1 Organisation des fonctions utiles

Avant de commencer à coder sur le logiciel e2studio proposé par Renesas©, nous avons établi en étroite corrélation avec le cahier des charges, une liste des fonctions utiles pour le projet qui permettront de répondre totalement au cahier des charges. La fonction principale est celle assurant le contrôle du moteur triphasé brushless à l'aide de six MLIs. Une autre fonction assurera le retour d'informations provenant du moteur grâce aux capteurs à effet HALL par exemple. Nous avons également prévu quatre autres tâches que notre programme devra remplir à savoir, celles liées aux différents bus de communication établis dans le cahier des charges, une tâche pour chaque bus (USB, I2C, CAN et l'UART). Pour la fonction optionnelle du cahier des charges à savoir, l'ajout d'un contrôle d'un servomoteur en position, nous avons jugé qu'une dernière fonction pourra gérer ce contrôle.

3.1.2 Description de chaque fonction

Cette sous-partie a pour but d'expliquer le rôle de chaque fonction citée précédemment. Il est important de noter que pour chacune de ces fonctions, le logiciel e2studio accompagné du SSP (Synergy Software Package) ont été utilisé. Ils ont permis d'éviter de coder manuellement chaque registre utilisé avec des lignes de code. En effet, pour les registres dédiés à des ressources qui sont couramment utilisées par les utilisateurs comme par exemple les bus I2C, CAN, USB, etc mais aussi les convertisseurs analogique numérique ou encore les "timers". Il est possible dans la configuration du projet dans lequel on travaille d'ajouter et de configurer les parties dont on a besoin. Une fois configuré, nous pouvons faire générer par l'outil les fichiers qui contiennent les lignes de codes permettant de retrouver la configuration entrée des registres concernés. Enfin, après avoir configuré les différents blocs utiles à notre besoin, il est nécessaire dans l'onglet broche d'attribuer les broches du microcontrôleur à la fonction choisie comme un "timer" par exemple, et c'est sur cette broche que l'on aura la MLI générée par le "timer".
La description des différentes fonctions choisies est :

Fonction permettant le contrôle du moteur triphasé brushless en vitesse : à l'aide de six MLIs qui alimenteront l'un des six transistors, le but va être, grâce à une commande trapézoïdale, de générer ces six MLIs qui seront déphasées entre elles de 120°. Pour ce faire nous utiliserons le périphérique OPS (Output Phase Switching) dédié au contrôle moteur triphasé brushless présent sur le microcontrôleur. Pour mieux comprendre comment nous avons configuré le périphérique OPS, nous vous invitons à vous référer à la note d'application concernée. A chaque instant uniquement deux des six MLIS seront à l'état haut simultanément comme l'illustre la figure suivante :
Fonction permettant le retour d'informations du moteur : à l'aide de plusieurs convertisseurs analogique numérique, nous serons en mesure de récupérer les valeurs fournies par les différents capteurs qui renvoient des données du moteur et de les afficher par exemple. Dans la configuration de cette fonction, les blocs convertisseurs ajoutés sont configurés pour utiliser certains des convertisseurs disponibles sur le microcontrôleur (comme ici les canaux 0 à 3) :
Fonctions mettant en place les quatre bus de communication demandés : nous avons choisi de réaliser une fonction par bus de communication. Il existe des blocs pour chacun de ces bus dans le SSP, la figure suivante illustre celle du bus I2C. Il faut les configurer en fonction du résultat que l'on veut obtenir.
Fonction optionnelle permettant de contrôler le servomoteur en position : nous avons utilisé un "timer" pour générer une MLI avec une période fixée à 20 millisecondes et c'est en faisant varier le temps à l'état haut que l'on peut choisir la position du servomoteur. La figure suivante montre la configuration (dans laquelle on peut choisir par exemple la période ou encore le rapport cyclique) du "timer" :

3.1.3 Test de ces fonctions

Chacune de ces fonctions est dans un premier temps créée sur un nouveau projet pour chacune d'entre elles. Après avoir ajouté et configuré les broches ou les blocs nécessaires pour la fonction, il est nécessaire d'écrire un programme en langage C pour tester si notre fonction est opérationnelle. Étant donné que nous ne possédons pas la partie puissance de la carte dû à des erreurs d'organisation de notre part notamment, nous avons testé les différentes fonctions sur la carte de démarrage fournie par Renesas©, le SK-S7G2.

Test des MLIs pour le moteur triphasé brushless : nous n'avons pas pu vérifier le fonctionnement de cette fonction sur le moteur par manque de la partie puissance sur notre carte. Mais nous avons pu valider son fonctionnement théorique à l'aide des oscilloscopes à deux voies mis à notre disposition. Pour plus de précisions, nous vous invitons à vous référer à la note d'application concernée. Il a, tout de même, été nécessaire d’ajouter la troisième MLI, avec un montage photo, pour voir au moins les trois MLIs dirigées dans les trois transistors situés en haut. La figure suivante montre trois des six MLIs que nous avons obtenues, elles sont déphasées de 120° entre elles et à tout instant il n'y en a que deux sur les six qui sont à l'état haut :
Test de la fonction permettant le retour d'informations du moteur : de la même manière, nous n'avons pas eu le temps de souder les capteurs à effet HALL. C'est pour cela que pour valider le fonctionnement d'un convertisseur analogique numérique, nous avons utilisé un potentiomètre. Nous avons pu récupérer la valeur fournie par le potentiomètre pour commander le servomoteur en position. En effet, en fonction de la valeur du potentiomètre, le servomoteur changeait de position. La figure suivante illustre, sur un oscilloscope, la MLI utilisée pour contrôler le servomoteur en position avec une période de 20 milliseconde (50 Hz) :
Test de chaque fonction mettant en œuvre un des quatre bus de communication :

Le bus I2C : pour valider son fonctionnement, nous l'avons testé avec un capteur de température de chez Microchip, le MCP9801 (la documentation est disponible ci-joint). Pour tester en écriture et en lecture, nous avons envoyé sur la broche SDA (Serial Data Line : broche P511 sur le kit de démarrage) deux valeurs que l'on retrouvait bien sur l'oscilloscope après vérification. Nous avons effectué une lecture de la température dans le registre du capteur concerné puis une conversion de celle-ci en degré Celsius comme le montre les deux images suivantes (l'une montre une partie du code en C et l'autre le résultat affiché, en posant un doigt sur le capteur, sur la console de débug du logiciel) :
Le bus CAN : dans l'idéal, il aurait fallu faire un test similaire à celui fait pour le bus I2C mais par manque de temps, nous avons dû opter pour un autre type de test. En effet, nous nous sommes appuyés sur une note d'application faite par Renesas(c) (ci-joint) pour le bus CAN. Nous obtenons les mêmes résultats que ceux obtenus à la fin de la note d'application. Après appui sur le bouton poussoir 4 de la carte de démarrage (SK-S7G2), le module CAN va transmettre un message et si ce bouton n'est pas poussé, alors le module reste en lecture continue. L'image suivante montre le résultat obtenu après un appuie sur le bouton poussoir numéro 4 :
Le bus USB : pour valider son fonctionnement, il fallait prouver qu'en envoyant une chaîne de caractères sur le bus par exemple, on arrivait à la récupérer sur un ordinateur en le connectant à la carte SK-S7G2. Pour cela, nous nous sommes appuyés sur un tutoriel disponible sur le fichier html disponible ci-joint. Après avoir configuré l'onglet "thread" d'un nouveau projet comme indiqué dans le tutoriel, nous avons pu réaliser un programme permettant d'afficher une chaîne de caractères indiquant le prochain état de la LED (allumée ou éteinte). La figure suivante montre le résultat sur un terminal (TeraTerm) sur l'ordinateur connecté à la carte ainsi qu'une partie du code en langage C écrit permettant d'envoyer le message sur le bus USB :
L' UART : pour valider le fonctionnement de l'UART, nous avons étudié, en premier, un document réalisé par Renesas© proposant un exemple d'utilisation de deux UARTs (disponible ci-joint). En connectant la broche RTS à la broche de la première UART à la broche CTS de la seconde, on s'assure que l'émetteur sera averti lorsqu'il pourra transmettre des données (la précédente donnée aura été transmise). Dès que l'UART émettrice a fini de transmettre sa donnée, un message "UART transmit" sera affiché sur la console de Renesas© du logiciel e2studio. Ensuite on viendra lire la broche de l'UART réceptrice et on obtient le message suivant "Hello World".

3.2 Partie Hardware¶

3.2.1 Découpage fonctionnel du projet

Afin d’effectuer le contrôle du moteur, M. Vedder a utilisé deux shunts** reliés chacun à deux pattes du driver de mosfets pour avoir une image du courant traversant au moins 1 bobine du moteur à la fois. Notre client nous a demandé d’ajouter un troisième shunt pour pouvoir avoir à tout moment une image du courant traversant chacune des phases du moteur, ce qui permet une meilleure régulation. Nous avons donc décidé de ne plus passer par le driver de mosfets mais directement par les convertisseurs Analogiques 12 bits du microcontrôleur.

3.2.2 Partie commande

Afin d’effectuer le contrôle du moteur, M. Vedder a utilisé deux shunts reliés chacun à 1 phase pour avoir une image du courant traversant au moins une bobine du moteur à la fois. Notre client nous a demandé d’ajouter un troisième shunt pour pouvoir avoir à tout moment une image du courant traversant chacune des phases du moteur, ce qui permet une meilleure régulation. Nous avons donc décidé de ne plus passer par le driver de MOSFETs mais directement par les convertisseurs Analogiques 12 bits du microcontrôleur.

Nous avons pu valider une partie de la schématique de la partie commande en faisant clignoter une led sur la carte que nous voulons fournir à nos successeurs.

3.2.3 Partie puissance

Chaque MOSFET sera commandé en Bloqué/Saturé (par le driver de MOSFETs) pour laisser passer la MLI jusqu’au moteur. C’est-à-dire qu’on peut voir chaque transistor comme un interrupteur ouvert ou fermé en commutation à une certaine fréquence définie par les contraintes d’un moteur (couple, vitesse) qui seront renvoyées au microcontrôleur par le biais des trois shunts, un sur chaque phase du moteur.
Sur le schéma ci-dessous (Illustration 7), on peut voir le montage de chaque MOSFET que nous avons réalisé avec les liaisons entre le driver de MOSFETs et le moteur brushless.

N.B : Pour un projet de cette ampleur, il est nécessaire de définir des feuilles de hiérarchies dans le projet KiCad. C’est-à-dire définir des sous feuilles de schémas pour pouvoir séparer distinctement les différentes fonctions de notre carte. Les schémas ci-dessus sont extraits de deux feuilles de hiérarchies distinctes, leur lien étant fait par des « Labels » qui représentent des liens entre deux fils comme celui-ci :

La partie commande moteur n’est pas encore complète. Il manque en effet les shunts qui rebouclent sur le microcontrôleur. Or, lors de la recherche de nos différents shunts, nous devions prendre en compte le nombre d’ampères maximum que celui-ci peut supporter, ainsi que la taille physique du shunt pour optimiser au mieux la taille de la carte.

Nous avons trouvé des shunts qui peuvent correspondre à nos besoins malheureusement la valeur résistive de ceux-ci ne permet pas une exploitation sur la plage de variation totale de tension en entrée des convertisseurs analogique/numérique 12 bits du microcontrôleur. Il sera donc sûrement nécessaire d’ajouter trois AOP (un pour chaque phase) pour amplifier le signal de tension venant des shunts (image des courants dans le moteur) pour utiliser la plage de tension variable maximale et ainsi avoir des mesures plus précises.

3.2.4 Le microcontrôleur

Le microcontrôleur S7G2 dans sa version LQFP-100 pins que nous devons utiliser pour notre carte électronique n’existait pas sous KiCad, nous avons donc dû le créer. Dans l’ordre d’apparition, ci-dessous dans l’illustration se trouve une photo du schéma KiCad du microcontrôleur et dans l’illustration 9 son empreinte physique sur la carte électronique.

On peut voir que pour plus de clarté dans le schéma, toutes les pattes de type « VSS », « VCC » ont été dessinées les unes à côté des autres. Les ports d’entrées/sorties sont déclarés dans l’ordre croissant de leur numérotation et les entrées/sorties « spécifiques » sont rassemblées du même côté du schéma.

Concernant l’illustration ci-dessous, il faudra bien faire attention au détrompeur (coin inférieur droit) pour souder le composant dans le bon sens.

Dans la continuité des tests effectués sur la carte, nous avons utilisé un debugger JTAG (Join Test Action Group) dans le but de nous connecter à la carte afin de la programmer. Pour cela, nous avons utilisé le logiciel J-Link Commander v6.20h et J-Flash v6.20h.
Nous avons obtenu les résultats ci-dessous:

Nous avons par la suite été bloqués dans les tests car l'utilisation d'un oscillateur externe comme nous l'avions pensé ne fonctionnait pas sur la carte dû à un problème d'empreinte du quartz utilisé.
Le jour de la rencontre avec le client, celui-ci nous a aidé afin d'utiliser l'oscillateur interne du microcontrôleur et nous avons pu allumer une led sur la carte.

3.3 Sous-traitance

Dans cette dernière partie de notre avancement, nous allons décrire comment nous avons utilisé la possibilité de sous-traiter certaines tâches aux élèves de quatrième année pour nous concentrer sur une autre tâche.

Par rapport à la partie programmation, nous avons choisi de demander à ces élèves d'étudier les différents registres et les valeurs que l'on doit mettre dans chacun d'entre eux pour faire un bus I2C, CAN et un UART. Pour cela nous leur avons fourni la documentation du microcontrôleur que nous avons utilisé et nous leur avons conseillé de vérifier, pour les aider, les fichier PDF faits par Renesas© sur les différents bus. Après un travail de recherche et de compréhension de leur part, nous leur avons demandé pour finaliser les tâches demandées de faire un fichier PDF nous expliquant comment paramétrer l'onglet "thread" présent dans la configuration d'un projet pour réaliser chaque bus.

Pour la partie matérielle, nous avons choisi de leur faire vérifier le schéma Kicad que nous avions effectué pour la carte finale pour le client avec la partie commande et la partie puissance. Cette étape avait pour but de vérifier si nous n'avions pas fait par erreur des fautes basiques comme un court circuit ou si toutes les broches reliées sont bien reliées à quelque chose, etc. Ensuite, nous leur avons demandé de réaliser le placement/routage de la partie commande, dans un premier temps, puis de la partie puissance ensuite. Bien entendu, nous restions à leur disposition pour les aider et leur donner des précisions sur comment placer les composants pour que cela rentre dans les tailles imposées par le client. Malheureusement, la carte était de petite taille avec beaucoup de composants à placer, cela a été donc assez compliqué pour les sous-traitants de respecter toutes les contraintes (la taille et la partie puissance avec des pics de courant et tension important). Il a fallu donc reprendre leur travail pour enlever les erreurs liées aux règles de dessin (DRC). Une mauvaise organisation de notre part expliquée en partie 2 nous a poussé à demander un travail de placement/routage compliqué avec des contraintes fortes à des étudiants de quatrième année. En effet, leur demander d'effectuer le placement/routage de carte de test plus simple (seulement une partie de la carte finale demandée) et sans contrainte de taille (carte sur deux couches réalisée en interne à Polytech) aurait été plus judicieux de notre part.

footprint.PNG

fonctionnement_système.jpg