Hallo Forum, ich benötige mal die Hilfe erfahrener Entwickler, ich komme nicht weiter beim Entwurf einer ADC-Strecke zum digitalisieren von Pixeldaten (NIR-Sensor). Die Ansteuerung des Sensors ist soweit fertig, allerdings habe ich Probleme beim Beschalten und der Taktung des ADC. Der NIR-Sensor liefert ein ADC-Trigger Signal, welches zum Sampeln verwendet werden soll. Die fallende Flanke des ADC-Trigger Signals gibt den optimalen Samplepunkt wieder. Der Sensor hat 192 Pixel, das ADC-Trigger-Signal beinhaltet also 192 clocks (siehe Anhang1). Nach den 192 clocks ist ADC-Trigger solange „High“ bis die nächste Messung getätigt wird, bzw. die Zeile erneut ausgelesen wird. Diese Pause habe ich auch wenn ich den Sensor kontinuierlich auslese, da zwischen jeder Messung immer eine „Processing Time“ von wenigen µs nötig ist. Siehe Anhang 2. Der ADC AD9826 http://www.analog.com/static/imported-files/data_sheets/AD9826.pdf sampelt auch bei fallender Flanke, das passt also erst einmal gut zusammen. Betreiben möchte ich den ADC im „1-Channel SHA Mode“. Der ADC benötigt in diesem Modus zwei clocks (CDSCLK1 und ADCCLK) zur Verarbeitung der Pixeldaten. Das Problem liegt für mich nun bei folgendem: Wenn ich Seite 13 des AD9826 datasheets (3channel SHA-Mode) richtig verstehe, benötige für das korrekte Verarbeiten/Sampeln der Pixeldaten nicht 192 fallende Flanken an CDSCLK1 und ADCCLK, sondern 192+3=195 clocks. “The output data latency is three ADCCLK cycles”. D.h. für mich, das erst 3 clocks nach dem pixel 192 gesampelt wurde, die digitale Information am Ausgang des ADC liegt. Diese 3 clocks zusätzlichen besitzt aber mein ADC-Trigger Signal nicht, nach 192 ist Schluss. Fragen: A)Verstehe ich das DB des AD9826 überhaupt richtig? B)Falls ja, war meine Idee nun, dass ich das ADC-Trigger Signal mit einem CPLD einlese, 3 clocks anhänge und dann erst auf den ADC gehe. Es würde zwar ein kleines Delay durch die Laufzeit entstehen, ich denke aber damit kann man leben?! C)Wie würdet ihr so etwas lösen? D)Falls die Idee mit dem CPLD gut ist, könnte mir jemand beim Programmieren helfen, VHDL ist nicht so meins :) E) ADCCLOCK muss zu CDSCLK verschoben sein, auch das würde ich gerne mit einem CPLD lösen... Bitte prügelt nicht zu sehr auf mich ein, ich benötige wirklich dringend Hilfe und bin kein Crack auf dem Gebiet :) Mfg fwc
Angehängte Dateien:
>The output data latency is three clock cycles.
Das bedeutet, dass die digitalisierten Ausgangswerte (bezogen auf den
analogen Eingang) drei Takte später am Ausgang anliegen.
Woher sollen denn die drei Takte ADCCLK, CDSCLK1 und CDSCLK2 kommen?
Liefert der Sensor mehrere Takte oder nur einen?
der Sensor liefert nur einen Takt: ADC-Trigg. Im 1 channel SHA-Mode benötige ich nur CDSCLK2 und ADCCLK für den ADC. Den ADC-Trigg-Takt der aus dem Sensor kommt plane ich mit einem CPLD weiter zu verabeiten, so das CDSCLK2 und ADCCLK generiert werden. Allerdings benötige ich (wenn ich das richtig verstehe), jeweils 3 clocks mehr, als mir ADC-Trigg liefert.
uiui.. clock an und aus... das wird hart... wo sollen die extra-takte auch herkommen. Aber der Sensor bekommt doch bestimmt irgendwoher einen Referenz-Takt oder ähnliches. Such Dir doch erstmal einen druchlaufende Clock die syncron zu deinen Pixel-Daten ist. Gruß
fwc schrieb: > Allerdings benötige ich (wenn ich das richtig verstehe), > jeweils 3 clocks mehr, als mir ADC-Trigg liefert. Ist doch halb so schlimm, die kommen ja vom Sensor mit der nächsten Zeile... Du musst also einfach einen Synchronimpuls erzeugen, der um 3 Taktimpulse versetzt ist: erst nach 3 Takten der "neuen" Zeile ist die "alte" durch den Wnadler durch.
Lothar Miller schrieb: > Ist doch halb so schlimm, die kommen ja vom Sensor mit der nächsten > Zeile... > Du musst also einfach einen Synchronimpuls erzeugen, der um 3 > Taktimpulse versetzt ist: erst nach 3 Takten der "neuen" Zeile ist die > "alte" durch den Wnadler durch. Das hatte ich mir auch schon überlegt, aber dann habe ich ja das Problem, das der letzte Pixel der aktuellen Zeile erst verzögert (also um die Pause des ADC-Trigg-Taktes) gesamplet wird, während die anderen Pixel schon im PC sind. Oder verstehe ich dich falsch? Von der Idee CDSCLK2 und ADCCLK aus ADC-Trigg mit einem CPLD zu generieren haltet ihr nichts?
ähm... um an die Daten zukommen brauchst du einen 16fachen Datentakt für das SPI-Interface. Wo kommt der her ? Gruß
was meinst du? Die Konfiguration des AD9826 durch das 3wire Interface (SPI) habe ich auch im CPLD realisiert. Der CPLD wird mit 40MHz getaktet. Die SPI selbst, takte ich nur mit 1MHz, also SCLK=1MHz.
fwc schrieb: > was meinst du? Gemeint war, dass die Daten auch über die SPI-Schnitte abgeholt werden würden.... > Der CPLD wird mit 40MHz getaktet. Hat dieser Takt was mit dem Takt vom Sensor zu tun? Wird der Sensor auch mit diesen 40MHz versorgt? > während die anderen Pixel schon im PC sind. In welchem PC? Der ist neu hier... > dann habe ich ja das Problem, das der letzte Pixel der aktuellen Zeile > erst verzögert (also um die Pause des ADC-Trigg-Taktes) gesamplet wird, > während die anderen Pixel schon im PC sind. Überlegs dir mal: genau das ist kein Problem. Denn es juckt ja überhaupt nicht, wenn du im "PC" 3 Pixel Offset hast. Das kannst du da leicht korrigieren, das ist nur Software....
Angehängte Dateien:
Hallo Lothar, also die 40MHz ist sowohl die GCK des CPLD als auch der Masterclock für den Sensor. Der Pixeloutput beträgt allerdings nur 5MHz. hier noch einmal kurz eine schematische Darstellung (Anhang). Die digitalisierten Daten sollen von einem FPGA aufgenommen und über Ethernet an einen Host-PC gesendet und verarbeitet werden (das ist bei dem Projekt dann allerdings nicht mehr mein Part). Die Sache ist, der Sensor soll Materialien detektieren, welche kontinuierlich unter dem Chip hinweglaufen. Dazu muss eine Zeile immer komplett im PC vorhanden sein. Habe ich die Zeile erst komplett im PC wenn die nächste Zeile (also die nächste Detektierung) verarbeitet wird, kommt es zu Fehlern in der Erkennung. Deswegen noch einmal die Frage: macht es Sinn und wie kompliziert ist es dem CPLD als Input die ADC-Trigg clock zu liefern und daraus CDSCLK2 und ADCCLK zu generieren?
Hi Ist die Schaltung fertig ? Warum den CPLD, und nicht alles durch/vom den FPGA ? Sensor, ADC und FPGA laufen doch Syncron zu den 40 MHz, dann kannst du auch einfach ne rising-edge detection auf das Trigger-Signal machen. Dann hast du auch keine Problem beliebige extra Takte zu erzeugen, für einen FPGA ist das ein einfach Spiel... Gruß
fwc schrieb: > Die Sache ist, der Sensor soll Materialien detektieren, welche > kontinuierlich unter dem Chip hinweglaufen. Dazu muss eine Zeile immer > komplett im PC vorhanden sein. Da ist ja zwischen dem ADC und dem PC noch ein FPGA. Dann ist das überhaupt kein Problem! > Habe ich die Zeile erst komplett im PC wenn die nächste Zeile > (also die nächste Detektierung) verarbeitet wird, kommt es zu Fehlern > in der Erkennung. Dann hast du noch irgendwo einen Fehler im System. Denn der PC merkt es überhaupt nicht (er kann es gar nicht merken!), wann der Sensor mit einer Zeile fertig ist. Und deshalb muss es egal sein, wann die Daten für die letzte Zeile kommen. Die paar ms dürfen da nichts ausmachen können, zumal sie sogar konstant sind. Zeichne dir das Ganze einfach mal auf: immer nach dem 3. Impuls der aktuellen Zeile kannst du die letzte Zeile auf den Weg schicken. Das Timing bleibt insgesamt gleich, die Daten kommen nicht schneller, nur ein wenig später...
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.