Forum: Mikrocontroller und Digitale Elektronik Saleae mit Logic SW


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rudolf (rudman)


Angehängte Dateien:

Lesenswert?

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!

von Rainer W. (rawi)


Lesenswert?

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
von Dieter S. (ds1)


Lesenswert?

Zumindest bei den älteren Versionen der Saleae Software konnte man 
Timing Marker setzen und die Protokoll-Dekodierung abhängig von den 
Markern starten.

von Rudolf (rudman)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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

von Dieter S. (ds1)


Lesenswert?

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
von Rainer W. (rawi)


Lesenswert?

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.

von Rainer W. (rawi)


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

von Rainer W. (rawi)


Lesenswert?

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

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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
von Rudolf (rudman)


Lesenswert?

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

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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.

von Pat A. (patamat)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Pat A. (patamat)


Lesenswert?

Pat A. schrieb:
> Und Dein 1-kHz SPI-Clock

Zu spät zum Editieren: ich meinte 1 MHz!

von J. S. (jojos)


Lesenswert?

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.

von Rainer W. (rawi)


Lesenswert?

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
von Rudolf (rudman)


Lesenswert?

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

von Rainer W. (rawi)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

Das SPI Device kann auch einen Timeout haben und damit richtig ohne CS 
reagieren. Aber warum dem Dekoder nicht nachhelfen mit dem richtigen 
Start?

von Rudolf (rudman)


Lesenswert?

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 :(

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

Rainer W. schrieb:
> Du willst anscheinend 10 Byte übertragen.
Nicht ich!

von Harald K. (kirnbichler)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.