[XMega] Wie Daten ohne Pausen über USART Maser SPI Mode lesen?

[Nicolas G. (Gast)]

Hi Leute,

ich versuche jetzt schon länger Daten von einem AD7606 über USART im 
MSPI Mode zu empfangen. Das funktioniert auch gut, allerdings habe ich 
immer diese hässlichen Pausen zwischen jedem gelesenen Byte (siehe 
Screenshot).

Aktuell sieht mein Code so aus:

volatile uint8_t blockTransferDone;

ISR(USARTE1_RXC_vect) {
  ((uint8_t*) &ad7606.values)[ad7606.transferIndex++] = ad7606.usart.usart->DATA;
  if (ad7606.transferIndex < 16) {
    USART_send(&ad7606.usart, 0);
  } else {
    blockTransferDone = 1;
  }
}

void AD7606_readBlock(void) {
  while (AD7606_isBusy());
  ad7606.CS_P->OUTCLR = _BV(CS);
  ad7606.transferIndex = 0;
  blockTransferDone = 0;

  USART_setReceiveInterrupt(&ad7606.usart, 1);

  USART_send(&ad7606.usart, 0);

  LED_set(&LED_debug, 0);

  while (blockTransferDone == 0);

  ad7606.CS_P->OUTSET = _BV(CS);
}

Ich denke die Funktionsnamen sind selbsterklärend.

Ich habe es auch schon ganz ohne Interrupt versucht und einfach nur auf 
das RECEIVE-Bit vom USART gewartet bis alle Bytes durch waren. 
Allerdings wurden dadurch die Pausen auch nicht kleiner.

Ich würde gerne die 16 Bytes ohne Pausen aus dem AD7606 heraus clocken 
und in den Puffer schreiben. Ich habe auch schon DMA ausprobiert, 
allerdings hat sich nach längerem Herumprobieren und Lesen heraus 
gestellt, dass das damit gar nicht geht, sondern nur wenn ich entweder 
den SPI Slave Mode nutze oder wenn ich mit USART Daten aus einem Puffer 
heraus schreiben will. Aber das Lesen geht so scheinbar nicht. Falls 
doch wäre ich natürlich sehr froh, wenn mir jemand einen passenden 
Beispielcode zeigen könnte.

Es muss doch möglich sein schneller Daten von einem Chip zu lesen, wenn 
man selbst die Clock in der Hand hat.

Einen hässlichen Umweg könnte ich mir noch vorstellen. Und zwar würde 
ich dafür SPI im Slave Mode nutzen und den Clock von einem internen 
Timer generieren lassen. Dann dürfte der Timer aber nur 16 * 8 mal an 
und aus schalten. Dieses Clock-Signal kommt dann aus dem XMega raus und 
geht wieder auf die SCLK-Line, die den XMega mit dem AD7606 verbinden. 
So würde der XMega denken er bekäme die Daten vom AD7606 rein geclockt, 
obwohl er selbst die Clock generiert. Aber eigentlich wäre diese Lösung 
ziemlich schrecklich. Da muss es doch was besseres geben...

Vielen Danke schon mal für alle Antworten.

[holger (Gast)]

Wenn du etwas sehr schnell tun möchtest vermeidet man
Umwege. Funktionsaufrufe mit Übergabeparametern zum Beispiel.

>  USART_send(&ad7606.usart, 0);

Ein

SPI_DATA_REGISTER = 0;

tut es erheblich schneller.
Wie dein SPI_DATA_REGISTER für deinen Controller
heisst weiss ich nicht.

[Nicolas G. (Gast)]

Im Grunde mache ich da keine Umwege, weil die Funktionen alle inline 
sind. Der Compiler eliminiert an der Stelle den Funktionsaufruf.

static inline void USART_send(HWUSART* const usart, uint8_t const value) ATTR_ALWAYS_INLINE ATTR_NON_NULL_PTR_ARG(1);
static inline void USART_send(HWUSART* const usart, uint8_t const value) {
  while ((usart->usart->STATUS & USART_DREIF_bm) == 0);
  usart->usart->DATA = value;
}

Aber ich könnte eventuell die unnütze while-Schleife an der Stelle 
heraus nehmen.

[holger (Gast)]

>Im Grunde mache ich da keine Umwege, weil die Funktionen alle inline
>sind. Der Compiler eliminiert an der Stelle den Funktionsaufruf.

Ok, Step2. Bei SPI lohnt es sich nicht per Interrupt
zu arbeiten wenn das SPI sehr schnell ist. Das wird oft
teurer als einfach nur auf das Ende der SPI Übertragung zu pollen.

[Nicolas G. (Gast)]

Interessanterweise ist es jetzt etwas schneller, weil ich den Interrupt 
weg gelassen habe (siehe Screenshot). Aber die Pausen bleiben und die 
stören mich am meisten. Der AD7606 kann normalerweise 200000 Samples pro 
Sekunde samplen, aber wenn ich die nicht schnell genug ausgelesen 
bekomme, dann klappt das eben hinten und vorne nicht. Das ist schade.

Ich dachte bei so was einfachem wie Daten von einem Chip zu empfangen, 
geht das alles etwas fixer.

[der tscheche (Gast)]

Schreibe es doch mal im assembler. Evtl. kannst du die while-schleife 
weglassen und stattdessen ein paar nop's da haben, so dass du den 
nächsten byte in den register genau dann schreibst, wenn der nix mehr zu 
tun hat...

[c-hater (Gast)]

der tscheche schrieb:

> Schreibe es doch mal im assembler.

Das ist hier nicht das Problem!

Das Problem ist, daß der TO nicht verstanden hat, daß das USART double 
buffered ist, auch im SPI-Mode. Oder er hat nicht verstanden, was die 
Implikationen so eines Doppelpuffers sind. Die erfordern nämlich ein 
anderes Programmierschema.

Um ein lückenlosen Datentransfer hinzubekommen, muß man zu Anfang 
einfach zweimal in das Datenregister schreiben und erst in der Folge bei 
jedem Interrupt nur einmal. Am Ende muß man beachten, daß nach dem 
letzten Schreibvorgang noch zweimal der Interrupt erfolgt.

Eigentlich ganz simpel.

[Nicolas G. (Gast)]

Achsooooo!

Das klingt doch mal einleuchtend. Das kann ich leider erst wieder 
nächste Woche testen, aber ich nehme das soll dann so ähnlich aussehen:

while ((usart->usart->STATUS & USART_DREIF_bm) == 0);
usart->usart->DATA = 0;
usart->usart->DATA = 0;
while (!(usart->usart->STATUS & USART_TXCIF_bm)); usart->usart->STATUS = USART_TXCIF_bm;
BYTE0 = usart->usart->DATA;
usart->usart->DATA = 0;
while (!(usart->usart->STATUS & USART_TXCIF_bm)); usart->usart->STATUS = USART_TXCIF_bm;
BYTE1 = usart->usart->DATA;
usart->usart->DATA = 0;
while (!(usart->usart->STATUS & USART_TXCIF_bm)); usart->usart->STATUS = USART_TXCIF_bm;
BYTE2 = usart->usart->DATA;
while (!(usart->usart->STATUS & USART_TXCIF_bm)); usart->usart->STATUS = USART_TXCIF_bm;
BYTE3 = usart->usart->DATA;

Beziehungsweise mit Interrupt:

volatile uint8_t blockTransferDone;

ISR(USARTE1_RXC_vect) {
  ((uint8_t*) &ad7606.values)[ad7606.transferIndex++] = ad7606.usart.usart->DATA;
  if (ad7606.transferIndex < 15) {  //Und hier einmal weniger
    USART_send(&ad7606.usart, 0);
  }
  if (ad7606.transferIndex == 16) {
    blockTransferDone = 1;
  }
}

void AD7606_readBlock(void) {
  while (AD7606_isBusy());
  ad7606.CS_P->OUTCLR = _BV(CS);
  ad7606.transferIndex = 0;
  blockTransferDone = 0;

  USART_setReceiveInterrupt(&ad7606.usart, 1);

  USART_send(&ad7606.usart, 0);
  USART_send(&ad7606.usart, 0);  //Einmal mehr wegen Doublebuffer

  LED_set(&LED_debug, 0);

  while (blockTransferDone == 0);

  ad7606.CS_P->OUTSET = _BV(CS);
}

Ich melde mich dann nochmal, sobald ich es ausprobiert habe. Ich muss eh 
vorher noch im Datenblatt lesen, ob man das Doublebuffering noch 
aktivieren muss oder nicht.

[c-hater (Gast)]

Nicolas G. schrieb:

[Zwei Codevarianten]

Ich habe mir jetzt bloß mal die Pollingvariante genauer angeschaut. Die 
ist im Prinzip richtig, aber trotzdem leider vollkommen falsch.

Wenn du allerdings überall TXCIF durch DREIF ersetzt und umgekehrt, dann 
paßt es schon sehr gut.

TXC heißt "transmit completed". Das ist genau dann der Fall, wenn 
beide Buffer leer sind. DRE hingegen heißt "data register empty". Das 
ist dann der Fall, wenn mindestens einer der beiden Buffer Daten 
entgegennehmen kann.

Dann kannst du wohl auch noch das Löschen des Flags nach jedem Byte 
rauswerfen, das DREIF wird wahrscheinlich beim Schreiben in's 
Datenregister automatisch zurücksetzt. So ist es jedenfalls bei den 
"normalen" AVRs.
Dafür mußt du aber das TXCIF einmal löschen, dies am Besten als Zeile 2 
einfügen.

Wenn du das in der Pollingvariante durchdacht hast, wirst du darauf 
kommen, daß du in der Interruptvariante natürlich den DRE-Int für den 
Datentransfer benutzen mußt.

Der Anfang sieht dann ganz genauso aus wie beim Polling:

while ((usart->usart->STATUS & USART_TXCIF_bm) == 0);
usart->usart->STATUS = USART_TXCIF_bm;
usart->usart->DATA = 0;
usart->usart->DATA = 0;

Jetzt kommt der feine Unterschied, genau hier mußt du nämlich jetzt den 
DRE-Int enablen. Alles andere passiert in dessen ISR.

[Nicolas G. (Gast)]

Wow, Danke!

Das macht alles wesentlich klarer jetzt für mich. Wieso erklärt Atmel 
das eigentlich nicht so schön einfach in ihren ganzen Dokumenten? 
Tststs...

Sehr cool, dann werde ich das beim nächsten mal ausprobieren, wenn ich 
wieder im Bastelkeller bin. Übrigens geht es dabei um folgendes Projekt: 
https://www.youtube.com/watch?v=K0-o1sqe4-0

[Nicolas G. (Gast)]

Ich merke gerade, dass ich wohl nur zu blöd zum Lesen war die ganze 
Zeit. Da steht's doch:

"TXCIF and DREIF may seem similar, but there is a small difference that 
can be utilized to speed up data transfers. TXCIF is not set until the 
USART has completed transmitting all data in the transmit shift register 
and the transmit buffers are empty. DREIF on the other hand, is set 
already when the buffer has room for more data. This means new data can 
be filled into the buffer before all data is transmitted, and the small 
pauses between each transmitted characters can be avoided."

Da sprechen sie genau über die Pausen, die ich meine. Das schlimme ist, 
dass ich das selbe Problem schon bei avr-freaks geschildert habe, was 
bei Atmel als offizielles Supportforum angegeben wird, aber da kriegt 
man von keinem richtig geholfen...

[Nicolas G. (Gast)]

So, Dreifachpost. Ich habe noch eine Frage.

Meiner Meinung nach müsste es bei reinem Polling für 4 Bytes so 
aussehen:

// Warte bis die vorherige Transaction komplett beendet ist.
while (!(usart->STATUS & USART_TXCIF_bm));

// TXCIF-Bit löschen, indem wir es setzen
usart->STATUS |= USART_TXCIF_bm;

// Schreibe beliebigen Wert in DATA
usart->DATA = 1:

// Nach einem CLK Cycle wird DATA in TX Buffer kopiert und wir
// können direkt einen neuen beliebigen Wert in DATA schreiben.
usart->DATA = 2;

// Nach einem USART CLK Cycle wird TX Buffer in TX Shift kopiert.
// Daraufhin wird nach einem CLK Cycle DATA in TX Buffer kopiert.
// Jetzt warten wir darauf, dass TX Buffer wieder frei wird.
while (!(usart->STATUS & USART_DREIF_bm));

// An dieser Stelle steht 2 bereits in TX Shift und wird übertragen.

// Wir schreiben einen weiteren beliebigen Wert in DATA
usart->DATA = 3;

// Wir warten, dass wir den eben empfangenen Wert lesen können.
// Dies ist aber vermutlich gar nicht nötig.
while (!(usart->STATUS & USART_RXCIF_bm));

// Dann lesen wir den Wert
buffer(0) = usart->DATA;

// Und jetzt das selbe Spielchen wie zuvor:
while (!(usart->STATUS & USART_DREIF_bm));  // TX Buffer frei?
usart->DATA = 4;
while (!(usart->STATUS & USART_RXCIF_bm));  // Wert verfügbar?
buffer(1) = usart->DATA;

// Jetzt müssen wir nur noch zwei mal warten um die letzten beiden
// Werte zu empfangen:

while (!(usart->STATUS & USART_RXCIF_bm));
buffer(2) = usart->DATA;
while (!(usart->STATUS & USART_RXCIF_bm));
buffer(3) = usart->DATA;

Und ich glaube, dass man es noch etwas einfacher machen kann. Dieser 
Teil

while (!(usart->STATUS & USART_DREIF_bm));  // TX Buffer frei?
usart->DATA = 4;
while (!(usart->STATUS & USART_RXCIF_bm));  // Wert eingelesen?
buffer(1) = usart->DATA;

müsste eigentlich so vereinfacht werden können, ohne dass es irgendwas 
an der Geschwindigkeit ändern würde:

// Und jetzt das selbe Spielchen wie zuvor:
while (!(usart->STATUS & (USART_DREIF_bm | USART_RXCIF_bm)));  // TX Buffer frei und Wert verfügbar?
usart->DATA = 4;
buffer(1) = usart->DATA;

Testen kann ich das ganze sowieso erst wieder nächste Woche, aber über 
eine vorläufige Bestätigung würde ich mich dennoch freuen.