mikrocontroller.net

Forum: Compiler & IDEs AVR-GCC: Variable wird im Interrupt gekillt / Math.h-Frage


Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche gerade mich in C zurechtzufinden.
Dabei kam nachfolgendes Programm heraus (s. u.)
Problem: Eine der Variablen wird konsequent abgeschossen,
d.h. auf 0 gesetzt.
Welche Variable es erwischt, hängt davon ab, wie diese
Variablen benannt werden, manchmal entscheidet auch die Reihenfolge,
in der die Variablen definiert werden.
Aber, heißt eine der Variablen 'Minuten', dann liegt die
Wahrscheinlichkeit bei 95%, daß es genau diese Variable erwischt.
Unabhängig davon, wie die anderen Variablen benannt werden.
Einige weitere Hinweise im Quelltext.
Frage an die Erfahrenen hier:
Was ist der Grund für diesen Effekt und wie kann man das abstellen?
Bei größeren Projekten sucht man sich bei sowas 'nen Wolf.

Und weil ich gerade dabei bin, ist es eigentlich normal,
daß bei Fließkomma-Arithmetik nur 6 Stellen Genauigkeit hinter
dem Komma erzielt wird? ( Math.h / libm.a / Variablen als Double dekl.)

GCC ist 4.1.2
AVR-LIBC ist 1.46
das Ganze aus dem letzten WinAVR-Paket und über AVRStudio bedient.
Alle Einstellungen auf Defaulteinstellungen,
Optimization steht auf -Os
Controller ist ein ATMega16 mit JTAG-Fuse aus und externem Quarz.
Die LCD-Routinen habe ich mal nicht mitgeliefert,
sind 1:1 aus dem AVR-GCC-Tutorial abkopiert.



// Testdatei
// CPU = ATMega16

#include <avr/io.h>
#include "lcd-routines.h"
#include <avr/pgmspace.h>
#include <stdio.h>
#include <avr/interrupt.h>

char StringImFlash[] PROGMEM = "FRG7-UniCounter"; // im "Flash"
volatile uint8_t Sekunde;
volatile uint8_t Minuten;   /* <-- das Hauptopfer  */
volatile uint8_t Minutes;
volatile uint8_t Minuten2;
volatile uint8_t Stunde;
volatile char Numout[2];

int main(void)
{
  DDRA = 0x00;
  DDRB = 0x00;
  DDRC = 0x3F;   /* Displayport */
  DDRD = 0xF0;
  PORTA = 0xFF;
  PORTB = 0xFF;
  PORTC = 0x0F;
  PORTD = 0xFF;
  
  lcd_init();

  set_cursor(0,1);
  lcd_string_p(StringImFlash);   /* Einschaltmeldung */

/* Hier werden die Variablen mit unterschiedlichen Werten initialisiert */
/* damit ich sehe, wen es erwischt hat.  */  
  Sekunde = 0;
  Minuten = 57;
  Minuten2 = 58;
  Stunde = 23;
  Minutes = 55;

/* Initialisierung von Timer2 und Interrupt, */
/* sowie Aktivierung vom 32kHz-Quarz an PC6 & 7 */
  ASSR |= (1<<AS2);
  TCCR2 |= (1<<WGM21) | (1<<CS20) | (1<<CS22) | (1<<COM20);
  OCR2 = 255;
  TCNT2 = 0;
  TIMSK |= (1<<OCIE2);
  sei();



  while(1)
  {
  }

  return 0;
}

ISR(TIMER2_COMP_vect)   /* Start Uhreninterrupt (Timer2 im Sekundentakt ) */
{
  Sekunde=Sekunde + 1;
  if (Sekunde > 59) /* Minute voll? */
  { 
    Sekunde = 0; 
    Minutes = Minutes + 1;    /* Dann eine Minute dazu */
    Minuten2 = Minuten2 + 1;  /* nochmal, damit ich sehe, */
                                          /* daß er auch hier durchläuft */
  /* weil der beim ersten Auftreten des Fehlers hier schon nicht */
        /* weiter kam. */
  }
  
  if (Minutes >= 60)    /* Stunde voll? */
  { 
    Minutes = 0;
    Minuten2 = 0;
    Stunde = Stunde + 1;     /* dann eine Stunde dazu */
  }

  if (Stunde >= 24)   /* Tag voll? */
  { 
    Sekunde = 0;    /*Dann alles von vorne. */
    Minutes = 0; 
    Stunde = 0; 
  }


  set_cursor(0,2);    /* Zweite Zeile vom 4-Zeilen-Display */
  
/* Nacheinander die Werte getrennt mit ':' ausgeben */

  sprintf(Numout, "%02d", Stunde);
  lcd_string(Numout);
  lcd_data(':');

  sprintf(Numout, "%02d", Minuten);
  lcd_string(Numout);
  lcd_data(':');

  sprintf(Numout, "%02d", Minutes);
  lcd_string(Numout);
  lcd_data(':');

  sprintf(Numout, "%02d", Minuten2);
  lcd_string(Numout);
  lcd_data(':');

  sprintf(Numout, "%02d", Sekunde);
  lcd_string(Numout);
  
}


Gruß
Jadeclaw.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Ansteuerung eines LCD Displays in der Interrupt Routine ist immer 
eine schlechte Idee.
ISR's sollen kurz sein, vielleicht ein paar Flags setzen und dann die HW 
neu aufsetzten.
So Funktionen wie lcd_data(), set_cursor() usw dauern sicher immer lang, 
und haben intern irgendwelche Warteschleifen in denen sie auf das busy 
Signal warten.
Dies gehört niemals in eine ISR.
Schreib dein Programm so um, dass die Ausgabe in der Hauptschleife 
erfolgt, am besten nur dann, wenn sich irgendetwas ändert, und die 
Timer-ISR macht nur das hochzählen.

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja, wie lange das Displayupdate dauert, ist hier relativ egal, da der 
Interrupt nur 1* pro Sekunde aufgerufen wird. Displayupdate ist aber 
auch schnell genug, daß der Interrupt 250 mal die Sekunde einlaufen 
darf, ohne daß es zu einem Rückstau kommt. Davon ab, zumindest wenn ich 
es in Assembler mache, habe ich die Wahl: Entweder ich packe die 
LCD-Ansteuerung komplett in die Interrupts oder ich verzichte ganz auf 
Interrupts. Weil, Interrupts und Displayupdate im Hauptprogramm führt 
dazu, daß das Display langsam aber sicher mit Müll gefüllt wird.

Gruß
Jadeclaw.
( not logged in )

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie groß ist der Stack initialisiert?

MW

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Weil, Interrupts und Displayupdate im Hauptprogramm führt
>dazu, daß das Display langsam aber sicher mit Müll gefüllt wird.
die Aussage verstehe ich nicht


aber schreib doch mal
volatile char Numout[3];

das wird dein Problem lösen

Walter

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den Fall das Du ein Scope hast:

Vielleicht solltest Du zum prüfen,
ob der IRQ wirklich nur 1 mal die Sekunde
kommt, am Anfang er Interrutroutine einen
Portpin togglen. Das schaust Du Dir dann mit dem
Scope an.

Autor: jl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie Walter schon schrieb:
volatile char Numout[3];

in deiner print funktion willst du eine Dezimalzahl mit 2Stellen 
ausgeben. Im C gibt es aber immer eine 0x00 als Stringendekennzeichnung. 
Der braucht auch auch ein Byte Speicherplatz.

Jörg

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast: Der kommt wirklich nur 1 mal pro Sekunde, es ist Timer2 im Output 
Compare Mode, da laß ich ihn OC2 (Pin21) toggeln.
Prescaler = 128, OCR2 = 255. Macht 32768 bei einem 32768Hz-Uhrenquarz.

Walter schrieb:
>> Weil, Interrupts und Displayupdate im Hauptprogramm führt
>> dazu, daß das Display langsam aber sicher mit Müll gefüllt wird.
> die Aussage verstehe ich nicht.

Das stellte sich so dar, daß während die normalen Daten ausgegeben 
wurden, auf den freien Bereichen des Displays zufällige Zeichen 
erscheinen, bis so langsam das ganze Display voll ist. Schalte ich 
Interrupts ab, bleibt das Display sauber, verteile ich die 
Displayupdates auf die Interrupts und fasse das Display nach der 
erstmaligen Initialiserung im Hauptprogramm nicht mehr an, bleibt das 
Display ebenfalls sauber. Getestet in Assembler auf ATMega8 und 
ATTiny2313.


Walter schrieb:
> aber schreib doch mal
> volatile char Numout[3];
> das wird dein Problem lösen

jL schrieb:
> wie Walter schon schrieb:
> volatile char Numout[3];
> in deiner print funktion willst du eine Dezimalzahl mit 2Stellen
> ausgeben. Im C gibt es aber immer eine 0x00 als Stringendekennzeichnung.
> Der braucht auch auch ein Byte Speicherplatz.

Je mehr ich darüber nachdenke, um so logischer erscheint mir das.
Mit anderen Worten: Der Compiler knallt mir das Terminierungsnullbyte in 
eine andere Variable rein, weil ich das Numout zu kurz gemacht habe. 
Gut, probiere ich das mal heute Abend aus, bin gerade außer Haus.

Bleibt noch die Frage nach der schlechten Genauigkeit im 
Fließkommabereich. Erwarte ich da zuviel?

Gruß
Jadeclaw.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw wrote:
>> wie Walter schon schrieb:
>> volatile char Numout[3];
>> in deiner print funktion willst du eine Dezimalzahl mit 2Stellen
>> ausgeben. Im C gibt es aber immer eine 0x00 als Stringendekennzeichnung.
>> Der braucht auch auch ein Byte Speicherplatz.
>
> Je mehr ich darüber nachdenke, um so logischer erscheint mir das.
> Mit anderen Worten: Der Compiler knallt mir das Terminierungsnullbyte in
> eine andere Variable rein, weil ich das Numout zu kurz gemacht habe.
> Gut, probiere ich das mal heute Abend aus, bin gerade außer Haus.

Was du aus dieser Erfahrung mitnehmen solltest:
* Es ist meistens keine gute Idee, Character Arrays die Strings
  aufnehmen sollen, zu klein zu dimensionieren. Lieber ein
  paar Bytes mehr reservieren.
  Grund: Irgendwann dreht man mal am Format String (in diesem
  Fall) und wenn man dann keine Reserven mehr hat, dann knallts
  ganz gewaltig.

* Wenn irgendwie möglich, verwende keine Funktionen, die einen String
  erzeugen und in deren Argumentliste es keinen Parameter gibt, der
  die Größe des empfangenden Character Arrays angibt. Wenn es eine
  derartige Funktion gibt, dann sollte die Version ohne diesen Parameter
  tabu sein.

  Im gegenständlichen Fall: snprintf  verwenden!
  snprintf( Numout, sizeof( Numout), "%02d", Stunde );


>
> Bleibt noch die Frage nach der schlechten Genauigkeit im
> Fließkommabereich. Erwarte ich da zuviel?

Ja. Aus 4 Byte ist nunmal nicht mehr herauszuholen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw wrote:

> Das stellte sich so dar, daß während die normalen Daten ausgegeben
> wurden, auf den freien Bereichen des Displays zufällige Zeichen
> erscheinen, bis so langsam das ganze Display voll ist.

Ja, woher soll denn das arme Display wissen, ob die Daten nun vom 
Interrupt oder Main kommen.

Das Main schreibt was, nun haut der Interrupt dazwischen und schreibt 
auch was. Im günstigsten Fall hast du nun den halben Text des Main, dann 
den vom Interrupt und dann den Rest des Main. In der Regel hast Du aber 
Zeichensalat.
Ausgaben dürfen entweder nur vom Main oder nur vom Interrupt erfolgen.
Oder das Main sperrt die Interrupts für die komplette Dauer der Ausgabe.

Das gleiche gilt natürlich auch für alle anderen Arten Interfaces (UART, 
SPI, I2C).

Und auch Timerzugriffe beinhalten Stolperfallen, wenn der Interrupt 
nicht das temporäre High-Register sichert.


Wenn es sich nicht vermeiden läßt, eine Peripherie im Interrupt und Main 
gleichzeitig zu benutzen, immer dran denken, daß ein Interrupt das Main 
an jeder beliebigen Stelle unterbrechen kann.


Peter

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ausgaben dürfen entweder nur vom Main oder nur vom Interrupt erfolgen.
Genau das ist der Fall.
Ausgabe erfolgt NUR über den Main, die Interrupts fassen das Display 
nicht an, nicht mal irgendeinen noch freien Pin am Displayport, dennoch 
füllt sich das Display mit Müll. Interrupts aus = alles Ok.
Ausgabe NUR über Interrupt, auch über verschiedene Vektoren = alles ok.

Gruß
Jadeclaw.
( not logged in )

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw wrote:
> Peter Dannegger schrieb:
>> Ausgaben dürfen entweder nur vom Main oder nur vom Interrupt erfolgen.
> Genau das ist der Fall.
> Ausgabe erfolgt NUR über den Main, die Interrupts fassen das Display
> nicht an, nicht mal irgendeinen noch freien Pin am Displayport, dennoch
> füllt sich das Display mit Müll.

Der LCD Funktion ist es sch...egal, wie gross du das Array
definiert hast, die interessiert sich ganz einfach nicht dafür.
Diese Funktion bekommt eine Startadresse im Speicher. Von dort
holt sie Byte für Byte und malt das entsprechende Zeichen auf
das Display. Solange bis das nächste Byte im Speicher den Inhalt
0 hat.
Du kannst dein char Array definieren wie du lustig bist,
interessiert die Ausgabefunktion nicht die Bohne. Die
hört erst dann mit der Ausgabe von Zeichen aus, bis sie ein
0 Byte im Speicher vorfindet. Wenn da kein 0 Zeichen ist,
dann gibt diese Funktion auch 2 Gigabyte aus (ok, auf einem
AVR nicht, weil der nicht genug Speicher hat :-), bis sie
dann das erste mal auf ein 0 im Speicher trifft.

Wie sich dein Müll auf dem LCD konkret aufbaut, hängt
nicht unwesentlich von der zeitlichen Abfolge der
Voorgänge ab. Wenn die lcd_ausgabe losläuft, noch
ehe der sprintf die Chance hatte, das 0 Byte zu schreiben,
tja, dann passiert sowas schon mal.

Was da konkret passiert, kann man nur vermuten wenn man
das konkrete Programm sieht. Aber irgendwo gibt es mit
ziemlicher Sicherheit eine Race-Kondition, so dass
die Ausgabefunktion das abschliessende 0 nicht sieht,
weil sie zu spät generiert wird.

In deinem fall kommt natürlich noch erschwerend dazu, dass
du zumindest im Original einen Buffer-Overflow hattest.

sprintf( NumOut, "%2d", Stunden );

schreibt nun mal 3 Zeichen und überschreibt damit eine Variable.
schlägt jetzt der Interrupt zwischen dem sprintf und dem
nachfolgenden lcd_string zu, so verändert die InterruptRoutine
diese Variable und zerstört dadurch das den String abchliessende
0 Byte. Woraufhin lcd_string auf der Suche nach dem 0 Byte
den halben Speicher ausdumpt.

Autor: Marvin M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Display wirklich von unterschiedlichen Programmteilen, die 
teilweise im Interrupt laufen, mit Daten versorgt werden muss, dann 
nutze ich einen Buffer.
In einem Timer-Interrupt wird dieser Buffer regelmäßig zum Display 
geschickt, die einzelnen Programmteile greifen dann nur auf den globalen 
Buffer zu. Dadurch kann man Datensalat verhindern und man verhindert 
Delays in den Interrupts.

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marvin: Ich hatte sowieso vor, Programm und die ganze Ausgabemimik 
voneinander zu trennen, damit das Ganze leichter wartbar wird und ein 
Displaytypwechsel schmerzlos vonstatten geht. Ich bin mit mir noch nicht 
ganz einig, ob es beim LC-Display bleibt. Das Ganze wird ein größeres 
Gerät, welches zum einen ein brauchbares Meßgerät abgeben soll, zum 
anderen einen vorhandenen KW-Empfänger um diverse Dinge erweitern soll 
(Frequenzanzeige, RTTY-Terminal, Beacon-Timer, Audiofiltersteuerung). 
Die Idee mit dem Displaybuffer erscheint mir auch am sinnvollsten, da 
ich dann am Rest nichts mehr umbauen muß, wenn ich das Display wechsle.

@Karl heinz Buchegger: Die Sache mit dem Müll im Display hat nichts mit 
dem GCC-Problem zu tun, sondern war eine frühere Beobachtung, bei der 
ich mir auch einen Wolf gesucht habe und habe ich als Antwort auf die 
Anmerkung von Klaus Falser von 8:25 Uhr erwähnt.

Gruß
Jadeclaw.
( not logged in )

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Marvin M. (Gast)

>Wenn das Display wirklich von unterschiedlichen Programmteilen, die
>teilweise im Interrupt laufen, mit Daten versorgt werden muss, dann
>nutze ich einen Buffer.

GENAU!

Interrupt

MFG
Falk

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ausgabe erfolgt NUR über den Main, die Interrupts fassen das Display
>nicht an, nicht mal irgendeinen noch freien Pin am Displayport, dennoch
>füllt sich das Display mit Müll. Interrupts aus = alles Ok.

in deinem Programm erfolgt die Ausgabe aber im Interrupt!

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> aber schreib doch mal
> volatile char Numout[3];
> das wird dein Problem lösen

jL schrieb:
> wie Walter schon schrieb:
> volatile char Numout[3];
> in deiner print funktion willst du eine Dezimalzahl mit 2Stellen
> ausgeben. Im C gibt es aber immer eine 0x00 als Stringendekennzeichnung.
> Der braucht auch auch ein Byte Speicherplatz.

Jupp, das war es auch.  >in die Tischplatte beiß<
Da hätte ich auch selbst drauf kommen müssen.

Karl heinz Buchegger schrieb:
>> Bleibt noch die Frage nach der schlechten Genauigkeit im
>> Fließkommabereich. Erwarte ich da zuviel?
>Ja. Aus 4 Byte ist nunmal nicht mehr herauszuholen.
Nur 4 Byte für double? Dann brauche ich mich ja nicht zu wundern.
Dann ist hier wohl Handarbeit angesagt.


Walter (Gast) schrieb:
> in deinem Programm erfolgt die Ausgabe aber im Interrupt!
Der Zumüllungseffekt hat mit diesem Programm nichts zu tun.
Das war eine andere Sache.

Gruß
Jadeclaw.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw Dinosaur wrote:
>>Ja. Aus 4 Byte ist nunmal nicht mehr herauszuholen.
> Nur 4 Byte für double? Dann brauche ich mich ja nicht zu wundern.
> Dann ist hier wohl Handarbeit angesagt.

Jep, sizeof(float) == sizeof(double) == 4 beim avr-gcc.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.