Que ce soit en spi ou i2c, le 23x17 utilise exactement les mêmes registres donc à l’utilisation ça ne doit rien changer puisque seul le protocole de communication change. Il y a juste une petite variante qu’il faut connaitre, c’est que sur le 23s17 (spi), le bit IOCON.HAEN est R/W et est à 0 par défaut alors qu’il est juste R sur le 23017 (i2c) et il est fixé a 1. Ce bit défini l’utilisation du mode adressable du composant (pin A0..A2), donc si on veut utiliser plusieurs 23s17 sur la meme SPI, il faut juste penser à le mettre à 1 a l’initialisation (j’en ai déjà parlé plusieurs fois sur ce forum, mais je ne sais plus ou).
SPI ou I2C ont chacun leur avantage et leurs inconvénients. Je ne connais pas les motivations de ortoelec pour le choix de la spi mais il y a bien plus d’intérêt à utiliser ce protocole que l’i2c
Avantage :
I2C : 2 fils de liaison seulement au lieu de 4 sur la spi
SPI : Beaucoup plus rapide (10MHz contre 400KHz max en i2c sur le PI) et échange simplifié (Pas d’ack entre l’opcode et le set du registre visé).
SPI : Le slave travail à la fréquence d’horloge imposé par le master quelle qu’elle soit. La fréquence d’horloge n’est donc pas critique et peut etre adaptée à toute contraintes de liaison. En i2c, si la fréquence du master n’est pas vraiment stable, cela génère des erreurs (c’est d’ailleurs pour ça qu’elle est fixé à 100KHz par défaut sur le PI)
SPI : L’adaptation d’un slave en 5V sur un master 3.3v (cas du pi) ne requière qu’une résistance sur le ligne MISO quel que soit le nombre de composant sur le bus (j'ai aussi déjà parlé de ca sur ce forum).
Apparemment tu as tous ce qu’il te faut
ICI. Le petit exemple de code sur la page met toutes les i/o de l’expander en sortie et les blink. Tu dois d’abord installer
RPi.GPIO et
spidev comme
précisé dans les commentaires de la lib. Une autre solution, c'est d'utiliser
CircuitPython avec les modules
Adafruit .
Attention toutefois a tout ce que tu vas trouver en exemple pour le PI et python. Beaucoup de chose sont deprecated voir meme totalement morte (comme par exemple tout ce qui repose sur wiringPi ...). Quelle que soit la méthode, la
datasheet du composant reste une source d'information incontournable.
jelopo a écrit : ↑ven. 26 nov. 2021 09:20
Dans un premier temps, ne serait-il pas judicieux de jouer avec la version I2C, mieux documentée sur le net, pour comprendre les principes de fonctionnement avec Python ?
Le probleme, c’est que ça va lui faire des modifs de code pour basculer de l’un a l’autre. D’une part parce que les noms des fonctions et les paramètres à leurs passer ne seront pas forcément les mêmes entre une lib écrite pour spi et une lib écrite pour l’i2c. En plus cela ferait appel à des interfaces différentes (/dev/i2c et spidev). L’idéal pour ça, serait de trouver une librairie qui repose sur une méthode unique d’accès au hardware et qui accepterait le type protocole en paramètre. C’est ce que je fais notamment avec .NET qui utilise libgpiod pour tout accès aux GPIO et C# qui facilite la surcharge de constructeur multiple. En code ça donnerait un truc tout simple du genre :
Où
Rien d’autre dans le code ne changerait pour passer de l’un a l’autre et toutes les autres fonctions d’accès au GPIO serait disponible sans avoir besoin de rien d'autre.
https://github.com/dotnet/iot/tree/main ... s/Mcp23xxx
Je n'ais pas écrit grand chose sur le MCP23S17 mais il y a quand meme des exemples en JS ou je n'utilisais aucune librairie spécifique pour le composant :
(
viewtopic.php?f=44&t=3033&start=60#p27268 ). Je l'avais aussi utilisé pour le projet 'datalogger' (
viewtopic.php?f=44&t=3033&start=80#p28151 ) .