Problem mit TI ADS 1234 -> bit24-17 immer 0x00 oder 0xFF HILFE! :)

[Avr N. (balze)]

Hallo zusammen,

ich habe ein Problem mit einem TI ADS 1234 (genauer mit 4 davon).

Ich moechte gerne mit diesen 4 ADS1234 insgesamt 16 DMS Messbruecken 
messen.
Soweit ist auch alles klar, Hardwareaufbau funktioniert und ich bekomme 
mit meinem uC auch Messwerte ueber das einfache serielle Protokoll.

Aber offensichtilch mache ich etwas falsch.

Zu den Rahmenbedingungen:
- Atmel Mega328P mit 6Mhz vom
- FTDI232R
- 4 * ADS 1234 mit 6MHz vom FTDI

ASD1234 fest verdrahtet auf Gain 128

Speed vom Atmel auf 80SPS eingestellt
Multiplexer vom Atmel bedient.

Funktioniert soweit, aber:

Ich erhalte fuer das hoechstwertige Byte immer (!) 0x00 oder 0xFF.

Und dies kommt definitiv von den ADS 1234

Ich habe mal einen test aufgebaut und nur den ertsen ADS und nur Kanal 1 
gelesen (4 mal, dann pause, dann von vorne)

Das Ergebins sieht so aus wie  auf den Screenshots zu sehen.

Ich habe den mMitschnitt vom Losic-Analyzer mal mit drangehaengt.
Die Software dazu gibt es hier : http://www.saleae.com/downloads/

Ich freue mich ueber jeden (sinnvollen :) Hinweis.

Schoenen Gruss,

balze aka Avr Noob

[Avr N. (balze)]

Hallo nochmals,

vielleicht noch ein paar zusaetzliche Erklaerungen.

Der ADS hat ein einfaches serielles Protokoll als Ausgang.
Der Pin !DRDY/DOUT ist so lange high, bis er mit der AD Wandlung fertig 
ist.
Ist er fertig mit der Wandlung und es sind gueltige Daten vorhanden, 
geht dieser Pin auf Low.
Legt man dann einen Takt an SCLK an, legt der ADS den ADC Wert in 24bit 
an den !DRDY/DOUT Pin an (MSB first). Ein 25er Takt zieht !DRDY/DOUT 
wieder auf high, bis neue Daten bereit liegen.

Zu den Screenshots:

1) TestApp:

In diesem Screenshot sieht man den Verlauf der Messwerte, wenn ich den 
DMS belaste.
Ich habe die Kraft auf meinen Messstab (DMS) gleichmaessig steigen 
lassen (ich hab's versucht :)
Der _Messwert steigt an und aendert das Vorzeichen beim Erreichen der 
16bit 2er Komplement Darstellung. (2.Byte UEbergang von 127 nach 128)

Interessant daran ist, das mit dem Erreichen der 128 im zweiten Byte
(UEbergang in die negativen Zahlen bei 16 bit 2er komplement) auch das 
dritte Byte (hoechstwertige Byte des ADS) die Wertigkeit aendert (wird 
255).
Genauso aendert sich das dritte Byte beim Wechsel von 255 zu 0 im 
zweiten Byte (wechselt nach 0)
Ich habe den Wert des dritten Byte im Graphen als rote Linie 
dargestellt.


2) Logic Analyzer:

In diesem Screenshot ist ein Mittschnitt der seriellen Uebertragung 
dargestellt. Der Zeitpunkt ist der, an dem die Linie in der 
Testapplikation das erste mal das Vorzeichen wechselt (von hoch positiv 
in hoch negativ).

Man kann erkennen, das die ersten bit in der ersten UEbertragung alle 
positiv sind und in der zeiten UEbertragung alle negativ.

Damit ist belegt, dass dieses Verhalten aus dem ADS1234 kommt und nicht 
im uC falsch verarbeitet wird (oder falsch seriell zwischen uC und FTDI 
uebertragen wird)

Ich wuerde mich ueber einen Hinweis zur Loesung meines Problemes sehr 
freuen.

MfG,

balze aka Avr Noob

[Avr N. (balze)]

Nochmal wieder hochhol.

Sorry, dass ich den thread nochmal hochhole, aber ich brauche hier 
Hilfe.

Ist mein Problem nicht verstaenlich beschrieben oder kennt sich wirklich 
niemand mit ADS1234 aus?

Ich freu mich ueber jeden Hinweis zu Loesung meines Problems.

THX!

balze aka Avr Noob

[Avr N. (balze)]

Da bin ich wieder.

Ich moechte fuer alle, die mal das gleiche Problem haben koennten mal 
eben zusammenschreiben, was (offenbar) die Ursache fuer dieses Verhalten 
war.

Da ich noch ein AVRNoob bin, habe ich ich die seriell uebertragenen 
Ergebnisbits unguenstig in mein Ergebnis (uint32_t) geschrieben.
Ich habe das erste Bit (MSB) 23 nach links ge-shift-et und mit meinem 
(vorher auf 0 gesetzten) Ergebnis verodert.
Das naechste Bit 22 mal ge-shiftet; ver-oder-t.
...
Das vorletzte Bit einmal nach links ge-shiftet; ver-oder-t.
Das letzte Bit ver-oder-t, fertig.

Dies hatte zur Folge, das meine low Zeit im Clock zuerst lang (23 
Operationen) und spaeter sehr kurz war.

Hiermit kommt der ADS 1234 offenbar nicht zurecht.

Jetzt shift-e ich das Ergebnis um 1 nach links und ver-oder-e mit dem 
geholten Bit. Geht schneller .... UUUUUND ..... FUNKTIONIERT !

Danke an alle, die sich ueber mein Problem ernsthaft Gedanken gemacht 
haben.

MfG,

Balze aka AVRNoob

[Jörg B. (joerg-sh)]

Hallo Balze,
wie hast du denn die 4 ASD1234 mit dem Atmega verschaltet?

Vielleicht rückst du evtl. den Schaltplan raus?

Gruß

Jörg

[Avr N. (balze)]

Hallo Jörg,

hoffentlich hast Du die E-Mail Benachrichtigung eingeschaltet.
Ich hatte sie naemlich aus und bin deshalb erst jetzt per Zufall drueber 
gestolpert. Sorry fuer die spaete Antwort.

Im Anhang ist das Eagle Projekt. (Ist mein erstes Eagle Projekt mit 
autodidaktik entstanden. ;-) Hab mich einfach mal mit Eagle rangetraut 
und dabei gelernt. Deshlab gibt's auch keinen Buss und das ganze ist 
etwas (raeusper) unuebersichtlich geworden. Vielleicht kannst Du ja was 
damit anfangen.

Bei meinem Aufbau waren die ADS1234 auf "Breakoutboards" verbaut und die 
fuer die ADS1234 erforderlichen Kondensatoren auf diesem Board 
angebracht. Zum besseren verstaendnis hab ich mal'n Foto rangehaengt.

Da ich ja der AVR Noob bin, sind meine sourcen eigentlich nicht 
vorzeigbar, aber falls es Dir hilft haengen die mit dran.

MfG,

Balze aka AVR Noob

[Jörg B. (joerg-sh)]

Moin Balze,
ja habe ich ;)
Allerdings habe ich mich zwischenzeitlich schon gegen den Chip 
entschieden.
Diese doch sehr eigenwillige SPI Schnittstelle finde ich persönlich zu 
aufwendig...
Im Moment favorisiere ich einen AD7799 von Analog Devices. Der hat 
allerdings leider nur 3 Kanäle.


Trotzdem sehr nett, dass du drüber gestolpert bist!


Gruß

Jörg

[Avr N. (balze)]

Naja, ist ja nicht viel, was ich zu diesem Forum beitragen kann. Da 
freue ich mich über jeden Beitrag, den ich leisten kann. ;-)

Ich bin auch umgestiegen und benutze jetzt den ADS1256 von TI und bin 
sehr zufrieden.

Schoenen Gruss,

Balze aka AVRNoob