Comparatif types de communication PIC

[inviteee2ce2b6]

Bonjour,

J'ai besoin de faire communiquer des PICs entre eux et/ou avec un PC.
Pour la communication vers le PC, j'ai dejà expérimenté l'USB avec un 18F4550. Pour la communication entre PICs, je ne sais pas quoi choisir : I2C, SPI, série ou autre que je ne connais pas.
Avez-vous un comparatif de ces types de communications avec leurs avantages et inconvénients, capacités techniques, etc, afin que je puisse choisir la communication en fonction de mon besoin.

Mon application est un bras robot dont je refais toute l'électronique.
Pour info, j'ai besoin de plusieurs PIC car j'ai besoin de séparer les tâche, afin de ne pas saturer (avec un seul PIC, mon robot ne réagit pas assez vite) :
- un PIC pour gérer les pupitres de commande (joysticks, boutons, clavier)
- un PIC pour gérer les calculs de position temps réel
- un PIC master interface entre les autres PICs et le PC
La config n'est pas figée, j'attend d'avoir justement identifié et testé le type de communication entre PICS pour la figer.
Si vous avez des conseils, je suis prenenur.

Mikaël.
-----

[inviteeb160de1]

Pour info, j'ai besoin de plusieurs PIC car j'ai besoin de séparer les tâche, afin de ne pas saturer (avec un seul PIC, mon robot ne réagit pas assez vite)

Le diagnostic est il correct ? Un ralentissement ou autre chose peut parfaitement venir d'une mauvaise structuration de programme.
Et je peux te garantir qu'à te lancer dans un dev avec plusieurs µC, t'es pas sorti ! Ca va etre affreux à debugger.
La bonne démarche serait :
- pourquoi est ce que mon robot ralentit => quelles sont les taches qui le limitent
- quelles améliorations je pourrais apporter à mon programme existant, tu peux passer sur une autre famille qui sera plus performante, ou augmenter la vitesse, etc...
Mais honnetement :
- le master interface avec un PC, pas besoin d'un PIC pour ça, c'est completement inutile. Suffit d'utiliser des FIFO logicielles qui se remplissent et se vident sur IT depuis ton UART ou ton USB, et c'est bon, tu as tout le temps de gérer les comms avec le PC
- la scrutation de joysticks, boutons, claviers peut etre optimisée, mais je ne sais pas quelles sont les contraintes donc je n'ai pas trop de pistes.

Si je réponds à côté de la place, c'est parce que pour faire ce que tu veux faire tu peux aussi bien utiliser un UART, un SPI, un CAN, etc...Mais tu vas galérer, et ce n'est pas la bonne reaction que de vouloir séparer des taches parce que ta premiere solution ralentit.
Ne penses tu pas que l'ajout des programmes de communications interPIC ne va pas ralentir le fonctionnement de tes micros ?
Peux tu me dire quel est l'interet de mettre un PIC qui gere les comms avec un PC alors que de toute façon les autres PIC vont devoir gerer un protocole pour envoyer des data à l'autre PIC qui lui meme les transmettra à un PC....usine à gaz!

Aurélien

[inviteee2ce2b6]

Merci de ta réponse Aurélien.
Compte tenu de tes remarques, je vais donc entrer plus dans les détails.
La finalité est de refaire toute l'électronique d'un robot (robot YOUPI, si vous êtes curieux, vous le trouverez sur le net : http://youpi.forler.ch/). Je souhaite aussi réaliser une supervision sur PC à cette électronique.

Pour expliquer, j'ai deux robots /
- le 1er a encore son électronique mais qui est commandée par port parallèle. je l'appelle robot d'origine
- le 2nd n'a plus d'électronique. je l'appelle robot modifié

Je pratique en plusieurs phases :
1-j'ai réalisé 6 cartes de commande pour les 6 moteurs pas-à-pas du robot modifié (rotation base, épaule, coude, poignet, rotation poignet, pince).
Chaque carte reçoit :
- un top d'horloge (un top par pas)
- un bit de sens
- un bit de validation de rotation
Il faudra que je construise une commande à base de PIC pouvant générer ces données.

2-j'ai programmé un PIC18F4550 capable de commander le robot d'origine, tout en lisant les données depuis une platine composée de 3 mini-joysticks (3x2 axes, pour la commande des 6 moteurs)
Le PIC pourra a terme commander les 6 cartes pour le robot modifié moyennant une légère reprogrammation.
Pour générer les tops, j'utilise un timer cadencé. A chaque interruption, j'incrémente 6 compteurs (un par moteur). Lorsque chaque compteur atteint un certain nombre (ce nombre est donné par la position des joystick, pour gérer les vitesses proportionnelles à leur position), je crée le top pour le moteur correspondant.

Mon problème actuel est que je trouve que le robot ralenti lorsque plus de 3 moteurs sont actionnés en même temps (c'est l'exécution du timer qui est plus longue). J'ai optimisé le code, ça a amélioré la vitesse, mais pas de gain énorme.
Par la suite, je vais devoir ajouter la communication avec le PC (qui enverra des positions), les calculs de positions (transcription des coordonnées cylindriques r, theta, Z en coordonnées des moteurs), ce qui ralentira encore plus les calculs.

J'ai donc décidé de séparer les commandes de moteurs en 2. Un PIC gèrera les moteurs épaule, coude et poignet qui sont liés pour les positions r et z, un autre les moteurs rotation base (correspondant directement à theta) et rotation poignet et pince qui sont indépendants.
Ces deux PICs seraient gérés par un PIC maitre effectuant les calculs et éventuellement la communication avec le PC (puisque tu me conseille à juste titre qu'un PIC uniquement pour la com PC serait inutile).

Si utile, je joint le code de mon programme (j'utilise MikroC, donc les instructions diffèrent légèrement des autres compilateurs). Joyboard18F4550.zip

Mikaël

[invite860936ec]

Bonsoir, pourquoi pas laisser faire les calcules et l 'élaboration des signaux par le pc (qui est prévu pour ca )et juste utiliser un pic ,pour une liaison pc robot, qui se charge juste de diriger les signaux au bon endroit?

[A voir en vidéo sur Futura]

[inviteee2ce2b6]

Parce que je veux que le système puisse marcher sans le PC, en passant par des coordonnées entrées par un clavier ou encore à faire suivre à mon robot une suite de points listés dans un fichier texte, lui même stocké dans une carte CF par exemple.

Et aussi pour le fun, parce c'est plus compliqué de faire un calcul embarqué que de le faire faire par le PC.
Je rappelle que pour moi c'est un loisir, je ne cherche pas à réaliser une application commercialisable ou autre, je veux juste m'amuser à trouver des solutions à des problématiques plus ou moins complexes.

Je tiens à dire que je sais faire chaque bout indépendamment (ecrire et lire un txt sur une CF, piloter un moteur comme décrit, communiquer entre 2 PICs...) mais je cherche la méthode la plus simple pour atteindre mon objectif : disposer d'un robot pilotable sans PC (le PC servirait de superviseur voire de pilotage plus tard avec CATIA par exemple, mais ça c'est pour BEAUCOUP plus tard), à partir d'une platine de joysticks, d'un clavier de PC lu directement par le PIC, avec un afficheur graphique relayant les informations. Un peu dingue peut-être, mais je m'amuse et c'est bien le principal.

Pour le moment, je cherche le moyen le plus simple pour piloter mes 6 moteurs en (quasi) temps réel (donc avec un top d'horloge le plus fiable et constant possible) depuis un pupitre de 3 joysticks tout en renvoyant les infos au PC en USB.
S'il y a une solution pour optimiser mon code, je suis preneur.
Si je dois passer par 2 ou 3 PICs, je souhaite savoir quels sont les protocoles de com les plus utilisés, leurs avantages/inconvénients, et ainsi pouvoir choisir celui qui sera le plus adapté à mon besoin, tout en me rappelant de mon objectif final.

Mikaël.

[RISC]

Salut,

Un bus souvent utilisé dans les robots pour sa robustesse intrinsèque est le bus CAN.
Une autre possibilité est l'I2C si le sébit n'est pas trop important

a+

[inviteeb160de1]

Tout d'abord, si tu es sur un 18F4550, c'est loin d'être le meilleur choix.
Passes sur du PIC24 par exemple, tu gagneras forcement en vitesse de calcul car en 16 bits, et avec des clocks plus élevées.
On ne sait pas à quelle vitesse tourne ton 18F actuel ?

Aurélien

[inviteee2ce2b6]

Aurélien,
Mon PIC est cadencé à 48MHz grace à un quartz de 20MHz et les réglages qui vont bien.
Je ne me suis pas intéressé au PIC24 car je me suis équipé pour des PIC16f et 18f poir mes projets passés et ne souhaite pas spécialement réinvestir dans le matos pour pic24. De plus, on trouve plus d'aide et de monde connaissant les 18f que les 24... Mais ça reste mon avis.

En partant de l'hypothèse que je souhaite rester sur 18f, que me conseilles-tu ? Je ne suis pas contre changer de PIC, le 4550 n'est peut-etre pas le meilleur choix, mais je ne changerai que si le gain de performances et suffisant.
Donc, vos conseils pour diriger mon étude sur ce projet ? Type de structure ? Type de communication ? Je cherche à apprendre et non à avoir seulement les réponses sans explications... Donc si vous avez de la bibliographie (structurer les timers, les types de communications...), je suis preneur

Bonne soirée.

Mikaël

[invite29971eb1]

N'oublie pas qu'un PIC18 à 48MHZ, c'est un micro à 12MHz au final....