Hallo, bin auf der Suche nach einer Lösung für mein Anliegen. Ich schaue mir mit Saleae (original) Logic Pro 16 und der passenden SW Logic 2.4.14 eine SPI Kommunikation an. Die Datenübernahme (Interpretation) erfolgt bei CLK high->low. Wenn ich es richtig sehe, ist der Ruhepegel des CLK high und in der "Kommunikationspause" geht der Pegel zurück auf low. Das führt nun zur Fehlinterpretation der Daten. Habe drei Bilder angehängt. Start, erster Block und Gesamt. Und habe die Stellen markiert, die ich gerne von der Interpretation der Daten ausnehmen würde. Ist das Möglich? Also die Kommunikation an sich ist natürlich einwandfrei. Es geht mir nur um die Interpretation durch die Anwendung! Vielleicht ist jemand schon mal über das Problem gestolpert. Danke!
Rudolf schrieb: > bin auf der Suche nach einer Lösung für mein Anliegen. Klar, sonst hättest du den Thread wohl nicht eröffnet > Das führt nun zur Fehlinterpretation der Daten. > ... > Also die Kommunikation an sich ist natürlich einwandfrei. Normalerweise würde man eine Kommunikation mit Fehlinterpretation nicht als "einwandfrei" bezeichnen. > Und habe die Stellen markiert, die ich gerne von der Interpretation der > Daten ausnehmen würde. Bei richtiger Einstellung des SPI-Modes musst du nirgendwo irgendetwas von der Interpretation ausnehmen. Die geringe Zeitauflösung deiner Bilder macht die Analyse etwas schwierig. Warum lädst du nicht eine (kurze) Datenaufzeichnung hoch und gibst dazu an, was übertragen wird und wie deine Anwendung dies interpretiert? Zeige mindestens CLK, MISO und MOSI
:
Bearbeitet durch User
Zumindest bei den älteren Versionen der Saleae Software konnte man Timing Marker setzen und die Protokoll-Dekodierung abhängig von den Markern starten.
Also mit Einwandfrei meine ich, dass ich mit der Elektronik an sich keine Probleme habe. Habe als Analyzer SPI ausgewählt und hier für CLK high to low ausgewählt. Die markierten Übergänge high->low sind mein Problem :) Kann man eizelne CLK ausblenden? Ich kann schon markieren und sagen ab hier oder bis hier interpretieren, aber ich müsste am ende jedes einzelnen Blocks ein CLK entfernen...
Rudolf schrieb: > Wenn ich es richtig sehe, ist der Ruhepegel des CLK high und in der > "Kommunikationspause" geht der Pegel zurück auf low. Wie sieht der zur Kommunikation dazugehörige SS# aus? Ist der tatsächlich ständig aktiv (= auf low)? (Anmerkung: das wäre eine schlechte Idee, denn dann bringt 1 einziger Störimpuls auf dem SCLK den SPI für den Rest des Tages ausser Takt) Dieter S. schrieb: > Saleae Software Die kann auch mit dem SS# umgehen und meint dazu ganz zu Beginn: "SPI uses a Clock signal, two data signals (MISO and MOSI), **and** an Enable signal": - https://support.saleae.com/protocol-analyzers/analyzer-user-guides/using-spi BTW: man sollte für die Namen im LA auch die üblichen SPI Namen verwenden. Denn es gibt da jeweils 2 In und 2 Out, es heißt ja nicht umsonst MOSI = Master Out Slave In und MISO = Master In Slave Out.
:
Bearbeitet durch Moderator
Rudolf schrieb: > Die Datenübernahme > (Interpretation) erfolgt bei CLK high->low. Unüblich! Oder: Verstehe ich nicht. Mir fehlt /CS bei dir. Ohne /CS ist das kein SPI
Lothar M. schrieb: > > Die kann auch mit dem SS# umgehen und meint dazu ganz zu Beginn: Mit SS# geht es natürlich, man kann es aber auch weglassen (es gibt gelegentlich solche Fälle). Und dann ist das Starten der Protokoll-Dekodierung an einer bestimmten Stelle manchmal hilfreich.
:
Bearbeitet durch User
Dieter S. schrieb: > Mit SS# geht es natürlich, man kann es aber auch weglassen (es gibt > gelegentlich solche Fälle). Das ist keine gute Idee, weil dann die Synchoniation auf den Master fehlt.
Arduino F. schrieb: > Unüblich! > Oder: Verstehe ich nicht. Warum? Es gibt 4 verschiedene Modi, die sich durch die Polarität vom CLK und die Flanke für die Datenübernahme unterscheiden. Da ist keiner besser als der andere. Master, Slave und LA müssen lediglich das selbe Spiel spielen, damit sich alle verstehen und der LA keinen Unfug interpretiert.
Rainer W. schrieb: > > Das ist keine gute Idee, weil dann die Synchoniation auf den Master > fehlt. Und genau deshalb startet man dann die Dekodierung an der richtigen Stelle. Wenn der Master nur dann Taktsignale erzeugt wenn auch Daten übertragen werden funktioniert das problemlos (bereits mehrfach so gemacht). Einer der Gründe warum das nützlich sein kann: Mein Saleae LA kann drei Signale bis 100 MHz abstasten, bei vier Signalen sind es maximal 50 MHz. Und dann läßt man bei Bedarf halt SS# weg.
Arduino F. schrieb: > Unüblich! > Oder: Verstehe ich nicht. Warum? Es gibt 4 verschiedene Modi, die sich durch die Polarität vom CLK und die Flanke für die Datenübernahme unterscheiden. Da ist keiner besser als der andere. Master, Slave und LA müssen lediglich das selbe Spiel spielen, damit sich alle verstehen und der LA keinen Unfug interpretiert. Rudolf schrieb: > Das führt nun zur Fehlinterpretation der Daten. Scheint so, als ob du einen Clock Puls zu viel generierst. https://de.wikipedia.org/wiki/Datei:SPI_timing_diagram2.svg
Rainer W. schrieb: > Warum? > Es gibt 4 verschiedene Modi, die sich durch die Polarität vom CLK und > die Flanke für die Datenübernahme unterscheiden. Danke für diese nützliche Information! (ich weiß nicht wer von uns beiden schon länger was mit SPI zu tun hat) Ohne /CS ? Ich keine keine SPI Hardware, die damit klar kommt. Wenn es welche gibt, auch gut, dann lerne ich hier noch was.
:
Bearbeitet durch User
Das ist alles schön und gut. Wie gesagt, die Kommunikation funktioniert ja! Es geht lediglich um die Dekodierung durch das Tool! Ich möchte diesen CLK Übergang von high nach low ausblenden, wenn die Kommunikation in "Pause" geht! Ich kann natürlich die Daten via CSV ausleiten und via Script (wie auch immer) auswerten. Ich hoffte auf eien bereits implemenetierte Möglichkeit im Tool. Ein Request bei Saleae habe ich parallel gestartet aber ich gehe nicht davon aus, daß ich hier kurzfristig eine Lösung bekomme. Wenn doch, poste ich...
Rudolf schrieb: > Ein Request bei Saleae habe ich parallel gestartet aber ich gehe nicht > davon aus, daß ich hier kurzfristig eine Lösung bekomme. Wenn doch, > poste ich... Für PulseView kannst du deine eigenen Decoder bauen.
Rudolf schrieb: > Ein Request bei Saleae habe ich parallel gestartet aber ich gehe nicht > davon aus, daß ich hier kurzfristig eine Lösung bekomme. Gehe mal lieber davon aus, dass Du auch langfristig keine Lösung von Saleae bekommst. Warum sollten die auch extra für Dich so eine [bescheuerte] Sonderlocke (extra für Dich) entwickeln? Benutze SPI so wie es vorgesehen ist - also mit CS, dann klappt's auch mit dem Protokolldekoder. Falls nicht, dann musst Du Dir eben einen eigenen Protokolldekoder schreiben. Und Dein 1-kHz SPI-Clock wirst Du ja wohl mit auch 50 Mhz (bei 4 Signalen) ordentlich abgetastet bekommen. Oder wofür brauchst Du da unbedingt 100 MHz?
Rudolf schrieb: > Die markierten Übergänge high->low sind mein Problem :) Diese "Übergänge" sind ausserhalb des üblicherweise vom SS# umrahmten Übetragungsbereich. In diesem deselektierten Bereich darf dann auch der SCLK machen, was er will, weil das dem Slave dank Nichtbeachtung egal ist. Verwendest du einen SS#? Oder bist du einer der Hasardeure, die meinen, ohne den SS# auszukommen? Rudolf schrieb: > Ein Request bei Saleae habe ich parallel gestartet Die Antwort wird lauten: "Es tut uns leid, aber die Auswertungssoftware kann ohne SS# nicht ermitteln, wo das SPI-Telegramm beginnt und endet."
:
Bearbeitet durch Moderator
Im ersten Kommunikationsblock hat die Auswertung doch schon zu früh begonnen. Schneide die Signale davor doch ab damit die Auswertung richtig startet. Wenn es unbedingt ohne CS ausgewertet werden soll.
Arduino F. schrieb: > Danke für diese nützliche Information! > (ich weiß nicht wer von uns beiden schon länger was mit SPI zu tun hat) Das kann ich dir auch nicht sagen 🤔 Du willst anscheinend 10 Byte übertragen. Dafür benötigst du GENAU 10*8=80 Clock Pulse. Dein Master schickt aber 81 Pulse, also genau einen zu viel. Dieser zusätzliche Clock Puls hat dort nichts zu suchen und ist ein Fehler in deinem Master. Der Interpreter kann nichts dafür. Ohne CS zur (Re-)Synchronisation kommen dann solche Fehlinterpretationen raus. Ein CS würde den Fehler zwar nicht beseitigen, ihn aber nach außen verbergen.
:
Bearbeitet durch User
Die Diskusion driftet immer in die selbe Richtung ab. Leider. Die Anwendung ist gegeben, tatsächlich ohne CS und funktioniert. Die SW kann die Daten ohne CS leider nicht korrekt dekodieren weil der CLK nach diesen 10 Byte in den Ruhezustand low geht und somit die Dekodierung der Daten sich je um ein Bit schiebt. Ich werde mich an einem eigenen Dekoder versuchen...
Rudolf schrieb: > Die Anwendung ist gegeben ... Dann hat sie einen Bug oder es handelt sich nicht um SPI im engeren Sinne und du kannst nicht erwarten, dass ein SPI-Dekoder damit funktioniert.
:
Bearbeitet durch User
Das SPI Device kann auch einen Timeout haben und damit richtig ohne CS reagieren. Aber warum dem Dekoder nicht nachhelfen mit dem richtigen Start?
J. S. schrieb: > Aber warum dem Dekoder nicht nachhelfen mit dem richtigen > Start? Das ist soweit korrekt. Damit sind die ersten 10 Byte richtig aber die nachvolgenden immer noch verschoben :(
Die Saleae-Software ist übrigens programmierbar, d.h. man kann sich dafür auch eigene Decoder bauen. https://support.saleae.com/saleae-api-and-sdk/protocol-analyzer-sdk Das hilft vielleicht bei der hier vorliegenden kaputten SPI-Übertragung.
Harald K. schrieb: > Das hilft vielleicht bei der hier vorliegenden kaputten SPI-Übertragung. Wenn kein SS# verwendet wird und zudem auf der Taktleitung pro Telegram 1 überzähliger Takt (81 statt nur 80!) kommt, dann ist das wirklich kaputt. Und wenn es "funktioniert", dann nur, weil der Slave das zu viel übertragene Bit irgendwie ignoriert. Frickelei hoch drei. J. S. schrieb: > Das SPI Device kann auch einen Timeout haben und damit richtig ohne CS > reagieren. Das ist dann aber eben auch kein SPI im Sinne des Motorola "Quasi-Standards". Dort taucht immer der SS# zwingend mit auf: - https://de.wikipedia.org/wiki/Serial_Peripheral_Interface Rudolf schrieb: > Also die Kommunikation an sich ist natürlich einwandfrei. Wenn die an sich einwandfrei läuft, warum brauchst du dann den LA? Zum Debuggen kanns dann ja nicht sein. Muss du das Protokoll ausknobeln/reverse-engineeren?
Bitte 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.