![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/busCAN2.png\")
Chaque n\u0153ud peut \u00eatre connect\u00e9 au bus par l’interm\u00e9diaire d’une paire torsad\u00e9e (blind\u00e9e ou non) (fig. 2). La longueur de cette connexion doit \u00eatre la plus courte possible, au maximum 30 cm. Le bus lui-m\u00eame peut s’\u00e9tendre lin\u00e9airement sur plusieurs dizaines de m\u00e8tres, voire plus. La longueur diminue cependant le d\u00e9bit maximum du bus. Le bus CAN a une topologie lin\u00e9aire. Une topologie en \u00e9toile est \u00e0 proscrire.<\/p>\n\n\n
![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/busCANetNoeuds3.png\")
Si la distance d’un n\u0153ud au bus doit d\u00e9passer 30 cm, il est alors pr\u00e9f\u00e9rable d’adopter une configuration comme celle-ci (fig. 3).<\/p>\n\n\n
![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/busCANetNoeuds02.png\")
La d\u00e9connexion d’un n\u0153ud ne doit jamais interrompre la continuit\u00e9 du bus qui doit pouvoir continuer \u00e0 fonctionner normalement. <\/p>\n\n\n\n
L\u2019information est v\u00e9hicul\u00e9e par le bus CAN sous la forme d\u2019une tension diff\u00e9rentielle entre les deux fils de la paire, nomm\u00e9s CAN_H et CAN_L. Cela assure une excellente immunit\u00e9 face aux perturbations \u00e9lectromagn\u00e9tiques : comme les perturbations touchent les deux fils, la diff\u00e9rence de potentiel entre les fils reste la m\u00eame.<\/p>\n\n\n\n
Les contr\u00f4leurs et leurs r\u00f4les<\/h5>\n\n\n\n
Chaque n\u0153ud d\u2019un bus CAN comporte, en sus des capteurs ou autres actionneurs qui lui sont propres, un microcontr\u00f4leur, un contr\u00f4leur CAN et un transceiver CAN (voir plus loin la figure 5). Les microcontr\u00f4leurs 32 bits r\u00e9cents comme ceux qui \u00e9quipent les cartes Teensy int\u00e8grent un ou plusieurs contr\u00f4leurs CAN. Il faut n\u00e9anmoins leur adjoindre un transceiver pour pouvoir les connecter \u00e0 un bus CAN (voir plus bas). Le microcontr\u00f4leur ATmega328P des cartes Arduino 8 bits comme la carte UNO Rev3 n’int\u00e8gre pas de contr\u00f4leur CAN, il faut donc lui adjoindre un contr\u00f4leur externe ET un transceiver.<\/p>\n\n\n\n
Tous les n\u0153uds connect\u00e9s au bus ont les m\u00eames droits, il n\u2019y a ni ma\u00eetre ni esclave. Le protocole r\u00e9gissant les \u00e9changes de messages est cod\u00e9 \u00ab\u00a0en dur\u00a0\u00bb dans le contr\u00f4leur. Il est bas\u00e9 sur le principe de diffusion g\u00e9n\u00e9rale : lors des transmissions, aucune station n’est adress\u00e9e en particulier.<\/p>\n\n\n\n
Le contenu de chaque message \u00e9mis sur le bus est explicit\u00e9 par un identifiant, le message est re\u00e7u par tous les \u00ababonn\u00e9s\u00bb. Gr\u00e2ce \u00e0 cet identifiant, les n\u0153uds, qui sont en permanence \u00e0 l’\u00e9coute du r\u00e9seau, reconnaissent et traitent les messages qui les concernent, et ignorent simplement les autres. Le bus CAN est donc un bus r\u00e9seau.<\/p>\n\n\n\n
L\u2019identifiant d\u2019un message n\u2019est pas une adresse de destination ni de provenance, mais plut\u00f4t une indication (convenue par le programmeur dans la couche logicielle, au moment de la programmation des n\u0153uds) sur la nature de l\u2019information contenue dans le message.<\/p>\n\n\n\n
Pour \u00e9viter la \u00ab cacophonie \u00bb, un syst\u00e8me d\u2019arbitrage est indispensable. Afin d’\u00eatre trait\u00e9es en temps r\u00e9el, les informations doivent non seulement \u00eatre transmises rapidement (ce qui suppose une voie physique autorisant un fort d\u00e9bit, jusqu’\u00e0 1 Mbit\/s), mais encore l\u2019assignation du bus \u00e0 un n\u0153ud prioritaire doit \u00eatre imm\u00e9diate, si plusieurs stations souhaitent transmettre simultan\u00e9ment des messages.<\/p>\n\n\n\n
L’urgence des informations \u00e9chang\u00e9es sur le bus peut en effet \u00eatre tr\u00e8s diverse : une valeur variant rapidement, comme l’\u00e9tat d’un capteur ou l’asservissement d’un moteur, doit \u00eatre transmise plus fr\u00e9quemment et avec un retard moindre que d’autres valeurs comme la temp\u00e9rature du moteur, qui \u00e9volue lentement. <\/p>\n\n\n\n
Sur un r\u00e9seau CAN, l’identifiant de chaque message, qui est une s\u00e9quence de 11 bits (format standard) ou 29 bits (format \u00e9tendu), d\u00e9termine sa priorit\u00e9. Les priorit\u00e9s sont donc attribu\u00e9es lors de la conception du programme informatique (la couche logicielle), au moyen de ces valeurs binaires. Plus la valeur binaire de l\u2019identifiant est faible, plus grande est la priorit\u00e9 du message.<\/p>\n\n\n\n
Les n\u0153uds qui tentent d\u2019\u00e9mettre simultan\u00e9ment sur le bus comparent l’identifiant de leur message avec celui des messages comp\u00e9titeurs. Les messages de priorit\u00e9 moins \u00e9lev\u00e9e perdent la comp\u00e9tition face \u00e0 celui qui a la priorit\u00e9 la plus \u00e9lev\u00e9e. Quand un n\u0153ud perd la comp\u00e9tition, il cesse d’\u00e9mettre. Il devient alors automatiquement un simple r\u00e9cepteur du message, et il ne tente \u00e0 nouveau d’\u00e9mettre son message que lorsque le bus se lib\u00e8re.<\/p>\n\n\n\n
Cette gestion des priorit\u00e9s est totalement transparente pour le programmeur qui n\u2019a pas \u00e0 s\u2019en pr\u00e9occuper, sauf au moment du choix des identifiants. Elle est int\u00e9gralement assur\u00e9e par le protocole contenu dans le contr\u00f4leur CAN de chaque n\u0153ud, si bien que chaque message est finalement toujours \u00e9mis, et qu\u2019il n\u2019y a jamais aucune information perdue.<\/p>\n\n\n\n
Structure des messages<\/h5>\n\n\n\n
On ne parle ici que du protocole CAN \u00ab classique \u00bb, limit\u00e9 \u00e0 des messages de 8 octets de donn\u00e9es avec un d\u00e9bit max de 1 Mbit\/s. Le CAN FD, plus r\u00e9cent, autorise des messages de 64 octets de donn\u00e9es avec un d\u00e9bit max de 2 Mbit\/s, mais en dehors de cela, il reprend exactement les m\u00eames principes.<\/p>\n\n\n\n
Le CAN \u00ab classique \u00bb existe lui-m\u00eame en 2 versions : CAN 2.0A avec identification sur 11 bits, et CAN 2.0B avec une identification comportant 18 bits suppl\u00e9mentaires, donc sur 29 bits. On parle de format CAN \u00e9tendu pour cette version 2.0B. La structure des trames est repr\u00e9sent\u00e9e ci-dessous (fig. 4).<\/p>\n\n\n
![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/trameCAN.png\")
Une trame est compos\u00e9e des champs suivants :<\/p>\n\n\n\n
- \n
- Bit SOF (Start Of Trame) : passage de HIGH (\u00e9tat de repos) \u00e0 LOW<\/li>\n\n\n\n
- Champ Identifiant et Arbitrage (11 ou 29 bits)<\/li>\n\n\n\n
- Bit RTR (Remote Transmission Request) : d\u00e9termine s’il s’agit d’une trame de donn\u00e9es ou d’une trame de demande de message.<\/li>\n\n\n\n
- Bit IDE qui \u00e9tablit la distinction entre format standard (\u00e9tat LOW ou dominant) et format \u00e9tendu (\u00e9tat HIGH, ou r\u00e9cessif)<\/li>\n\n\n\n
- Champ R, 1 ou 2 bits : r\u00e9serv\u00e9 pour une utilisation future<\/li>\n\n\n\n
- Champ DLC de 4 bits : nombre d’octets contenus dans la zone de donn\u00e9es<\/li>\n\n\n\n
- Champ de donn\u00e9es, de longueur comprise entre 0 et 8 octets<\/li>\n\n\n\n
- Champ CRC de 15 bits (Cyclic Redundancy Code). Ces bits sont recalcul\u00e9s \u00e0 la r\u00e9ception et compar\u00e9s aux bits re\u00e7us. S’il y a une diff\u00e9rence, une erreur CRC est d\u00e9clar\u00e9e.<\/li>\n\n\n\n
- Champ ACK compos\u00e9 d’un bit \u00e0 l’\u00e9tat HIGH ainsi qu’un bit s\u00e9parateur ACK. Le premier bit doit \u00eatre forc\u00e9 \u00e0 l\u2019\u00e9tat LOW par les stations ayant bien re\u00e7u cette trame.<\/li>\n\n\n\n
- Champ EOF (End Of Frame) de 7 bits HIGH : permet d’identifier la fin de la trame.<\/li>\n<\/ul>\n\n\n\n
Avec un identifiant sur 11 bits et un message de 8 octets, on arrive donc \u00e0 une longueur th\u00e9orique de message de 108 bits. Mais il faut rajouter des bits de \u00ab\u00a0bit stuffing\u00a0\u00bb, une technique qui impose au transmetteur d\u2019ajouter automatiquement un bit de valeur oppos\u00e9e lorsqu\u2019il d\u00e9tecte 5 bits cons\u00e9cutifs de m\u00eame valeur. Ce qui fait que la longueur d’un message peut atteindre presque 130 bits. Il faut en tenir compte pour calculer la charge du bus et d\u00e9terminer si cette charge est compatible avec le d\u00e9bit de donn\u00e9es du bus.<\/p>\n\n\n\n
Les contr\u00f4leurs CAN qui admettent le format \u00e9tendu peuvent aussi \u00e9mettre et recevoir des messages au format standard. Mais si on utilise sur le r\u00e9seau des contr\u00f4leurs ne maitrisant que le format standard, les messages \u00e9tendus seront mal interpr\u00e9t\u00e9s.<\/p>\n\n\n\n
Les contr\u00f4leurs CAN des cartes Teensy utilis\u00e9es dans le projet AvionicsDuino admettent le format \u00e9tendu. Compte tenu des besoins modestes du projet, ils sont utilis\u00e9s avec le format standard, donc avec des identifiants sur 11 bits. Ce qui permet d’utiliser 2048 identifiants diff\u00e9rents, un nombre plus que largement suffisant.<\/p>\n\n\n\n
La s\u00e9curit\u00e9 et la fiabilit\u00e9<\/h5>\n\n\n\n
Le protocole CAN int\u00e8gre donc des m\u00e9canismes de d\u00e9tection et de gestion des erreurs. Tous les n\u0153uds du r\u00e9seau surveillent simultan\u00e9ment le bus, ils d\u00e9tectent imm\u00e9diatement des diff\u00e9rences entre bits re\u00e7us et bits \u00e9mis. D\u00e8s qu’une erreur est d\u00e9tect\u00e9e, la transmission en cours est interrompue par l’\u00e9mission d’un indicateur d’erreur (\u00ab\u00a0Error Flag\u00a0\u00bb). L’\u00e9metteur doit donc recommencer \u00e0 \u00e9mettre son message.<\/p>\n\n\n\n
Ce syst\u00e8me de gestion des erreurs est transparent pour le d\u00e9veloppeur et l’utilisateur. Le syst\u00e8me est capable de g\u00e9rer automatiquement ses conflits et ses erreurs en \u00e9mettant des trames d’erreur pour renseigner l’\u00e9metteur du message sur le type d\u2019erreur rencontr\u00e9e. Une station est m\u00eame capable de faire la distinction entre des perturbations temporaires et des d\u00e9fauts permanents. Les stations en d\u00e9faut permanent sont d\u00e9connect\u00e9es automatiquement du r\u00e9seau. Ainsi, la probabilit\u00e9 qu\u2019une erreur reste non d\u00e9tect\u00e9e est inf\u00e9rieure \u00e0 4,7 x 10-11<\/sup>.<\/p>\n\n\n\n
La puissance, la robustesse et l\u2019efficacit\u00e9 du bus CAN sont li\u00e9es \u00e0 cette gestion rigoureuse des erreurs et des priorit\u00e9s par le protocole, qui est \u00ab hardcoded \u00bb dans les contr\u00f4leurs CAN de chaque n\u0153ud, et \u00e0 l\u2019immunit\u00e9 vis-\u00e0-vis des perturbations \u00e9lectromagn\u00e9tiques des paires torsad\u00e9es v\u00e9hiculant un signal diff\u00e9rentiel.<\/p>\n\n\n\n
Contr\u00f4leurs et transceivers<\/h5>\n\n\n\n
Toute la complexit\u00e9 du protocole est donc g\u00e9r\u00e9e par un circuit \u00e9lectronique sp\u00e9cialis\u00e9, le contr\u00f4leur (ou driver) CAN. Comme d\u00e9j\u00e0 mentionn\u00e9 plus haut, le microcontr\u00f4leur 8 bits des cartes Arduino Uno, Nano et Mega ne comporte pas de driver CAN. Si on veut \u00e9tablir une liaison CAN avec ces microcontr\u00f4leurs, il faut leur ajouter un module externe, g\u00e9n\u00e9ralement connect\u00e9 en I2C ou SPI. Ce module est le plus souvent \u00e9quip\u00e9 du circuit contr\u00f4leur de CAN bus MCP2515, associ\u00e9 \u00e0 un transceiver tr\u00e8s variable selon les modules, MCP2551, MCP2562, TJA1050, SN65HVD1050\u2026 etc. <\/p>\n\n\n\n
Le r\u00f4le du transceiver est de convertir les signaux TTL g\u00e9n\u00e9r\u00e9s par le contr\u00f4leur CAN en signaux diff\u00e9rentiels qui v\u00e9hiculent l\u2019information sur la paire CAN_H et CAN_L constituant le CAN bus. Les microcontr\u00f4leurs 32 bits qui \u00e9quipent les cartes Teensy 4.x utilis\u00e9es dans le projet AvionicsDuino comportent plusieurs contr\u00f4leurs CAN. Si on souhaite utiliser plusieurs contr\u00f4leurs CAN d’un m\u00eame microcontr\u00f4leur, il faut leur adjoindre chacun un transceiver.<\/p>\n\n\n\n
Chaque n\u0153ud d\u2019un bus CAN comporte donc un microcontr\u00f4leur, un contr\u00f4leur CAN et un transceiver CAN (fig. 5).<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/busCANetNoeudsDetails2.png\")
Figure 5 : Sch\u00e9ma complet d’un bus CAN avec les microcontr\u00f4leurs, les contr\u00f4leurs CAN et les transceivers.<\/figcaption><\/figure>\n<\/div>\n\n\n C\u00e2bles et connecteurs<\/h5>\n\n\n\n
La r\u00e9alisation pratique du bus est peu document\u00e9e : quels c\u00e2bles, quels connecteurs ? Le concepteur dispose d’une certaine libert\u00e9, seule la notion de paire torsad\u00e9e est bien \u00e9tablie et \u00e0 respecter scrupuleusement. Sauf \u00e0 d\u00e9cider de respecter des normes beaucoup plus strictes comme celles \u00e9dict\u00e9es par CANAerospace (cf. plus bas). Nous utilisons un c\u00e2ble compos\u00e9 d’un fil de masse et de deux paires torsad\u00e9es blind\u00e9es individuellement (Ref. Belden 8723, fig. 6). Ce c\u00e2ble l\u00e9ger, robuste et facile \u00e0 connecter est malheureusement assez on\u00e9reux. On peut aussi utiliser du c\u00e2ble Ethernet, beaucoup plus r\u00e9pandu et moins cher, mais moins facile \u00e0 connecter en raison du tr\u00e8s petit diam\u00e8tre des fils. La paire rouge-noire du c\u00e2ble Belden est utilis\u00e9e si n\u00e9cessaire pour l’alimentation des n\u0153uds, la paire blanc-vert constitue le bus CAN. Les n\u0153uds sont tous cens\u00e9s partager une masse commune dans l’avion, \u00e9ventuellement via le fil noir. Le fil de masse non isol\u00e9 permet de relier tous les blindages \u00e0 la masse, mais \u00e0 une seule extr\u00e9mit\u00e9 du bus,<\/em><\/strong> car il ne doit \u00eatre parcouru par aucun courant. Sa continuit\u00e9 doit \u00eatre assur\u00e9e dans les connecteurs des n\u0153uds . Ce fil de masse ne doit pas \u00eatre utilis\u00e9 pour un autre usage.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/Belden8723.png\")
Figure 6 : C\u00e2ble \u00e0 double paire torsad\u00e9e blind\u00e9e<\/figcaption><\/figure>\n<\/div>\n\n\n Le connecteur CAN \u00ab standardis\u00e9 \u00bb est un SUB-D9 (fig. 7). Les broches 7 et 2 sont d\u00e9di\u00e9es aux signaux CANH et CANL, les broches 3 et 6 sont d\u00e9di\u00e9es \u00e0 la masse, une alimentation externe peut si n\u00e9cessaire \u00eatre connect\u00e9e sur la broche 9. Le blindage g\u00e9n\u00e9ral du bus peut \u00eatre connect\u00e9 \u00e0 la broche 5 d’un seul n\u0153ud, lequel doit assurer la mise \u00e0 la masse unique de ce blindage.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/SubD9CAN2-300x288.png\")
Figure 7 : Brochage standard d’un connecteur CAN SUB-D9<\/figcaption><\/figure>\n<\/div>\n\n\n Il n’existe pas de connecteur en T standard et \u00e9conomique pour relier de fa\u00e7on fiable un c\u00e2ble issu d’un n\u0153ud au bus lui-m\u00eame. On a vu plus haut qu’un tel c\u00e2ble, lorsqu’on ne peut pas l’\u00e9viter, doit \u00eatre le plus court possible. Il est donc nettement pr\u00e9f\u00e9rable de d\u00e9vier le bus vers un n\u0153ud plut\u00f4t que d’allonger exag\u00e9r\u00e9ment une connexion en T (voir la figure 3). Le connecteur SUB-D est alors ins\u00e9r\u00e9 sur le bus lui-m\u00eame (fig. 8). <\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/SUB-D9_doubleCable.jpg\")
Figure 8 : Connecteur SUB-D ins\u00e9r\u00e9 sur le c\u00e2ble d’un CAN Bus.<\/figcaption><\/figure>\n<\/div>\n\n\n Un capot SUB-D9 \u00e0 double entr\u00e9e comme celui de la figure 9 (Ref. MH Connectors MHDU45ZK9-K) offre plus de place pour r\u00e9aliser les connexions. Les fils des c\u00e2bles p\u00e9n\u00e9trant de chaque c\u00f4t\u00e9 du capot sont reli\u00e9s entre eux selon leur couleur et connect\u00e9s aux broches correspondantes du connecteur SUB-D. Si bien que le bus traverse cette connexion sans \u00eatre interrompu. On peut \u00f4ter le n\u0153ud sans perturber le fonctionnement du bus. Et lorsque le n\u0153ud est connect\u00e9, il est directement sur le bus, ce qui est conforme \u00e0 l’imp\u00e9ratif de connexion courte \u00e9voqu\u00e9 plus haut.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/ConnecteurSUB-D_double_entree.png\")
Figure 9 : connecteur SUB-D \u00e0 double entr\u00e9e<\/figcaption><\/figure>\n<\/div>\n\n\n Le logiciel<\/h5>\n\n\n\n
Le contr\u00f4leur CAN g\u00e8re le protocole, c’est-\u00e0-dire la t\u00e2che la plus complexe. Le programmeur va essentiellement avoir pour r\u00f4le g\u00e9n\u00e9ral de d\u00e9cider des attributions d’ID aux messages du r\u00e9seau en fonction de leurs priorit\u00e9s. Et de programmer le microcontr\u00f4leur de chaque n\u0153ud. En particulier pour que ledit n\u0153ud r\u00e9agisse de fa\u00e7on appropri\u00e9e en fonction du contexte : \u00e9mission d’un message sur le r\u00e9seau lorsque ses capteurs lui fournissent de nouvelles informations, \u00e9coute et tri des messages du r\u00e9seau pour r\u00e9pondre de fa\u00e7on ad\u00e9quate ou entamer une action particuli\u00e8re.<\/p>\n\n\n\n
Le programmeur peut s’aider de tr\u00e8s nombreuses biblioth\u00e8ques, plus ou moins g\u00e9n\u00e9riques, plus ou moins d\u00e9di\u00e9es \u00e0 certains contr\u00f4leurs CAN. Dans le monde Teensy, et plus particuli\u00e8rement Teensy 4.x, une biblioth\u00e8que commun\u00e9ment utilis\u00e9e est Flexcan_t4<\/a>. <\/p>\n\n\n\n
Cette biblioth\u00e8que exploite pleinement les nombreuses possibilit\u00e9s offertes par les contr\u00f4leurs CAN des microcontr\u00f4leurs iMXRT1062 qui \u00e9quipent les cartes Teensy 4.x. En particulier la gestion des buffers de r\u00e9ception, des mailboxes, et des m\u00e9canismes de filtrage qui permettent aux contr\u00f4leurs de n\u2019accepter que les messages qui les concernent et d\u2019ignorer les autres sans avoir \u00e0 les traiter. En pratique, pour nos besoins basiques, seule une petite partie des fonctionnalit\u00e9s de cette biblioth\u00e8que est utilis\u00e9e.<\/p>\n\n\n\n
CANaerospace<\/h5>\n\n\n\n
CANaerospace <\/a>est un projet open source d\u00e9velopp\u00e9 par Stock Flight Systems<\/a>. Il s\u2019agit de la description d’un ensemble standardis\u00e9 de protocoles et de formats de donn\u00e9es con\u00e7us pour assurer une communication hautement fiabilis\u00e9e entre syst\u00e8mes informatiques a\u00e9ronautiques, via le Controller Area Network (CAN). <\/p>\n\n\n\n
La lecture de cette pr\u00e9sentation<\/a> est tr\u00e8s instructive, le concept d\u2019IMA (Integrated Modular Avionics Concept) y est bien expos\u00e9.<\/p>\n\n\n\n
Le CAN bus du projet AvionicsDuino<\/h5>\n\n\n\n
Les besoins sont modestes. Il s\u2019agit seulement de relier quatre, cinq, voire six n\u0153uds qui \u00e9changent quelques messages entre eux \u00e0 des fr\u00e9quences mod\u00e9r\u00e9es entre 5 et 20 Hz. Aucune technique de filtrage n\u2019est utilis\u00e9e. Tous les n\u0153uds lisent l\u2019ID de tous les messages qui transitent sur le bus et ne d\u00e9codent que les informations qui les concernent. Nous n\u2019avons pas cherch\u00e9 \u00e0 appliquer les contraintes et pr\u00e9conisations du protocole CANaerospace, disproportionn\u00e9es par rapport \u00e0 notre projet. <\/p>\n\n\n\n
Premi\u00e8re configuration du CAN bus<\/h6>\n\n\n\n
La figure 10 ci-dessous montre l’architecture du r\u00e9seau de communication tel qu’il \u00e9tait initialement install\u00e9 dans l’un des avions participant au projet AvionicsDuino. Il n’y avait que 4 n\u0153uds . En effet, pour des raisons historiques, le module AHRS \u00e9tait encore connect\u00e9 \u00e0 l’unit\u00e9 principale de l’EFIS par une connexion UART s\u00e9rie.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2024\/03\/CAN_bus_V1-1.png\")
Figure 10 : Architecture du r\u00e9seau de communication CAN et UART. Premi\u00e8re configuration<\/figcaption><\/figure>\n<\/div>\n\n\n Le tableau ci-dessous (fig. 11) r\u00e9sume les \u00e9changes de donn\u00e9es sur le CAN bus de cet avion, dans cette premi\u00e8re configuration. La vitesse du bus \u00e9tait fix\u00e9e \u00e0 0,5 Mbit\/s. Les \u00e9l\u00e9ments en r\u00e9seau \u00e9taient l’unit\u00e9 principale de l’EFIS<\/a>, le module distant magn\u00e9tom\u00e8tre<\/a>, l’EMS<\/a>, et le micro-EMS<\/a>.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2023\/11\/TableauMessagesCANbusFT-1024x507.png\")
<\/figure>\n<\/div>\n\n\nDans cette premi\u00e8re configuration, en estimant des longueurs totales de messages de 130 bits (pour 8 octets), 115 bits (pour 6 octets) et 100 bits (pour 4 octets), et compte tenu des fr\u00e9quences d’envoi, on peut calculer une estimation haute de la charge du bus \u00e0 13,825 Kbit\/s, soit seulement 2,7 % du d\u00e9bit maximum du bus. Donc tr\u00e8s loin de la zone de risque de perte de donn\u00e9es !<\/p>\n\n\n\n
Seconde configuration du CAN bus<\/h6>\n\n\n\n
La figure 12 ci-dessous montre l’architecture actuelle du CAN bus, dans le m\u00eame avion que pr\u00e9c\u00e9demment. Six n\u0153uds y sont connect\u00e9s, ce qui reste tr\u00e8s peu compar\u00e9 \u00e0 la centaine de n\u0153uds des voitures modernes, souvent r\u00e9partis sur plusieurs bus. L’ancienne liaison UART entre l’unit\u00e9 principale de l’EFIS et l’AHRS a \u00e9t\u00e9 supprim\u00e9e. Un nouveau Flight Data Recorder (FDR) fait son apparition, son design hardware est termin\u00e9, les premiers essais en vol sont tr\u00e8s satisfaisants. Il est bas\u00e9 sur un module ESP32 coupl\u00e9 \u00e0 un lecteur de carte micro-SD. Une mise \u00e0 jour substantielle de la page d\u00e9di\u00e9e \u00e0 l’enregistreur de vol<\/a> a \u00e9t\u00e9 r\u00e9alis\u00e9e, elle sera compl\u00e9t\u00e9e d\u00e8s que les derniers d\u00e9veloppements du logiciel de cet enregistreur seront achev\u00e9s.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2024\/03\/CAN_bus_V2.png\")
Figure 12 : Architecture du CAN bus. Deuxi\u00e8me configuration.<\/figcaption><\/figure>\n<\/div>\n\n\n Le tableau ci-dessous (fig. 13) r\u00e9sume les \u00e9changes de donn\u00e9es sur le CAN bus dans cette seconde configuration. La vitesse du bus reste fix\u00e9e \u00e0 0,5 Mbit\/s.<\/p>\n\n\n
\n![\"\"](\"https:\/\/avionicsduino.com\/wp-content\/uploads\/2024\/04\/MsgCAN_V3.png\")
Figure 13 : Tableau des ID et des messages CAN du projet AvionicsDuino. Deuxi\u00e8me configuration.<\/figcaption><\/figure>\n<\/div>\n\n\n Dans cette deuxi\u00e8me configuration, on voit que le nombre de messages \u00e9mis sur le bus a beaucoup augment\u00e9, que la plupart ont un contenu de 8 octets, que tous sont destin\u00e9s au FDR, et beaucoup uniquement au FDR. Le r\u00f4le du FDR est bien entendu d’enregistrer tout le trafic du bus CAN. Une estimation haute de la charge du bus est calcul\u00e9e \u00e0 23,650 Kbit\/s, soit seulement 4,7 % de la charge maximale possible compte tenu de la vitesse du bus.<\/p>\n\n\n\n
Les logiciels compatibles avec ces deux configurations du CAN bus sont t\u00e9l\u00e9chargeables sur GitHub. Il convient \u00e9videmment de ne pas les panacher. Le logiciel du nouveau FDR ne sera pas compatible avec les logiciels de la premi\u00e8re configuration. Il est important de lire soigneusement les fichiers README sur GitHub, ils d\u00e9taillent les versions logicielles et leurs compatibilit\u00e9s<\/p>\n","protected":false},"excerpt":{"rendered":"
(Le bus CAN : derni\u00e8re mise \u00e0 jour par Benjamin le 9 avril 2024) Le bus de donn\u00e9es CAN (Controller Area Network) est un bus s\u00e9rie bidirectionnel, asynchrone (pas de fil d\u2019horloge, les diff\u00e9rents \u00e9l\u00e9ments connect\u00e9s doivent tous \u00eatre configur\u00e9s avec le m\u00eame d\u00e9bit) et Half Duplex (on parle chacun \u00e0 son tour, \u00e0 condition … Continuer la lecture de « Le bus CAN »<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"class_list":["post-3139","page","type-page","status-publish","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/pages\/3139","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/comments?post=3139"}],"version-history":[{"count":80,"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/pages\/3139\/revisions"}],"predecessor-version":[{"id":5026,"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/pages\/3139\/revisions\/5026"}],"wp:attachment":[{"href":"https:\/\/avionicsduino.com\/index.php\/wp-json\/wp\/v2\/media?parent=3139"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}