Ich verwende den MCP3201 von Mikrochip und möchte das Ergebnis über SPI zu einem ATmega8 senden und von dort über den UART ausgeben. Das erste Byte wird fehlerfrei übertragen. Das zweite wird nur sporadisch gesendet und ist meistens = 0. Dabei hilft es auch nicht einfach weitere Messversuche zu machen bis man das Byte empfängt, sondern so wie es aussieht hängt es von der Eingangsspannung ab, ob das zweite Byte gesendet wird oder nicht. Der AVR ist mit 16 MHz getaktet und die SPI Frequenz wird durch 128 geteilt, d. h. also eine SPI-Frequenz von 125 KHz. Das entspricht doch 125000 / 13,5 = 9,5 ksps 13,5 weil 12 clock cycles conversion time + 1,5 clock cycles analog input sample time lt. Datenblatt oder hab ich etwas falsch verstanden bzw. könnte hier der fehler liegen?
der häufigste Fehler beim Auslesen von SPI Peripherie mit mehr als 8 Bit besteht darin das nicht weiter getaktet wird. SPI macht einen Lesezyklus mit 8 Bit also solltest Du 8 weitere "irrelevante" ausgeben um dem Slave weitere 8 Takte zu spendieren. Dann wird er auch was ausspucken. Sonst müßten wir schon den Code in unserer Glaskugel sehen können, die gerade beim TÜV ist.
Moin! Dein MCP3201 kann die 100ksps aber nur bei 5V Vcc... Außerdem könntest Du ja erstmal probieren, den Wert in deutlich langsameren Abständen abzuholen. Was hast Du denn an den Refenz-Input und an die differenziellen Inputs angeschlossen? Sind alle analogen Signale im spezifizierten Spannungs-Fenster? Keine floating Inputs? Wie schnell ändert sich das analoge Signal, das Du abtastest? Hast Du ausreichende Tiefpässe zwischen Signalquelle und ADC?
Ich sende bereits 2 "Dummybytes". Aber ich schicke einfach mal Plan und Quellcode.
Hm, nach Deinem Plan sollten ca. 50µA durch die Ref. Diode fließen - ist laut Diode ok - aber Dein ADC hat auch Strombedarf - vielleicht mal mit 5k probieren? Sind am Vref tatsächlich stabile 2.5V? Ich würde den Ref-Input auch mit 1-10µF puffern. Hast mal mit einem Multimeter die aniegenden Pegel geprüft? Erst wenn Du Dir sicher sein kannst, dass die analogen Werte von außen richtig sind, kannst Du Dich per SW auf Fehlersuche begeben ;) Ich weiß ja nicht, was Du später mit den Werten anfangen willst, aber je nach Anwendung könnte man noch berücksichtigen, dass Potis analog ziemliche Schweinereien verursachen können -> Tiefpass nach Poti. Die 100nF am Eingang Deines ADCs belasten direkt die Endstufe Deines OPs. Falls Du als Signalquelle mal etwas rauschendes anschließst, kann Dein OP heiß werden - wobei 100nF noch recht moderat sind.
Langfristig hab ich vor eine Temperaturmessung mit einem Pt100 zu realisieren. Am Vref liegen immer so ~2,497 V an, mit Pufferkondensator kann ichs mal versuchen. Welche anliegenden Pegel meinst du denn? Die Versorgungsspannung, Vref und Eingangsspannung sind laut Multimeter i. O.
Was mit gerade noch einfällt: War denn meine Rechnung mit den Samples richtig? Mir ist nämlich aufgefallen, dass bei Verringerung der ksps die Wandlungen deutlich genauer wurden.
Mit Pegeln meine ich auch die Potentiale an V_in +/- Die Abhängigkeit zwischen Sampling & Genauigkeit könnte ich mir nur durch das Sample-Hold-Glied erklären. Wenn Dir die Wahl des AD-Wandler noch frei ist, so würd ich Dir den AD1248 oder Derivate empfehlen. Damit kannst Du ohne viele ext. Bauteile eine sehr genaue Vier-Draht-Messung realisieren. Falls Du bei diesen Bauteilen bleiben möchtest, musst Du dir noch eine Stromquelle ausdenken, sodass der Spannungsabfall über dem PT100 linear zur Temperatur ist - sonst misst Du die Kennlinie Deiner Stromquelle mit. Hast Du den 0-Byte - Effekt nun im Griff?
Das mit der Konstantstromquelle ist logisch nur ich wollte mich erstmal etwas mit externen AD-Wandlern und SPI vertraut machen weil ich damit bis jetzt keine Erfahrung hatte ;-) Bis jetzt ist es noch auf dem Stand, ich komme aber vsl. auch erst dazu Freitag herumzuprobieren. Auf jeden Fall erstmal danke für die Antworten ;-)
Nach dem CS->LOW würde ich eine Verzögerung einbauen. Die paar Nanosekunden zwischen Port setzen und Taktung beginnen werden wohl kaum als Sampling Time ausreichen ;-) Vielleicht mal hier ca. 100 us einplanen. >Der AVR ist mit 16 MHz getaktet und die SPI Frequenz wird durch 128 >geteilt, d. h. also eine SPI-Frequenz von 125 KHz. Das entspricht doch >125000 / 13,5 = 9,5 ksps ALso mal rechnen: ----------------- 16MHz : 128 = 125 KHz (soweit ok). Da der ADC den Takt vom SPI bezieht gehts dann folgendermaßen weiter: Dauer einer Wandlung = (Zeit zw. CS->LOW und dem ersten SPI Takt) + 16 Takte [1 SPI Takt => 8 us * 16 = 128 us] also 100us + 128 us => 228 us (Best case!) Wären dann ca. 4 KHz (1:228us), wenn Du das ganze zyklisch mit max. Geschwindigkeit laufen lassen würdest. Die Befehle für's Port setzen und die serielle Übertragung per UART nehmen wegen dem Polling auch Zeit in anspruch, so dass es wohl eher etwas weniger ist. Nur so als Hinweis: ------------------- Der ADC darf laut Datenblatt nicht langsamer als 10 KHz getaktet werden. (10 KHz SPI Takt), sonst hat sich die Ladung auf dem S&H Kondensator im ADC verflüchtigt, bevor die Messung beendet ist ;-) Und natürlich sollte man zwischen den beiden TX Dummy Bytes des SPI keinen Breakpoint für's debuggen setzen! ;-)
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.