10bit Resolver spuckt über SPI 16 bits aus!

Peter H. schrieb:

Im angehängten Bild ist zu sehen, dass auf der Datenleitung 16 bits ausgegeben werden, was für mich irgendwie nicht zum Datenblatt passt. (Gelb Data Out, Blau Takt, Lila CS)

Wenn du in den SPI 16 Takte oder gar endlos reintaktest, dann kommen ganz logisch auch 16 Bit oder viel mehr "heraus". Denn SPI sind nur gekoppelte Schieberegister.

was mein Fehler sein könnte.

Du hältst dich bei der Takterzeugung nicht ans Datenblatt. Denn das Timing im Datenblatt gibt vor, dass du nur 10 Takte reintaktest. Halte dich daran, dann kommen auch nur 10 Bits zurück.

Peter H. schrieb:

Screenshot_Oszi.jpg

Noch'n Tipp: Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG oder WEBP Format. Dann gibt es nicht diese JPEG Kompressionsartefakte, die bei Fotos gar nicht auffallen.

Und noch einer: wenn du die Masseleitungen der Tastköpfe auch mit anschließt, dann gibt es nicht diese hässlichen Spikes an der Flanke.

Du sollst einfach nicht mehr auslesen und CS wieder hochfahren nach den 10-12 bit. Nachdem CS hochgesetzt wird, resettet wohl auch der interne Counter im Drehgeber wieder für's nächste Auslesen.

Wer weiß Du liest da dann eventuell etwas aus einem internen Register aus was eigentlich nicht verwendet werden sollte.

Tja, SPI-Engines können oft nur Daten 8-Bit-weise übertragen. Wenns da keinerlei "Kompromissfähigkeit" gibt, bleibt nur Bit-Banging....

Gruß

Franko P. schrieb:

Tja, SPI-Engines können oft nur Daten 8-Bit-weise übertragen. Wenns da keinerlei "Kompromissfähigkeit" gibt, bleibt nur Bit-Banging....

Ich würde fast annehmen, dass die eigentlich relevante Information in den ersten 10 (oder 12) übertragenen Bits steckt.

Evtl. kann man mit diesem "Übertakten" sogar den 10-Bit-Geber zum 12-Bit-Geber oder gar 16-Bit-Geber "pimpen". Das ist ja leicht zu erkennen am Oszibild, welche Bits sich da bei langsamem Drehen ändern.

Konfiguriere einfach dein SPI richtig, der G4 kann jede Anzahl an Bits von 4 bis 16.

Lothar M. schrieb:

Peter H. schrieb:

Im angehängten Bild ist zu sehen, dass auf der Datenleitung 16 bits ausgegeben werden, was für mich irgendwie nicht zum Datenblatt passt. (Gelb Data Out, Blau Takt, Lila CS)

Wenn du in den SPI 16 Takte oder gar endlos reintaktest, dann kommen ganz logisch auch 16 Bit oder viel mehr "heraus". Denn SPI sind nur gekoppelte Schieberegister.

was mein Fehler sein könnte.

Du hältst dich bei der Takterzeugung nicht ans Datenblatt. Denn das Timing im Datenblatt gibt vor, dass du nur 10 Takte reintaktest. Halte dich daran, dann kommen auch nur 10 Bits zurück.

Peter H. schrieb:

Screenshot_Oszi.jpg

Noch'n Tipp: Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG oder WEBP Format. Dann gibt es nicht diese JPEG Kompressionsartefakte, die bei Fotos gar nicht auffallen.

Und noch einer: wenn du die Masseleitungen der Tastköpfe auch mit anschließt, dann gibt es nicht diese hässlichen Spikes an der Flanke.

Danke Dir, probiere ich gleich aus.

Viele Grüße Peter

Du kannst einfach die letzten 6 Bits ausmaskieren. Der Drehgeber wird schon nicht explodieren bei 16 Takten. Er synchronisiert einfach neu auf jede fallende Flanke von CS.

Das ist ein magnetischer Single-Turn Absolut-Encoder, kein Resolver[1]! Ich habe mich schon gewundert, seit wann es Resolver mit SPI-Schnittstelle geben soll...

Mit freundlichen Grüßen Thorsten Ostermann

[1] https://de.wikipedia.org/wiki/Resolver

Lothar M. schrieb:

Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG

Seit wann ist das PNG-Format nichtkomprimierend?

Rainer W. schrieb:

Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG

Seit wann ist das PNG-Format nichtkomprimierend?

Er meinte verlustfreie Kompression. JPG macht Artefakte, siehe Bildformate.

Falk B. schrieb:

Er meinte verlustfreie Kompression. JPG macht Artefakte, siehe Bildformate.

Meine Glaskugel ist leider zur Wartung.

Rainer W. schrieb:

Lothar M. schrieb:

Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG

Seit wann ist das PNG-Format nichtkomprimierend?

Ich meinte "nichtkompromittierend"... ;-)

Nein, Witzlein, natürlich wie vermutet "verlustfreien PNG" statt "komprimierenden PNG". Aber zum Glück habe ich wenigstens die eigentlich relevanten "Kompressionsartefakte" dazugeschrieben.

Rainer W. schrieb:

Meine Glaskugel ist leider zur Wartung.

Ist aber im Grunde auch ohne Glaskugel und Hirnverrenkungen noch zu schaffen.