Guten Abend, ich habe mal eine Frage und möchte ich mit einem ADC über SPI ein Signal am Raspberry-Pi auslesen. Im Datenblatt ist der ADC mit 1 MSps bepreist. Jeder Messtwert ist 2 Byte (inkl Führungsnullen groß) Um dem 1 MSps zu kommen wird die Taktleitung auf 15.6 Mhz getaktet. Macht ziemlich genau 1,024*10^-6 Sekunden pro Messwert. Um die Geschwindigkeit zu überprüfen habe ich 1 Sekunde lang ein 1 Hz, 1 V Sinus-Signal aufzeichen lassen. Dabei kommt der Graph aus der Abbildung raus, die Taktung scheint also etwas niedriger zu liegen als die 15,6 Mhz. Wisst ihr woran das liegt und wie ich den Messwerten einen Zeitpunkt in Referenz zum ersten Messwert zuordnen kann ? Ich hatte gehofft, die Messwerte mit n*1,024 Mikrosekunden durchnummerieren zu können.
Angehängte Dateien:
-
graph.JPG
65 KB
Der Takt vom SPI Master muss schon passend konfiguriert werden, von alleine passiert das nicht.
wie meinst du das, ich hatte doch geschrieben, dass im Skript der Takt von 15,6 MHz eingestellt wird?
Na dann nimm eine Scope und mess den Takt nach.
Ja das werde ich vermutlich auch so machen müssen, dachte es gäbe da vielleicht schon erfahrungen dass der Takt schankt oder woran es liegen könnte.
Der Takt wird 15,6MHz haben, er läuft aber m.W. nicht durch. Dadurch dauert das ganze länger als gedacht. Normalerweise macht man das aber auch schneller und fragt die Daten als Words im gewünschten Raster ab um genau das zu vermeiden.
Das Sampling selbst wird gemäß der Doku im DMA Controller durchgeführt und sollte doch daher eigentlich keine Verzögerung aufweisen, oder doch? Jens M. schrieb: > Normalerweise macht man das aber auch schneller und fragt die Daten als > Words im gewünschten Raster ab um genau das zu vermeiden. Hast du dazu nähere Infos ? Im Web finde ich außer Word (Textverarbeitung) nichts dazu.
Ja, wie jetzt? Du willst 15600000 Bits pro Sekunde haben und stellst das als Takt ein. Der SPI-Master hat aber die Angewohnheit, 8 bits abzufragen und dann abzugeben, danach kommen die nächsten 8 bits. Effektiv braucht er für 8 bits also z.B. 8,5 Zeit. Und schon ist deine Samplerate durch, denn der Takt ist mit 15,6MHz festgelegt, macht aber eben immer ein kleines Päuschen alle 8 Bits. Halt mal nen Ossi dran, dann siehst du das. Das ist kein konstanter 15,6MHz-Rechteck. Also macht man normal die SPI-Rate höher und stellt das System nicht auf 15,6MHz Takt sondern auf 1Msps ein, d.h. jede Mikrosekunde wird ein "Samplestart" geschickt und dann die Werte eingelesen und weggespeichert. Mit den Pausen umzu muss man dann eben 18, 20 oder noch mehr MHz SPI-Takt einstellen, und zwar so lange, bis man am Ossi sieht, das zwischen 2 Samples eine kurze Ruhephase ist. In deiner Situation ist das nicht der Fall, die Anforderung eines neuen Samples kommt schon, während das vorherige noch eingelesen wird.
RPi schrieb: > Um dem 1 MSps zu kommen wird die Taktleitung auf 15.6 Mhz getaktet. > Macht ziemlich genau 1,024*10^-6 Sekunden pro Messwert. Und schon falsch. Wenn pro Meßwert 2 Byte übertragen werden müssen, dann braucht man mindestens 16MHz SPI-Takt für 1Msps. > Um die Geschwindigkeit zu überprüfen habe ich ... > die Taktung scheint also etwas niedriger zu liegen als > die 15,6 Mhz. Wisst ihr woran das liegt Du kannst die SPI-Taktfrequenz nicht auf beliebige Werte einstellen. Die wird mit einem Frequenzteiler aus dem CPU-Takt abgeleitet, kann also nur ein ganzzahliger Bruchteil der CPU-Frequenz sein. Der SPI-Treiber im Linux-Kernel akzeptiert andere Frequenzen zwar, rundet die tatsächlich verwendete Taktfrequenz aber auf den nächstliegenden möglichen Wert.
Axel S. schrieb: > Du kannst die SPI-Taktfrequenz nicht auf beliebige Werte einstellen. Die > wird mit einem Frequenzteiler aus dem CPU-Takt abgeleitet, kann also nur > ein ganzzahliger Bruchteil der CPU-Frequenz sein. Der SPI-Treiber im > Linux-Kernel akzeptiert andere Frequenzen zwar, rundet die tatsächlich > verwendete Taktfrequenz aber auf den nächstliegenden möglichen Wert. Es kommt noch dazu, dass die SPI Hardware im RaspberryPi so ihre Eigenheiten hat, z.B. ändert sich die Taktrate, wenn die CPU in den Turbo-Modus geht.
Angehängte Dateien:
-
fig39.png
40 KB -
table4.png
160 KB
Jens M. schrieb: > Der SPI-Master hat aber die Angewohnheit, 8 bits abzufragen und dann > abzugeben, danach kommen die nächsten 8 bits. Echt ist das so? Ich hätte vermutet, dass man auch die Länge in Bits einstellen kann, hier dann eben auf 16. Und auch 16 MHz SPI-Takt reichen üblicherweise nicht. Um welchen ADC handelt es sich denn? Die allermeisten ADCs geben die Daten nämlich nicht dauerhaft aus, sondern haben verschiedene Zustände. Und nur in einem der Zustände kann man die Bits heraustakten. Als Beispiel mal ein Bild eines 16 Bit 1 Msps ADCs, dem AD7902, Datenblatt: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7902.pdf Auf Seite 18 Figure 39 ist das Timing aufgemalt, und auf Seite 5 in Tabelle 4 stehen die Werte drinnen. Beides im Anhang als Bildchen. Ein Zyklus sind also minimal t_cyc 1000ns, das macht 1MHz, passt. Während der Conversion Phase werden keine Daten ausgegeben. Diese Phase dauert t_conv minimal 500 ns. Dann hat mal also nur noch maximal 500 ns Zeit die 16 Bits abzuholen. Macht 500 ns/16 = 31.25 ns entspricht 32 MHz. Jetzt kann der Stein aber mit t_sck minimal 10,5 ns wenn er mit 5V betrieben wird. Das sind schon 95,24 MHz. Dann dauert es nurnoch 168 ns um die Daten zu lesen. So kurz muss es aber nicht sein, denn t_conv sollte maximal 700 ns lang sein. Also wählt man einen schön passenden Wert mit dem sich gut arbeiten lässt. Z. B. einen 50 MHz SPI Takt, dann sind das 16*20ns=320 ns um die Bits zu lesen, drum herum ggf. noch etwas Pause zwichen den Flanken vom CS bis zum Takt und der Rest wird dann als t_conv verwendet.
Gustl B. schrieb: > Echt ist das so? Ich hätte vermutet, dass man auch die Länge in Bits > einstellen kann, hier dann eben auf 16. Die 8 war jetzt als Beispiel, aus 8 und 8,5 werden dann eben 16 und 16,5. You get the idea... Die meisten SPI-Module sind aber byte-orientiert, auch wenn die CPU mehr kann/hat, und ich meine gelesen zu haben, das speziell der RPi sogar eine sehr lange Pause macht, warum auch immer. rµ schrieb: > Es kommt noch dazu, dass die SPI Hardware im RaspberryPi so ihre > Eigenheiten hat, z.B. ändert sich die Taktrate, wenn die CPU in den > Turbo-Modus geht. Weil der Teiler nicht mitgeändert wird. Axel S. schrieb: > Der SPI-Treiber im > Linux-Kernel akzeptiert andere Frequenzen zwar, rundet die tatsächlich > verwendete Taktfrequenz aber auf den nächstliegenden möglichen Wert. Nächstgelegen oder Nächsthöher? Ersteres wäre ja noch schräger, dann wäre man u.U. ja noch mehr zu langsam als eh schon...
RPi schrieb: > die Taktung scheint also etwas niedriger zu liegen als die 15,6 Mhz. > Wisst ihr woran das liegt Netto != Brutto Was genau passiert, sagt dir ein Oszilloskop. Das brauchst du sowieso zur Inbetriebnahme einer seriellen Schnitte. Denn bei solchen Taktraten musst du auf jeden Fall die Signalqualität (Falnkensteilheit, Überschwinger,...) kontrollieren. RPi schrieb: > Das Sampling selbst wird gemäß der Doku im DMA Controller durchgeführt > und sollte doch daher eigentlich keine Verzögerung aufweisen, oder doch? Zwischen zwei Übertragungen möchte so ein SPI-Bautein meist auch mal per SS# Eingang deselektiert und erneut selektiert werden, um eine Wortsynchronisation zu bekommen. Und für diesen Vorgang müssen oft auch noch irgendwelche Mindestzeiten eingehalten werden. Es ist übrigens eine ganz schlechte Idee, völlig ohne Frame-Synchronisation per SS# zu fahren, auch wenn der Bautein das könnte. Denn wenn dann ein kleiner ESD-Impuls auf der SCLK Leitung auftritt, bist du den Rest des Tages um 1 Bit versetzt und liest nur noch unsinnige Werte ein.
:
Bearbeitet durch Moderator
Jens M. schrieb: > Axel S. schrieb: >> Der SPI-Treiber im >> Linux-Kernel akzeptiert andere Frequenzen zwar, rundet die tatsächlich >> verwendete Taktfrequenz aber auf den nächstliegenden möglichen Wert. > > Nächstgelegen oder Nächsthöher? > Ersteres wäre ja noch schräger, dann wäre man u.U. ja noch mehr zu > langsam als eh schon... Das ist so oder so egal. Wenn man ein exaktes Timing einhalten will, sollte man den ADC den SPI-Takt vorgeben lassen. Der RasPi ist dann SPI-Slave und wenn man genug Buffer hat und die schnell leert (DMA?), dann bekommt man auch einen hypschen kontinuierlichen Datenstrom. Oder wenn man die Reserven hat, dann macht man das SPI sehr viel schneller als theoretisch nötig wäre und macht entsprechend Pausen zwischen den Datenworten. Details darfst du selber nachschlagen. ich erinnere mich nur, letztens mal eine Tabelle der möglichen SPI-Taktraten des RasPi gesehen zu haben [1]. Auslöser war ein Thread hier. Irgendwas mit Problemen wenn der RasPi als SPI-Slave arbeiten soll. [1] möglicherweise hier: http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_SPI.html - die beschränkte Auswahl an Frequenzen ist aber wohl eine Softwaresache, die Hardware kann mehr [2] [2] https://raspberrypi.stackexchange.com/questions/699/what-spi-frequencies-does-raspberry-pi-support
Die meisten ADCs haben keine Taktquelle um SPI Master zu spielen. Und wenn die einen Takt haben, dann wird oft nur der verzögerte Takt vom Takteingang ausgegeben. Ja man kann das mit einem externen Taktgeber und etwas Logikschaltung lösen. Ist hier in dem Fall aber vermutlich nicht so. Daher nochmal: Welcher ADC wird hier verwendet?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.