Un livre sur protocoles/bus de communications (SPI/I2C/CAN/RS232/RS422-85/...)

[Control]

Bonjour,

En consultant les offres de stage et d'emploi des postes qui m’intéresse, la connaissance sur les protocoles/bus de communications (SPI/I2C/CAN/RS232/RS422-85/...) revient souvent.
Je voudrais donc savoir si vous connaissez un livre de niveau étudiant qui traite du sujet. J'aimerais profiter de ma bibliothèque universitaire pour emprunter un tel livre.
Si cela est possible, un livre avec une bonne dose d'exercices, je retiens mieux en m'exerçant. Dans le cas contraire, je me contenterai de ce que vous me proposer.

Merci d'avance.
-----

[Murayama]

Bonjour!

Si cela est possible, un livre avec une bonne dose d'exercices, je retiens mieux en m'exerçant.

Des exercices sur le papier, ou alors un livre d'expériences à faire avec les différents protocoles?
Parce que sur le papier, je ne vois pas trop comment faire un exercice. Avec un microcontrôleur
et un capteur ou autre, je vois mieux.

Pascal

[Control]

Bonjour!



Des exercices sur le papier, ou alors un livre d'expériences à faire avec les différents protocoles?
Parce que sur le papier, je ne vois pas trop comment faire un exercice. Avec un microcontrôleur
et un capteur ou autre, je vois mieux.

Pascal[/COLOR]

J'avais en tête des exercices sur le papier mais un livre sur les principes et un autre, cette fois-ci, livre d’expérience serait génial.
J'ai passé deux entretiens de stage et j'ai complétement sécher sur la question sur la connaissance de ces bus

[umfred]

Tu peux commencer par regarder leur page wikipédia.
Chaque protocole/bus fait l'objet de son propre livre (souvent chez les éditions Dunod).
Des exercices sur papier, je ne vois pas trop non plus, à part te faire décoder un chronogramme pour retrouver la trame (ça peut être utile de savoir le faire) ou au contraire, faire le chronogramme d'une trame de données.

[A voir en vidéo sur Futura]

[Control]

Tu peux commencer par regarder leur page wikipédia.
Chaque protocole/bus fait l'objet de son propre livre (souvent chez les éditions Dunod).
Des exercices sur papier, je ne vois pas trop non plus, à part te faire décoder un chronogramme pour retrouver la trame (ça peut être utile de savoir le faire) ou au contraire, faire le chronogramme d'une trame de données.

D'accord je vais faire ça pour commencer.
Oui à vrai dire j'espérais un unique livre qui traite des principaux protocole/bus, je ne cherche pas à être un expert sur le sujet mais juste à avoir des bases solides pour effectuer un stage.
Franchement je suis preneur d'à peut pres toute recommandation (déjà qu'il faut que je m'assure que ma bibliothèque dispose de ce livre alors si je commence à faire le difficile...)

[antek]

La lecture des datasheet des µC permet de pas mal dégrossir le sujet.
Et c'est gratuit !

[Vincent PETIT]

Bonjour,
Je ne connais aucun livre traitant de tout ça en même temps. Dans ce que tu cites il y a ; des bus de terrain et d'autres de communication, il y a de simples couches physiques, des bus synchrones, d'autres asynchrones. Il y a de tout !

Ensuite c'est en lisant des papiers sur la CEM qu'on comprend pourquoi une liaison différentielle est naturellement immunisée contre les perturbations, qu'on comprend pourquoi une paire torsadée contribue à l'annulation des courants induits par un couplage inductif etc...

Je n'ai jamais vu de livre traitant de tout ces sujets.

J'ai passé deux entretiens de stage et j'ai complétement sécher sur la question sur la connaissance de ces bus

Tu as des exemples de questions qui t'on était posé ? Parce que sur le bus CAN il y a une tonne de chose à dire tellement c'est chiadé (gestion des collisions, multi-maître, correcteur d'erreur), sur le RS485 c'est beaucoup plus simple, ensuite viennent des notions de CEM pour expliquer pourquoi certain bus sont de terrain et d'autres non, pourquoi on utilise une paire torsadée pour les liaisons différentielles etc...

[Control]

La lecture des datasheet des µC permet de pas mal dégrossir le sujet.
Et c'est gratuit !

"µC" veut dire microcontroleurs?
Je suis encore un étudiant, j'ai besoin d'être guidé d'où le fait que je cherche un livre qui m'apprends pas à pas, ce que son ces bus et comment on les manipule si besoin

[Control]

Bonjour,
Je ne connais aucun livre traitant de tout ça en même temps. Dans ce que tu cites il y a ; des bus de terrain et d'autres de communication, il y a de simples couches physiques, des bus synchrones, d'autres asynchrones. Il y a de tout !

Ensuite c'est en lisant des papiers sur la CEM qu'on comprend pourquoi une liaison différentielle est naturellement immunisée contre les perturbations, qu'on comprend pourquoi une paire torsadée contribue à l'annulation des courants induits par un couplage inductif etc...

Je n'ai jamais vu de livre traitant de tout ces sujets.


Tu as des exemples de questions qui t'on était posé ? Parce que sur le bus CAN il y a une tonne de chose à dire tellement c'est chiadé (gestion des collisions, multi-maître, correcteur d'erreur), sur le RS485 c'est beaucoup plus simple, ensuite viennent des notions de CEM pour expliquer pourquoi certain bus sont de terrain et d'autres non, pourquoi on utilise une paire torsadée pour les liaisons différentielles etc...

Ah d'accord, bah dans ce cas si je devais prendre 2-3 livres sur ces bus, lequel me conseillerais-tu? SPI, I2C et CAN?

La question que l'on m'a posé était simplement si j'avais des connaissances sur les bus de communications, et pour être franc je me suis souvenu qu'on m'ai posé cette question qu'en voyant les récentes offres de stage

[umfred]

les pages wiki (regarde aussi celles en anglais, bien souvent un peu plus complètes) devraient suffire dans un 1er temps, à mon avis.
la mise en place diffère d'un µC (= micro contrôleur) à l'autre (bien qu'il y ai des similitudes forcément), en général, leur doc (ou une application note) décrit comment utiliser chaque type (si il en dispose) sinon il faut s'adapter.

[jiherve]

bonsoir
le sujet est tellement vaste qu'un livre n'y suffirait pas!
presque au hasard un bus inconnu de la plupart:https://fr.wikipedia.org/wiki/ARINC_818
on commence par la 232 puis la 485 puis SPI,I²c, ensuite le 1553, le Digibus, Ethernet .... c'est un métier à part entière.
Bon courage!
JR

[Vincent PETIT]

Bonsoir,

Ah d'accord, bah dans ce cas si je devais prendre 2-3 livres sur ces bus, lequel me conseillerais-tu? SPI, I2C et CAN?

Biscotte, je viens de regarder dans ma bibliothèque, qui pourtant est assez bien fournie, et je n'ai trouvé aucun livre sur les bus de communications.

- RS232, I2C et SPI, je les ai appris lors de mes études au moment de la mise en œuvre des microcontrôleurs comme tout le monde normalement.
- RS485, c'était dans mon boulot.
- CAN, je l'ai effleuré plus tard encore.

Après vérification je rejoints les avis précédents ; Wikipedia explique très bien toutes les notions ci dessus et pour approfondir un peu il suffit d'ouvrir la doc constructeur d'un composant ayant le périphérique recherché.


En ce qui concerne la robustesse des bus différentiels, qui en font des bus de terrain, pouvant sortir du PCB (~1km pour du RS485) là il faudra peut être poser ici même des questions.

[Murayama]

Bonjour!

J'ai passé deux entretiens de stage et j'ai complétement sécher sur la question sur
la connaissance de ces bus

Ça dépend quels bus, mais de mon point de vue, sur SPI et UART, il n'y s pas grand chose
à savoir si ce n'est comprendre le principe, ce qui devrait se faire en assez peu de
temps. Lisez la page Wiki pour comprendre comment ça marche, c'est suffisant.
Ensuite, pour les expérimentations, vous achetez une carte à microcontroleur et un
capteur quelconque. Ou un module GPS. Vous connectez un LCD, vous lisez par UART
les données GPS et vous les affichez. Si vous savez faire cela, vous allez
impressionner plus d'un employeur potentiel, moi en premier parce que dans tous
les candidats, si j'enlève les commerciaux et les programmeurs Java, il doit en rester
assez peu (en près de 20 ans) qui savent faire ça.
Pour I2C, vous lisez aussi Wiki, vous achetez une mémoire 24Cxx ou autre et vous la
connectez à la même carte, et vous apprenez à lire et écrire dedans.
À tout hasard, vous pouvez ajouter les protocoles SSI et BiSS. Là, vous allez impressionner
du monde si vous postulez dans la robotique.
Pour CAN, aucune idée, je n'ai jamais utilisé, mais ça ne doit pas être sorcier non plus.
Tiens, une idée qui me vient: à la place d'un microcontrôleur, vous achetez une carte
FPGA, vous téléchargez Quartus Prime ou autre et vous implémentez les protocoles vous
même (i.e. sans utiliser les modules tout faits). Si vous faites ça, beaucoup de portes
vont s'ouvrir. Sur tous les ingénieurs qui sortent de l'école, il y en a environ 10% qui
savent programmer un microcontrôleur. Et dans ces 10%, il y en a en gros 1 sur 10 qui
sait ce qu'est un FPGA. Alors si en plus vous le programmez...
Si vous le faites avec un FPGA, n'utilisez pas de modules tout faits, programmez votre
SPI vous-même, c'est un bon exercice (ou UART, ou I2C). Avec un FPGA, vous connaîtrez
les niveaux physique et logique, parce qu'il ne suffira pas d'écrire spi.sendbyte(val),
il faudra faire un module SPI complet et tout gérer bit par bit.


Pascal

[Vincent PETIT]

J'ajouterai qu'il faut quand même savoir où on peut et où on ne peut pas utiliser tel ou tel bus.

Si pour faire une liaison filaire entre 2 appareils distant de 100m en milieu industriel tu parles de I2C ou de SPI... le recruteur va te regarder avec des gros yeux.

[Gyrocompas]

Bonjour,
Le point de départ de chaque communication reste son domaine d'emploi.
Communiquer à 10cm ou des km impose d'employer des interfaces, vitesses adaptées.
Ensuite, qui est concerné, un seul dispositif (point à point) ou plusieurs (point à multi point), différents ou en groupe?
La 1ère approche serait de faire un tour du côté de l'ancien modèle OSI et ses 7 couches.
Son intérêt est son respect qui permet d'éviter la confusion en cherchant à tout faire.
L'intégration des circuits d'aujourd'hui permet d'intégrer différentes couches, souvent les 3 premières avec différentes approches selon la destination.

[Murayama]

Bonjour!

J'en rajoute une (petite) couche: il serait bon aussi de faire la différence dans tout
ce cirque, entre les "protocoles" et les spécifications physiques.
Ex: RS422 n'est pas un protocole, c'est juste une définition des niveaux électriques.
Sur RS422, on peut utiliser différents protocoles, par exemple BiSS, SSI. RS232 c'est
un peu la même chose mis à part que je ne connais aucun autre mode de transmission que
les UARTS sur RS232.

La 1ère approche serait de faire un tour du côté de l'ancien modèle OSI et ses 7 couches.

L'idée OSI est bien, mais je n'ai jamais rien vu qui le respecte. J'ai lu il y a très
longtemps un bouquin sur GSM, il y avait dedans des découpages en demi-couches OSI.
Ça valait bien la peine de s'emmerder à définir en 7 couches s'il y a des choses qu'on ne peut
définir sans massacrer le modèle. Pourtant GSM est apparu bien après la définition du modèle.
J'ai eu à étudier OSI en détails il y a longtemps, mais je n'ai jamais vu une seule
application pratique. Et puis pourquoi 7 couches et pas 6 ou 8?
Pour un rapport de thèse, c'est vrai, ça en jette. Mais comme disait Virgile, OSI cerebrum
masturbationem est.

L'intégration des circuits d'aujourd'hui permet d'intégrer différentes couches,
souvent les 3 premières avec différentes approches selon la destination.

Ben voilà! Les circuits intègrent 3 ou 4 couches à la fois selon une méthode du doigt
mouillé, de quel pied l'auteur s'est levé, si sa femme s'est refusée à lui la veille.
Et le modèle OSI est relégué dans les merveilleuses constructions académiques.

Voyons quelques exemples pratiques:
- Ai-je besoin d'OSI pour faire communiquer un µC avec un module en SPI ou UART?
-> Non. Tous les µC ont un SPI / UART intégré, il suffit de l'utiliser.
- Ai-je besoin d'OSI pour créer un programme embarqué qui communique avec des
capteurs?
-> Non. Ce qui n'empêche que j'ai intérêt à bien structurer mon programme pour
pouvoir réutiliser un maximum de code.
- Ai-je besoin d'OSI pour créer des applications PC / téléphone portable / etc
qui communiquent avec un serveur?
-> Non. Les drivers existent, il suffit de les utiliser. Et même remarque pour la structure
du programme.

NB: Je ne dis pas que personne n'a jamais utilisé OSI, je pense que si, ça doit
dépendre du domaine. Je n'en ai jamais eu besoin, que ce soit pour de la programmation
"embedded" ou le développement d'un ASIC.

Mais pour quelqu'un comme l'initiateur de cette discussion qui ne sait pas encore ce
qu'est SPI, je pense qu'il vaut mieux éviter de s'encombrer la tête avec de l'abstraction
qu'il ne peut vraisemblablement pas encore bien comprendre, et plutôt bricoler pour avoir
en premier un peu d'expérience pratique avec divers "protocoles", expérience sur laquelle
on peut ensuite bâtir un savoir plus académique.

Pascal

[Gyrocompas]

Bonjour,
L'intérêt du modèle OSI était de différencier ce qui dépend de l'interface physique, du protocole pour en extraire le contenu.
Pour mémoire, selon les cas, des couches pouvaient être vides.

Tous les µC ont un SPI / UART intégré, il suffit de l'utiliser

Comment fonctionne-t-il si ce n'est par une adaptation au signal attendu?
Au final, si tout est correct, la donnée sera disponible dans le registre, sinon génère un avertissement d'erreur.
Un I2C fait de même en triant uniquement ce qui lui est destiné, ce qui est une sérieuse simplification etc.

[albanxiii]

Bonjour,

A mon avis, il n'est pas nécessaire d'être un expert dans les protocoles / bus de communications cités. Je pense qu'on peut se contenter, dans un premier temps d'en connaître les principes, les principales caractéristiques électriques, du protocole, l'allure des signaux échangés.
Ce sont des outils qu'on utilise pour faire d'autres choses, on les étudie rarement pour eux. S'il faut faire le bring-up sur une carte, on s'en sort avec ce que j'ai mentionné.
Il est plus important de savoir ce genre de chose :

J'ajouterai qu'il faut quand même savoir où on peut et où on ne peut pas utiliser tel ou tel bus.

Et si jamais on a besoin de mettre les mains dans le cambouis, il est toujours temps de le faire.