Accueil Articles Concevoir séparément et intégrer de manière transparente avec un contrôleur double...

Concevoir séparément et s'intégrer de manière transparente avec un pilote double cœur

Simplifiez l'intégration de votre logiciel avec un pilote de signal numérique double cœur
Les applications embarquées deviennent complexes et sophistiquées pour répondre à divers objectifs. Premièrement, les applications doivent améliorer leur efficacité, ce qui nécessite des performances de pilote importantes pour exécuter des algorithmes sophistiqués. Ensuite, la disponibilité omniprésente d'Internet permet aux applications embarquées de devenir « plus intelligentes » et plus « connectées ». Le troisième objectif est de réduire les coûts en intégrant diverses fonctions telles que l'interface capteur, la connectivité, le contrôle moteur, la conversion numérique de puissance, la sûreté et la sécurité dans un seul contrôleur. Un tel niveau d'intégration nécessite des experts de domaine respectifs pour gérer des modules ou des domaines fonctionnels spécifiques, puis plusieurs fonctions doivent être intégrées dans une application finale. Souvent, les entreprises multinationales qui ont leurs équipes réparties dans le monde entier rendent encore plus important que plusieurs modules puissent être conçus séparément et intégrés de manière transparente avec facilité pour réduire les risques et les efforts de développement.
Une efficacité améliorée Voyons d'abord comment l'objectif d'amélioration de l'efficacité énergétique nécessite des performances de contrôleur plus élevées. Prenons l'exemple d'une application de commande de moteur. L'industrie s'est éloignée des moteurs à courant continu à balais, qui offrent une efficacité de 75 à 80 %, vers les moteurs à courant continu sans balais (BLDC) ou les nouveaux moteurs synchrones à aimants permanents (PMSM). Ces moteurs offrent une efficacité jusqu'à 85 à 90 % supérieure, un bruit acoustique réduit et une durée de vie plus longue. Le contrôle typique d'un moteur à courant continu à balais nécessite des techniques de contrôle de vitesse et de direction très simples qui peuvent être obtenues à l'aide d'un microcontrôleur 8 bits d'entrée de gamme. En comparaison, le contrôle d'un moteur BLDC ou PMSM sans capteur avec "Field Oriented Control" (FOC) est plus sophistiqué et gourmand en calculs. Il permet un contrôle précis de l'énergie utilisée par le moteur sur une large plage de charge ou de vitesse et contribue à améliorer considérablement l'efficacité. Des algorithmes de contrôle supplémentaires peuvent également être mis en œuvre en fonction des exigences de l'application, tels que "Détection et récupération du décrochage du rotor", "Moulinage", "Saturation de la boucle PI et anti-basculement", "Affaiblissement du flux" et "Couple maximal par ampère", qui aide à améliorer les performances, la réponse à une charge dynamique et augmente l'efficacité globale.
Toutes ces techniques de contrôle avancées sont intensives en calcul et impliquent des opérations mathématiques telles que la division, la multiplication, la racine carrée et les opérations trigonométriques, qui nécessitent une bande passante importante de l'unité centrale de traitement (CPU). Comme ces fonctions de contrôle doivent être exécutées périodiquement à une fréquence élevée, il est nécessaire que le CPU soit affecté à un intervalle de temps spécifique. Une telle exécution stricte de la boucle de contrôle peut occuper la majeure partie de la bande passante du processeur et peut affecter d'autres fonctions critiques dans une application complexe. Un développeur embarqué aura une flexibilité limitée pour incorporer des fonctionnalités supplémentaires telles que la communication, la surveillance de la sécurité, les fonctions système et les fonctions de maintenance qui pourraient interférer avec le contrôle à temps critique du moteur. Le défi augmente dans les applications d'alimentation numérique où les fonctions de boucle de contrôle à temps critique doivent fonctionner à une fréquence encore plus élevée.
Logiciel complexe
Considérons maintenant le prochain objectif motivé par la connectivité Internet ou cloud. La dernière tendance du secteur est que les applications soient « intelligentes » et « connectées », offrant intelligence et accessibilité de n'importe où. Ces exigences exigent que les applications embarquées incluent plusieurs piles logicielles telles que : 1. Le logiciel de la fonction principale de l'application. Dans notre exemple, cette fonction implémente le contrôle moteur, les tâches de maintenance et les opérations d'interface utilisateur qui sont couramment requises dans la plupart des applications. 2. Le logiciel de communication qui exécute les protocoles d'application réseau nécessaires à la connectivité. 3. Logiciel de sécurité pour la protection IP, la confidentialité, l'intégrité des données, l'authenticité, le contrôle d'accès et contrecarre toute possibilité de piratage 4. Si les applications impliquent des opérations humaines et peuvent causer des lésions corporelles en raison d'un dysfonctionnement, alors même la sécurité fonctionnelle du logiciel devrait faire partie de ces applications critiques pour la sécurité. 5. Certaines des applications finales peuvent également avoir des exigences de personnalisation où certaines fonctionnalités seront exclusives à des variantes spécifiques ciblant différents segments de marché. Toutes ces exigences de fonctionnalités nécessitent que plusieurs équipes d'experts du domaine soient impliquées dans le développement des piles logicielles respectives et soient en mesure de les intégrer de manière transparente et rapide dans une application finale. Des experts de plusieurs domaines devront se coordonner très étroitement avec l'architecte et mettre en œuvre une application finale. Ce scénario est encore plus compliqué dans les entreprises multinationales où des équipes d'experts sont réparties dans le monde entier.
Réduction des coûts
Enfin, l'optimisation des coûts est un objectif important et commun à toutes les applications finales. Souvent, les ingénieurs embarqués n'auront pas le budget pour envisager une conception multi-microcontrôleurs où une seule pile logicielle peut fonctionner sur différents microcontrôleurs avec très peu de coordination. Opter pour une conception de microcontrôleur unique avec une intégration très élevée sera la solution la plus optimale. Cela permet en outre de réduire les coûts grâce à une disposition de PCB compacte et à un nombre réduit de composants externes tels que des oscillateurs à cristal et des composants passifs.
Quels sont les enjeux de développement ?
Pour implémenter des algorithmes sophistiqués et exécuter plusieurs piles logicielles, les concepteurs embarqués choisissent souvent un microcontrôleur plus performant. Cependant, ce n'est peut-être pas la meilleure option en raison des défis associés à l'exécution urgente, au développement, à l'intégration et aux tests de piles multi-logiciels. Un simple planificateur ou système d'exploitation en temps réel (RTOS) peut être utilisé pour planifier et exécuter plusieurs tâches à partir de différentes piles sur un processeur hautes performances en temps partagé. Mais, un planificateur ou un RTOS intègre une surcharge qui consomme de la bande passante CPU, de la mémoire et d'autres ressources du microcontrôleur. La division temporelle augmente également la surcharge de commutation, réduisant l'utilisation efficace du processeur. Le scénario est encore plus compliqué lorsque deux boucles de contrôle complexes et critiques doivent s'exécuter périodiquement dans un intervalle de temps précis qui se chevauche ou lorsque deux fonctions asynchrones critiques pour la sécurité doivent s'exécuter simultanément en temps réel. Dans de tels cas, envisager un microcontrôleur encore plus performant ne répondra pas toujours aux exigences du système. Même si un microcontrôleur monocœur hautes performances dispose d'une bande passante CPU suffisante pour accueillir plusieurs piles logicielles, peut-être en conjonction avec un RTOS, il existe de nombreuses autres complications de conception à prendre en compte. Le développement, l'intégration et le test de plusieurs piles logicielles nécessitent une coordination considérable entre les experts en la matière. Cela nécessite de concevoir une architecture logicielle modulaire et compatible qui partage dynamiquement des ressources et échange des informations. Les complications sont encore accrues s'il existe des piles héritées sans architecture prise en charge.

  • Les piles héritées peuvent avoir différentes architectures en fonction du mode d'interrogation ou du mode d'interruption
  • Les piles héritées peuvent utiliser les mêmes ressources de microcontrôleur qui doivent maintenant être partagées sans conflits pour éviter les risques tels que les conditions de concurrence et les impasses
  • Les piles peuvent avoir plusieurs variables globales communes et des fonctions portant les mêmes noms.
  • Chaque pile peut fonctionner parfaitement lorsqu'elle est exécutée individuellement, mais peut échouer dans l'intégration. Le débogage d'une telle solution intégrée sera un cauchemar augmentant le temps de développement. Une pile autonome prête à l'emploi ne permet pas toujours de réduire le temps de développement lorsqu'elle est implémentée sur un microcontrôleur monocœur. Tous ces défis présentent un risque de développement important et augmentent les délais de mise sur le marché.

Pilote double cœur
Un pilote double cœur permet d'améliorer l'efficacité, de simplifier les efforts de développement et de réduire les coûts avec les avantages suivants.

  • Il offre des performances supérieures à celles d'un contrôleur monocœur similaire fonctionnant à deux fois la vitesse et est idéal pour les applications où deux fonctions critiques ou plus sont présentes • Simplifie le développement logiciel avec deux cœurs indépendants qui permettent : o Le développement logiciel géographiquement dispersé. o Intégration transparente avec très peu de coordination. o Personnalisation facile des fonctionnalités sur plusieurs variantes d'une gamme de produits

Pilote Dual Core - Meilleures performances
Un pilote double cœur facilite une meilleure intégration logicielle en permettant à différentes fonctions de s'exécuter sur deux cœurs distincts. Il est particulièrement utile si une application nécessite d'exécuter deux fonctions critiques périodiquement à un instant précis ou en réponse à des événements asynchrones. Chaque fonction critique s'exécutant sur deux cœurs indépendants différents, il n'y aura pas de conflit entre les fonctions. Cela améliore l'utilisation globale du processeur en raison de la réduction ou de l'absence de pertes de commutation entre les fonctions.
De nombreux pilotes double cœur sont livrés avec des ressources dédiées qui réduisent encore les pertes de commutation et d'arbitrage. Certains des contrôleurs double cœur disposent également d'une PRAM dédiée rapide (Program-RAM) couplée à l'un des cœurs, généralement le cœur esclave, améliorant encore les performances. Par conséquent, un pilote double cœur offre des performances supérieures à celles d'un pilote monocœur similaire qui s'exécute deux fois plus vite.
Pilote Dual Core - Développement simplifié
De nombreux pilotes double cœur offrent une mémoire dédiée, des périphériques et une prise en charge du débogage avec chaque cœur. Un schéma de gestion de ressources flexible permet en outre l'allocation de ressources partagées à l'un quelconque des cœurs sur la base des exigences d'une application. Cette architecture de microcontrôleur permet un développement logiciel indépendant avec une coordination minimale entre les experts du domaine et facilite l'intégration. Un contrôleur double cœur simplifie particulièrement l'intégration de deux piles logicielles basées sur des architectures différentes ou nécessitant des ressources de microcontrôleur similaires, qui peuvent désormais fonctionner sur deux cœurs distincts. Cela revient à développer des piles pour s'exécuter sur deux contrôleurs différents, mais avec les avantages d'une amélioration des performances, d'une utilisation optimale des ressources et d'un coût réduit. Cela élimine toutes les complications associées à l'intégration de la pile, au partage des ressources en temps partagé et aux conditions de compromis associées. Un pilote double cœur permet également un débogage post-intégration facile, car chaque cœur est livré avec ses propres interfaces de débogage. En raison des dépendances minimisées entre les piles, le débogage est extrêmement simplifié pour isoler les problèmes et les corriger. En offrant autant d'avantages, un pilote double cœur réduit considérablement les risques de développement et les délais de mise sur le marché. Pour ajouter à la liste des avantages, un pilote double cœur permet une personnalisation facile sans modifier les fonctionnalités de base. En concevant les fonctionnalités de base pour qu'elles s'exécutent sur un noyau, les fonctionnalités personnalisées peuvent être implémentées sur un autre noyau. Toutes ces offres de pilotes double cœur simplifient la conception de logiciels, même lorsque plusieurs équipes sont impliquées à travers le monde, et permettent une intégration transparente avec des efforts de coordination très minimes.

Contrôleur Dual Core – Réduction des coûts
En offrant des performances supérieures, un contrôleur double cœur permet à un concepteur embarqué d'exécuter des applications complexes à l'aide d'un seul microcontrôleur. En simplifiant le développement, un pilote double cœur réduit considérablement le temps et les risques de conception et permet des conceptions compétitives avec un coût et un délai de mise sur le marché réduits. Pour obtenir à peu près tous les avantages ci-dessus d'un pilote double cœur, une petite expérience a été réalisée. Dans cette démo, l'un des noyaux (généralement le noyau esclave) implémente le contrôle moteur qui exécute l'algorithme FOC pour contrôler un moteur BLDC.
Pour fournir une interface utilisateur graphique, l'autre noyau (le noyau maître) exécute une pile graphique pour interfacer un écran OLED et implémente la fonction système pour interfacer le potentiomètre et les boutons qui contrôlent la vitesse et l'état du moteur. Pour démontrer la simplicité de conception offerte par un appareil à double cœur, la pile graphique et le logiciel de contrôle du moteur ont été développés par deux équipes différentes géographiquement séparées. Avec la flexibilité de maintenir une architecture logicielle distincte, très peu de coordination était nécessaire entre les deux équipes. Une équipe expérimentée dans le domaine du contrôle moteur pourrait rapidement implémenter l'algorithme FOC pour contrôler un moteur BLDC. L'autre équipe ayant de l'expérience dans le développement d'interfaces graphiques, les deux équipes ont pu tirer parti de leur expertise dans leurs domaines respectifs et terminer rapidement le projet. Une coordination minimale était nécessaire pour établir un accord qui transmettrait l'état du bouton et du potentiomètre entre les deux cœurs.
Dans le cadre d'une expérience élargie, les deux équipes ont utilisé des bibliothèques de logiciels déjà disponibles pour implémenter le contrôle moteur et l'interface graphique. Cela a abouti à l'achèvement du projet en très peu de temps avec très peu d'efforts consacrés à l'intégration de deux piles héritées différentes. En raison des hautes performances du cœur, il y avait encore beaucoup de bande passante CPU disponible sur les deux cœurs. Pour repousser les limites, une interface d'affichage OLED a également été intégrée au noyau esclave pour afficher les paramètres dynamiques du moteur sans affecter les performances du moteur. Un exemple de contrôleur double cœur qui offre tous ces avantages est le dernier contrôleur de signal numérique (DSC) double cœur dsPIC33CH128MP508 de Microchip. Le dsPIC33CH double cœur offre des performances élevées avec une mémoire dédiée et des périphériques spécifiques à l'application, ce qui le rend idéal pour les applications embarquées hautes performances, le contrôle moteur et la conversion de puissance numérique. Le double cœur de cette famille permet aux concepteurs de développer séparément des micrologiciels pour différentes fonctions système, puis de les assembler de manière transparente sans que des blocs de code n'interfèrent les uns avec les autres.