USART Probleme mit Receiver, bleibt in schleife hängen, AD7687

[Nikolai E. (Firma: Student) (nikolaie88)]

So ich hoffe mal, dass ich mich nicht blamiere ;)
Ich benutze einen ATMEGA168 und möchte einen AD7687 (ADWandler) 
ansteuern.

ich nutze dden USART im MSPIM, dieser ist auch korrekt konfiguriert, 
denn einen DAC kann ich bereits ansteuern.

Den AD Wandler steuert man mit einer Flanke an mit folgendem Einlesen.
Er spuckt 16Bit aus.

Ich benutze folgenden Code, er führt die Schleife einmal aus, bleibt 
dann aber beim neuen Durchlauf hängen in der Receive Funktion.

Es steht alles in der main(), die Ports etc sind korrekt eingestellt.

 for (int i; i <= 4; i++) _delay_us(1);
    PORTD ^= (1<<PD2);
    for (int i; i < 2; i++) _delay_us(1);
    PORTD ^= (1<<PD2);
    for (int i; i <= 10; i++) _delay_us(1);
    
    cnv_data[0] =
    USART_Receive();
    
    cnv_data[1] = 
    USART_Receive();

    for (int i; i <= 10; i++) _delay_us(1);
    
    USART_Flush();
    
   // for (int i; i <= 1000; i++) _delay_us(1);
    //if( cnv_data[0] > 0 || cnv_data[1] > 0 )
     PORTD ^= (1<<PD5);

____________________________________________________________

Die Versuche mit dem Flush Befehl sind neu , ohne gehts auch nicht.
Es handelt sich hier um die Standard Receive Funktion aus dem Datenblatt 
des ATMEGA168, er bleibt beim 2. Durchlauf der main while(1) hängen, 
beim ersten Durchlauf schaltet er die Diode an. Die Receive-Befelhle 
werden also ausgeführt. Dann aber sagt er, er findet keine neuen Daten 
und bleibt in der while der Rec-Funktion hängen, weil wohl das RXC0 Flag 
nicht auf 0 geht.

Danke für Helfe :))

[isidor (Gast)]

Nikolai Ehrhardt schrieb:
> die Ports etc sind korrekt eingestellt.

Bitte ganzes Programm zeigen und Schaltplan dazu.

[W.S. (Gast)]

Nikolai Ehrhardt schrieb:
> ich nutze dden USART im MSPIM, dieser ist auch korrekt konfiguriert,
> denn einen DAC kann ich bereits ansteuern.

Das glaube ich dir nicht.

Zitat:
"Serial interface SPI®/QSPI™/MICROWIRE™/DSP-compatible"

Lies das Datenblatt des AD7687. Dessen Interface ist SPI, konkret SDI, 
SDO, SCK und CONV. Da ist ein USART wirklich nicht geeignet, es sei 
denn, man kann ihn zum SPI Interface umprogrammieren.

Abgesehen davon ist das ein 250 kSamples/s ADC und ich befürchte, so ein 
ATmega168 ist für diesen ADC ein bissel zu langsam.

Also, dein Fehler ist (wie ach so häufig), daß du die Unterlagen zu 
deinem Chip nicht gelesen hast.

W.S.

[spess53 (Gast)]

Hi

>Da ist ein USART wirklich nicht geeignet, es sei
>denn, man kann ihn zum SPI Interface umprogrammieren.

Der ATMega168 besitzt eine USART mit SPI-Mode. Aber ob die 
ARDUINO-Software das auch kann?

MfG Spess

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

W.S. schrieb:
> Da ist ein USART wirklich nicht geeignet, es sei denn, man kann ihn zum
> SPI Interface umprogrammieren.
Kann man.

> Fehler ist (wie ach so häufig), daß du die Unterlagen zu deinem
> Chip nicht gelesen hast.
Siehe Anhang...

> Abgesehen davon ist das ein 250 kSamples/s ADC und ich befürchte, so ein
> ATmega168 ist für diesen ADC ein bissel zu langsam.
Macht doch nichts. Langsamer geht immmer...

spess53 schrieb:
> Aber ob die ARDUINO-Software das auch kann?
Ratestunde? Glaskugel? Ach so: USART_Receive()...USART_Flush()...

[isidor (Gast)]

W.S. schrieb:
> es sei
> denn, man kann ihn zum SPI Interface umprogrammieren.

Kann man. Ein Blick ins Datenblatt würde helfen.

W.S. schrieb:
> Also, dein Fehler ist (wie ach so häufig), daß du die Unterlagen zu
> deinem Chip nicht gelesen hast.

[Nikolai E. (Firma: Student) (nikolaie88)]

Ich habe nun ersuche gemacht mit

    USART_Transmit(0b00000000);
    cnv_data[0] =
    USART_Receive();
    USART_Transmit(0b00000000);
    cnv_data[1] =
    USART_Receive();


dann läuft die Schleife durch, ist das nun standard so, dass so ich so 
tun muss als ob ich was sende, damit der Takt zum Lesen anspringt, 
scheint Forschungsthema zu sein...

Im Application Note, steht sowas ähnliches ...

Eigentlich sagt er im Datenblatt, dass Takterzeugung für R/T ist.
Also das kann es doch nicht sein?

[isidor (Gast)]

Nikolai Ehrhardt schrieb:
> Eigentlich sagt er im Datenblatt, dass Takterzeugung für R/T ist.
> Also das kann es doch nicht sein?

Doch doch ...

Im SPI Mode gibt es nur einen Takterzeuger, und das ist der Master.
Mit dem Aufruf USART_Transmit(..) erzeugst du ein Clock Paket
das den Slave veranlasst seine Daten auszugeben. Et voilá, dann
kannst du die Daten im Receive Register abholen.

[Nikolai E. (Firma: Student) (nikolaie88)]

Joa, also an den Gast der da rumspammt und einen abtut, ... hab ich nix 
zu sagen :)

Joa mich wundert bloß, dass er keinen Takt erzeugt beim Receive-Aufruf.
Weil ist ja als Master konfiguriert.
Aber wenn das so richtig ist .... ?! Dann Gut Gut

Ansonsten Dankeschön.

[Falk B. (falk)]

@ Nikolai Ehrhardt (Firma: Student) (nikolaie88)

>Joa mich wundert bloß, dass er keinen Takt erzeugt beim Receive-Aufruf.

Das ist so bei SPI. Der Master gibt beim Senden den Takt vor. PARALLEL 
dazu wird ein Byte auch empfangen. Das kann man nach dem Senden 
auslesen. Einfach Auslesen wollen ohne vorher zu senden geht nicht.