Ich versuche, eine serielle Kommunikation zwischen zwei Mikrocontrollern (1 Gerät und 1 Mikrocontroller auf einer Platine) zurückzuentwickeln. Eine MCU validiert die andere MCU und ich möchte die Validierung knacken und die validierte MCU nachahmen. Ich möchte herausfinden, welches Protokoll verwendet wird, um die Daten zu verstehen. Ich habe die Kommunikation mit einem Logikanalysator aufgezeichnet und hier ist ein Screenshot von PulseView:
PulseView hat eine Dekodierungsfunktion, aber ich weiß nicht, wo ich anfangen soll. Die Kommunikation erfolgt nur über 1 Draht. Aber ich bin mir nicht sicher, ob das Protokoll "eindrahtig" ist. Gibt es bekannte Standardmethoden, um ein unbekanntes Kommunikationsprotokoll zu identifizieren? Oder muss ich es durch bloßes Anschauen erkennen?
Ich habe ein Skript geschrieben, um die Daten in die Zeit umzuwandeln, die zum Wechseln von einem Zustand in einen anderen (hoch-zu-niedrig oder niedrig-zu-hoch) erforderlich ist, um wiederholte Messungen und das Fehlen der validierten MCU zu vergleichen. Jedes Mal sehen die Muster etwas anders aus. Es wäre großartig gewesen zu wissen, dies in ein Byte-Array oder was auch immer dafür gedacht ist, zu dekodieren.
Die erste lange Low-Periode jedes Zyklus beträgt manchmal 90 μs, manchmal 30 μs. Jeder Zyklus hat insgesamt 14 Schalter. Lange hohe Perioden zwischen Zyklen können unterschiedlich lang sein (~270-330μs).
PS: Die kleinste Zeit, die für eine Änderung benötigt wird, beträgt 30 μs, wie in der 3. Reihe auf dem Bild zu sehen (120 μs = 4 Zustände).
Danke!
Bearbeiten: Hier sind Beispiele für Signale, die nicht der allgemeinen Regel entsprechen.
Edit2: Verteilung der hohen Perioden zwischen den Zyklen:
Edit3: In der ersten Phase (vergrößert in der obersten Reihe) gibt es 4 Frames, die mit 90 μs Low beginnen, gefolgt von 23 Frames, die mit 30 μs Low beginnen, und schließlich wieder ein Frame, der mit 90 μs Low beginnt.
Edit4: Hier ist die sigrok-Sitzungsdatei .
Angesichts der Anzahl der Umschalter vermute ich, dass dies eine Art ungewöhnliche Zeilencodierung ist. Ich denke, wir müssten mehr Nahaufnahmen von jedem Frame sehen (was Sie einen "Zyklus" nennen), um eine Vermutung anstellen zu können. In der Zwischenzeit finden Sie hier einige Tipps, wie Sie die Codierung herausfinden können.
Übliche Leitungscodierungen wie NRZ und Manchester stellen Bits als Pegelübergänge dar, nicht die Pegel selbst. Bei einigen Codierungen (wie Manchester) ist die Richtung des Übergangs von Bedeutung:
In anderen (wie NRZ) ist das Vorhandensein oder Fehlen eines Übergangs signifikant.
Manchmal gibt es zwei Übergänge pro Bitzeit, manchmal nur einen. Der Leitungscode- Artikel auf Wikipedia enthält viel mehr Informationen mit Beispielen für mehrere Codierungen. Implementierungen von asynchronen Protokollen verwenden oft Bitstuffing (zB CAN und USB), aber das scheint hier nicht vorhanden zu sein. Das Füllen von Bits erfolgt normalerweise nach einem Lauf von ~ 6 Bits, aber ich sehe in Ihren Daten keine Läufe, die länger als 3-4 Bits sind.
Die Tatsache, dass Sie immer 14 Übergänge pro Frame sehen, scheint bedeutsam, aber ich bin mir nicht sicher, wie ich das interpretieren soll. Es sieht so aus, als gäbe es 15 Bitzeiten pro Frame. Wenn also eines ein Startbit ist, hätten Sie 14 Datenbitzeiten. Bei einer Kodierung im Manchester-Stil wären das 7 Bits, die ein ASCII-Zeichen enthalten könnten.
Einige Realisierungen in einfacher Hardware sind möglicherweise mit einem UART kompatibel, möglicherweise mit Parität, nachdem Sie sich wiederholende Muster korrelieren und synchronisieren.
Hier ist ein Standard nicht unbedingt der von Nikon
https://www.basecamelectronics.com/files/SimpleBGC_2_6_Serial_Protocol_Specification.pdf
Präambel Alle 1er Leerlauf Dann 00 1010 1010 1010 Taktsynchronisation 33,0 kHz
1111 1111 1111 ignorieren.
xxxx xxxx meldet dies für jede Sequenz zurück.
Wiederholen.
Verwenden Sie 30 us Takt und zentrieren Sie das Sample synchron. Ignorieren Sie den Jitter im Histogramm, aber korrigieren Sie die x-Achse um /10. Es scheint 30 uns nicht 300 uns zu sein.
Die Spitzen von +40–60 werden durch Kanalgruppenverzögerungsverzerrung auf verschiedenen Datenmustern verursacht, die Intersymbolinterferenz (ISI) genannt werden, die vermieden werden kann, aber für diesen kurzen stetigen Pfad nicht notwendig ist. Ich könnte allein zu diesem Thema einen 3-stündigen Vortrag darüber halten, wie man Quellen von Signalfehlern identifiziert und wie sie für hohe Geschwindigkeiten korrigiert werden.
Tony Stewart EE75
Saren Tasciyan
Tony Stewart EE75
W5VO
Saren Tasciyan
Adam Haun
Saren Tasciyan
Tony Stewart EE75
Saren Tasciyan
Saren Tasciyan
Tony Stewart EE75
Tony Stewart EE75
Saren Tasciyan
jsotola
Saren Tasciyan
jsotola
jsotola
Saren Tasciyan
jsotola