bit 0 in datenstrom finden?
-
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).