ADC LTC2445 - Funktionskontrolle / Ansteuerung über SPI

Ah, die Clock ist nicht immer zu sehen, sondern immer nur alle 2  - 4 ms 
für die Dauer einer Datenübertragung (also 32 mal gehts auf Low runter)
Das scheint also doch irgendwie zu gehen

Hi nochmal,
ich hab jetzt mal probiert, die SPI Daten manuell einzulesen, weil ich 
es gerne verstehen würde. Mir ist klar, dass man das wohl in dem meisten 
Anwendungen mit der SPI-Einheit von nem Microcontroller macht :)

Wie auch immer, mein Versuch war folgender:

1

while(1)

2

  {

3

i=0;

4

  mPORTBClearBits(BIT_2);  //ADU aktivieren

5

6

  while(mPORTFReadBits(BIT_6)) ; // Warten auf fallende Taktflanke 

7

  while(!mPORTFReadBits(BIT_6)); // Warten auf steigende Taktflanke

8

9

  while(i<32)

10

    {

11

    ausgabe[i]=mPORTFReadBits(BIT_7);  // Datenbit lesen

12

    while(mPORTFReadBits(BIT_6)) ;    // Warten auf fallende Taktflanke

13

    while(!mPORTFReadBits(BIT_6)) ;  // Warten auf steigende Taktflanke

14

    i++;  // Nächstes Bit

15

    }

16

  mPORTBSetBits(BIT_2); //ADU deaktivieren

17

18

for(i=0;i<=500000;i++) ; //Warten

19

}

Dabei gilt:
BIT_6 ist die externe Clock vom ADU
BIT_7 ist SPI
BIT_2 ist CS - und das wird anscheinend nur zum an und auschalten vom 
ADC-verwendet...

Irgendwie ist aber mein Ergebnis nicht plausibel :( - obwohl ich die 
Spannung am ADU nicht ändere bleiben nicht mal die ersten 2 MSBs 
gleich...und das kann ja irgendwie nicht sein
Fang ich mir hier irgendwelche Bit-Verschiebungen ein?
Ich dachte, dass kann ich abwenden, in dem ich den ADU nach jeder 
Konversation abschalte...

Die externe Clock vom ADU läuft mit 1 MHz.
Kann es sein, das die ALU da nicht schnell genug ist, um da mitzukommen?
Ich verwende das PIC-StarterKit von Microchip mit einem PIC32MX360?

Hi,
warum erzeugst Du nicht selbst den Takt für die SPI. Ist in den meisten 
Fällen die bessere Wahl

ja, die Herren, die die Platine fertigen lassen haben, haben das 
verbockt :/ - der eine PIN der dafür verantwortlich ist liegt auf 5 V 
und das ist eine winzig kleine Platine. Und des Ding gibts jetzt in 
x-facher Ausführung. Damit hatte ich gar nix zu tun :] - Aber mir wurde 
jetzt gesagt, ich soll mal schauen, was man da machen kann, dass es 
trotzdem geht. So wie ich die SPI-Architektur verstanden hab, sollte es 
doch eigentlich in beide Richtungen funktionieren...

Hex Oschi schrieb:
> Der Controller sollte immer der Master sein. Alles andere macht wenig
> Sinn.

Warum ist das so schlimm? Weil man die Übertragung der einzelnen 
Datenwerte schlecht voneinander unterscheiden kann?

Ist mein Code denn vom Prinzip her richtig? ?

ah egal, der Code ist einfach richtung und der uC ist mit 80 MHz einfach 
zu langsam um eine 1Mhz Clock und die zugehörigen Datenbits schnell 
genug zu erfassen.

Versteh zwar nicht genau warum, aber anscheinend braucht es mehr als 80 
CPU-Zyklen um einen Port viermal zu lesen :)

Werds über das SPI-Register machen.
Aber warum es ein Problem ist, dass der ADU der Master ist versteh ich 
nicht. Wenn Chips miteinander über SPI kommunizieren muss ja auch einer 
der Slave sein... :)

Hi,
im Prinzip ist auch ein Microcontroller als "Slave" nutzbar. Versuch 
doch mal, denn zeitkritischen Teil in Assembler zu machen. Sind ja nur 
ein paar Zeilen.

Niemand schrieb:
> Hi,
> im Prinzip ist auch ein Microcontroller als "Slave" nutzbar. Versuch
> doch mal, denn zeitkritischen Teil in Assembler zu machen. Sind ja nur
> ein paar Zeilen.

hihi, ich hab leider null Plan von Assembler :)

Mit SPI klappts nun wunderbar, auch wenn der Mikrocontroller Slave ist 
:)