SPI Interrupt auf MEGA32U4

[Jan H. (janiiix3)]

Hallo,

ich wollte jetzt mal vom Polling auf Interrupt umsteigen um eine saubere 
Kommunikation am SPI-Bus zu haben.

Mit dem "poll" Verfahren klappt soweit alles prima...
Aktiviere ich jetzt aber die dazugehörige "ISR" bricht alles zusammen 
und nichts funktioniert mehr.
Ich weiß nicht woran das liegt?! :(
Hat jemand eine Idee?

Main

int main(void)
{
  
  DDRD |= (1<<PD5);
    
  lcd_init(LCD_DISP_ON);
  spi_master_init(64,2);
  
    while (1) 
    {
    spi_master_transmit(0xFF);  
          
    sprintf(Buffer,"L1: %d", cnt);
    lcd_gotoxy(5,0);
    lcd_puts("           ");
    lcd_gotoxy(5,0);
    lcd_puts(Buffer);
          
    _delay_ms(800);  
                
    }
}

Master Init for MEGA32U4

void spi_master_init(uint8_t prescaler, uint8_t clock_option)
{  
  /* ONLY FOR MEGA32! */
  #if defined(__AVR_ATmega32__)
  {
    /* set MOSI and SCK output, all others input */
    MOSI_DDR |= (1<<MOSI_BIT);
    SCK_DDR   |=  (1<<SCK_BIT);
    SS_DDR   |= (1<<SS_BIT);
  
    /* enable SPI, Master */
    SPCR |= (1<<SPE) | (1<<MSTR);
    
    /* clear the bit´s (for multi init) */
    SPCR &= ~((1<<SPI2X) | (1<<SPR0) | (1<<SPR1)); // fclk/4
  
    /* config SPI Bus Speed fclk/prescaler */
    switch (prescaler)
    {
      case 2:   {SPCR |=  (1<<SPI2X);               };break;
      case 8:   {SPCR |=  ((1<<SPI2X) | (1<<SPR0));       };break;
      case 32:  {SPCR |=  ((1<<SPI2X) | (1<<SPR1));       };break;
      case 64:  {SPCR |=  ((1<<SPI2X) | (1<<SPR1) | (1<<SPR0));};break;
      default:  {SPCR |=  (1<<SPI2X);               };break;
    }
  }
  #endif  
  
  /* ONLY FOR MEGA32U4! */
  #if defined (__AVR_ATmega32U4__)
  {
      /* set MOSI and SCK output, all others input */
      MOSI_DDR  |= (1<<MOSI_BIT);
      SCK_DDR    |=  (1<<SCK_BIT);
      SS_DDR    |= (1<<SS_BIT);     // software slave select signal
      SS_HA_DDR  |= (1<<SS_HA_BIT); // hardware slave select signal
      
      /* enable SPI, Master */
      SPCR |= ((1<<SPE) | (1<<MSTR) | (1<<SPIE));      
      
      /* config "Clock Polarity and "Clock Phase" */
      switch(clock_option)
      {
        case 0 : {SPCR &= ~((1<<CPOL) | (1<<CPHA)); }break; // mode 1
        case 1 : {SPCR |=  (1<<CPHA);        }break; // mode 2
        case 2 : {SPCR |=  (1<<CPOL);        }break; // mode 3
        case 3 : {SPCR |=  ((1<<CPOL) | (1<<CPHA));  }break; // mode 4
      }
      
      /* config SPI Bus Speed fclk/prescaler */
      switch (prescaler)
      {
        case 2:   {SPSR |= (1<<SPI2X);                  }break; // prescaler 2
        case 8:   {SPSR |= (1<<SPI2X); SPCR |= (1<<SPR0);        }break; // prescaler 8
        case 32:  {SPSR |= (1<<SPI2X); SPCR |= (1<<SPR1);        }break; // prescaler 32
        case 64:  {SPSR |= (1<<SPI2X); SPCR |= (1<<SPR1) | (1<<SPR0); }break; // prescaler 64
        default:  {SPSR |= (1<<SPI2X);                  }break; // default = 2
      }
  }
  #endif
}

ISR

/* byte received */
ISR(SPI_STC_vect)
{
   static uint8_t i;
   PORTD ^= (1<<PD5);
   data[i++] = SPDR;
 }

[Jörg W. (dl8dtl) (Moderator)]

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?

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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 (Gast)]

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 ...

[Jörg W. (dl8dtl) (Moderator)]

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.

[S. Landolt (Gast)]

Wie sieht 'spi_master_transmit' aus?

[Jan H. (janiiix3)]

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 :

uint8_t spi_receive(void)
{  
  /* ONLY FOR MEGA32! */
  #if defined(__AVR_ATmega32__)
  {
    /* Wait for reception complete */
    while(!(SPSR & (1<<SPIF)));
  }
  #endif  
  
  /* ONLY FOR MEGA32U4! */
  #if defined (__AVR_ATmega32U4__)
  {
    /* Wait for reception complete */
    while(!(SPSR & (1<<SPIF)));        
  }
  #endif
  
  /* return data register */
  return SPDR;  
  
}

mehrere bytes hintereinander zu empfangen.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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.

  spi_master_transmit(reg); // register address
  spi_master_transmit(0x00); // dummy byte
  Buffer[0] = spi_receive(); // first byte

  spi_master_transmit(reg); // register address  
  spi_master_transmit(0x00);
  Buffer[1] = spi_receive(); // secound byte
  
  spi_master_transmit(reg); // register address
  spi_master_transmit(0x00);
  Buffer[2] = spi_receive(); // third byte

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

[Jörg W. (dl8dtl) (Moderator)]

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

Zeig doch mal den kompletten Code.

[S. Landolt (Gast)]

> Zeig doch mal den kompletten Code.
Darauf warte ich seit 17:17.

[Jan H. (janiiix3)]

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

unsigned long ADE7758_read_uint32(uint8_t reg)
{
  Buffer[0] = 0; // default value
  Buffer[1] = 0; // default value
  Buffer[2] = 0; // default value
  
  spi_enable_chip();
  spi_disable_chip(); // start transmission condition
  
  spi_master_transmit(reg);  // register address
  spi_master_transmit(0x00); // dummy byte
  Buffer[0] = spi_receive(); // first byte
  
  spi_master_transmit(0x00);
  Buffer[1] = spi_receive(); // secound byte
  
  spi_master_transmit(0x00);
  Buffer[2] = spi_receive(); // third byte
  
  spi_enable_chip(); // stop transmission condition  
              /*     first byte      second byte      third byte */
  unsigned long result = ((16 << Buffer[0]) |  (8 << Buffer[1]) | Buffer[2]);
  
  return result;
}

Hier für meine 3 bytes.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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...

[Jörg W. (dl8dtl) (Moderator)]

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.

[S. Landolt (Gast)]

Stimmt dieses '__AVR_ATmega32U4__'? In Assembler kenne ich es nur ohne 
'AVR', also z.B. '__ATmega1284P__'.

[Jan H. (janiiix3)]

Master Transmit:

void spi_master_transmit(uint8_t cData)
{
  /* ONLY FOR MEGA32! */
  #if defined(__AVR_ATmega32__)
  {
    /* start transmission */
    SPDR = cData;
  
    /* wait for transmission complete */
    while(!(SPSR & (1<<SPIF)));
  }
  #endif
  
  /* ONLY FOR MEGA32U4! */
  #if defined (__AVR_ATmega32U4__)
  {
    /* start transmission */
    SPDR = cData;

    /* wait for transmission complete */
    while(!(SPSR & (1<<SPIF)));  
  }
  #endif
  
}

Main

int main(void)
{
  
  DDRD |= (1<<PD5);
    
  lcd_init(LCD_DISP_ON);
  spi_master_init(64,2);
  
    while (1) 
    {
    unsigned long test = ADE7758_get_U(2);
          
    sprintf(Buffer,"L1: %lu", test);
    lcd_gotoxy(5,0);
    lcd_puts("           ");
    lcd_gotoxy(5,0);
    lcd_puts(Buffer);
          
    _delay_ms(800);  
                
    }
}

unsigned long ADE7758_get_U(uint8_t phase)
{
  uint32_t voltage = 0;

  switch (phase)
  {
    case 1  : {voltage = ADE7758_read_uint32(REG_AVRMS);  }break; // L1       [Voltage]
    case 2  : {voltage = ADE7758_read_uint32(REG_BVRMS);  }break; // L2       [Voltage]
    case 3  : {voltage = ADE7758_read_uint32(REG_CVRMS);  }break; // L3       [Voltage]
    default  : {voltage = ADE7758_read_uint32(REG_AVRMS);  }break; // default = L1  [Voltage]
  }

  return voltage;
}

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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

uint8_t spi_receive(void)
{  
  /* Wait for reception complete */
  //while(!(SPSR & (1<<SPIF)));        

  /* return data register */
  return SPDR;  
}

[S. Landolt (Gast)]

Reden wir jetzt von Interrupt oder von Polling?

[Jan H. (janiiix3)]

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

Vom Polling. Sorry!

[Jörg W. (dl8dtl) (Moderator)]

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

Yep.

[S. Landolt (Gast)]

Jan H. schrieb:
> Mein "Problem" ist es so :
...
> mehrere bytes hintereinander zu empfangen.

Und dieses Problem besteht jetzt, trotz korrigiertem 'spi_receive', noch 
immer?

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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?

[Jan H. (janiiix3)]

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.

[S. Landolt (Gast)]

Auf die Gefahr hin, auf die Nerven zu fallen: das komplette Programm im 
aktuellen Stand wäre hilfreich, auch die Auskunft, wie das Problem 
aussieht.

[Jan H. (janiiix3)]

Da sind die einzelnen Daten.

[S. Landolt (Gast)]

Nur ganz am Rande:
> SPCR &= ~((1<<SPI2X) | (1<<SPR0) | (1<<SPR1)); // fclk/4
Das klappt auch nur durch einen glücklichen Zufall, SPI2X steht in SPSR.

[S. Landolt (Gast)]

Jetzt bin ich prompt drauf reingefallen, das gilt ja nur für den 
ATmega32.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Was genau passiert denn nun bei den breiteren Registern?

[Jan H. (janiiix3)]

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 (Gast)]

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.

[c-hater (Gast)]

SPIProgrammierer schrieb:

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

???

Die dedizierte SPI-Hardware der AVR8 bietet überhaupt nur einen 
Interrupt, weder braucht sie mehr noch hat sie mehr. Leider... Das liegt 
nämlich schlicht daran, dass sie nicht double-buffered ist. Wie auch 
immer: der TO benutzt genau diesen einen überhaupt nur möglichen 
Interrupt. Er konnte also diesbezüglich garnichts falsch machen und hat 
es demgemäss auch nicht getan.

Allerdings stimmt seine Interrupt*logik* schlicht nicht. Man muss den 
SPI-Interrupt im geeigneten Moment erlauben, Bytes mitzählen und den 
Interrupt im passenden Moment wieder verbieten.

Üblicherweise liegen solche Fehler daran, dass der Delinquent SPI als 
Solches überhaupt nicht verstanden hat. Und/oder nicht die 
SPI-Hardware...

Dabei ist das überaus trivial. Ein wenig spannend wird es erst mit den 
double-buffer-fähigen UARTs im SPI-Master-Mode. Dann kann man nämlich 
tatsächlich zwischen drei potentiell möglichen Interrupts wählen. Und 
für den Fall des hier offensichtlich avisierten "Burst-Modell" des 
Datenaustauschs ist da der RXC-Interupt sicher nicht die schlechteste 
Wahl...

[Jan H. (janiiix3)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.

[S. Landolt (Gast)]

> Was müsste ich denn ca. für einen A/D Wert bekommen bei
> einer Wechselspannung von ~18V?
Soll das heißen, dass am ADE7758 18 V~ anliegen? Im Datenblatt lese ich 
unter Maximum Ratings: "Analog Input Voltage to AGND: –6 V to +6 V."

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jan H. (janiiix3)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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