SPI-CS-Extension

SPI-CS-Extension am RaspberryPi

Der Raspberry Pi ist mit dem SPI Bus ausgestattet. SPI ist ein 4 Drath Bus System an den die Geräte über die 4. Leitung, dem sogenannten Chip Select, angesprochen werden. Sobald der Master das System selektiert hat (durch LOW des CS Signals) horcht der Empfänger auf dem BUS und man kann mit dem Device kommunizieren. Das Problem ist die Anzahl der CS Leitungen, sie ist beim RaspberryPi auf 2 begrenzt. Somit könnten nur 2 Systeme mit dem Master kommunizieren. Das könnte und ist für viele Anwendungen zu wenig.

 

Wie kann eine Lösung dafür aussehen?

  • Verwendung von freien GPIO Pins am Raspi
  • Einsatz von Adressdecodern  .... 74138/9
  • CS Leitungen mit einem MCP2317 am I2C Bus
  • ...

 

Alle diese Lösungen benötigen frei GPIOs oder weitere technologische Konzepte des Raspi und damit legt man sich fest und verliert flexibilität in der Zukunft. Auch das Debugging wird komplizierter, wenn beispielsweise neben dem SPI Bus nun auch der I2C Bus in der Kommunikation überwacht und analysiert werden muss.

Ich favorisiere ein System wo die bestehende SPI Infrastruktur so erweitert wird, dass es das übrige System des Raspi dadurch nicht beeinflusst. Hier wird also die bestehende SPI Infrastruktur so erweitert das keine PINs des Raspi oder andere BUS Systeme zum Einsatz kommen. Ein Nachteil gibt es aber schon - es ist zusätzliche Hardware notwendig

 

Mein Konzept:

  • Es stehen zwei CS Leitungen zur Verfügung und diese sind auch in den Libraries zur Programmierung integriert. Beipielsweise: wiringPI
  • Der MCP23S7 hat die Möglichkeit einer Adressauswahl (A0..A2). Es können also bis zu 7 Systeme mit 16 Ports angesprochen werden. Daraus resultiert eine theoretische Anzahl von 7 x 16 CS Leitungen = 112
  • CS0 wird ausschliesslich zur Kommunikation mit dem/ den MCP23S17 verwendet
  • CS1 wird für die eigentliche Kommunikation mit den Geräten auf dem SPI Bus eingesetzt.
  • Damit es mit den CSx Signalen keine Timing Problem gibt müssen die Ausgänge des MCP23S17 ODER verknüpft werden mit CS1. Das stellt sicher, CSx ist nur dann auf LOW geht, wenn auch CS1 für die Kommunikation verwendet wird.
  • Programmiertechnisch ist vor und nach einer SPI Kommunikation mit dem Device nun auf das setzen der richtigen CSx Line zu achten. Dieser Punkt ist keine Besonderheit Meiner Lösung, es ist vielmehr ein Punkt der bei jeder Erweiterung zutrifft. Dieser lässt sich aber programmiertechnisch lösen, wenn das Konzept ganzheitlich umgesetzt wird.
  • Beim debuggen am logic Analyser sind nur 4 Leitungen relevant, MOSI, MISO, CLK und CS1 unter der Annahme das die Software CSx entsprechend setzt und die ODER Verknüpfung zwischen CS1 und CSx funktioniert.Damit ist zumindest das debugging einfacher als wenn noch andere Systemkomponenten hinzugezogen würden.