XMega braucht Delay damit HW Module korrekt funktionieren

Chris N. Gast #3921373
Lesenswert?
• ▲
▼ 
Hallo Gemeinde,

ich wundere mich gerade über Probleme mit internen Modulen im XMega an 
meheren Baustellen die ich mit einem ATXMEGA256A3U habe. Vielleicht 
kennt ja jemand von euch dieses Verhalten.

Wenn ich eine Datenkommunikation nach außen durchführen möchte, sei es 
per I2C, SPI oder UART funktioniert immer nur die erste Datenübertragung 
korrekt. Bei der zweiten stimmen die Datenraten nicht mehr. Dieses 
Problem kann ich lösen, indem ich ein Delay nach!!! dem aussenden des 
Datenpacketes einbaue.  Sieht dann zum Beispiel so aus

1
      TWI_MasterWriteRead(&twiDSP, TWI_SLAVE_DSP_W, &volume[0], 5,0);

2
        

3
      while(twiLCD.status != TWIM_STATUS_READY)  //wait until last package was correctly send (wait for Ack from dsp)

4
      {

5
          

6
      }

7
      

8
      _delay_ms(1);

9


10
Der Rest der I2C Programmierung entstammt der Atmel Referenz Implementierung


der XMEGA läuft mit der internen PLL auf 2x mit einem externen 16 MHz 
als Quelle. Also stabiler Systemtakt mit 32 MHz.

Gruß Chris
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Stefan F. Gast #3921407
Lesenswert?
• ▲
▼ 
> Bei der zweiten stimmen die Datenraten nicht mehr.

Ganz sicher? Hast du das nachgemessen? Falls ja, prüfe mal die 
Spannungsversorgung während der Übertragung.

Ansonsten könnte auch daran liegen, dass deine Peripherie etwas Zeit 
benötigt, um empfangene Daten zu verarbeiten. Bei LCD Displays und 
Ultraschall Sensoren ist das ganz Sicher der Fall.

Weiterhin könnte es sein, dass du den R/C Oszillator ohne 
Synchronisation verwendest. Dann läuft er ziemlich instabil (in etwa wie 
beim Atmega).

Vergleiche mit diesem erprobten Code:
1
        // Set clock source to 32Mhz using the internal R/C Oscillator.

2
        OSC.CTRL|=OSC_RC32MEN_bm;

3
        while (!(OSC.STATUS & OSC_RC32MRDY_bm)); 

4
        CCP=CCP_IOREG_gc;

5
        CLK.CTRL=CLK_SCLKSEL_RC32M_gc; 

6
        // Synchronize to the calibrated 32kHz oscillator (needed for the UART)

7
        OSC.CTRL&=(~OSC_RC2MEN_bm);

8
        OSC.CTRL|= OSC_RC32KEN_bm;

9
        while (!(OSC.STATUS & OSC_RC32KRDY_bm)); 

10
        OSC.DFLLCTRL &= ~OSC_RC32MCREF_bm;

11
        DFLLRC32M.CTRL |= DFLL_ENABLE_bm;
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Chris N. Gast #3924951
Lesenswert?
• ▲
▼ 
Nein auch mit dieser Art den Clock zu Initialisieren wird es nicht 
besser. Ohne ein Delay stimmen die Datenraten einfach nicht. Ich habe 
mein Programm jetzt auch auf das Minimum gekürzt. Atmel Referenz Dateien 
für I2C Kommunikation, die zuvor von Stefan erwähnte Clock 
Initialisierung und dann einfach alle 100ms ein festes Register meines 
DSP abfragen. Ich muss das Delay einbauen, sonst funktioniert es nicht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren