SPI : RPi en mode esclave ? Alternatives ?

Des infos, des conseils sur les bus DSI,CSI, I2C, SPI... du Raspberry Pi

Modérateur : Francois

Pinhapple
Raspinaute
Messages : 122
Enregistré le : jeu. 23 févr. 2017 16:53
Localisation : Rouen

Re: SPI : RPi en mode esclave ? Alternatives ?

Messagepar Pinhapple » jeu. 13 juil. 2017 11:26

spourre a écrit :Oh put* le c*n, j'ai failli lire autre chose :lol: :lol: :lol:

J'ai pas envie de savoir mais je pense savoir quand même ! :lol:

spourre a écrit :Tu as bien compris ma proposition (honnête).
Tu peux aussi avoir une autre approche:
Le SPI du Raspberry peut gérer 2 esclaves , par un signal CS (chip Select). Tu peux utiliser ce signal pour demander la transmission à intervalle régulier (timer ? thread ?). C'est mieux que le polling et c'est le Pi qui garde le contrôle.

Les broches 24 et 26, respectivement SPI_CE0_N et SPI_CE1_N ? J'ai mon branchement sur la 0 actuellement.
Le souci du timer qui vient à l'esprit, c'est qu'il y a un risque de décalage : si je demande une transmission toutes les n microsecondes mais que le signal est légèrement décalé, je risque de louper le coche à un moment. :?

spourre a écrit :Dans le sens Arduino (5V) vers Pï (3.3V), un pont diviseur est suffisant.
Dans le sens Pi (3.3V) vers Arduino (5V), tu n'as pas besoin de pont diviseur mais, comme dé"jà expliqué (hé hé), il y a un risque de mauvais fonctionnement très difficile à déceler: En logique CMOS les niveaux H(ight) et L(ow) sont définis respectivement à 2/3 et 1/3 de Vcc (alimentation). Entre ces 2 niveaux, il y a indétermination, et le circuit peut prendre n'importe quel état.

Oui, je me souviens bien de ton explication du inférieur à 1/3 pour le LOW, supérieur à 2/3 pour le HIGH, et le flou entre deux. ;)
Pour l'instant dans mes tests, ça communique sans souci visible en tout cas. Si ça venait à poser problème, comment corriger ça ? (je pense à l'inverse d'un pont diviseur de tension, un "pont multiplicateur de tension" ? :D )
  • RPi 3 + RetroPie ; RPi 3 + Sense HAT ou Framboisedorf ; RPi B+ + OpenELEC
  • Arduino Mega, Uno, Nano
  • FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 891
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: SPI : RPi en mode esclave ? Alternatives ?

Messagepar destroyedlolo » jeu. 13 juil. 2017 14:39

Yo !

spourre a écrit :Côté Arduino, le programme (ou la thread) qui traite les signaux, fait le calcul et remplit le buffer de transmission, termine en mettant une pin (à déterminer) à 1 puis 0.

Là, côté PI, c'est un cas idéal d'utilisation d'interruption : comme ca, pas besoin de faire du polling bouffeur de CPU.

Pour la conversion 3.3 <-> 5.v, il y a aussi des "level shifter" tout fait à base de mosfet et qui ne coutent que quelques centimes. Souvent utilisé par exemple pour les bus I2C.

A+
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo.
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Sur mon site un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 468
Enregistré le : lun. 22 déc. 2014 17:50
Localisation : 67380 LINGOLSHEIM

Re: SPI : RPi en mode esclave ? Alternatives ?

Messagepar spourre » jeu. 13 juil. 2017 16:49

destroyedlolo a écrit :...
Pour la conversion 3.3 <-> 5.v, il y a aussi des "level shifter" tout fait à base de mosfet et qui ne coutent que quelques centimes. Souvent utilisé par exemple pour les bus I2C.

A+


Toutafé.
Sinon, le moindre petit transistor qui traîne au fond de la boîte à malices peut convenir.

Je ne sais si notre ami alimente son Arduino à partir du 5 V du Pi, mais ça peut aussi éviter que les 2 alims dérivent en sens inverse, même en restant dans la tolérance:
Celle du 5V à 5 V et des poussières, Celle du 3.3V à 3.3V - des poussières ==> risque indétermination du niveau O ou 1 fournit par le Pi.

Sylvain

spourre
Raspinaute
Messages : 468
Enregistré le : lun. 22 déc. 2014 17:50
Localisation : 67380 LINGOLSHEIM

Re: SPI : RPi en mode esclave ? Alternatives ?

Messagepar spourre » jeu. 13 juil. 2017 17:09

Pinhapple a écrit :...
Les broches 24 et 26, respectivement SPI_CE0_N et SPI_CE1_N ? J'ai mon branchement sur la 0 actuellement.
Le souci du timer qui vient à l'esprit, c'est qu'il y a un risque de décalage : si je demande une transmission toutes les n microsecondes mais que le signal est légèrement décalé, je risque de louper le coche à un moment. :?
)


Oui, sur mes docs, il y a bien CE indiqué , le E vient de Enable.
Qu'as-tu branché dessus côté Arduino ? Normalement, il n'y a pas de donnée qui transiste dessus, juste un changement d'état pour dire quel est l'esclave interrogé.

Il me semble que tout au début de nos échanges, pour des problèmes de rapidité justement (écriture vers la SD), Bud t'avait suggéré un tampon (buffer) circulaire .
Évidemment, si le Raspberry est trop chargé et que l'Arduino pédale trop vite, ça finira par une perte de données.
D'où l'intérêt d'alléger au maximum le PI en faisant maigrir son OS et en le déchargeant de l'acquisition/conversion des signaux.

On retombe sur la problématique bien évoquée dans l'autre discussion (UDP) de la volumétrie et du débit (liaison ET traitement)..
Destroyedlolo y a bien rappelé la problématique et les éventuelles solutions. J'avais aussi lourdement insisté sur le choix de la bibliothèque pour pousser le Pi dans ses retranchement avant de se lancer dans le RT ou le driver dans le kernel ( voire passer au bare metal).
Ce sont des piste intéressantes mais trop compliquées à explorer dans le peu de temps qu'il te reste.
Tu pourrais esayer la lib bcm qui est moins sexy que libwiringpi mais qui est, du coup, plus proche du hard. Même si maintenant tu as de bons réflexes en C + lib, ça reste un gros morceau à avaler (j'ai pas encore sauter le pas).
Sylvain


Retourner vers « Les BUS interfaces »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité