bit 0 in datenstrom finden?
-
junix schrieb:
Kann man also davon ausgehen, dass das 1er Bit von Byte zu Byte toggelt?
nicht von byte zu byte, es können ja auch theoretisch 2,4,6 in den messdaten auftauchen aber dann auch wieder z.b. 10,11,12,13. über einen grösseren bereich von messdaten sollte sich bit 0 aber häufigsten ändern.
junix schrieb:
Bestünde die Möglichkeit die Lauschhardware etwas auszubauen? Ich denke dabei zum Beispiel beim Abhören eines SPI an die SS\ sowie viel interessanter den Clock o.ä. mit aufzuzeichnen, bzw. da schon zu separieren?
Wie sieht dein Aufzeichnungsmechanismus aus, bzw. hast du überhaupt Einfluss darauf? Um die Bits sauber erkennen zu können, musst du den Clock ja sowieso haben? - Meine Embeddedsysteme haben zumindest nie eine Non-Stop-Kommunikation auf dem SPI?ich benutzte für das aufzeichnen der daten tatsächlich eine spi hardware. der eigenliche bus allerdings ist kein echter spi-bus (hat keine /SS leitung). die aufzeichnung funktioniert sehr zuverlässig, es geht nichts verloren.
die übertragung geht so:
der master clockt zwischen 20 und 25 mal und muss dann eine pause von mindestens 16µs machen. das problem dabei ist nur, dass die clockimpulse des masters beleibig lang sein können - und - diese 16µs sind ein mindestwert d.h. der master könnte clockimpulse von 1ms länge und eine pause von 50µs machen und es würde trotzdem funktionieren - mit der messung der clockzeiten kommt man also nicht weit.
-
net schrieb:
junix schrieb:
Kann man also davon ausgehen, dass das 1er Bit von Byte zu Byte toggelt?
nicht von byte zu byte, es können ja auch theoretisch 2,4,6 in den messdaten auftauchen aber dann auch wieder z.b. 10,11,12,13. über einen grösseren bereich von messdaten sollte sich bit 0 aber häufigsten ändern.
Gewagte, vermutlich meist richtige Theorie, die ich persönlich nicht unterschreiben würde...
net schrieb:
der eigenliche bus allerdings ist kein echter spi-bus (hat keine /SS leitung)
Ist auch nicht unbedingt notwendig. Dann gehe ich mal davon aus, es ist einfach ein MOSI/MISO und CLK-Signal...?
net schrieb:
der master clockt zwischen 20 und 25 mal und muss dann eine pause von mindestens 16µs machen.
das problem dabei ist nur, dass die clockimpulse des masters beleibig lang sein können - und - diese 16µs sind ein mindestwert d.h. der master könnte clockimpulse von 1ms länge und eine pause von 50µs machen und es würde trotzdem funktionieren - mit der messung der clockzeiten kommt man also nicht weit.Hmmm... an deiner Stelle würde ich dennoch die Zeit mal in die Auswertung mit einfliessen lassen. Vielleicht änderst du das Aufzeichenformat mal so, dass du immer zu jedem Bitzustand einen Timestamp mit speicherst?
Ich wage mal die Behauptung: Wenn du die Aufzeichnung mal grafisch darstellst (die Zeitunterschiede zwischen den Clocks) dann müsste sich ein eindeutig erkennbares Muster (zumindest für dich als Mensch) abzeichnen.
Die Erkennung dieses Clockmusters wäre dann zumindest für mich der Schlüssel.
-
junix schrieb:
Dann gehe ich mal davon aus, es ist einfach ein MOSI/MISO und CLK-Signal...?
ja, so ähnlich. es sind jeweils 2 miso und 2 clk leitungen (differentielle signale, wird ja oft so gemacht bei hi-speed zeugs) meinem sniffer reichst aber nur jeweils nur eine davon.
junix schrieb:
Hmmm... an deiner Stelle würde ich dennoch die Zeit mal in die Auswertung mit einfliessen lassen. Vielleicht änderst du das Aufzeichenformat mal so, dass du immer zu jedem Bitzustand einen Timestamp mit speicherst?
....
Die Erkennung dieses Clockmusters wäre dann zumindest für mich der Schlüssel.ja, das wäre ideal. der controller hat capture/compare timer um sowas zu messen, aber leider hab' ich nicht die rechenpower, diese, um ein vielfaches gesteigerte datenmenge zu speichern. schon jetzt (1 megabits/sekunde) ist das ganze hart an der grenze. bei der aufzweichnung entstehen etwa 131 kbytes pro sekunde und das schaffe ich gerade so. deshalb scheidet das mitspeichern von timestamps aus (schlapper controller, freescale S12X typ, aber billig und sowas zählt ja oft mehr als die optimale lösung
).
-
net schrieb:
sowas zählt ja oft mehr als die optimale lösung
).Kenn ich nur zu gut (o;
Naja, das mit dem rausfiltern würd ich irgendwie so machen, dass du zunächst nichts mit loggst, und nur mal dem Clock lauschst... Wenn du da unregelmässigkeiten findest, hast du auch das Timing gefunden...?
-
hi,
ich hab noch'n trick: anstelle die meisten änderungen festzustellen, was eventuell sehr unzuverlässig sein kann mach ich das so:
wenn ich z.b. ein datenwort von 24 bits länge habe, addiere ich x werte aus dem datenstrom ab position 0, dann x werte ab position 1, usw... bis x werte ab position 23. die kleinste summe müsste der treffer sein. was haltet ihr davon?
-
Muss sie das wirklich? Also wenn ich nur kurz darüber nachdenke, würd ich sagen, muss nicht unbedingt...? Was spricht dagegen, dass der kleine Freescale erst das Clock-Timing ausfindig macht?
Folgende Prämisse: Ist die Übertragung am Laufen, wird vermutlich der Clock sich um mehrere 100kHz bewegen... die Pause ist daher klar im Clock erkennbar.
Schau dir das Clocksignal vielleicht mal auf nem Oszilloskop an ob sich da wohl ne Regelmässigkeit finden lassen würde?
-
hi, hier ist der slave, zur info: http://www.mtssensor.de/download/datasheets/rd_ssi.pdf
junix schrieb:
Muss sie das wirklich? Also wenn ich nur kurz darüber nachdenke, würd ich sagen, muss nicht unbedingt...?
bestimmt nicht immer, z.b. wenn konstant ein wert von z.b. 0x8000 gesendet würde, oder der wertebereich voll ausgeschöpft wird. aber bei mir scheint's zu klappen :). trotzdem bleibt ein mulmiges bauchgefühl. ich werde noch mal nach dem thema googlen. bin bestimmt nicht der erste dem sowas begegnet ist.
junix schrieb:
Was spricht dagegen, dass der kleine Freescale erst das Clock-Timing ausfindig macht?
eigentlich nur, dass ich nie wissen kann, wie ge'clock't wird. es kann durchaus sein, dass die clockimpulse des masters so unregelmässig sind (z.b. weil bei ihm viele interrups laufen), dass sich zeitlich da nichts erkennen lässt. stellt dir vor der master clockt mit 1µs und macht 16µs pausen. wenn interrupts dazwischenhauen sind manche clocks vielleicht länger als die pause. den slave stört's nicht. wenn clocks und pause in einem bestimmten verhältnis stehen müssten, wärs's ganz easy, aber das ist ja leider nicht so.
-
Ach, das ist ja sowieso easy:
datenblatt schrieb:
Zwischen den einzelnen Taktfolgen benötigt der Sensor ca. 25 μs zum Laden von neuen Wegdaten. Stehen diese an, schaltet das Schieberegister über LSB auf HIGH-Pegel und der Vorgang wiederholt sich (s. unten)
Mit anderen Worten: Dein Controller muss lediglich darauf achten, wann der Clock ruhig steht, und dennoch ne Transition des Pegels der Datenleitung von Low nach High stattfindet. Ab da kann er mit dem Loggen beginnen und hat das Datenwort vom ersten Bit an.
-
junix schrieb:
Ach, das ist ja sowieso easy:
datenblatt schrieb:
Zwischen den einzelnen Taktfolgen benötigt der Sensor ca. 25 μs zum Laden von neuen Wegdaten. Stehen diese an, schaltet das Schieberegister über LSB auf HIGH-Pegel und der Vorgang wiederholt sich (s. unten)
Mit anderen Worten: Dein Controller muss lediglich darauf achten, wann der Clock ruhig steht, und dennoch ne Transition des Pegels der Datenleitung von Low nach High stattfindet. Ab da kann er mit dem Loggen beginnen und hat das Datenwort vom ersten Bit an.
ich hatte mich schon gefreut aber, sorry, das war das falsche pdf
hab' geglaubt die machen das überall gleich, das richtige pdf ist hier: www.mtssensor.de/download/datasheets/rprh_ssi.pdf
zu erkennen an den 16µs statt 25µs...
mist, das wär zu schön gewesen
-
äh... SSI ist SSI oder?
Auch hier lässt sich aus dem Impulsdiagramm exakt das Selbe entnehmen... Schaus dir doch mit dem Oszilloskop an...
-
junix schrieb:
äh... SSI ist SSI oder?
woll'n wirs hoffen...
junix schrieb:
Auch hier lässt sich aus dem Impulsdiagramm exakt das Selbe entnehmen... Schaus dir doch mit dem Oszilloskop an...
das werde ich machen. danke, du hast mir sehr geholfen
-
Reine neugierde meinerseits: KLappts? (o:
-
junix schrieb:
Reine neugierde meinerseits: KLappts? (o:
hi junix,
ja, es funzt. ich nehme so'n ollen code zum dekodieren und entprellen von drehimpulsgebern, um die startbedingung zu erkennen.:D die clock und datenleitung werden mit 500khz gescannt und der code schmeisst dann einen eindeutigen wert raus bei der startbedingung. geht auch wenn jemand super-langsam clockt. bei voller clockspeed kann es passieren, dass die startbedingung erst ein paar messwerte später erkannt wird. das ist aber nicht schlimm.
-
Klingt aber arg nach bruteforce... keine Chance das etwas interruptbasiert zu betreiben?
-
junix schrieb:
Klingt aber arg nach bruteforce... keine Chance das etwas interruptbasiert zu betreiben?
könnte schon gehen, aber dazu müsste ich beide leitungen nochmal mit interruptfähigen eingängen verbinden und wahrscheinlich immer abwechselnd umschalten, welche flanke einen interrupt auslöst. so wie ich's jetzt mache wird's von einem timer-interrupt gesteuert. ist die startbedingung einmal gefunden, wird der timer interrupt abgeschaltet und erst bei beginn der nächsten messung wieder aktiviert.
edit: die eigentlich messung läuft natürlich interruptgesteuert. alle 8 bits gibt's einen interrupt vom spi-modul und dann schiebe ich das byte in einen FIFO. am anderen ende des FIFOs hängt die zweite cpu (ja, ein S12X hat 2 cpus!), die die daten aufs speichermedium bringt (alle 512 bytes wird ein sektor geschrieben).