Brevet FR3150884A1 — publié le 20250110

L’invention concerne un procédé de transmission de données de consigne lumineuse mis en œuvre dans un module de commande comprenant au moins une interface Serial Peripheral Interface, SPI, apte à transmettre une trame SPI via un port de transmission raccordé à un module lumineux comprenant une source de lumière pixellisée, le procédé comprenant l’obtention (601) d’un premier ensemble de données de consigne lumineuse et l’adaptation (602) d’une trame de données SPI, la trame de données SPI adaptée comprenant un nombre de bits conforme au protocole SPI, comprenant le premier ensemble de données, et étant apte à être reçue et décodée par un port de réception d’une interface Universal Asynchronous Receiver Transmitter, UART. La trame de données SPI adaptée est transmise (603) par le port de transmission raccordé au module lumineux FIG. 6 Transmission de données de consigne vers un module lumineux La présente invention se rapporte au domaine du contrôle d’un module lumineux comprenant une source de lumière pixellisée, notamment pour véhicule automobile. Il est connu d’utiliser des sources de lumière pixellisées pour remplir de nombreuses fonctions lumineuses, en particulier pour des fonctions d’affichage ou des fonctions d’éclairage, notamment pour véhicule automobile. On entend par « véhicule », tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un vélo, un robot de stockage, etc. Les sources de lumière pixellisées comprennent un ensemble d’émetteurs lumineux élémentaires qui sont pilotables individuellement. Le pilotage est assuré par une unité de pilotage intégrée dans le module lumineux. Un tel module de pilotage reçoit des données de consigne depuis un module de commande en charge de déterminer les images, ou trames lumineuses ou encore photométries, à afficher ou à projeter par le module lumineux, et à transmettre des données de consigne à l’unité de pilotage de manière à réaliser de telles images. A cet effet, les données de consigne peuvent être transmises par une jonction filaire entre le module de commande et le module lumineux. Plusieurs protocoles de communication peuvent être prévus pour la communication des données de consigne. Un protocole UART, pour « Universal Asynchronous Receiver/Transmitter », est généralement privilégié pour une telle communication, car il implique des interfaces UART qui sont peu coûteuses, avec notamment un seul canal de transmission de données de consigne d’une entité maître à une entité esclave. Afin de réaliser des fonctions lumineuses de plus en plus complexes, avec une résolution de plus en plus élevée, les sources de lumière pixellisées comprennent de plus en plus d’émetteurs lumineux élémentaires. C’est le cas pour certaines sources de lumière pixellisées qui sont dites monolithiques en ce qu’elles comprennent des éléments électroluminescents pilotables individuellement et épitaxiés sur un substrat commun. De telles sources de lumière pixellisées monolithiques peuvent comprendre plusieurs milliers d’éléments électroluminescents pilotables individuellement. C’est également le cas pour des sources de lumière pixellisées comprenant des éléments à électroluminescence sous forme d'éléments discrets, c’est-à-dire distincts physiquement les uns des autres, qui peuvent comprendre plusieurs dizaines voire plusieurs centaines d’éléments électroluminescents. En outre, des fonctions lumineuses peuvent désormais requérir une fréquence de plusieurs dizaines d’images par seconde, voire d’une centaine d’images par seconde. Une telle fréquence et un nombre élevé de pixels des sources de lumière imposent des débits de plus en plus élevés au niveau de la communication des données de consigne, notamment de l’ordre de plusieurs dizaines de mégabits par seconde. L’interface UART de la plupart des modules de commande est incapable d’atteindre de tels débits, si bien que l’interface UART ne peut être utilisée pour le contrôle du module lumineux. Il serait toutefois souhaitable de conserver les avantages précités du protocole UART. Il existe ainsi un besoin de permettre, à moindre coûts, la transmission de données de consigne à un débit élevé vers un module lumineux comprenant une source de lumière pixellisée, notamment avec un grand nombre de pixels. A cet effet un premier aspect de l’invention concerne un procédé de transmission de données de consigne lumineuse mis en œuvre dans un module de commande comprenant au moins une interface Serial Peripheral Interface, SPI, apte à transmettre une trame SPI via un port de transmission raccordé à un module lumineux comprenant une source de lumière pixellisée, le procédé comprenant les étapes suivantes : - obtention d’un premier ensemble de données de consigne lumineuse ; - adaptation d’une trame de données SPI, la trame de données SPI adaptée comprenant un nombre de bits conforme au protocole SPI, comprenant le premier ensemble de données, et étant apte à être reçue et décodée par un port de réception d’une interface Universal Asynchronous Receiver Transmitter, UART ; - transmission de la trame de données SPI adaptée par le port de transmission raccordé au module lumineux. Ainsi, la présente invention propose d’émuler une trame UART sur une interface SPI d’un module de commande. L’interface SPI de la plupart des modules de commande permet des débits de données élevés, ce qui permet de commander un module lumineux avec une source de lumière pixellisée ayant un grand nombre de pixels, à une fréquence élevée. En outre, il est permis que le module lumineux reçoive les données de consigne via une interface UART, ce qui limite les coûts associés au système de transmission. Un seul câble de transmission de données peut notamment être prévu entre le module de commande et le module lumineux. Selon des modes de réalisation, la trame de données SPI adaptée peut comprendre une première partie ayant un premier nombre de bits conforme au protocole UART, et une deuxième partie comprenant un deuxième nombre de bits de remplissage, et une somme du premier nombre de bits et du deuxième nombre de bits peut être conforme au protocole SPI. Les bits de remplissage ne sont pas détectés par le module lumineux, ce qui permet de rendre l’émulation transparente pour le module lumineux. En outre, un tel format induit un « overhead », ou une perte, au moins correspondant aux bits de remplissage (et à des bits de début de trame et de fin de trame lorsqu’ils sont présents). Toutefois, en pratique, une telle perte est négligeable comparativement aux gains en débit permis par l’invention. En complément, la première partie peut comprendre au moins le premier ensemble de données de consigne lumineuse, un bit de début de trame et un ou deux bits d’arrêt. La première partie correspond ainsi à une trame UART et est interprétée et décodée comme telle par le module lumineux recevant la trame SPI adaptée. Selon des modes de réalisation, le premier ensemble de données peut comprendre entre 6 et 10 bits de données de consigne lumineuse, notamment 8 bits de données de consigne lumineuse. Il est ainsi rendu possible de transmettre au moins 6 bits de données de consigne dans chaque trame SPI adaptée. En complément, la trame SPI adaptée peut comprendre 16 bits, la première partie comprenant 12 bits et la deuxième partie comprenant 4 bits de remplissage. En pratique, une telle adaptation de trame SPI permet un overhead faible comparativement au gain en débit occasionné par une transmission sur une interface SPI plutôt que sur une interface UART. Selon des modes de réalisation, le premier ensemble peut comprendre les données de consigne lumineuse d’un pixel de la source de lumière pixellisée du module lumineux, le module de commande peut déterminer un deuxième ensemble comprenant les données de consigne lumineuse d’une trame lumineuse pour tous les pixels de la source de lumière pixellisée, et le premier ensemble peut être obtenu parmi le deuxième ensemble. Ainsi, chaque trame SPI adaptée comprend les données de consigne d’un pixel donné de la source de lumière pixellisée, et la construction de la trame SPI adaptée et sa transmission sont ainsi facilitées. En complément, les données de consigne du deuxième ensemble peuvent comprendre un nombre de bits au moins égal au nombre de bits du premier ensemble, multiplié par le nombre de pixels de la source de lumière pixellisée du module lumineux. Ainsi, l’invention est adaptable à n’importe quel nombre de pixels d’une source de lumière pixellisée, y compris pour des sources de lumière comprenant un grand nombre de pixels, par exemple plus de 1000 voire plus de 10 000 pixels. Selon des modes de réalisation, le procédé peut comprendre en outre une configuration d’une première vitesse d’horloge de l’interface SPI à une valeur comprise entre 90 % et 110 % d’une deuxième vitesse d’horloge d’une interface UART du module lumineux. Ainsi, le port d’horloge de l’interface SPI du module de commande peut être déconnecté, tout en permettant une synchronisation approximative des horloges des interfaces SPI et UART. Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l’invention concerne un module de commande comprenant au moins une interface Serial Peripheral Interface, SPI, apte à transmettre une trame SPI via un port de transmission raccordé à un module lumineux comprenant une source de lumière pixellisée, le module comprenant en outre : - une unité de calcul apte à obtenir d’un premier ensemble de données de consigne lumineuse ; et - un module d’adaptation d’une trame de données SPI, la trame de données SPI adaptée comprenant un nombre de bits conforme au protocole SPI, comprenant le premier ensemble de données, et étant apte à être reçue et décodée par un port de réception d’une interface Universal Asynchronous Receiver Transmitter, UART. Le port de transmission est apte à transmettre la trame SPI adaptée au module lumineux. Un quatrième aspect de l’invention concerne un système de transmission de données de consigne lumineuse comprenant le module de commande selon le troisième aspect de l’invention, et comprenant un module lumineux comprenant : - une interface UART, avec un port de réception relié au port de transmission de l’interface SPI du module de commande ; - une source de lumière pixellisée ; - une unité de pilotage apte à piloter la source de lumière pixellisée en fonction des données de consigne lumineuse reçues dans la trame SPI adaptée. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : illustre un système de transmission de données par le protocole UART selon l’art antérieur; illustre une trame de données conforme au protocole UART, selon l’art antérieur; illustre un système de transmission de données par le protocole SPI, selon l’art antérieur ; illustre un système de transmission de données de consigne pour un module lumineux à source de lumière pixellisée, selon des modes de réalisation de l’invention ; illustre une configuration matérielle d’une interface SPI de module de commande et d’une interface UART 311 d’un module lumineux 311, selon des modes de réalisation de l’invention ; illustre une trame SPI adaptée pour une transmission vers une interface UART, selon des modes de réalisation de l’invention; illustre un procédé de transmission de données de consigne d’un module de commande vers un module lumineux à source de lumière pixellisée, selon des modes de réalisation de l’invention. La description se concentre sur les caractéristiques qui démarquent le système et le module de commande de ceux connus dans l’état de l’art. La illustre un système de transmission de données par le protocole UART, selon l’art antérieur. Le système comprend un dispositif maître 100 et un dispositif esclave 110. Le dispositif maître 100 comprend une interface adaptée au protocole UART comprenant : - un port de transmission 101, apte à transmettre des trames de données conformes au protocole UART ; - un port de réception 102 apte à recevoir des trames de données conformes au protocole UART ; - un port de masse 103 apte à être relié à la masse. Le dispositif esclave 110 comprend une interface adaptée au protocole UART comprenant : - un port de réception 111 apte à recevoir des trames de données conformes au protocole UART ; - un port de transmission 112 apte à transmettre des trames de données conformes au protocole UART ; - un port de masse 113 apte à être relié à la masse. Le port de transmission 101 peut être relié, par voie filaire, au port de réception 111 pour une transmission de trames UART du dispositif maître 100 au dispositif esclave 110. Le port de réception 102 peut être relié, par voie filaire, au port de transmission 112 pour une transmission de trames UART du dispositif esclave 110 vers le dispositif maître 100. Aucun signal d’horloge n’étant partagé entre le dispositif maître 100 et le dispositif esclave 110, le protocole UART est asynchrone. La présente le format d’une trame de données 120 conforme au protocole UART, ou trame UART ci-après, selon l’art antérieur. La trame UART 120 comprend : - 1 bit de départ 121 ; - 5 à 9 bits de données 122 ; - 0 à 1 bit de parité 123. Autrement dit, le bit de parité 123 est optionnel. Un tel bit de parité 123 permet de détecter une erreur dans une trame reçue, de manière bien connue ; - 1 à 2 bit d’arrêt ou de stop 124. Ainsi, une trame UART comprend entre 7 et 13 bits. Sur la , les bits de la trame UART 120 sont parcourus de la gauche vers la droite, soit à partir du bit le plus significatif, ou MSB en anglais pour « Most Significant Bit ». En variante, la trame UART 120 peut être inversée pour une lecture de la droite vers la gauche, soit en partant du bit le moins significatif, ou LSB en anglais, pour « Least Significant Bit ». La illustre un système de transmission de données par le protocole SPI, selon l’art antérieur. Le protocole SPI se réfère à « Serial Peripheral Interface » en anglais, et est mis en œuvre entre un dispositif maître 200 et au moins un dispositif esclave. Sur la , un système de transmission avec trois dispositifs esclaves 210.1, 210.2 et 210.3 est représenté, à titre illustratif uniquement. Le dispositif maître 200 comprend une interface adaptée au protocole SPI et comprenant : - un port de signal d’horloge 201 apte à transmettre un signal d’horloge du dispositif maître 200 vers les dispositifs esclaves 210.1-210.3 ; - un port de transmission 202, appelé MOSI pour « Master Output Slave Input » apte à transmettre des données du dispositif maître vers les dispositifs esclaves 210.1-210.3 ; - un port de réception 203, appelé MISO pour « Master Input Slave Output » apte à recevoir des données depuis les dispositifs esclaves 210.1-210.3 ; - trois ports de sélection d’esclave 204, 205 et 206 aptes à transmettre un signal de sélection d’esclave aux dispositifs esclaves 210.1-210.3. Du fait de l’échange d’un signal d’horloge, les échanges de données entre le dispositif maître 200 et les dispositifs esclaves 210.1-210.3 sont synchrones. Chacun des dispositifs esclaves 210.1, 210.2 et 210.3 comprend une interface comprenant les ports suivants, décrits pour le premier dispositif esclave 210.1 à titre illustratif : - un port de réception de signal d’horloge 211.1 apte à recevoir le signal d’horloge depuis le port de signal d’horloge 201 décrit précédemment. A cet effet, le port de réception de signal d’horloge 211.1 est relié par voie filaire au port de signal d’horloge 201. Il en va de même des ports de réception de signal d’horloge des autres dispositifs esclaves, reliés par voie filaire au port de signal d’horloge 201 ; - un port de réception 212.1, appelé MOSI, et relié, par voie filaire, au port MOSI 202 du dispositif maître 200. Chaque port de réception MOSI des autres dispositifs esclaves 210.2 et 210.3 est également relié par voie filaire au port MOSI 202 du dispositif maître 200 ; - un port de transmission 213.1, aussi appelé MISO, et relié, par voie filaire, au port MISO 203 du dispositif maître 200. Chaque port de transmission MISO des autres dispositifs esclaves 210.2 et 210.3 est également relié par voie filaire au port MISO 203 du dispositif maître 200 ; - un port de réception d’un signal de sélection 214.1 apte à recevoir un signal de sélection depuis le port de sélection d’esclave 204 du dispositif maître, par voie filaire. Le port de réception de signal de sélection du deuxième dispositif esclave 210.1 est relié par voie filaire au port de sélection d’esclave 205 et le port de réception de signal de sélection du troisième dispositif esclave 210.3 est relié par voie filaire au port de sélection d’esclave 206. Une trame de données conforme au protocole SPI, appelée trame SPI dans ce qui suit : - comprend un nombre de bits de données configurables, par exemple compris entre 2 et 32 bits sur certains microprocesseurs utilisés comme dispositif maître 200 ; - comprend un bit de parité optionnel, donc entre 0 et 1 bit de parité ; - comprend une polarité d’horloge configurable, entre les valeurs 0 et 1 par exemple ; - comprend une polarité de phase configurable, entre les valeurs 0 et 1 par exemple ; - permet de configurer une direction de transmission de la trame, indiquant si le LSB est transmis en premier ou si le MSB est transmis en premier. La plupart des microprocesseurs comprenant une interface SPI sont capables de transmettre des données à des débits élevés, notamment à des débits de plusieurs dizaines de mégabits par seconde, du fait de la synchronisation des horloges. La présente un système de transmission de données de consigne lumineuse selon des modes de réalisation de l’invention. Le système comprend un module de commande 300, ayant le rôle de dispositif maître, ainsi qu’un module lumineux 310, ayant le rôle de dispositif esclave. Le système peut ainsi être intégré dans un véhicule automobile, le module lumineux 310 remplissant une fonction lumineuse du véhicule, telle que : - une fonction d’affichage, par exemple à l’intérieur du véhicule, ou à des fins de signalisation à l’extérieur du véhicule ; - une fonction d’éclairage, telle qu’une fonction de feu de croisement LB, pour « Low Beam » en anglais, ou feu de route HB, pour « High Beam » en anglais, à l’extérieur du véhicule, le module lumineux 310 pouvant être intégré dans un dispositif d’éclairage à l’avant du véhicule. Dans ce qui suit, il est considéré à titre illustratif que le module lumineux 310 est intégré dans un dispositif d’éclairage de véhicule automobile. Le module lumineux 310 comprend une source de lumière pixellisée 313. Dans le présent document, on entend par source de lumière pixellisée 313 une source de lumière comprenant une pluralité de n émetteurs lumineux élémentaires 314 qui sont pilotables individuellement, n'étant un entier supérieur ou égal à 2, de préférence supérieur à 10, voire supérieur à 100, ou encore supérieur à 1000 ou 10 000. Les n émetteurs lumineux élémentaires 314 peuvent être agencés en au moins deux rangées et/ou au moins deux colonnes. Par exemple, les émetteurs lumineux élémentaires 134 peuvent être disposés en matrice avec au moins deux rangées et/ou au moins deux colonnes. Dans l’exemple de la , une source de lumière pixellisée comprend 6 colonnes et 6 lignes d’émetteurs lumineux élémentaires 134 formant 36 pixels. Ainsi, plus n est grand, plus la résolution de l’image affichée ou projetée par le module lumineux 310 est élevée. Les émetteurs lumineux élémentaires 314 peuvent être des éléments à électroluminescence, aussi appelés éléments électroluminescents dans ce qui suit. Dans ce cas, les éléments à électroluminescence peuvent présenter sous forme d'éléments discrets, c’est-à-dire distincts physiquement des uns des autres. Des exemples d’éléments à électroluminescence de ce type incluent la diode électroluminescente ou LED (acronyme anglais pour « Light Emitting Diode »), la diode électroluminescente organique ou OLED (acronyme anglais pour « Organic Light-Emitting Diode »), ou la diode électroluminescente polymérique ou PLED (acronyme anglais pour « Polymer Light- Emitting Diode »). De telles LED peuvent avoir au moins une dimension de taille millimétrique, voire de taille micrométrique. Par exemple, des LEDs de type microLED ou miniLED ont des dimensions toutes inférieures à 1mm, voire inférieures à 200 micromètres. De manière alternative, les émetteurs lumineux élémentaires 314 à électroluminescence, sont crûs depuis un substrat commun et sont connectés électriquement de manière à être pilotables individuellement. Le substrat commun peut comprendre au moins une couche semi-conductrice comportant une zone active permettant de générer la lumière correspondante par électroluminescence. Le substrat peut comporter un ou plusieurs autres matériaux, par exemple non semi-conducteurs. Ainsi chaque émetteur élémentaire ou groupe d’émetteurs élémentaires peut former un pixel lumineux et peut émettre de la lumière lorsque son ou leur matériau est alimenté en électricité. La source de lumière ainsi configurée est appelée source de lumière monolithique et présente l’avantage d’avoir des émetteurs élémentaires très proches les uns des autres par rapport aux diodes électroluminescentes classiques. Compte tenu du progrès dans le développement des sources de lumière pixellisées jusqu’à ce jour, une source de lumière pixellisée est qualifiée de haute résolution lorsque le nombre d’émetteurs lumineux élémentaires est au moins égal à 20. Cette définition est basée sur le document ci-dessous qui retrace l’évolution des sources de lumière pixellisée à haute résolution: Wang Li ping ET AL: “High-Resolution Pixel LED Headlamps: Functional Requirement Analysis and Research Progress”, Applied Sciences, vol.11, no.8, 9 April 2021 (2021-04-09), page 3368, XP055916448, DOI: 10.3390/app 11083368. Dans un exemple de source de lumière pixellisée monolithique à haute résolution, le nombre d’émetteurs lumineux élémentaires peut être de l’ordre de 20 000 émetteurs. Une source dite « monolithique » peut présenter une densité d’éléments lumineux particulièrement élevée, ce qui la rend particulièrement intéressante pour une pluralité d’applications. Une source monolithique implique une pluralité d’éléments semi-conducteurs électroluminescents à dimensions submillimétriques, épitaxiés directement sur un substrat commun, le substrat étant généralement formé de silicium. A l’opposé de matrices de LEDs conventionnelles, dans lesquelles chaque source lumineuse élémentaire est un composant électronique produit de manière individuelle et monté sur un substrat tel qu’un circuit imprimé, PCB, une source de lumière monolithique est à considérer comme un composant électronique unique, lors de la production duquel plusieurs plages de jonctions semi-conductrices électroluminescentes sont générées sur un substrat commun, sous forme d’une matrice. Cette technique de production permet de réaliser des plages électroluminescentes, faisant chacune office de source lumineuse élémentaire, très rapprochées les unes des autres. Les interstices entre les sources élémentaires peuvent présenter des dimensions submillimétriques. Un avantage de cette technique de production est le niveau élevé de la densité de pixels qui peut en résulter sur un substrat unique. Dans ce qui suit, l’exemple d’éléments lumineux à électroluminescence est considéré, à titre illustratif. Les éléments électroluminescents 314 pilotables individuellement sont également appelés pixels dans ce qui suit. Le module lumineux 310 comprend en outre une unité de pilotage 312 de la source de lumière pixellisée 313, apte à piloter individuellement les pixels de la source de lumière pixellisée en fonction de données de consigne lumineuse. L’unité de pilotage 312 peut être un circuit intégré permettant le contrôle de l’alimentation électrique des pixels 314 de la source de lumière pixellisée 313. L’unité de pilotage 312 peut être montée sur un même support que la source lumière pixellisée 313. L’unité de pilotage 312 peut en outre être partiellement ou totalement intégrée dans le même substrat que la source de lumière pixellisée 313. L’unité de pilotage 312 peut être un circuit intégré de type ASIC, pour « Application Specific Integrated Circuit » en anglais. Lorsque la source de lumière 313 comprend des LEDs 314 discrètes, par exemple de type miniLED ou microLED, l’unité de pilotage 312 peut : - piloter les LEDs 314 via des matrices actives : dans ce cas une source de courant individuelle est prévue pour chaque LED 314, et des commandes d’activation/désactivation des sources de courant individuelles sont envoyées par l’unité de pilotage 312 en fonction des données de consigne reçues ; - piloter les LEDs 314 via des matrices passives : dans ce cas, une source de courant individuelle peut être prévue pour chaque ligne et une source de tension commune peut être prévue pour chaque colonne. Les LEDs sont alternativement activées en contrôlant sélectivement les sources de courant et de tension en fonction de données de consigne reçues. Des éléments de pilotage 312 en matrices actives et en matrices passives sont bien connus et ne sont pas détaillés davantage dans la présente description. Dans le cas d’un module de projection 310 intégré dans un dispositif d’éclairage et réalisant donc au moins une fonction d’éclairage, le module de projection 310 peut comprendre en outre un système optique de projection apte à projeter les rayons lumineux issues de la source de lumière pixellisée 313, le système optique de projection n’étant pas représenté sur la . Le module de commande 300 peut comprendre une unité de calcul 301 de données de consigne. Les données de consigne peuvent être déterminées par l’unité 301 en fonction de commandes reçues depuis un module de contrôle central du véhicule, non représenté sur la , pouvant être un module de contrôle de type BCM pour « Body Controller Module » en anglais. De manière alternative, l’unité 301 détermine les données de consigne en fonction d’informations issues d’autres modules, issues de capteurs et/ou issues d’interfaces de communication. De manière alternative, les données de consigne peuvent être prédéterminées et stockées dans une mémoire 304 du module de commande 300. Les commandes reçues peuvent indiquer des trames lumineuses, c’est-à-dire des répartitions matricielles d’intensité lumineuse, qui peuvent être : - une série de photométries d’éclairage reçues à intervalles temporels donnés, pour projection des photométrie d’éclairage ; - une série de trames vidéo pour affichage des trames vidéos. On distingue les trames lumineuses qui correspondent à des images ou répartitions matricielles d’intensité lumineuse, des trames de données selon les protocoles UART et SPI, qui sont des ensembles de bits de taille donnée. Dans ce qui suit, il est considéré à titre illustratif, que le module de commande 300 est apte à recevoir des commandes depuis un module de contrôle de type BCM, et que l’unité de calcul 301 est apte à déterminer des données de consigne sur la base des commandes reçues. Le module de commande 300 peut être intégré n’importe où dans le véhicule automobile, entre le module de contrôle BCM et le module lumineux 310. Par exemple, le module de commande 300 peut être intégré dans le dispositif d’éclairage, avec le module d’éclairage 310, ce qui présente l’avantage de limiter les interférences sur le câble transportant les données de consigne entre le module de commande 300 et le module lumineux 310. En variante, le module de commande 300 peut être en dehors du dispositif d’éclairage, à proximité du module de contrôle BCM. Le module de commande 300 comprend une interface SPI 303 conforme à l’interface 200 représentée sur la , et apte à transmettre des trames SPI. Dans l’art antérieur, une unité de calcul est apte à intégrer des données de consigne dans des trames SPI pour transmission à une interface SPI 303 esclave. Toutefois, une telle trame SPI, selon l’art antérieur, n’est pas interprétable par une interface UART telle que l’interface UART 311 du module lumineux 310. L’art antérieur exige ainsi d’équiper le module lumineux 310 d’une interface SPI coûteuse pour permettre le transfert de données de consigne à un débit élevé. Selon l’invention, le module de commande 300 comprend un module d’adaptation 302, apte à recevoir des données de consigne, sous la forme d’une série de bits de consigne, et apte à générer une trame SPI adaptée incluant des données de consigne, la trame SPI adaptée apte à être reçue par l’interface UART 311 du module lumineux 310. En outre, l’interface SPI 303 du module de commande est configurée et câblée de manière à être reliée à l’interface UART 311 du module lumineux 310. Il est ainsi rendu possible de transmettre des données de consigne à un débit élevé par un module de commande 300, tout en permettant une réception des données de consigne par un module lumineux 310 équipé d’une interface UART peu coûteuse. Le module d’adaptation 302 peut être un module matériel en interception entre l’unité de calcul 301 et l’interface SPI 303. Dans ce cas, l’unité de calcul 301 est apte à transmettre au module d’adaptation 302 des données de consigne, sous la forme d’une série de bits de données de consigne, et une trame SPI est générée par le module d’adaptation 302. En variante, le module d’adaptation 302 est un module logiciel qui peut être intégré dans l’unité de calcul 301. Dans ce cas, l’unité de calcul transmet une trame SPI adaptée par le module d’adaptation 302, à l’interface SPI 303. L’adaptation de la trame SPI par le module d’adaptation 302 permet l’émulation d’une trame UART sur une interface SPI, et une telle adaptation sera détaillée lors de la description de la . Le module de commande 300 peut être un microprocesseur, l’unité 301, le module d’adaptation 302 et l’interface SPI 303 étant intégrés dans le microprocesseur. Le module de commande 300 peut également comprendre une interface UART, non représentée sur la . Toutefois, dans un tel cas, l’interface UART n’est pas reliée au module lumineux 310, puisque la plupart des microprocesseurs comprenant une telle interface UART sont incapables de transmettre des données de consigne à des débits élevés, supérieurs notamment à un mégaoctet par seconde. La présente la configuration matérielle de l’interface SPI 303 du module de commande 300 et de l’interface UART 311 du module lumineux 310, permettant une émulation d’une trame UART, qui est une trame SPI adaptée selon l’invention, sur l’interface SPI. On entend par configuration matérielle le câblage et la configuration des différents ports des interfaces SPI 303 et UART 311. Comme indiqué sur la , l’interface SPI 303 est configurée matériellement de la manière suivante : - un port MOSI 401 est relié à un port de réception 411 de l’interface UART, par un câble 420 apte à transporter les trames SPI adaptées du module de commande 300 vers le module lumineux 310 ; - un port MISO 402 est déconnecté, c’est-à-dire qui n’est relié à aucun autre port ; - un port d’horloge 403 est déconnecté, c’est-à-dire qui n’est relié à aucun autre port ; - un port de sélection d’esclave 404 est relié à la masse, par exemple câblé sur un port de masse 405. Côté récepteur, l’interface UART 311 du module lumineux 310 est configurée matériellement de la manière suivante : - comme indiqué ci-dessus, le port de réception 411 est relié au port MOSI 401 de l’interface SPI 303 du module de commande 300 ; - un port de transmission 412 qui est déconnecté, c’est-à-dire qui n’est relié à aucun autre port ; - un port de masse 413 relié à la masse. La illustre une trame SPI adaptée 510 par un module de commande 300 selon des modes de réalisation de l’invention. Un ensemble 500 de données de consigne est obtenu par l’unité de calcul 301 décrite précédemment. L’ensemble 500 peut par exemple comprendre 8 bits de données de consigne. L’ensemble 500 est intégré par le module d’adaptation 302 dans une trame SPI adaptée 510 qui peut être obtenue par la configuration suivante : - la direction de transmission est configurée à partir du LSB par exemple ; - la taille de la trame SPI adaptée est configurée de manière à avoir la taille d’une trame UART, lorsque des bits de remplissage 504 sont ignorés. Par exemple, la trame SPI adaptée peut comprendre 16 bits, dont une première partie de 12 bits émulant une trame UART, et une deuxième partie comprenant 4 bits de remplissage 504 ; - la première partie émulant une trame UART peut comprendre un bit de début 501, l’ensemble 500 de bits de données, comprenant 8 bits dans cet exemple, un bit de parité 502 et deux bits de fin ou d’arrêt 503. Une répartition différente peut être prévue selon l’invention, la personne du métier pouvant déterminer la structure de la trame adaptée 510 en fonction de la taille de l’ensemble 500 de données de consigne transmis à chaque trame, et en fonction du format d’une trame UART. La illustre un procédé de transmission de données de consigne d’un module de commande vers un module lumineux, selon des modes de réalisation de l’invention. Le procédé peut être mis en œuvre dans le module de commande 300 décrit précédemment. A une étape 600, une configuration matérielle du module de commande 300 est mise en œuvre, notamment une configuration matérielle de l’interface SPI 303. La configuration matérielle peut comprendre, conformément à ce qui a été précédemment décrit, la connexion d’un port MOSI 401 de l’interface SPI 303 à l’interface de réception 411 de l’interface UART 311 du module lumineux 310. Les ports 402 et 403 ne sont connectés à aucun autre port lors de la configuration matérielle et le port de sélection d’esclave 404 est relié à la masse. En outre, l’étape 600 peut comprendre tout ou partie des éléments de la configuration suivante du protocole SPI du dispositif maître 200 : - fixation d’une direction de transmission de la trame SPI partant du LSB, de manière à conserver un ordre d’envoi des bits des données de consigne ; - absence de bit de parité, de manière à ne pas introduire de bit supplémentaire qui serait interprété (de manière erronée) à la réception ; - fixation des horloges à une polarité haute, afin de ne pas inverser le signal transmis ; - synchronisation de l’horloge SPI à une valeur proche de l’horloge du dispositif esclave 210, par exemple comprise entre 90 % et 110 % de la fréquence de l’horloge du dispositif esclave 210. A une étape 601, un premier ensemble de données de consigne est obtenu par le module de commande 300, par exemple par l’unité de calcul 301. Comme décrit précédemment, dans certains modes de réalisation, l’unité de calcul 301 peut déterminer les données de consigne en fonction d’une commande reçue depuis un module de contrôle BCM. Aucune restriction n’est attachée aux données de consigne, ni à la quantité de données de consigne du premier ensemble obtenu à l’étape 601. Le premier ensemble peut par exemple être un octet, donc 8 bits, d’un deuxième ensemble plus large de données de consigne correspondant à la consigne d’une trame lumineuse entière. L’octet du premier ensemble peut alors coder la consigne lumineuse d’un pixel donné de la trame lumineuse. On entend par trame lumineuse, comme décrit précédemment, un élément d’une séquence d’éléments formant ensemble une animation lumineuse, pour être affichée ou projetée par le module lumineux. Les données de consigne du deuxième ensemble peuvent ainsi correspondre à des données de consigne d’une image entière, ou trame vidéo, à afficher ou projeter par le module lumineux 310, auquel cas la quantité de données de consigne du deuxième ensemble dépend du nombre de pixels de la source de lumière pixellisée 313, et de la granularité associée à la luminosité de chaque pixel. Afin de permettre une granularité meilleure qu’une granularité binaire « allumé » / « éteint » pour la consigne de chaque pixel, un contrôle en modulation de largeur d’impulsion, ou PWM pour « Pulse Width Modulation » en anglais, peut être mis en œuvre par l’unité de pilotage 312 précédemment décrite. A titre d’exemple, il est considéré une source de lumière pixellisée 313 comprenant 25600 pixels, soit 320 lignes et 80 colonnes de pixels. Dans ce cas, pour chaque trame vidéo, c’est-à-dire pour une consigne permettant au module lumineux 310 d’afficher ou de projeter une image donnée, et en considérant que la consigne de chaque pixel 314 est codée sur un octet, soit 8 bits, l’unité de calcul 301 est apte à déterminer un deuxième ensemble d’au moins 25600 octets. Aucune restriction n’est cependant associée au nombre de bits du premier ensemble codant la consigne lumineuse de chaque pixel 314 de la source de lumière pixellisée 313. La consigne pour chaque trame vidéo, c’est-à-dire le deuxième ensemble, peut comprendre cependant plus de 25600 octets, afin d’ajouter notamment des bits de contrôle, par exemple : - 4 octets pour indiquer le début d’une nouvelle trame vidéo ; - 4 octets de contrôle de redondance cyclique, ou CRC pour « Cyclic Redundancy Check » en anglais. Dans ce cas, le deuxième ensemble comprend 25608 octets de données de consigne. A une étape 602, le module d’adaptation 302 détermine une trame SPI adaptée en fonction des données de consigne du premier ensemble obtenues à l’étape 601. Comme décrit précédemment, la trame SPI adaptée est une trame de données : - adaptée pour être transmise par une interface SPI ; et - adaptée pour être reçue par l’interface UART 311 et interprétée comme une trame UART par le module lumineux 310 comprenant l’interface UART 311. Ainsi, la trame SPI adaptée permet d’émuler une trame UART sur une interface SPI. A une étape 603, la trame SPI adaptée déterminée à l’étape 602 est transmise par le module de commande 300 via l’interface SPI 303, notamment via le port de transmission MOSI 401 précédemment décrit. A une étape 604, le module de commande 300 détermine si le deuxième ensemble comprend un autre premier ensemble de données qui n’a pas encore été transmis. Autrement dit, dans l’exemple considéré ici, le module de commande 300 détermine si au moins un octet de données de consigne du deuxième ensemble codant la trame lumineuse courante, c’est-à-dire la trame lumineuse en cours de transmission, n’a pas été transmis au module lumineux 310. Si le deuxième ensemble comprend au moins un autre premier ensemble qui n’a pas encore été transmis, le procédé de transmission est répété depuis l’étape 601 et ledit autre premier ensemble de données est obtenu à l’étape 601. Une autre trame SPI adaptée est déterminée à l’étape 602 sur la base de l’autre premier ensemble, et l’autre trame SPI adaptée est transmise à l’étape 603. Si le deuxième ensemble ne comprend aucun autre premier ensemble qui n’a pas encore été transmis, c’est-à-dire si les données de consigne du deuxième ensemble ont toutes été transmises au module lumineux 310, le procédé de transmission de données de consigne s’achève à une étape 605. Le procédé de transmission peut toutefois se poursuivre avec la transmission de données de consigne d’un nouveau deuxième ensemble, codant la consigne d’une trame vidéo suivante. Dans ce cas, le procédé est également itéré à partir de l’étape 601, pour le nouveau deuxième ensemble. Lorsque le module d’adaptation 302 est un module logiciel, comme décrit précédemment, les étapes 601 à 604 peuvent être mises en œuvre par exécution d’instructions d’un programme informatique par un processeur du module de commande 300, par exemple par un processeur de l’unité de calcul 301. Le programme informatique peut être stocké dans une mémoire du module de commande 300. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Procédé de transmission de données de consigne lumineuse mis en œuvre dans un module de commande (300) comprenant au moins une interface Serial Peripheral Interface, SPI, apte à transmettre une trame SPI via un port de transmission (401) raccordé à un module lumineux (310) comprenant une source de lumière pixellisée (313), le procédé comprenant les étapes suivantes : - obtention (601) d’un premier ensemble (500) de données de consigne lumineuse ; - adaptation (602) d’une trame de données SPI, la trame de données SPI adaptée (510) comprenant un nombre de bits conforme au protocole SPI, comprenant le premier ensemble de données, et étant apte à être reçue et décodée par un port de réception (411) d’une interface Universal Asynchronous Receiver Transmitter, UART (311) ; - transmission (603) de la trame de données SPI adaptée par le port de transmission raccordé au module lumineux. Procédé selon la revendication 1, dans lequel la trame de données SPI adaptée (510) comprend une première partie (500 ; 501 ; 502 ; 503) ayant un premier nombre de bits conforme au protocole UART, et une deuxième partie (504) comprenant un deuxième nombre de bits de remplissage, dans lequel une somme du premier nombre de bits et du deuxième nombre de bits est conforme au protocole SPI. Procédé selon la revendication 2, dans lequel la première partie (500 ; 501 ; 502 ; 503) comprend au moins le premier ensemble (500) de données de consigne lumineuse, un bit de début de trame (501) et un ou deux bits d’arrêt (503). Procédé selon l’une des revendications précédentes, dans lequel le premier ensemble (500) de données comprend entre 6 et 10 bits de données de consigne lumineuse, par exemple 8 bits de données de consigne lumineuse. Procédé selon la revendication 3 et selon la revendication 4, dans lequel la trame SPI adaptée (510) comprend 16 bits, la première partie (500 ; 501 ; 502 ; 503) comprenant 12 bits et la deuxième partie (504) comprenant 4 bits de remplissage. Procédé selon l’une des revendications précédentes, dans lequel le premier ensemble (500) comprend les données de consigne lumineuse d’un pixel (314) de la source de lumière pixellisée (313) du module lumineux (310), dans lequel le module de commande (300) détermine un deuxième ensemble comprenant les données de consigne lumineuse d’une trame lumineuse pour tous les pixels de la source de lumière pixellisée, et dans lequel le premier ensemble est obtenu parmi le deuxième ensemble. Procédé selon la revendication 6, dans lequel les données de consigne du deuxième ensemble comprennent un nombre de bits au moins égal au nombre de bits du premier ensemble (500), multiplié par le nombre de pixels (314) de la source de lumière pixellisée (313) du module lumineux (310). Procédé selon l’une des revendications précédentes, comprenant en outre une configuration d’une première vitesse d’horloge de l’interface SPI (303) à une valeur comprise entre 90 % et 110 % d’une deuxième vitesse d’horloge d’une interface UART (311) du module lumineux (310). Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. Module de commande comprenant au moins une interface Serial Peripheral Interface (303), SPI, apte à transmettre une trame SPI via un port de transmission (401) raccordé à un module lumineux (310) comprenant une source de lumière pixellisée (313), le module de commande comprenant en outre : - une unité de calcul (301) apte à obtenir d’un premier ensemble (500) de données de consigne lumineuse ; et - un module d’adaptation (302) apte à obtenir une trame de données SPI adaptée (510) comprenant un nombre de bits conforme au protocole SPI, comprenant le premier ensemble de données, et étant apte à être reçue et décodée par un port de réception (411) d’une interface Universal Asynchronous Receiver Transmitter (311), UART ; dans lequel le port de transmission est apte à transmettre la trame SPI adaptée au module lumineux. Système de transmission de données de consigne lumineuse comprenant le module de commande (300) selon la revendication 10, et comprenant un module lumineux (310), le module lumineux comprenant : - une interface UART (311), avec un port de réception (411) relié au port de transmission (401) de l’interface SPI (303) du module de commande (300) ; - une source de lumière pixellisée (313) ; - une unité de pilotage (312) apte à piloter la source de lumière pixellisée en fonction des données de consigne lumineuse reçues dans la trame SPI adaptée (510).