Kompilerfehler avr-g++ ?

[F. Weber (Gast)]

Hallo,

Ich habe ein Problem mit einem c++ Projekt (Atmel-Studio 7) auf einem 
Atmega2560.
Das Programm steht vollständig auf github 
(https://github.com/FlorianWeber1018/ArduinoIO).

Dieses Programm soll Befehle über den UART empfangen und entsprechend 
antworten. Leider funktioniert dies nicht und das Programm verhält sich 
seltsam.
Genauer wird der this-Pointer des cmdParser Objekts (cmdParser.cpp) 
durch den Aufruf der  globalen Funktion 
"cmdHandler_get_config_io(uint8_t pin)" (cmdHandler.cpp), in der 
MemberFunction "void cmdParser::parseOne() volatile" (cmdParser.cpp) 
auf null gesetzt. Dies führt letztendlich zu dem seltsamen verhalten des 
Programms.

ich habe bereits längere Zeit damit verbracht den Fehler einzugrenzen 
und kann mir es nicht mehr anders erklären wie mit einem Compilerfehler.
in den Eingangsbuffer des UART lade ich zum Test ein Paar Pakete, sodass 
die Simulation des Projekts den Fehler reproduziert.
Die Optimierung habe bereits deaktiviert.

Nun bin ich ratlos und frage hier nach Hilfe.
Ist es wirklich ein Fehler im Compiler oder sehe ich den Wald vor lauter 
Bäumen nicht mehr?

[foobar (Gast)]

> Ist es wirklich ein Fehler im Compiler oder sehe ich den Wald vor
> lauter Bäumen nicht mehr?

Eher letzteres. Wenn lokale Variablen auf einmal ihren Inhalt verlieren, 
würd ich als erstes mal nach Buffer-Overflows schauen ...

[F. Weber (Gast)]

Vielen Dank für den Tipp. Ich habe gerade nochmal speziell danach 
gesucht, allerdings greife ich nur an einer Stelle im betreffenden 
Abschnitt schreibend auf ein Array zu, ein Auskommentieren dieser Zeile 
hat nichts geändert.

[Kaj (Gast)]

foobar schrieb:
> Buffer-Overflows

Ich hab dein Problem mal auf das wesentliche reduziert:

void cmdHandler_get_config_io(uint8_t pin)
{
    if(pin < 40){

        uint8_t numberStr[2];

        plotNumber(3, numberStr);

    }
}

void plotNumber(int16_t number, unsigned char* result) {
    result[0] = (unsigned char)( number & 0x000F );
    result[1] = (unsigned char)( ( number >> 4 ) & 0x000F );
    result[2] = (unsigned char)( ( number >> 8 ) & 0x000F );
    result[3] = (unsigned char)( ( number >> 12 ) & 0x000F );
}

Wahrscheinlich rechnest du damit, dass die andere Funktion aufgerufen 
wird:

void plotNumber(uint8_t number, unsigned char* result){
    result[0] = ( number & 0x0F );
    result[1] = ( number >> 4 ) & 0x0F;
}

Das ist aber nicht der Fall, wie man im Simulator auch einfach 
feststellen kann.

[(prx) A. K. (prx)]

NB: In eine ISR gehört normalerweise kein cli/sei.

[Florian W. (florian_weber)]

Vielen Dank für die schnelle Hilfe.
Ich hatte schon in dem Assemblercode gesucht, dabei war es so was 
simples.

Super Forum, zwischen Eröffnung und Lösung weniger als eine Stunde.

Vielen Dank

[Florian W. (florian_weber)]

A. K. schrieb:
> NB: In eine ISR gehört normalerweise kein cli/sei.

Dessen bin ich mir bewusst.... Ist dort auch nur zu Testzwecken 
vorhanden um den Fehler einzugrenzen. (bevor ich das mit dem this 
Pointer entdeckt habe war an dieser Stelle das erste Anzeichen das etwas 
nicht stimmt)

[(prx) A. K. (prx)]

Florian W. schrieb:
>> NB: In eine ISR gehört normalerweise kein cli/sei.
>
> Dessen bin ich mir bewusst....

Wirklich? Es tut hier das Gegenteil dessen, nach dem es aussieht. Bei
 ISR(...) { cli(); ...; sei(); }
entsteht zwischen sei() und dem tatsächlichen Ende der ISR ein recht 
signifikantes Fenster aus Befehlen, die mit eingeschaltetem Interrupt 
ablaufen. Kann ggf zu Stack-Überlauf aufgrund verschachtelter ISRs 
führen. Ohne cli()...sei() hingegen wird die gesamte ISR mit 
abgeschalteten Interrupts ausgeführt.

[Florian W. (florian_weber)]

A. K. schrieb:
> Wirklich? Es tut hier das Gegenteil dessen, nach dem es aussieht.

Da war ich wohl falsch informiert, ich dachte eine ISR könnte eine 
andere
standardmäßig unterbrechen.

Danke für die Aufklärung.

[Kaj (Gast)]

Florian W. schrieb:
> Da war ich wohl falsch informiert, ich dachte eine ISR könnte eine
> andere standardmäßig unterbrechen.
Das haengt vom Controller ab. Bei AVR geht das nicht, bei ARM schon. Ein 
Blick ins Datenblatt hilft.

7.8 Reset and Interrupt Handling

[...]
When an interrupt occurs, the Global Interrupt Enable I-bit
is cleared and all interrupts are disabled.