hi, wozu benötige ich zum decoden von SPI den Chip Select ? In meinem Oszi gibt es verschiedenen SPI Auswahlmöglichkeiten: SPI (Data, CLK, CS) SSPI (Data, CLK) SIOT SPI (Data, CLK) SPI custom (Data, CLK) meine Hardware besteht aus einem touch display der an den App Processor via SPI seine daten liefert. der spi besteht dort aus MOSI MISO SCLK CS meine FRage: Muss ich zum Decoden am Oszi den CS mit verwenden um die Datenbytes richtig zu interpretieren ? kann man den nicht einfach weglassen und dafür SSPI z.b. als config am oszi hernehmen wo kein CS benötigt wird ?
ja kann man, du musst dann nur die Pausen-Zeit zwischen den Datenpacketen einstellen. Dein Oszi bildet nämlich intern ein CS, und zwar wenn längere Zeit kein Takt kommt (diese Zeit musst du einstellen).
ok danke für deine antwort. wenn ich aber CS doch verwende, muss ich dann auch gezwungenermaßen auf diesen triggern ? nein oder ? habe CPOL=1 CPHA=1 und würde auf negative flanke vom CLK triggern
user schrieb: > Dein Oszi bildet nämlich intern ein CS, und > zwar wenn längere Zeit kein Takt kommt ich habe da dann das problem dass wenn der touch nicht berührt wird, dann auch kein CLK kommt und das solange bis jemand den touch wieder berührt. wenn ich einen single-schuss mit dem trigger machen möchte, um genau diese daten zum zeitpunkt des berührens des touches (wohl X,Y Koordinaten) abzufangen , brauche ich doch auch keinen CS wenn das oszi sowieso auf den anfang vom CLK triggert ?
Alex schrieb: > ok danke für deine antwort. wenn ich aber CS doch verwende, muss ich > dann auch gezwungenermaßen auf diesen triggern ? nein oder ? Sinnvollerweise ja, denn der SS (SlaveSelect heißt der Chipselect beim SPI) zeigt an, dass eine neue Übertragung für diesen Slave beginnt. Wenn du nur die anderen signale anschließt, aber 5 Slaves am Bus hast, dann kannst du nur mit MISO, MOSI und SCLK nicht unterscheiden, welcher Slave gemeint ist. > wenn ich einen single-schuss mit dem trigger machen möchte > brauche ich doch auch keinen CS wenn das oszi sowieso auf den anfang > vom CLK triggert ? Das geht sowieso nicht. Egal ob mit oder ohne SS. Denn weil das Display von sich aus nichts "senden" kann, sondern von dort alles "abgeholt" werden muss, wird der uC laufend nachfragen müssen, ob was passiert ist. Und das auch in den Zeiten, wo nichts auf dem Touch los ist. Das kannst du aber einfach bei einer "Leerlaufmessung" feststellen. > auf diesen triggern ? nein oder ? Bitte nicht Plenken! https://de.wikipedia.org/wiki/Plenk Und Groß- und Kleinschreibung verwenden, damit sich der Text nicht so abartig holprig liest. Dass du prinzipiell Großbuchstaben eingeben kannst sieht man ja...
Alex schrieb: > Muss ich zum Decoden am Oszi den CS mit verwenden um die > Datenbytes richtig zu interpretieren ? kann man den nicht einfach > weglassen und dafür SSPI z.b. als config am oszi hernehmen wo kein CS > benötigt wird ? Das entscheidet nicht das Oszi, sondern der SPI-Master. Wenn der ein /CS bereitstellt, dann ist es auch nötig. SPI ohne /CS benötigt spezielle Protokolle, z.B. ein Startbit.
Lothar M. schrieb: > Das geht sowieso nicht. Egal ob mit oder ohne SS. > Denn weil das Display von sich aus nichts "senden" kann, sondern von > dort alles "abgeholt" werden muss, wird der uC laufend nachfragen > müssen, ob was passiert ist. Und das auch in den Zeiten, wo nichts auf > dem Touch los ist. Das kannst du aber einfach bei einer > "Leerlaufmessung" feststellen. bei Berührung des Touches >> das TouchDisplay schickt an den AP ein INT der dann weiss dass Touchdaten vorhanden sind und der dann den CS aktiviert um die Daten via SPI vom Slave (Display) raustaktet. ich habe nur 1 slave und das ist das Display selbst und 1 AP. man könnte doch auch den Chip Select ständig auf LOW lassen ?
Peter D. schrieb: > SPI ohne /CS benötigt spezielle Protokolle, z.B. ein Startbit. OK, ich habe aber gehört dass man bei 1 Master und 1 Slave das CS Signal ständig auf LOW lassen könnte. Ist das richtig ? zum Decodieren auf dem Oszi muss ich aber dann trotzdem den CS mit verwenden, richtig ?
Alex schrieb: > bei Berührung des Touches >> das TouchDisplay schickt an den AP ein INT Das ist neu, bisher war nur von SPI die Rede: >> Alex schrieb: >>> meine Hardware besteht aus einem touch display der an den App Processor >>> via SPI seine daten liefert. > der dann weiss dass Touchdaten vorhanden sind und der dann den CS > aktiviert um die Daten via SPI vom Slave (Display) raustaktet. ich habe > nur 1 slave und das ist das Display selbst und 1 AP. Dann kannst du auch auf den Takt triggern oder die Flanke vom Interrupt. Alex schrieb: > man könnte doch auch den Chip Select ständig auf LOW lassen ? Das ist bei SPI generell eine schlechte Idee, denn üblicherweise wird der SS (der heißt SlaveSelect, irgendwann wirds hängen bleiben) wird idR. zur Framesynchronisation verwendet. > man könnte doch auch den Chip Select ständig auf LOW lassen ? Dann brauchst du eine andere Methode, um den Start eines Frames aufzuzeigen. Denn wenn du sonst nur 1 Störimpuls auf der Taktleitung hast, bist du für den Rest des Tages um 1 bit versetzt... > man könnte doch auch den Chip Select ständig auf LOW lassen ? Lies das Datenblatt deines Displays.
Das Datenblatt eines Devices beschreibt wie man es ansteuern muss. Entweder man macht es genau so oder es geht nicht. Du kannst natuerlich alle nicht beschriebenen Zustaende testen, solltest dich aber nicht wundern wenn's nicht geht. Ich hab auch schon einen halben Tag gesucht, bis ich eine winzige timingverletzung entdeckte. die allerdings bewirkte, dass ich den vorgesehenen SPI Mode nicht benutzen konnte, und den Transfer daher haendisch machen musste.
:
Bearbeitet durch User
Lothar M. schrieb: > Lies das Datenblatt deines Displays. apple gibt nix raus :) ist von einem iPhone7 . mache reverse engineering :D Danke mal für die Infos. Ich lese mir das alles hier nochmal durch. Speziell auch Danke an Dich Lothar ! Melde mich wieder wenn ich weitergekommen bin :) Gruss Alex
Hallo liebe Kollegen :) zum Thema SPI Bus decoden: es hat nun geklappt. ich nutze nun das Setup/Config vom SPI was heisst: ich verwende DATA (MISO), CLK und CS triggern muss ich auf CS, weil er mir sonst nicht die Datenwörter in der Table anzeigt, obwohl alle 3 Signale in den jeweiligen Grids korrekt dargestellt werden!?! Bisheriger Erfolg: ich konnte schon die Touch-IDs heraus erkennen und zuordnen. was jetzt noch kommt, ist, die Koordinaten X u. Y aus dem ganzen HEX-Gewirrwarr herausfinden. Man bekommt halt nur irgendwelche HEX-Daten vom Digitizer und hat keinerlei Doku oder Spec dazu. Aber es macht irrsinnig viel Spass. Bis bald , euer Alex
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.