GPIO schalten

Markus schrieb:
> Jetzt habe ich vom SPI Verfahren gehört und möchte wissen wie man
> einzelne GPIO Pins als CS deklariert oder MOSI oder MISO.

SPI ist kein Verfahren, sondern ein Bussystem.

Der Raspberry Pi hat fest definierte Pins für SPI, da die Kommunikation 
ein Hardwareteil im Prozessor übernimmt. Entsprechende Libraries für den 
Pi interessieren sich dann nicht mehr für die Pins, sondern nutzen das 
im Device-Tree. Von dort aus geht es dann über den entsprechenden 
Kerneltreiber an den Hardware-SPI im Prozessor, der fest mit bestimmten 
Pins verbunden ist.

Wofür brauchst du SPI denn?
Wenn man lernen will, wie's funktioniert, kann man sich auch ein 
Soft-SPI erarbeiten, das zwar langsam ist, aber mit jeden GPIOs 
funktioniert und man lernt, wann welcher Pin was zu tun hat.


Ansonsten gibt es zum SPI am Pi ebenfalls sehr viele Tutorials.

Markus schrieb:
> Das muss doch
> möglich sein

Ein CS ist auch nur ein normaler Ausgang. Und wie du GPIOs ansteuerst, 
weiß du ja. Dann musst du in deinem Code einfach nur selber den CS 
umschalten.

Geht's noch? Schon wieder ein neuer Thread?

Markus schrieb:
> Jetzt habe ich vom SPI Verfahren gehört
Und im Beitrag "SPI-Verfahren" sowie den 
Vorgänger-Threads das Thema schon extensiv durchgekaut. Hast du 
inzwischen mal mit dem Oszilloskop nachgemessen, ob der SS-Pin was tut? 
Oder den mal statisch auf 0 oder 1 geschaltet und mit dem Multimeter 
gemessen?

Überhaupt müsstest du wenigstens mal grundlegend verstehen wollen, was 
SPI ist und wie SPI funktioniert. Das ist in ein paar Zeilen erklärt:
http://www.lothar-miller.de/s9y/categories/17-SPI
Und wenn du dann selber ein wenig mitdenkst, dann kommst du drauf, dass 
du  einfach den SPI-Treiber die SPI-Schieberegister verwalten lassen 
kannst, und du selber irgend einen Pin als SS# selber in die Hand 
nimmst.

Markus schrieb:
> Ja zum Beispiel ist beim Raspi GPIO 7 und 8 CS0 und CS1 aber was ist
> wenn ich jetzt einen anderen GPIO als CS verwenden will.
Wie gesagt:
1. verwende irgendeinen Pin als SS# und setze den auf low
2. starte einen SPI-Transfer und ignoriere den dort spezifizierten 
SPI-Pin
3. setze den irgendeinen SS# Pin wieder auf high
Fertig.
Denke über jeden der 3 Schritte sorgfältig nach. Es ist tatsächlich so 
einfach.

> Das muss doch möglich sein
Die Hardware und/oder die zugehörigen Treiber können das nicht. Und du 
kannst die Treiber nicht ändern. Ergo: allein mit den angebotenen 
Funktionen ist es NICHT MÖGLICH, auch wenn du unbedingt meinst, dass es 
das "muss".

Markus schrieb:
> wie kann ich z.B meinen MISO Anschluss von Gpio 9 auf z. B GPIO22 setzen
Du kannst das NICHT auf x-beliebige Pins setzen, weil die SPI-Hardware 
auf dem Silizium des Controllers an genau diesem Pin angeschlossen ist.

Markus schrieb:
> bitte exakt den Code schicken
Bitte selber denken.

Im Ernst: es sieht so aus, als ob dieses Hobby dich ziemlich überfordern 
würde. Aber vielleicht wirds ja noch was, wenn du hartnäckig dran 
bleibst. Viel Erfolg dabei.

Markus schrieb:
> Ok mir war bekannt dass man den CS auf jeden GPIO legen kann ...
> verwunderlich...

Wenn du dich selber in deinem Programm um den Chip Select kümmerst, geht 
das. Dann kannst du auch 200 Chip Selects mit IO-Expandern (I2C oder 
Schieberegister) implementieren und dann im Code durch die einzelnen 
"Chips selecten".

Der Linux-Kerneltreiber für SPI hat allerdings die 2 bzw. 3 CS-Signale 
fest verbaut. Für bestimmte Funktionen ist das erforderlich. Wenn z.B. 
ein SPI-Flash im Dateisystem als Speicher auftauchen soll oder wenn ein 
SPI-Beschleunidungssensor wie eine Maus im System auftauchen soll. Dann 
hat Linux selber gerne die Kontrolle darüber, was wo angeschlossen ist, 
weil's auch um Geschwindigkeit und Latenz geht.

Wenn du nun gemütlich deine 20 AD-Wandler abfragen willst, dann kannst 
du einfach GPIOs in einem Source definieren und als Chipselect nutzen, 
weil es dann wohl eher nicht auf Latenz ankommt und deine AD-Wandler 
nicht im Devicetree mit Kerneltreiber auftauchen sollen/müssen.

weiter weg schrieb:
> Lothar M. schrieb:
>> Du kannst das NICHT auf x-beliebige Pins setzen, weil die SPI-Hardware
>> auf dem Silizium des Controllers an genau diesem Pin angeschlossen ist.
> nur die halbe Wahrheit. Enweder hat der Raspberry gar keine SPI-
> Maschine die auch einen CS bedient
Bei miner Aussage gings um die beliebige Zuordnung von MOSI und MISO. 
Das bieten nur ganz wenige Controller. Manche haben noch eine oder zei 
Platzierungsalternativen, dann kommt man aber wieder mit anderen 
Funktionen in Konflikt.

> Enweder hat der Raspberry gar keine SPI-Maschine die auch einen CS bedient
Weil es da einen DMA-Modus gibt, wo die Hardware den SS# bedient (siehe 
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#chip-selects) 
ist es naheliegend, dass in diesem Mode auch nur genau die 
vordefinierten SS#-Pins funktionieren.

Markus schrieb:
> OK mein SPI arbeitet aber nunmal falsch konnte einen defekten Pin
> ausschließen jetzt. Jetzt müsste ich mit einem oszi die signale
> aufnehmen um den Fehler zu finden ? Allerdings wäre ich mir nicht sicher
> wie dieser dann zu beheben wäre

Solange du nicht weißt, was dein Problem ist, gibt es dafür auch keine 
Lösung.

Und wie weißt du ohne Oszi, dass kein Pin defekt ist?


Und irgendwie habe ich die Vermutung, dass entweder dein Aufbau oder 
dein Code falsch ist.

Markus schrieb:
> Aus irgendeinem Grund werden die Bits falsch übertragen aber es liegt
> definitiv nicht am Aufbau.

Wie kannst du den Aufbau ausschließen?

> finde die richtige Software leider nichtmal
Dann können wir dir nicht helfen. Ohne zu wissen, was passieren soll und 
was wirklich auf den Leitungen passiert, wirst du nicht in der Lage 
sein, den Fehler zu finden oder gar zu beheben.

Markus schrieb:
> Aus irgendeinem Grund werden die Bits falsch übertragen aber es liegt
> definitiv nicht am Aufbau.

Du glaubst wirklich, Dein unterirdisch schlechter Steckbrettaufbau, der 
gegen so ziemlich jede elektrotechnische Entwurfsrichtlinie verstößt, 
sei einwandfrei?

Mach erst einmal ein EMV-gerechtes, sauberes Leiterplattenlayout, lasse 
von der zugehörigen Schaltung und dem Layout ein Review durchführe, 
beseitige die vorliegenden zehn bis zwanzig fehlerhaften Stellen, lasse 
die Leiterplatten professionell herstellen und bestücken, führe 
anschließend mit geeigneten Messmitteln, die über geeignete 
Adaptierungen mit der Schaltung verbunden sind, die zur 
Konformitätsbewertung geeigneten Messungen durch, korrigiere ggf. 
unsaubere Signale, usw..

Und wenn Du das alles gemacht hast, kannst Du hier wieder auftauchen und 
die Behauptung "es liegt vermutlich nicht am Aufbau" aufstellen. Vorher 
nicht.

Andreas S. schrieb:
> Du glaubst wirklich, Dein unterirdisch schlechter Steckbrettaufbau, der
> gegen so ziemlich jede elektrotechnische Entwurfsrichtlinie verstößt,
> sei einwandfrei?

Wenn's darum geht, nen SPI-ADC oder so auszulesen, dann kann das auch 
aufm Steckbrett klappen. Man muss halt nur wissen, wo die Grenzen des 
Aufbaus liegen und was man vor hat.

Ein Kollege hatte mal mit SPI gespielt.
Die Software, die er gefunden hatte, hat dummerweise jbei mehr als 
8-Bit) die Byte-Reihenfolge nicht beachtet.

Dirk B. schrieb:
> Die Software, die er gefunden hatte, hat dummerweise jbei mehr als
> 8-Bit) die Byte-Reihenfolge nicht beachtet.
Bei weniger oder gleich 8 Bit kann man die Bytereihenfolge auch nicht 
arg vertauschen. Und darüber hinaus gibt es keine richtige oder falsche 
Reihenfolge (bestenfalls ist die Reihenfolge anders als man sie 
erwartet). Wichtig ist nur, dass die Bytes in der korrekten Reihenfolge 
am Slave auftauchen. Mit dem Speicheroszi oder dem 10€ Logikanalyzer hat 
man das in spätestens einer viertel Stunde überprüft. Und ohne Oszi/LA 
sollte man eigentlich keine seriellen Busse in Betrieb nehmen.

Sebastian R. schrieb:
> dann kann das auch aufm Steckbrett klappen.
Wenn man einen vernünftigen Steckbrettaufbau macht. Aber bei dem hier 
wundert mich nichts: 
Beitrag "Re: Raspberry - AD-Wandler"

Wolfgang schrieb:
> SPI braucht für jeden Busteilnehmer einen eigenen CS. Wie willst du das
> mit einem über die Hardware festgelegten CS hinbekommen, wenn mehr als
> ein Slave auf dem Bus sitzt?
Der kann dann mit den dedizierten Pins eben nur 2 Slaves ansprechen, 
wenn der DMA-Modus verwendet und wie vorgesehen der jeweilige SS# Pin 
von der Hardware angesteuert wird.
Wenn du mehr Slaves ansprechen willst, dann darfst du den DMA-Modus und 
die zugehörigen SS# Pins nicht verwenden.
Siehe die Dokumente dort:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#spi-hardware

Markus schrieb:
> habe einen anderen raspi dran selber Fehler daher schließe ich den
> kaputten Pin aus.

Und woher willst Du wissen, dass nicht Dein Aufbau die 'falsche 
Übertragung' verursacht?
Oder gar den entsprechenden Pin des Raspi zerstört (was beim Anschließen 
eines anderen Raspis dann auch wieder passieren würde)?

Markus schrieb:
> OK mein SPI arbeitet aber nunmal falsch konnte einen defekten Pin
> ausschließen jetzt. Jetzt müsste ich mit einem oszi die signale
> aufnehmen um den Fehler zu finden ? Allerdings wäre ich mir nicht sicher
> wie dieser dann zu beheben wäre

Lothar hat es dir schon geschrieben:
Für CS kannst du jeden beliebigen Pin nehmen, nur musst du den selber
steuern (und natürlich verbinden und dabei aufpassen, dass die beiden
nicht gegeneinander steuern).
Für DMA geht das aber nur mit Interrupts, weil DMA unabhängig
von deinen SPI Aufrufen arbeitet.
In Hardware SPI gibt es einen Fehler wie "falsch arbeitet" nicht.
Es gibt verschiedene Modi, die kanst du vorgeben, aber wenn einmal
alles richtig eingestellt ist, gibt es keine falschen Bytes mehr.
Falls doch, liegt es am Aufbau.

Sebastian R. schrieb:
> Andreas S. schrieb:
>> Du glaubst wirklich, Dein unterirdisch schlechter Steckbrettaufbau, der
>> gegen so ziemlich jede elektrotechnische Entwurfsrichtlinie verstößt,
>> sei einwandfrei?
>
> Wenn's darum geht, nen SPI-ADC oder so auszulesen, dann kann das auch
> aufm Steckbrett klappen. Man muss halt nur wissen, wo die Grenzen des
> Aufbaus liegen und was man vor hat.

Der TE erhebt aber den absoluten Anspruch, dass sein Aufbau völlig 
korrekt wäre. Dabei haben wir schon in den anderen Threads so ziemlich 
das Gegenteil davon gesehen.