Liaison i2c, SPI ou autres ?

[kronanberg]

Bonjour,

J’étudie actuellement l'architecture d'un futur prototype : son but est de réaliser l'acquisition de différents capteurs, de corriger ces données et ensuite de les transmettre à un PC et à des afficheurs.

La partie qui me pose problème en ce moment est l'acquisition des capteurs puisqu'il faut que je puisse faire l'acquisition de liaisons séries, de signaux pulses, de signaux analogiques, de BUS CAN... Je vais donc partir sur une architecture distribuée.

Plusieurs microcontroleurs se chargeront d'effectuer l'acquisition des données puis devront les transmettre aux processeurs pour qu'il traite ces données. L'acquisition des données se fera à 10 Hz. Le nombre maximum de données à transmettre au processeur est de 100.

Le but est donc de trouver une liaison pour connecter tous les microcontroleurs et le processeur entre eux. Cette liaison devra permettre de faire circuler 100 données (codées sur 32 bits) en moins de 100 ms.

Mon choix se penche donc sur 2 liaisons : i2c et SPI

A priori l'i2c est plus lent (100 kbit/s ou 400 kbit/s) mais demande moins de broche. Pour une vitesse de 100 kbit/s, un octet (1 bit start/8 bit données/ 1 bit Ack/ 1 bit de stop) est transmis en 110 us. Pour envoyer mes 100 données codées sur 32 bits il me faudra 44 ms. Si je compte en plus 1 octet de commande entre chaque lecture c'est à dire 100*110 us donc 11 ms, on en arrive à 55 ms pour faire l'acquisition des 100 variables. On est donc en dessous des 100 ms mais ça veut dire que j'occuperai quand même beaucoup de temps du processeur pour réaliser l'acquisition des données.

La liaison SPI pourrait quand à elle être beaucoup plus rapide mais elle consommerai aussi plus de broche pour contrôler le bus.

De plus, pour le moment le prototype sera réalisé à partir d'une carte de développement (pour la carte processeur) et sera relié aux cartes d'acquisitions à travers des files. Or, il me semble que pour utiliser la liaison I2C les 2 composants doivent être reliés sur le même PCB ?

Voilà les quelques questions que je me pose. Si vous avez des avis/propositions je suis preneur. Merci.
-----

[xberger]

Bonjour,

Si tu restes sur la même carte un MCU maitre qui interroge successivement plusieurs esclaves à travers un bus SPI me parait approprié. Je l'ai testé et approuvé.

Cordialement

Xavier

[Lytharan]

I2C et SPI c’est du pareil au même niveau encombrement, le SPI est plus rapide par contre c'est un protocole "brut" pas de gestion d'adressage en dehors des chips select (donc un master et un slave uniquement, mais tu peux faire toi même un système d'adressage software). L'I2C est protocole complet avec adressage et tu peux avoir jusqu’à 128 modules. Les deux sont prevu que pour etre sur un PCB, si tu as de câble tu change de protocole (CAN, RS232, ...) ou tu utilises des drivers pour booster ton signal I2C ou SPI.

[ftorama]

Peu importe le protocole, à 10Hz, même le processeur seul aurait le temps de faire les acquisitions, à condition de ne pas travailler avec des pièces archéologiques bien sur...

Sinon, tu as une alternative proche du SPI qui est de gérer tous les capteurs comme des registres à décalage. Soit tu les chaines tous et 3 broches seulement sont nécessaires, soit tu utilises un signal d'horloge commun et chaque périphérique arrive sur un port différent du micro central.

On a 10 fois 100 données 32 bits par seconde, soit un débit théorique de 32 kbits/s. C'est à la portée de n'importe quel protocole et tu te poses à mon avis un faux problème.

[A voir en vidéo sur Futura]

[kronanberg]

Ok. Merci pour ces réponses.

En faite l'idée de faire une architecture distribuée est partie du fait que j'ai un certain nombre d'acquisition à faire :
6 liaisons séries
2 bus CAN
1 liaison ethernet
5 entrés pulse
10 entrées analogiques
10 entrées TTL

Sachant que par la suite le traitement sur les données peut être assez lourds, j'ai plusieurs filtres de Kalman à appliquer (dont je suis d'ailleurs en train d'estimer la complexité). Donc le but était de libérer le processeur de la partie acquisition pour qu'il puisse se consacrer uniquement à la correction des données et à la transmission des informations vers un PC.

Maintenant si je trouve une carte de développement qui est capable de me faire tout ça c'est sur que c'est une meilleur solution. En plus je n'aurai pas besoin de développer des cartes d'acquisition à bases de microcontroleur.

[ftorama]

Bah il faut déjà estimer combien de temps prend une acquisition sur le contrôleur et combien de temps prendrait la communication avec d'autres micros...Si ça se trouve l'acquisition prend moins de temps que le dialogue

[kronanberg]

Ok. C'est sur que ça pourra m'aider dans mon choix. Par contre je ne vois pas spécialement comment estimer l'acquisition des temps des entrées analogiques, TTL ainsi que des entrées pulses (qui permettent de calculer la fréquence d'un signal) sachant que je ne sais pas encore quel processeur je vais utilisé.

Mais d'après ce que j'ai fait pour les liaisons série, je dépasse déjà les 100 ms. J'estime le temps d'acquisition des liaisons de la manière suivante :

Liaison série à 19200 bauds (START / 8 Data / STOP). Sachant que le protocole transmet 50 octets le temps de transmission est de (1/19200)*50*10, ce qui fait environ 26 ms. J'ai utilisé ce principe pour les autres liaisons séries et en les additionnant je me retrouve avec un temps supérieur à 100 ms.

Pour les bus CAN ne connaissant pas le nombre de capteurs qu'il y aura dessus il est difficile d'estimer un temps d'acquisition mais a priori comme sa vitesse de communication est beaucoup plus rapide, il ne risque pas de poser de problème pour travailler à 10 Hz.

[ftorama]

La transmission n'a pas besoin de se faire en tâche principale....Avec une interruption, le programme ne fait que transmettre l'octet suivant dans le buffer, rien d'autre. Le transfert en lui-même est effectué par le module UART, sans charger le coeur.

Avec du DMA, c'est quasi 0 cycle processeur....

Avant de chercher des optimisations, il faudrait déjà comprendre comment marchent les choses.

[ftorama]

Supposons un micro à 10MHz, soit un temps de cycle de 100 ns.

Admettons (hypothèse large) que la routine d'interruption prenne 100 instructions, ça nous mène à 100*100= 10 µs par caractère envoyé soit 500 µs pour 50 caractères.

Sur les 26ms que prend effectivement la transmission, il en reste 25,5 de dispo pour faire autre chose.

Etant donné le nombre de périphériques dont tu as besoin, tu vas sans doute aller lorgner du côté des Cortex-M3, et là ça n'est plus 10MHz, mais 60 ou 80, voire plus sur les STM32F2xx de chez ST

[kronanberg]

Merci pour cette éclaircissement.

On a donc l'UART qui est géré de façon matériel ce qui permet de ne quasiment pas utilisé le processeur (sauf pour lire ou écrire dans le buffer). Va falloir que je rebosse un peu le sujet je crois !

Après le fait de passer sur une architecture distribuée est que je ne pensais pas trouver de carte développement pouvant faire l'acquisition de toute ces liaisons. Mais finalement en regardant un peu, il y a certaine carte avec au moins 6 UART par exemple la APF27 de chez Armadeus (http://www.armadeus.com/francais/pro...eur-apf27.html) mais elle n'a pas de bus CAN !

Pour le moment mes conceptions de carte électronique n'ont jamais dépassées la carte d'acquisition avec de simple microcontroleur! Voilà pourquoi je rame un peu dans la conception d'une plate forme embarquée !