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!
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?
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...
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.
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.
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.
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.
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.
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...
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.
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?
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?
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.
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.
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...
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.
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?
StartKommunikation.PNG
(19 KB)
ErsterKommunikationsblock.PNG
(35 KB)
Gesamt.PNG
(25 KB)
