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.
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
