SPI multi esclave

[gcortex]

Bonjour,

J'utilise un arduino uno configuré en maitre qui envoie un octet dans le vide,
pour récupérer un octet d'un pic 18F13K22 en esclave activé par la pin SS/

jusque là tout va bien, mais quand je mets 2 pics avec le SDO de l'un sur
le SDI de l'autre et les pins CLK et SS/ en commun, rien ne va plus.

J'envoie ma donnée et j'attends 2 "receive complete" avec lecture fictive
pour remettre le flag à zéro.

Normalement quand je vide le buffer, il doit se remplir en même temps
avec la donnée du 2ème pic or ce n'est pas le cas.

Je transmet puis je lis, mais dans la doc (qui ne parle pas de chainage),
il faut lire avant d'écrire : Faut il lire puis renvoyer ma 2ème donnée,
ou c'est automatique (ce que je suppose) ?

Merci.
-----

[inviteb565bafd]

Bonjour,

Je n'ai pas vérifié la datasheet du PIC, mais es-tu sûr qu'il gère le daisy-chain? Il me semble que peux de PIC gère cette fonction, et d'après ta config tu veux que les données transitent d'un PIC à l'autre (SDO vers SDI en utilisant les pin SS comme latch)
Le muti-esclave standard consiste à relier les SDO ensemble, les SDI ensemble, les SCK ensemble, et chaque Chip Select (CS ou SS) est commandé indépendamment pour adresser l'esclave concerné.
Bien sur il faut t'assurer que tes PIC sont bien configurés en esclave.

[gcortex]

Merci pour ta réponse. Comment savoir s'il gère ou pas le daisy chain ?
Si ce n'est pas le cas, c'est très mauvais pour mon projet !

http://www.microchip.com/wwwproducts/en/PIC18F13K22

[inviteb565bafd]

En fait je crois que cette fonction n'existe pas sur les PIC16F et 18F, à voir si c'est disponible sur les PIC24 et 32.

Tu peux essayer de l'implémenter en soft mais c'est compliqué car c'est le maître qui va générer les fronts d'horloge sur SCK. De plus le PIC que tu veux utiliser n'a qu'un module SPI et ne peut pas être mapper sur d'autres pins (cette fonction n'est disponible qu'à partir des 24F).
Avec un PIC qui a deux modules SPI (par exemple PIC18F26K22) tu peux tenter d'émuler ce mode de fonctionnement :

char receivedByte=0;
char previousByte=0;
bool SPI1_receivedByte=FALSE;

SPI1_init();
SPI2_init();

if(SPI1_byteReceived==TRUE)
{
previousByte=receivedByte; // déplace la valeur courante vers la valeur précédente
receivedByte=SPI1BUF; // nouvelle valeur courante
SPI2_sendByte(previousByte); // envoie la valeur précédente sur le second port SPI vers l'autre PIC
SPI1_receivedByte=FALSE;
}

J'ai essayé de faire simple, dans le principe tu n'as plus aucune liaison entre le second PIC et le maître : le premier PIC reçoit du maître sur SDI1, SCK1 et SS1 et renvoie les info au maître par SDO1. Le PIC n°1 va également générer SDO2, SCK2 et SS (GPIO) vers le PIC n°2 et recevoir sur SDI2.

Je ne sais pas exactement comment est gérée l'interruption du SPI en mode slave, si c'est uniquement avec le buffer full, tu peux utiliser les pins SS en commaun pour faire la fonction latch. si l'interruption se fait avec un évènement sur SS, tu vas devoir utiliser une autre GPIO commune pour faire le latch.

Quelle est la contrainte liée à l'utilisation de ce PIC?

Quelle est la contrainte d'utiliser cette configuration plutôt que l'adressage individuel? Si c'est pour économiser des I/O tu peux passer par de l'I²C. Plus besoin de chip select, l'adressage se fait en soft.

[A voir en vidéo sur Futura]

[gcortex]

C'est une très mauvaise nouvelle. J'ai pris le pic18 le moins cher et j'ai routé des cartes avec.
L'environnement est susceptible d'être bruité et le but est de mettre beaucoup d'esclaves.

C'est pour çà que j'ai choisi une liaison plutôt robuste et simple à mettre en oeuvre.
Il y a peut être un tour de passe-passe, pour que je ne refasse pas des autres cartes !!!

[Seb.26]

Tu as besoin d'un gros débit/volume d'info ?

Mets nous un petit schéma de principe sur tes connexions stp

[gcortex]

Pas besoin d'un gros débit.
La première réponse tend à confirmer : http://www.microchip.com/forums/m562477.aspx
Dans les années 70 on pouvait chainer. C'est çà le progrès ? Merci microchip !

[inviteb565bafd]

Le problème c'est qu'en SPI il me semble que les niveaux sont fixés par le maître.
Il y a bien un truc qui peut se tenter mais il faudra bien gérer les timing (utilisation des interruptions fortement conseillées) et ça risque de dépendre du nombre de uC que tu mets sur la ligne :
- Tu as toujours la gestion de valeur courante et ancienne valeur à gérer comme dans mon exemple
- Une fois que le maître a émis un octet (en générant SCK vers les autres périph), il passe en esclave pour ne pas occuper la ligne
- Une fois qu'un des PIC (esclave) reçoit un octet, il le garde en mémoire, il passe en maître, transmet l'ancienne valeur au PIC suivant, et repasse en esclave.

Dans ce sens là ça paraît assez simple.

Ce qui est plus difficile, c'est de faire remonter l'info, car ton SDI ne peut pas devenir un SDO, et inversement...

[inviteb565bafd]

Trop tard pour l'edit, si en fait il faut relier ton dernier SDO au SDI de l'arduino, ça peut se tenter, c'est pas sans complications mais sur un malentendu ça peut marcher!

[invitee05a3fcc]

Pourquoi utiliser du SPI ?

Pas besoin d'un gros débit.

moi, je verrai plutôt du RS485 en transmission asynchrone

[inviteb565bafd]

moi, je verrai plutôt du RS485 en transmission asynchrone

C'est vrai que les protocoles ne manquent pas, mais du coup les périphériques sont figés* sur les PIC18F. Les PIC24 et 32 ont la fonction Remappable Pin qui permet de choisir (avec quelques contraintes quand même) sur quelles I/O tu veux tes périphériques.

Il y a toujours possibilité de passer par du bus CAN avec des transceiver SPI, mais bon c'est rajouté de la complexité...

* Il y a moyen d'implémenter un périphérique virtuel avec du bit-banging, mais c'est pas toujours évidant de détecter des interruptions et éviter les erreurs de transmission

[gcortex]

Pourquoi utiliser du SPI ?

Pourquoi pas ?

moi, je verrai plutôt du RS485 en transmission asynchrone

Pas besoin d'une usine à gaz !

[Seb.26]

selon le câblage il y a probablement une solution à faire en soft ...

[Seb.26]

Vu ton câblage je ferais un bus synchrone en boucle :

Arduino est le #0 (le maitre)
-> il génère l'horloge (tout le temps)
-> il emet sur MISO
-> il reçoit sur IO

PIC1 est le #1 ( esclave)
-> il est synchro avec l'horloge
-> il emet sur SDI
-> il reçoit sur SDO
-> SS en entrée (non utilisée)

PIC2 est le #2 (esclave)
-> il est synchro avec l'horloge
-> il emet sur SS
-> il reçoit sur SDO

le tout avec des trames qui inclus une adr de destination et une adr d’expéditeur (#0/#1/#2) et avec 1b de start + 8b de data + 1b de stop

...

> chaque CPU fait suivre une trame qui ne lui est pas destinée si elle est valide (sauf l'expediteur de la trame qui la poubelise)
> chaque CPU détruit une trame incomplète ou corrompue (CRC)
> chaque CPU traite une trame qui lui est destinée

[invitee05a3fcc]

Pas besoin d'une usine à gaz !

C'est pas une usine à gaz !!! Tu n'as même pas évalué cette solution .

[gcortex]

C'est pas une usine à gaz !!! Tu n'as même pas évalué cette solution .

J'évalue dans l'ordre. Si çà c'est pas une tuile !

Les Freescale fonctionnent en daisy-chain ?

Merci pour vos réponses.

[invitee05a3fcc]

J'évalue dans l'ordre. Si çà c'est pas une tuile !

Tu as quelle distance entre tes différentes cartes ?

[inviteb9a90acc]

Si c'est la sélection de l'esclave qui te pose problème pourquoi ne pas faire un système de jeton.
Tu utilises 2 gpios de plus sur l'arduino : un pour sélectionner l'esclave suivant et un autre pour que le dernier esclave te renvoie le jeton (fin de chaine).
Chacun de tes pic esclave à une entrée "JetonIn" (configurée avec IOC) qui recoit le jeton (de l'arduino pour le premier et du pic esclave précédent pour les autres). Avec interrupt-on-change du PIC tu configure une interruption, celle-ci s'occupe d'activer le SPI du pic lors du premier appel. Les appels suivant désactive le SPI de l'esclave et recopies le signal jeton in sur jeton out (du pic suivant). Le systeme de jeton est remis à 0 par l'arduino avec jeton reset.
Lorsque que le dernier PIC envoie le signal jeton in sur jeton out, c'est l'arduino qui le recoit. Il sait alors que tous les esclaves ont été interrogé. L'arduino envoie le signal JetonReset sur tous les esclaves, leur pin jeton reset étant elle aussi configurée avec l'IOC.

[gcortex]

Tu as quelle distance entre tes différentes cartes ?

3 cm entre les pics (un peu plus en longueur des pistes), et pour l'instant l'arduino est à un petit mètre.

Merci pour le système de jeton, ainsi que les autres pistes.

[gcortex]

moi, je verrai plutôt du RS485 en transmission asynchrone

Tu as un cours sur cette fameuse liaison dont tout le monde parle ?

[invitee05a3fcc]

Tu as un cours sur cette fameuse liaison dont tout le monde parle ?

Tu peux répondre à cette question :

Tu as quelle distance entre tes différentes cartes ?

[inviteb565bafd]

DAUDET la réponse est dans le message juste avant le tien

3 cm entre les pics (un peu plus en longueur des pistes), et pour l'instant l'arduino est à un petit mètre.

Le RS485 serait une solution parmi d'autre et aurait permis de simplifier le problème s'il avait été prévu au départ. Le problème majeur que j'ai déjà souligné précédemment c'est que sur cette famille de microcontrôleurs on ne peut pas router les périphériques sur une autre broche. Ce qui fait que SDI, SDO et SCK ne peuvent être autre que des I/O ou SDI, SDO et SCK, et en aucun cas tu ne peux les utiliser pour un UART par exemple.

Comme le hard est déjà fait, et qu'il ne semble pas pouvoir être modifié, c'est le soft qui doit être adapté. Certes le choix n'était peut être pas judicieux mais ça arrive à tout le monde de faire des erreurs, et on peut encore corriger le tir

Les solutions possibles actuellement sont :

- Configuration en étoile avec chip select indépendant (utilisation standard du SPI). Inconvénient : il faut autant de Chip Select sur le maître qu'il y a d'esclave (ou utiliser un circuit multiplexeur)
- Configuration Daisy-Chain avec inversion des rôles (l'esclave devient maître le temps de transférer l'octet au prochain esclave) en rebouclant le SDO du dernier esclave sur le SDI du maître. Chaque esclave est adressé par son chip select, donc il te faut une I/O supplémentaire pour le latch commun (à voir si c'est réellement nécessaire). L'inconvénient, c'est que ça prend plus de temps qu'un vrai Daisy-Chain, et que ça peut ne pas fonctionner si le temps est mal géré (par exemple un esclave passe maître avant que le maître précédent devienne esclave, tu te retrouves avec deux maîtres sur le bus et potentiellement une collision de donnée)
- Configuration étoile avec jeton comme proposé par Johnplayer, si tu as des I/O de dispo, je te conseille de partir sur cette solution.
- Interface logicielle avec la technique de bit-banging, l'avantage c'est que tu es libre d'implémenter ton propre protocole, y compris un daisy-chain (en restant dans les limites temporelles de ce que peut faire le micro). L'inconvénient, c'est que c'est pas toujours évident de bien interpréter les données reçues, et pour debugger c'est pas simple non plus.

Concernant la distance, faire transiter de la SPI sur 1m ça me paraît pas top, ça peut marcher mais il faut pas qu'il bourine à 50 MHz, et dans un environement pas trop bruité. peut être que tu devrais convertir tes signaux en différentiel avec un transceiver pour chaque signal en émission et réception, sinon une interface SPI<=>UART<=>Transceiver RS-422/RS-485, simplement pour avoir du différentiel. C'est des signaux plus lents que la SPI, donc attention à ton temps entre 2 transmissions

[gcortex]

Merci. 1m c'est provisoire, et l'arduino aussi. Et je ne sais pas si je vais garder le pic.

J'ai déjà vu un µC Freescale qui fait 4 échantillonnages simultanés et çà m'intéresse !

[gcortex]

Et si mon arduino envoie l'adresse de l'esclave et que l'esclave concerné répond soit en tant que maitre,
soit en tant qu'esclave, çà peut marcher non ? Comme çà je n'ai pas grand chose à modifier !

[invite830075ec]

J'ai pas compris pourquoi il n'est pas possible que le maître envoie 2 octets et reçoive en retour 2 datas, chacune d'elle envoyée par un des 2 pic esclaves. Il faut entre les 2 octets envoyés une tempo d'attente que l'ISR spi des esclaves s'exécute, c'est ça qui coince ?

[inviteb9a90acc]

Tu ne peux pas demander au maitre d'envoyer une adresse sur le réseau en sélectionnant tout tes esclaves. Le SPI n'est pas un réseau multipoint! Tu as 1 maitre, plusieurs esclaves mais 1 seul est actif à la fois, c'est une communication synchrone entre un maitre et 1 esclave.

Le maitre place un état sur MOSI (SDO maitre, SDI esclave) puis valide l'état avec un top d'horloge. MAIS l'esclave à lui aussi placé sa réponse sur MISO (SDI maitre, SDO esclave). Bref, à chaque top d'horloge du maitre c'est un échange de bit qui se fait entre maitre et esclave. Donc si tout tes esclaves sont sélectionnés en même temps, tout tes esclaves envoie une données au maitre en même temps! Un gros caffouilli quoi.

Pour ce que tu veux faire, utilise soit un systeme de jeton ou assimilé, soit un réseau multipoint genre RS485 ou CAN. Les PIC intégrent un UART avec transmission 9Bits et un flag "adress auto-detect" qui permet de faire facilement un réseau RS485 avec adressage. L'avantage c'est que le pic ne réagit que lorsque le maitre envoie un trame avec le 9ème bit à 1. S'il est à 0 le PIC non concerné n'a pas d'interruptions qui viennent le déranger.

[gcortex]

Oui mais je souhaite transformer 1 octet de donnée en 1 octet d'adresse et faire 1 programme spécifique pour chaque esclave.
On peut désactiver par soft le SDO. Je n'ai pas compris non plus d'où vient l'adresse sur la RS485 à partir de Rx et Tx. Merci.

[inviteb9a90acc]

D'abord il faut que l'arduino supporte la transmission sur 9bits, normalement c'est possible mais je n'ai jamais utiliser d'arduino donc ce sera à toi de te renseigner la dessus.

Pour faire du RS485 avec un PIC, il faut utiliser un convertisseur UART/RS485 (genre SN65176).

Dans ton PIC, tu actives le bit TX9 du registre TXSTA ainsi que le bit RX9 du registre RCSTA. Tu actives l'auto-detection d'adresse avec ADDEN du registre RCSTA.
Si ADDEN=1, la réception d'une donnée ne déclenche une exception que si le RX9D(esclave) = TX9D(maitre) = 1 .

Je considère que ton PIC est uniquement esclave et l'arduino est le seul maitre du bus.
Avec ton arduino, tu transmets donc sur 9bits, TX9D + data. Si TX9D = 1, data est une adresse, s'il vaut 0 c'est une donnée.

DEROULEMENT TRANSMISSION :
- Ton arduino envoie une adresse, TX9D = 1 + adresse 8bits;
- Tes pics ont ADDEN=1 donc le fait que RX9D=1, déclenche une interruption.
- Les PICs comparent leur adresse à celle reçue (les 8 bits de données consécutifs à TX9D).
Si elle ne correspond pas, il ne fait rien. Sinon, il y a démarrage d'une conversation donc il met à zéro ADDEN afin de recevoir les données et il envoie un octet de confirmation(TX9D=0+data8bits) comme quoi il est prêt.
- Ton arduino réceptionne l'octet de confirmation, il commence à envoyer des données au pic connecté (les autres ne répondront pas puisqu'ils ont ADDEN actif et que l'arduino mets TX9D à 0 pour envoyer des données).
- Lorsque la conversation est terminée, le PIC remet ADDEN à 1 et attends la prochaine adresse envoyé par l'arduino.

Je ne suis pas être pas très clair mais si tu jettes à coup d’œil à une doc d'un PIC dans la rubrique EUSART, ça s'éclaircira. Il y a des diagrammes du périphérique.

[gcortex]

Je vais essayer la SPI en 8 bits (l'arduino n'envoie que des adresses donc pas de confusion).
Si çà va pas, je fais comme tu as dit. Merci à tous pour vos réponses.

[gcortex]

Bonjour,

Le pic en esclave n'envoie que des 2,
çà veut dire qu'il ne reçoit que des 0 !

le code de l'arduino :

#include <SPI.h>

byte n;

void setup() {
  pinMode(8, OUTPUT);
  //pinMode(11, OUTPUT);
  SPI.begin();
  Serial.begin(9600);
}

void recep(byte i)
{
  digitalWrite(8, LOW);
  n=SPI.transfer(i);
  digitalWrite(8, HIGH);
}  

void loop() 
{
    recep(1); Serial.print (n); Serial.print (";");
    recep(2); Serial.print (n);Serial.print (";");
    recep(3); Serial.print (n);Serial.print (";");
    recep(4); Serial.print (n);Serial.println ();
    
}

le code du pic :

short in;

void send (void)
{
    in=0;
    while (in==0) {in=SSPSTAT & 0x01;};
    in=SSPBUF;
    SSPBUF=in+2;
}

void main (void)
{
    OSCCON=0x72;
    SSPSTAT=0x40;
    SSPCON1=0x24;
    DDRC=0x6F;
    while(1)
    {
        send();
    }
}

C'est un bug des pics ?
Merci.