10bit Resolver spuckt über SPI 16 bits aus!

[Peter H. (borntopizza)]

Servus,

ich habe einen 10-bit Resolver von der Firma Avago, welcher mir keine 
10bit ausgibt. Ich weiss nicht was ich falsch mache bzw. was das Problem 
sein könnte.

Ich Nutze einen STM32G431 Nucleo Board um den Absolutwertgeber per SPI 
auszulesen.

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)

Vielleicht fällt jemandem auf, was mein Fehler sein könnte.

Danke und viele Grüße
Peter

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Thomas H. (thomash2)]

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.

[Franko P. (sgssn)]

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


Gruß

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Kevin M. (arduinolover)]

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

[Peter H. (borntopizza)]

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

[Peter D. (peda)]

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.

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

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

[Bernd G. (Gast)]

Thorsten O. schrieb:
> Ich habe mich schon gewundert, seit wann es Resolver mit
> SPI-Schnittstelle geben soll...

Steht ja auch klar und deutlich auf der ersten Seite, dass es ein 
SSI-Geber ist.

[Rainer W. (rawi)]

Lothar M. schrieb:
> Screenshots von digitalen Bildern am besten im nichtkomprimierenden PNG

Seit wann ist das PNG-Format nichtkomprimierend?

[Falk B. (falk)]

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.

[Rainer W. (rawi)]

Falk B. schrieb:
> Er meinte verlustfreie Kompression. JPG macht Artefakte, siehe
> Bildformate.

Meine Glaskugel ist leider zur Wartung.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.