Forum: Mikrocontroller und Digitale Elektronik Probleme beim Auslesen von ADS8698 mit Arduino


von Christian D. (cdegelmann)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

wir sind zurzeit dabei innerhalb eines Projekts einen AD-Wandler mit 
einem Arduino über die SPI- Schnittstelle in Betrieb zu nehmen. 
Allerdings häufen sich dabei leider die Probleme.

Es handelt sich um einen 18-Bit AD-Wandler ADS8698 mit 8 Kanälen 
(http://www.datasheets360.com/pdf/-2640322731015858730?query=ADS8698&pqid=70380223).

Die Verkabelung erfolgt gemäß der SPI-Kommunikation über die Leitungen 
SDI, SDO, CS und SCLK. Vorschaltungen für den AD-Wandler haben wir 
größtenteils aus dem Datenblatt übernommen, um bessere Ergebnisse zu 
erzielen (Spannungsversorgung, Vorschaltung bei interner Referenz etc.). 
Weiterhin haben wir den Anschluss RST/PD des AD-Wandlers dauerhaft auf 
HIGH und DAISY auf LOW gesetzt.

Bisher versuchen wir über das Setzen der Programmregister (Kapitel 8.5.2 
im Datenblatt) einen Befehl an den AD-Wandler zu schicken und uns 
letzten Endes die Antwort über die SDO-Leitung herausgeben zu lassen.
Unser Befehl (Programm Register) setzt sich dabei aus 16 Bits zusammen, 
wobei die ersten 7 Bits die Register Adresse angeben, das nächste Bit 
gibt an ob es sich um einen Lese- oder Schreibbefehl handelt  und die 
letzten 8 Bits beinhalten den Befehl. Unmittelbar danach müssten über 
die SDO-Leitung die Daten, welche in das Register geschrieben worden 
sind, ausgegeben werden.

Wir senden dementsprechend in unserem Sketch zunächst den Befehl

SPI.transfer(0x05);

um anzugeben, dass wir einen Schreibbefehl senden wollen, mit dem wir 
festlegen welche der 8 Kanäle in den Power-Down versetzt werden und 
welche nicht.

Anschließend senden wir weitere 8 Bits mit unserem Datensatz:

SPI.transfer(0xAA);

Demzufolge sollten uns als nächstes über die Datenleitung SDO 
abwechselnd 0 und 1 gesendet werden (AA).
Im Anhang ist ein solcher Datenaustausch dargestellt (aufgenommen mit 
Oszilloskop, jedoch nicht hundertprozentig synchron dargestellt).
Dabei wird klar ersichtlich, dass alle Kanäle die richtigen Ergebnisse 
liefern, bis auf die MISO-Leitung, welche die Antwort des AD-Wandlers 
beinhaltet. Komischerweise bekommen wir dort durchgängig eine leicht 
zeitverzögerte Version unseres Clock-Signals, welches wir mit dem 
Arduino erzeugen. Wir wissen diesbezüglich einfach nicht mehr weiter.
Unser Sketch sieht wie folgt aus:
1
#include <SPI.h>
2
// Variablen zum Speichern der Antwort-Bytes erzeugen
3
byte AntwortByte1 = 0;
4
byte AntwortByte2 = 0;
5
byte AntwortByte3 = 0;
6
// Benennung der Pins am Arduino Mega
7
const int CS     = 53;        // Pin 10 beim Uno
8
const int RST_PD = 54;      // Pin für Reset/Power Down -> Dauer-High
9
10
void setup() 
11
{
12
  // Pins definieren
13
  // Master Input, Slave Output
14
  pinMode(MISO, INPUT);              // Pin 50 beim Mega, Pin 12 beim Uno
15
  // Master Output, Slave Input  
16
  pinMode(MOSI, OUTPUT);           // Pin 51 beim Mega, Pin 11 beim Uno
17
  // Ausgabe Taktsignal an ADC   
18
  pinMode(SCK, OUTPUT);              // Pin 52 beim Mega, Pin 13 beim Uno
19
  // Ausgabe Start der Kommunikation
20
  pinMode(CS, OUTPUT);               // Pin 53 beim Mega, Pin 10 beim Uno
21
  digitalWrite(CS, HIGH);            // Chip Select auf HIGH -> keine Kommunikation
22
  digitalWrite(RST_PD, HIGH);       // Reset/Power Down auf HIGH -> Normalbetrieb
23
  
24
  // SPI-Schnittstelle initialisieren
25
  SPI.beginTransaction(SPISettings(500000, MSBFIRST, SPI_MODE1));  
26
  // Schnittstelle für seriellen Monitor starten
27
  Serial.begin(9600);
28
  }  // Ende des Setups
29
30
void loop()
31
{
32
  // ADC ansteuern
33
  digitalWrite(CS, LOW);      // Chip Select auf LOW -> Start Kommunikation
34
  delayMicroseconds(10);      // kurze Pause
35
  SPI.transfer(0x05);           // erstes Anweisungs-Byte
36
  SPI.transfer(0xAA);         // zweites Anweisungs-Byte
37
  delayMicroseconds(10);      // kurze Pause
38
  
39
  // abspeichern der Antwort-Bytes
40
  AntwortByte1 = SPI.transfer(0);  // Empfangen des ersten Antwort-Bytes, in Variable 1 abspeichern
41
  AntwortByte2 = SPI.transfer(0);  // Empfangen des zweiten Antwort-Bytes, in Variable 2 abspeichern
42
  AntwortByte3 = SPI.transfer(0);  // Empfangen des dritten Antwort-Bytes, in Variable 3 abspeichern
43
  digitalWrite(CS, HIGH);                 // Chip Select auf HIGH -> Ende Kommunikation
44
  
45
}  // Ende des Loops

Wir würden uns wirklich sehr über ein wenig Hilfe von Experten freuen!

Vielen Dank im Voraus!

Gruß

: Bearbeitet durch User
von Frickelfritze (Gast)


Lesenswert?

Wo ist die Definition von MISO?
Wo ist die Definition von MOSI?
Wo ist die Definition von SCK?

Warum schreibst du deine Source nicht so wie es die
Richtlinien verlangen (siehe Formatierung)?

Der MISO Kanal zeigt zu geringen Pegel.

von Frickelfritze (Gast)


Lesenswert?

Frickelfritze schrieb:
> Der MISO Kanal zeigt zu geringen Pegel.

und der MOSI Kanal zeigt zuviel Pegel.

Und das Oszilloskop ist grosser Mist.

von Christian D. (cdegelmann)


Lesenswert?

Frickelfritze schrieb:
> Wo ist die Definition von MISO?
> Wo ist die Definition von MOSI?
> Wo ist die Definition von SCK?
>
> Warum schreibst du deine Source nicht so wie es die
> Richtlinien verlangen (siehe Formatierung)?
>
> Der MISO Kanal zeigt zu geringen Pegel.


Ups, habe die Formatierung direkt geändert! Sorry dafür!

Die Definitionen für MISO, MOSI und SCK sind laut einer Anleitung für 
die SPI-Kommunikation mit Arduino nicht nötig, da diese Kanäle alleine 
durch die Bezeichnung in der Pin Definition erkannt werden, wenn man die 
SPI-Library integriert.

Die Tatsache, dass die Pegel zu gering und zum Teil zu hoch sind, ist 
uns auch aufgefallen. Trotzdem macht der Verlauf ja gar keinen Sinn.
Egal wie schlecht das Oszilloskop ist, der Verlauf dürfte ja trotzdem 
ansatzweise zu erkennen sein.
Das Ergebnis auf der MISO Leitung dürfte demzufolge auf keinen Fall dem 
Clock Signal ähneln.

von Frickelfritze (Gast)


Lesenswert?

Christian D. schrieb:
> Die Tatsache, dass die Pegel zu gering und zum Teil zu hoch sind, ist
> uns auch aufgefallen.

Das solltest du klären. Sonst macht eine weitere Diskussion
keinen Sinn. Ohne saubere Pegelverhältnisse keine Funktion ....

Christian D. schrieb:
> Das Ergebnis auf der MISO Leitung dürfte demzufolge auf keinen Fall dem
> Clock Signal ähneln.

Richtig. Deswegen Verdacht auf Verdrahtungsfehler. Pegel und
Verdrahtung überprüfen.

von Mondragon (Gast)


Lesenswert?

Hi, dumme Frage aber habt Ihr das Sketch dann zum Laufen gebracht?
Ich sitze gerade auch an einem Projekt, bei dem ich den ADS8698 verwende 
und würde mich dafür interessieren :)

Beste Grüße

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
Noch kein Account? Hier anmelden.