Hallo!
Ich habe mir einen ADS 8320 ADC [1] gekauft. Diesen versuche ich jetzt
über SPI mit einem Raspberry Pi anzusteuern. Ich habe die im Datenblatt
vorgeschlagene Schaltung aufgebaut [2] und die Anschlüsse entsprechend
verkabelt. Wenn ich nun 3 Bytes sende und empfange (zum Beispiel mit dem
spi-bcm2708-Treiber, der im Linux-Kernel für den auf dem Pi verbauten
SPI-Controller beiliegt), kriege ich auch tatsächlich Daten, die so
aussehen, wie das was man erwarten würde (ändern sich, wenn man eine
andere Spannung anlegt, etc.). Rechnet man diese allerdings wie folgt
1
// rx ist der Buffer mit den empfangenen Daten und enhält 3 Bytes
2
intr0=rx[0]&0b00000011;
3
intr1=rx[1];
4
intr2=rx[2]&0b11111100;
5
intresult=(r0<<14)+(r1<<6)+(r2>>2);
in eine Dezimalzahl um, so ergibt sich ein sehr merkwürdiges Bild [3],
wenn man die Spannung am Netzteil langsam hoch- und wieder runterdreht.
Bei näherem Hinsehen fällt auf, dass schon in den übertragenen Bitfolgen
immer wieder deutliche Sprünge zu erkennen sind. Ein Beispiel solcher
Daten ist hier [4]: je weiter man runter scrollt, desto größer ist die
anliegende Spannung (die ersten 6 und letzten 2 Bit sind Müll, die Daten
fangen mit dem höchstwertigen Bit beim 7. Bit der ersten Zeile an; die
durch Striche getrennten Dreierblocks sind immer eine Messung). Ungefähr
bei Zeile 170 passiert aber etwas sehr merkwürdiges: Die Einsen am
Anfang verschwinden einfach, ohne das nächsthöhere (achte) Bit zu
flippen. Erst bei der nächsten Markierung (127 Zeilen später) wird
dieses dann inkrementiert -- nachdem das nächst-niederwertige (neunte)
Bit zum zweiten Mal von 1 auf 0 wechselt.
Das verstehe ich nun wirklich überhaupt nicht. Ich konnte dieses
Verhalten mit verschiedenen Bus-Takten zwischen 8kHz und 2MHz
reproduzieren, und zwar mit dem Hardware-SPI-Controller + Kerneltreiber
und meiner eigenen "Bit-Banging"-Softwarelösung über die GPIO-Pins
(letztere erreicht natürlich bei weitem keine 2MHz Bustakt).
Ich habe mir das Ganze auch mit dem Oszilloskop angeschaut, aber bei der
Softwarelösung flackert es extrem, und bei dem Hardware-Controller sind
immer so kleine Pausen zwischen den Bytes, sodass ich mir nie ganz
sicher bin, ob jetzt ein oder zwei nebeneinanderliegende Bits geflippt
wurden... deshalb kann ich leider keine definitive Aussage treffen, ob
man das Verhalten hier auch beobachten kann (das Oszilloskop ist leider
rein analog).
Nun frage ich mich, woran kann das noch liegen? Habe ich den Chip
vielleicht duch unvorsichtiges Löten gegrillt? Ich denke eigentlich
nicht, und wenn, dann wäre das ja doch eine sehr merkwürdige
Fehlfunktion, oder?
Einen zweiten habe ich leider nicht da, weil die ziemlich teuer sind (10
Euro) und ich eigentlich nur einen brauche.
Hat irgendjemand noch eine Idee, was man versuchen könnte, um dem
Problem auf die Spur zu kommen?
Danke und viele Grüße,
Sven
_______
[1] Datenblatt: http://www.ti.com/lit/ds/symlink/ads8320.pdf
[2] Siehe Datenblatt Seite 13. Foto meines Aufbaus:
http://i.imgur.com/28nwU.jpg
[3] Messdaten bei einer zuerst ansteigenden, dann wieder abfallenden
Spannung : http://i.imgur.com/w1gUd.png
[4] http://pastie.org/4897771
>Hat irgendjemand noch eine Idee, was man versuchen könnte, um dem>Problem auf die Spur zu kommen?
Das Timing Diagramm aus dem Datenblatt 1:1 nachbilden?
Das kann man mehr per Bitbanging eigentlich immer gut machen.
Also schön langsam und darauf achten bei welchem Bit wo was passiert.
Wann wird CS auf 0 gezogen, bei welcher Flanke von CLK muss ich lesen...
Wenn das klappt Speed geben;)
Hey,
das habe ich eigentlich probiert, auch darauf geachtet, bei welcher
Flanke die Daten übertragen werden, und mit verschiedenen Delays
versucht... irgendwie hat das nicht geklappt! Immer dasselbe Ergebnis.
:(
Grüße,
Sven
>das habe ich eigentlich probiert, auch darauf geachtet, bei welcher>Flanke die Daten übertragen werden, und mit verschiedenen Delays>versucht... irgendwie hat das nicht geklappt! Immer dasselbe Ergebnis.
Dann machst du was falsch. Was auch immer.
Mit nem AVR, PIC oder ARM hätte ich das Timing Diagramm dieses
ADC in weniger als einer Stunde im Griff.
>das habe ich eigentlich probiert
Mach es nicht "eigentlich" sondern richtig. Dann geht das auch.
Hört sich blöd an, aber so ist es nun ein mal;)
Hi,
holger schrieb:> Dann machst du was falsch. Was auch immer.> Mit nem AVR, PIC oder ARM hätte ich das Timing Diagramm dieses> ADC in weniger als einer Stunde im Griff.
Dass das Bauteil beschädigt ist, hältst du demzufolge für
ausgeschlossen?
Gut, dann werde ich das nochmal probieren. Ich finde es nur sehr
merkwürdig, dass der Hardware-SPI-Controller dasselbe Problem hat wie
meine selbstgeschriebene Lösung -- und für den in Frage kommt ja nur ein
Fehler in Hardware oder im Linux-Kernel, und die sind eigentlich beide
relativ selten. Oder eben eine Inkompatibilität zwischen Controller und
Chip, aber das ist aufgrund der Software-Geschichte auch irgendwie
unwahrscheinlich.
Ich versuch's nochmal mit dem Oszi, vielleicht kann man das ein bisschen
besser einstellen. Dann sieht man vielleicht, ob der Fehler beim
Empfangen der Daten passiert, oder ob der ADC schon falsche Daten
sendet.
Gruß,
Sven
Falscher SPI-Mode?? Ansonsten sieht der Wertebereich aus dem Bild
http://i.imgur.com/w1gUd.png irgendwie stark nach übersteuertem Eingang
aus. Beim Messwert 800 (ca.) hat der Digitalwert den Maximalwert 65535
erreicht. Danach kommt aber nochmal der Rest der positiven Halbwelle. Da
ist was faul. Wie ist In- und In+ beschaltet? Welche Versorgungsspannung
wird genutzt, woher kommt die Referenzspannung?
Messe mal Ratiometrisch, Uref=Vcc, Poti als Spannungsteiler zwischen
Uref, In+ und In-, In- auf GND. Dann noch ein paar nF von In+ nach GND.
Jetzt sollte der Potiweg im Bereich 0x0000 beis 0xFFFF abgebildet
werden.
Hi!
Ich habe einige (eigentlich "alle verfügbaren") SPI-Modes probiert, ich
bin mir ziemlich sicher, dass es daran nicht liegt. Die ankommenden
Daten sind zwar leicht unterschiedlich (der Offset verschiebt sich),
aber das Ergebnis ist im Endeffekt dasselbe. Manche funktionieren
natürlich auch überhaupt nicht. Und: In dem, was ich anhand des
Timing-Diagramms selbst geschrieben habe, gibt es ja so etwas wie einen
Mode gar nicht. :)
Übersteuert sollte das Ganze eigentlich auch nicht sein, im Datenblatt
steht "bis +- VRef", und VRef sind 3.3 Volt. Die kommen vom 3.3V-Pin des
RPi (ich weiß, keine tolle Referenz für tatsächliche Einsätze). Die
Test-Spannung am Input kommt aus einem großen Labornetzteil und beträgt
in dem Diagramm, was ich gepostet habe, maximal 2.5V -- also klar
kleiner als VRef (die beiden Massen sind natürlich verbunden). Das
Labornetzteil habe ich schon bei verschiedenen Gelegenheiten
ausgemessen, dessen Spannung ist sehr stabil und verlässlich. Ein
anderer (viel billigerer!) ADC zeigt eine glatte, saubere Kurve beim
Hochdrehen des Reglers.
Dass die Spannung nach dem Maximalwert abbricht, ist auch nicht das
einzige Problem, diese Abbrüche passieren ja auch während des Anstiegs
immer wieder (in kleinem Maße). Es sieht fast so aus, als ob da im Laufe
der Daten zwei oder drei Bits fehlen, aber so ganz passt das irgendwie
auch nicht.
Das mit dem Poti werde ich morgen mal ausprobieren, danke für den
Hinweis. Ich kann mir zwar nicht vorstellen, dass es an der
Eingangsspannung liegt, aber eine gute Testmethode ist es trotzem.
Grüße,
Sven
Hallo!
Ich habe mich gerade nochmal drangesetzt, und den Fehler gefunden: das
Kabel, mit dem die SPI-Kanäle verbunden waren, war wohl zu lang, und es
haben sich Störungen eingeschlichen. Ein Anlöten von drei
100pF-Kondensatoren der drei SPI-Lanes zu GND neben dem ADC hat das
Problem sofort gelöst, und die Daten sehen jetzt sehr gut aus:
http://i.imgur.com/daKQV.png
Überrascht bin ich, dass man dies auf dem Oszilloskop wirklich überhaupt
nicht gesehen hat, da sah die ganze Kommunikation perfekt scharf aus.
Danke für eure Hilfe.
Viele Grüße,
Sven
Thread beobachten
Seitenaufteilung abschalten
