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.
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.
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.
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?
graph.JPG
(65 KB)
