moin wie man GPIOs als Ausgang bzw Eingang definiert weiß ich: https://tutorials-raspberrypi.de/raspberry-pi-gpio-erklaerung-beginner-programmierung-lernen/ Jetzt habe ich vom SPI Verfahren gehört und möchte wissen wie man einzelne GPIO Pins als CS deklariert oder MOSI oder MISO. Danke schonmal
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.
:
Bearbeitet durch User
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. Das muss doch möglich sein
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".
:
Bearbeitet durch Moderator
wie starte ich manuell den Datentransfer ? Durch ausführen des Programms ? Wenn ich den auf GPIO den ich als CS auf Low ziehe ?
>oder wie kann ich z.B meinen MISO Anschluss von Gpio 9 auf z. B GPIO22 >setzen gar nicht... wie gesagt ist "in" dem Pin bzw. "zwischen" Pin und CPU der SPI controller. Es gibt zwar µC die Multiplexer von jeder Hardwareeinheit zu jedem Externen Pin haben, die sind jedoch rar (z.B. PSoC von Infineon früher Cypress Semiconductor).
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.
Ok mir war bekannt dass man den CS auf jeden GPIO legen kann ... verwunderlich... Lothar welche Qualifikation besitzt du ? rein aus Interesse du bist sehr aktiv hier
Markus schrieb: > Ok mir war bekannt dass man den CS auf jeden GPIO legen kann ... > verwunderlich... Das geht prinzipiell schon, jedoch müsstest du dafür Änderungen im bestehenden Treiber machen die dich wiederum überfordern werden/würden. Insofern ist diese Aussage 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 (das ist SPI-technisch ja möglich), oder man kann alternativ zur Hardware-Bedienung einen Soft-CS implementieren (wenn man es kann). Wie es beim Raspberry intern aussieht weiss ich nicht ....
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.
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 M. schrieb: > Bei miner Aussage gings um die beliebige Zuordnung von MOSI und MISO. Ja ok, ich zu ungenau gefolgert. Der TO redete die ganze Zeit von CS, und plötzlich kommt er mit MISO daher ....
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.
habe einen anderen raspi dran selber Fehler daher schließe ich den kaputten Pin aus. Aus irgendeinem Grund werden die Bits falsch übertragen aber es liegt definitiv nicht am Aufbau. finde die richtige Software leider nichtmal
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.
weiter weg schrieb: > Enweder hat der Raspberry gar keine SPI- > Maschine die auch einen CS bedient (das ist SPI-technisch ja > möglich), oder man kann alternativ zur Hardware-Bedienung einen > Soft-CS implementieren (wenn man es kann). 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?
Angehängte Dateien:
-
RPi_SPI0.PNG
54 KB -
RPi_SPIx.PNG
41 KB
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
:
Bearbeitet durch Moderator
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.
Ich glaube es hakt, schon wieder ein neuer Thread zur selben Schaltung! Bei dem Verhalten bekommst du von mir keine hilfreiche Antwort mehr.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.