SPI Interrupt auf MEGA32U4

Jan H. schrieb:
> um eine saubere Kommunikation am SPI-Bus zu haben.

Sauber ist die SPI-Kommunikation auch im polled mode.

Bei hinreichend hohem SPI-Takt lohnt sich Interruptbetrieb überhaupt
nicht.  Am ehesten wäre es noch sinnvoll, wenn du einige Daten „am
Stück“ übertragen musst, dafür DMA zu nutzen, sodass er am Ende eines
Transfers ohne CPU-Zutun den nächsten starten kann.

> Ich weiß nicht woran das liegt?! :(

Vielleicht daran, dass deine Indexvariable in der ISR über alle
Maßen wachsen kann, und somit der ganze Speicher zugemüllt wird?

Jörg W. schrieb:
> Jan H. schrieb:
>> um eine saubere Kommunikation am SPI-Bus zu haben.
>
> Sauber ist die SPI-Kommunikation auch im polled mode.
>
> Bei hinreichend hohem SPI-Takt lohnt sich Interruptbetrieb überhaupt
> nicht.  Am ehesten wäre es noch sinnvoll, wenn du einige Daten „am
> Stück“ übertragen musst, dafür DMA zu nutzen, sodass er am Ende eines
> Transfers ohne CPU-Zutun den nächsten starten kann.
>
>> Ich weiß nicht woran das liegt?! :(
>
> Vielleicht daran, dass deine Indexvariable in der ISR über alle
> Maßen wachsen kann, und somit der ganze Speicher zugemüllt wird?

Ich habe die ISR auch leer gelassen und genau den selben Effekt 
vorgefunden.
Daran kann es nicht liegen.

Jan H. schrieb:
> Daran kann es nicht liegen.

Wie geschrieben: überleg' dir erstmal, ob ein Interruptbetrieb
überhaupt irgendeinen Sinn hat.  Wenn du dein SPI mit f_CPU/2
taktest, dann hast du nach 16 CPU-Takten ein Byte komplett durch.
In dieser Zeit hat die ISR gerade mal die nötigen CPU-Register
gerettet.

SPIProgrammierer schrieb:
> Ich kann nicht so recht den Sinn erkennen bei einem SPI Master
> den Recieve Interrupt zu nutzen.

Das ist ja ohnehin kein Receive-Interrupt, sondern ein "Transfer
complete".

Für sehr langsames SPI kann man sowas schon machen, wenn man in
der Zwischenzeit auf der CPU was anderes tun könnte.

SPIProgrammierer schrieb:
> Ich kann nicht so recht den Sinn erkennen bei einem SPI Master
> den Recieve Interrupt zu nutzen. Ich weiss ja dass ich (sowieso)
> ein Receive durch einen Transmit initiiere. Die Daten sind ja
> "schon da" wenn ich auf den "Transmit-Knopf" gedrückt habe ...

Mein "Problem" ist es so :

1

uint8_t spi_receive(void)

2

{  

3

  /* ONLY FOR MEGA32! */

4

  #if defined(__AVR_ATmega32__)

5

  {

6

    /* Wait for reception complete */

7

    while(!(SPSR & (1<<SPIF)));

8

  }

9

  #endif  

10

11

  /* ONLY FOR MEGA32U4! */

12

  #if defined (__AVR_ATmega32U4__)

13

  {

14

    /* Wait for reception complete */

15

    while(!(SPSR & (1<<SPIF)));        

16

  }

17

  #endif

18

19

  /* return data register */

20

  return SPDR;  

21

22

}

mehrere bytes hintereinander zu empfangen.

Jan H. schrieb:
> mehrere bytes hintereinander zu empfangen.

Hast du das Prinzip von SPI überhaupt verstanden?

SPI ist ein Schieberegister.  Du schiebst 8 Bits raus (indem du
das SPDR „abgehend“ beschreibst, die Hardware leiert dann die
Taktbits an), und gleichzeitig werden 8 Bits von MISO reingeschoben.
Die kannst du danach aus SPDR „ankommend“ einlesen.

Wenn du mehrere Bytes lesen willst, musst du auch genauso viele Bytes
schreiben.

Jörg W. schrieb:
> Jan H. schrieb:
>> mehrere bytes hintereinander zu empfangen.
>
> Hast du das Prinzip von SPI überhaupt verstanden?
>
> SPI ist ein Schieberegister.  Du schiebst 8 Bits raus (indem du
> das SPDR „abgehend“ beschreibst, die Hardware leiert dann die
> Taktbits an), und gleichzeitig werden 8 Bits von MISO reingeschoben.
> Die kannst du danach aus SPDR „ankommend“ einlesen.
>
> Wenn du mehrere Bytes lesen willst, musst du auch genauso viele Bytes
> schreiben.

1

  spi_master_transmit(reg); // register address

2

  spi_master_transmit(0x00); // dummy byte

3

  Buffer[0] = spi_receive(); // first byte

4

5

  spi_master_transmit(reg); // register address  

6

  spi_master_transmit(0x00);

7

  Buffer[1] = spi_receive(); // secound byte

8

9

  spi_master_transmit(reg); // register address

10

  spi_master_transmit(0x00);

11

  Buffer[2] = spi_receive(); // third byte

Das "dummy" reicht aus für 3 byte oder ?

Wartest du am Ende des spi_master_transmit() auch, bis die
Übertragung fertig ist?

Zeig doch mal den kompletten Code.

Jörg W. schrieb:
> Wartest du am Ende des spi_master_transmit() auch, bis die
> Übertragung fertig ist?
>
> Zeig doch mal den kompletten Code.

1

unsigned long ADE7758_read_uint32(uint8_t reg)

2

{

3

  Buffer[0] = 0; // default value

4

  Buffer[1] = 0; // default value

5

  Buffer[2] = 0; // default value

6

7

  spi_enable_chip();

8

  spi_disable_chip(); // start transmission condition

9

10

  spi_master_transmit(reg);  // register address

11

  spi_master_transmit(0x00); // dummy byte

12

  Buffer[0] = spi_receive(); // first byte

13

14

  spi_master_transmit(0x00);

15

  Buffer[1] = spi_receive(); // secound byte

16

17

  spi_master_transmit(0x00);

18

  Buffer[2] = spi_receive(); // third byte

19

20

  spi_enable_chip(); // stop transmission condition  

21

              /*     first byte      second byte      third byte */

22

  unsigned long result = ((16 << Buffer[0]) |  (8 << Buffer[1]) | Buffer[2]);

23

24

  return result;

25

}

Hier für meine 3 bytes.

Jan H. schrieb:
> Hier für meine 3 bytes.

Immer noch nicht komplett …

„Komplett“ ist etwas, wenn man es compilieren kann.

Ich hab' keine Lust mehr, dir jedes Detail einzeln aus der Nase zu
ziehen.

Jörg W. schrieb:
> Jan H. schrieb:
>> Hier für meine 3 bytes.
>
> Immer noch nicht komplett …
>
> „Komplett“ ist etwas, wenn man es compilieren kann.

Was willst du denn jetzt sehen?
In der Main rufe ich nur diese Routine auf...

Jan H. schrieb:
> Was willst du denn jetzt sehen?

Ein komplettes, in sich schlüssiges, compilierbares Beispiel.

Nicht hier ein Stück, da ein Stück, und spi_master_transmit()
fehlt immer noch.

Master Transmit:

1

void spi_master_transmit(uint8_t cData)

2

{

3

  /* ONLY FOR MEGA32! */

4

  #if defined(__AVR_ATmega32__)

5

  {

6

    /* start transmission */

7

    SPDR = cData;

8

9

    /* wait for transmission complete */

10

    while(!(SPSR & (1<<SPIF)));

11

  }

12

  #endif

13

14

  /* ONLY FOR MEGA32U4! */

15

  #if defined (__AVR_ATmega32U4__)

16

  {

17

    /* start transmission */

18

    SPDR = cData;

19

20

    /* wait for transmission complete */

21

    while(!(SPSR & (1<<SPIF)));  

22

  }

23

  #endif

24

25

}

Main

1

int main(void)

2

{

3

4

  DDRD |= (1<<PD5);

5

6

  lcd_init(LCD_DISP_ON);

7

  spi_master_init(64,2);

8

9

    while (1) 

10

    {

11

    unsigned long test = ADE7758_get_U(2);

12

13

    sprintf(Buffer,"L1: %lu", test);

14

    lcd_gotoxy(5,0);

15

    lcd_puts("           ");

16

    lcd_gotoxy(5,0);

17

    lcd_puts(Buffer);

18

19

    _delay_ms(800);  

20

21

    }

22

}

1

unsigned long ADE7758_get_U(uint8_t phase)

2

{

3

  uint32_t voltage = 0;

4

5

  switch (phase)

6

  {

7

    case 1  : {voltage = ADE7758_read_uint32(REG_AVRMS);  }break; // L1       [Voltage]

8

    case 2  : {voltage = ADE7758_read_uint32(REG_BVRMS);  }break; // L2       [Voltage]

9

    case 3  : {voltage = ADE7758_read_uint32(REG_CVRMS);  }break; // L3       [Voltage]

10

    default  : {voltage = ADE7758_read_uint32(REG_AVRMS);  }break; // default = L1  [Voltage]

11

  }

12

13

  return voltage;

14

}

S. Landolt schrieb:
> Stimmt dieses '__AVR_ATmega32U4__'?

Ja, die werden so vom Compiler definiert.

Wobei ich mich schon frage, warum man (in spi_master_receive())
überhaupt dergestalt eine Fallunterscheidung machen möchte, wenn
dann beide Implementierungen gleich sind.

Jörg W. schrieb:
> S. Landolt schrieb:
>> Stimmt dieses '__AVR_ATmega32U4__'?
>
> Ja, die werden so vom Compiler definiert.
>
> Wobei ich mich schon frage, warum man (in spi_master_receive())
> überhaupt dergestalt eine Fallunterscheidung machen möchte, wenn
> dann beide Implementierungen gleich sind.

Es vebraucht keinen speicher auf meinem AVR, wieso sollte ich es nicht 
machen? Es kann bei einem anderen AVR auch ein anderes Register mal 
sein.

OK, ist zwar immer noch blöd, dass du nicht mal einfach alles in
eine Datei packst, die man auch durch den Compiler schicken kann
(so muss ich mir all deine Puzzelsteine im Kopf zusammensetzen),
aber dein Problem wird es einfach sein, dass du zweimal auf das
Ende eines Transfers warten möchtest: einmal in spi_master_transmit()
und dann noch einmal in spi_master_receive().

Das Flag wird aber nur einmal gesetzt.

Entweder wartest du am Ende von transmit(), oder am Anfang von
receive().  Ersteres ist dahingehend sinnvoll, dass du auf diese
Weise zwei transmit() direkt hintereinander setzen kannst, ansonsten
müsstest du vor dem zweiten nochmal separat warten.

Jan H. schrieb:
>> Wobei ich mich schon frage, warum man (in spi_master_receive())
>> überhaupt dergestalt eine Fallunterscheidung machen möchte, wenn
>> dann beide Implementierungen gleich sind.
>
> Es vebraucht keinen speicher auf meinem AVR, wieso sollte ich es nicht
> machen?

Weil es den Code umständlicher macht (code obfuscation).

Fallunterscheidungen macht man dann, wenn man sie braucht, und
nicht „für den Fall der Fälle“.

Da du sowieso schon zwei verschiedene Klassen von AVRs hast (einmal
MegaAVR und einmal Xmega) und bei beiden Senden und Empfang gleich
sind, und die Routine jenseits von AVRs ohnehin völlig anders
aussehen dürfte, kannst du die Fallunterscheidung dort getrost
weglassen.  Dann blieben nur noch ein paar Bits in der
Initialisierung, für die man wirklich eine Unterscheidung braucht.
Der größte Teil davon ist selbst dort bei beiden Klassen gleich.

Jörg W. schrieb:
> Jan H. schrieb:
>>> Wobei ich mich schon frage, warum man (in spi_master_receive())
>>> überhaupt dergestalt eine Fallunterscheidung machen möchte, wenn
>>> dann beide Implementierungen gleich sind.
>>
>> Es vebraucht keinen speicher auf meinem AVR, wieso sollte ich es nicht
>> machen?
>
> Weil es den Code umständlicher macht (code obfuscation).
>
> Fallunterscheidungen macht man dann, wenn man sie braucht, und
> nicht „für den Fall der Fälle“.
>
> Da du sowieso schon zwei verschiedene Klassen von AVRs hast (einmal
> MegaAVR und einmal Xmega) und bei beiden Senden und Empfang gleich
> sind, und die Routine jenseits von AVRs ohnehin völlig anders
> aussehen dürfte, kannst du die Fallunterscheidung dort getrost
> weglassen.  Dann blieben nur noch ein paar Bits in der
> Initialisierung, für die man wirklich eine Unterscheidung braucht.
> Der größte Teil davon ist selbst dort bei beiden Klassen gleich.

Du hast ja Recht. Habe es geändert.
Du meinst mit warten sicherlich die "while(bedingung" Abfrage.

Habe es im spi_receive(); rausgenommen

1

uint8_t spi_receive(void)

2

{  

3

  /* Wait for reception complete */

4

  //while(!(SPSR & (1<<SPIF)));        

5

6

  /* return data register */

7

  return SPDR;  

8

}

S. Landolt schrieb:
> Reden wir jetzt von Interrupt oder von Polling?

Vom Polling. Sorry!

Jan H. schrieb:
> Du meinst mit warten sicherlich die "while(bedingung" Abfrage.

Yep.

S. Landolt schrieb:
> Jan H. schrieb:
>> Mein "Problem" ist es so :
> ...
>> mehrere bytes hintereinander zu empfangen.
>
> Und dieses Problem besteht jetzt, trotz korrigiertem 'spi_receive', noch
> immer?

Ja.

Jan H. schrieb:
> Ja.

Glaub' ich nicht.

Also, ein Problem wirst du wohl noch haben, aber ich denke nicht,
dass an den SPI-Transfers jetzt immer noch was foul ist.

Halt doch mal einen Oszi an die Leitungen und schau nach, was auf
dem Draht passiert.

Was ist denn dein Fehlerbild?

Jörg W. schrieb:
> Jan H. schrieb:
>> Ja.
>
> Glaub' ich nicht.
>
> Also, ein Problem wirst du wohl noch haben, aber ich denke nicht,
> dass an den SPI-Transfers jetzt immer noch was foul ist.
>
> Halt doch mal einen Oszi an die Leitungen und schau nach, was auf
> dem Draht passiert.
>
> Was ist denn dein Fehlerbild?

Ich kann nicht wirklich nachvollziehen ob mein Sensor mir wirklich 24 
Bit schickt oder ob ich die Rechnung falsch angehe.

Da sind die einzelnen Daten.

Wenn ich das richtig sehe, muss man den ADE7758 mit CPHA=1 CPOL=0
betreiben.

Dafür hat dein spi_master_init() beim ATmega32 keinen Code, und
der Wert 2 bei der Xmega-Initialisierung müsste wohl eher eine 1
sein, oder täusche ich mich da?

Ich versteh' auch nicht ganz, warum du so einen riesigien Prescaler
von 64 nimmst.  Der ADE7758 verkraftet doch maximal 10 MHz.

Wie schon geschrieben: ich würde mir die Signale jetzt auf einem Oszi
oder LA ansehen.

Jörg W. schrieb:
> Wenn ich das richtig sehe, muss man den ADE7758 mit CPHA=1 CPOL=0
> betreiben.
>
> Dafür hat dein spi_master_init() beim ATmega32 keinen Code, und
> der Wert 2 bei der Xmega-Initialisierung müsste wohl eher eine 1
> sein, oder täusche ich mich da?
>
> Ich versteh' auch nicht ganz, warum du so einen riesigien Prescaler
> von 64 nimmst.  Der ADE7758 verkraftet doch maximal 10 MHz.
>
> Wie schon geschrieben: ich würde mir die Signale jetzt auf einem Oszi
> oder LA ansehen.

Das mit CPHA=1 CPOL=0, kann sein. Habe es mit der aktuellen Einstellung 
getestet und kann div. Register die 8 Bit breit sind Erfolgreicht zurück 
lesen.

Den Prescaler hatte ich nur so hoch eingestellt, damit ich was testen 
konnte.

Was genau passiert denn nun bei den breiteren Registern?

Ich habe eine ~18VAC Spannung am Eingang 3 angelegt (PhaseC)
Mit entsprechenden Widerständen etc.

Ich bekomme keinen Wert der dazu passen könnte.

S. Landolt schrieb:
> Das Erraten, welcher Wert angezeigt, welcher erwartet wird, welche
> Spannung überhaupt anliegt, übersteigt meine Fähigkeiten. Ich schaue mir
> stattdessen die Eco-Verfilmung an. Einen schönen Abend allerseits.

Was müsste ich denn ca. für einen A/D Wert bekommen bei einer 
Wechselspannung von ~18V?

Jan H. schrieb:
> Ich habe eine ~18VAC Spannung am Eingang 3 angelegt (PhaseC)
> Mit entsprechenden Widerständen etc.

Jan H. schrieb:
> Was müsste ich denn ca. für einen A/D Wert bekommen bei einer
> Wechselspannung von ~18V?

Das hängt von den „entsprechenden Widerständen“ ab.  Sicher von noch
weiteren Faktoren, wenn ich das sehe, dass es ein ganzes Kapitel über
die Kalibrierung gibt.

Das Datenblatt wirst du wohl selbst erstmal verstehen müssen.

Wichtig wäre es doch als erstes, dass bei konstanter angelegter
Wechselspannung ein (einigermaßen) konstanter Wert herauskommt, und
bei einer geringeren Spannung ein kleinerer.

Nein. Das ist eine Schaltung die schon fertig ist.

Es liegen maximal 360mV an.
Mir scheint es wirklich so als würde ich die 3 Bytes nicht richtig 
bekommen. Ich kann es auch nicht wirklich nachvollziehen.

Jan H. schrieb:
> Mir scheint es wirklich so als würde ich die 3 Bytes nicht richtig
> bekommen. Ich kann es auch nicht wirklich nachvollziehen.

Dann musst du es nachvollziehen lernen.

Sorry, deine eigene Arbeit können wir dir schlecht abnehmen.

Die Methoden, die ich als nächstes anwenden würde, habe ich dir
ja genannt: LA um zu sehen, dass der eingelesene Wert auch dem
Bitmuster entspricht, und Plausibilitätstest um zu sehen, dass
der gemessene Wert was mit der Eingangsspannung zu tun hat.

Jörg W. schrieb:
> Jan H. schrieb:
>> Mir scheint es wirklich so als würde ich die 3 Bytes nicht richtig
>> bekommen. Ich kann es auch nicht wirklich nachvollziehen.
>
> Dann musst du es nachvollziehen lernen.
>
> Sorry, deine eigene Arbeit können wir dir schlecht abnehmen.
>
> Die Methoden, die ich als nächstes anwenden würde, habe ich dir
> ja genannt: LA um zu sehen, dass der eingelesene Wert auch dem
> Bitmuster entspricht, und Plausibilitätstest um zu sehen, dass
> der gemessene Wert was mit der Eingangsspannung zu tun hat.

Ich habe die Spannung mit einem Stelltrafo geändert und das 
entsprechende Register ausgelesen. Synchron dazu das Temperatur 
Register. Alles habe ich auf einem LCD dargestellt.

Temperatur passt. Spannung jedoch nicht. Ich zweifel immer noch daran 
das ich die 3 bytes richtig auslese.

Naja, dann musst du schon von vorn anfangen und dir erstmal die Bits
auf dem Bus angucken.