mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik kleines C-Problem


Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielleicht kann jemand mal einen kurzen, aber fachmännischen Blick auf
den unten stehenden Code werfen, den ich bewusst extem einfach gehalten
habe. Und trotzdem funktioniert es nicht nach meinen Vorstellungen. In
"main()" wird eigentlich nur der externe Interrupt INT0 initialisiert
und dann gewartet. Der Sprung in die Routine klappt auch, allerdings
lande ich beim Rücksprung wieder bei "int i=0" in "main()".
Eigentlich müsse ich aber doch immer in der Endlosschleife "while
(1)" landen. Das Ganze läuft auf dem ICCAVR von Imagecraft.
Weiß jemand, warum dem nicht so ist?

vielen Dank

Jürgen

________________________________________________

#include <iom8535v.h>
#pragma interrupt_handler  INT0_handler:    INT0

void INT0_handler (void);
void init (void);

void main (void)
{
    int i=0;

   MCUCR = 0x03;
   SREG |= 0x80;
   GICR = 0x40;

   while (1);
}

void INT0_handler(void)
{
 i++;
}

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kann zwar kein c, aber in den anderen Sprachen (asm und Bascom)
brauchen die interruptroutinen einen expliziten reti.
Könnte vielleicht eine Lösungsidee sein??

grüsse leo9

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leo,

vielen Dank für dein Antwort. Ein "reti"-Befehl dürfte nicht nötig
sein.

Jürgen

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

kann es sein, dass du "int i" global, d.h. außerhalb von main
deklarieren musst?

Tux

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

<glaskugelmode>
Meaga128? Simulation oder Hardware? Wenn Hardware und Mega128 ist die
M103C-Fuse gesetzt.
</glaskugelmode>

Matthias

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Tux: Auch eine globale Variable löst das Problem nicht

@Matthias: Hardwaremäßig habe ich es ehrlich gesagt noch nicht
ausporbiert. Es handelt sich um einen Atmega8535.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hast Du schonmal ins listing des Compilers geschaut? Da erkennt man oft
mehr. Vielleicht muss man die Interrupt-Routine anders deklarieren. Ich
denke allerdings auch, dass i global sein muss.

Viele Grüße,

Ralf

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
muss ja global sein, sonst hätte der Compiler das ja nicht übersetzt,
was soll er denn mmit i++ machen, wenn er i nicht kennt?
Was mich wundert: wieso steht da zweimal: "void INT0_handler(void)",
müsste doch auch einen Compilierungsfehler erzeugen?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

"void INT0_handler(void)" kommt zweimal vor, da es sich beim ersten
mal um die Deklaration, beim zweiten mal um die Definition handelt. Ich
hoffe ich bring nicht alles durcheinander :) Jedenfalls denke ich, das
hat seine Richtigkeit. Es wird ja alles fehlerfrei compiliert und ich
kann ja bis auf den Rücksprung aus der Routine alles einwandfrei
simulieren.

Jürgen

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne den ICCAVR nicht.
Aber mach doch testweise einfach mal das int i = 0; in der main weg.

Ich vermute mal, daß dir der Debugger dieses i anzeigt. Das ist aber
nur lokal in main. Bei dem anderen muß es sich um eine andere Variable
handeln. Wo die allerdings deklariert wird weiss ich nicht.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit _SEI immer alle Interrupts freigegeben

Autor: Mehmet Kendi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Variable i ist in main deklariert, weshalb es in der Interrupt-Funktion
gar nicht sichtbar ist. Eigentlich haette der Compiler hier ein Error
ausgeben muessen.
Wenn Du i ausserhalb von main deklarierst, sollte es klappen.

MfG

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Juergen,

ich kenne mich zwar nicht mit dem ICCAVR aus, aber beim avrgcc werden
Konstrukte wie while (1) z.T. wegoptimiert, wenn man die Optimierung
nicht explizit ausschaltet.

Ich verwende im Hauptprogramm meistens solche Schleifen

for(;;){
tastenabfrage();
warten(x);
}

Hoffe, dir weitergeholfen zu haben.

MfG

Marcel

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
while(1) sollte auf keinen Fall wegoptimiert werden, warum auch?

Autor: MooseC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jürgen,

Du deklariert falsch.
Du schreibst:

#pragma interrupt_handler  INT0_handler:    INT0

richtig ist aber
#pragma interrupt_handler  INT0_handler:iv_INT0

wenn Du nur INT0 schreibst wird der Interruptvektor Nr.6
benutzt, also iv_TIMER1_CAPT. Du willst aber ja iv_INT0
und der hat laut der #include <iom8535v.h> die Nr. 2!

siehe unten:


#define iv_RESET        1
#define iv_INT0         2    <----------- richtig
#define iv_INT1         3
#define iv_TIMER2_COMP  4
#define iv_TIMER2_OVF   5
#define iv_TIMER1_CAPT  6    <----------- falsch
#define iv_TIMER1_COMPA 7
#define iv_TIMER1_COMPB 8
#define iv_TIMER1_OVF   9
#define iv_TIMER0_OVF   10
#define iv_SPI_STC      11
#define iv_UART_RX      12
#define iv_UART_RXC     12
#define iv_UART_DRE     13
#define iv_UART_UDRE    13
#define iv_UART_TX      14
#define iv_UART_TXC     14
#define iv_ADC          15
#define iv_EE_RDY       16
#define iv_EE_READY     16
#define iv_ANA_COMP     17
#define iv_ANALOG_COMP  17


#define    INT0     6   <--------- hier kommt die "falsche" 6 her


MooseC

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MooseC,

bei mir stehen folgende Interrupt_Vektoren in der include-Datei
"iom8535v.h":
__________________________________________________
/* General Interrupts */
#define GIFR  (*(volatile unsigned char *)0x5A)
#define  INTF1    7
#define  INTF0    6
#define  INTF2    5
#define GIMSK  (*(volatile unsigned char *)0x5B)
#define GICR  (*(volatile unsigned char *)0x5B)
#define  INT1     7
#define  INT0     6
#define  INT2     5
#define  IVSEL    1
#define  IVCE     0
____________________________________________________

Ich verstehe nicht, woher du da iv_INT0 nimmst.
Aber wie ich sehe liegt das Problem wohl eher beim Simulieren mit
AVR-Studio. Selbst bei unten stehendem "Progrämmchen" stimmt der
gelbe Pfeil mit den Tatsachen überhaupt nicht überein.
#include <iom8535v.h>
___________________________
void main ()
{
   MCUCR = 0x03;
   SREG |= 0x80;
   GICR = 0x40;

   while (1);
}
____________________________
Wenn ich mir das Ganze aber in der "Disassembler"-Ansicht ansehe,
dann sehe ich, dass das Programm richtig abläuft, während sich der
gelbe Pfeil in der Normalansicht ausserhalb des Codes befindet.
Naja, da kann ich wohl nicht viel machen. Vielleicht mal sehen, ob es
bei Atmel irgendwelche Updates vor das Studio gibt.

Jürgen

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

du kannst in einer Interrupt-Routine nur auf globale Variablen
zugreifen und diese müssen dann auf jeden Fall als "volatile"
deklariert sein. Damit wird angegeben, dass die Variable auch außerhalb
des normalen Programmablaufs geändert werden kann (-> in einer
Interrupt-Routine).

volatile int i;

Gruß,
Olaf

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Olaf,

mir gehts nicht so sehr um den Zugriff auf Variablen. Das Beispiel habe
ich rein zufällig so gewählt. Von mir aus macht die Routine auch
nichts. Das komische ist halt der Rücksprung, da der nicht richtig
erfolgt.
Tja, so wurde aus meinem kleinen C-Problem doch ein großes :)

Jürgen

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... ein wirkliches Problem gibt es hier anscheinend gar nicht. Wenn man
"Schrott" (Entschuldigung für diesen Ausdruck) programmiert, dann
darf man sich auch nicht über das Verhalten des Debuggers wundern
(unabhängig davon, ob und warum und wie der Code übersetzt wurde). Du
schraubst ja auch nicht einfach ein viereckiges Rad an dein Auto und
wunderst dich danach über die komischen Fahreigenschaften, gell?

Vielleicht verhält der Debugger sich so wie du es erwartest, wenn du es
mit einem vernünftigen Programm probierst ;o)

Gruß,
Olaf

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Olaf: Vielen Dank für diese unglaublich geistreichen Ausführungen.

Autor: MooseC (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

>>bei mir stehen folgende Interrupt_Vektoren in der include-Datei
"iom8535v.h":
>>____________________________________________________
/* General Interrupts */
#define GIFR  (*(volatile unsigned char *)0x5A)
#define  INTF1    7
#define  INTF0    6
#define  INTF2    5
#define GIMSK  (*(volatile unsigned char *)0x5B)
#define GICR  (*(volatile unsigned char *)0x5B)
#define  INT1     7
#define  INT0     6
#define  INT2     5
#define  IVSEL    1
#define  IVCE     0
____________________________________________________

>>Ich verstehe nicht, woher du da iv_INT0 nimmst.

Hmm, das sind nicht die Interruptvektoren, sondern Bitdeklarationen
einiger im Mega8535 vorhandenen Interruptbits für Flags und Enable.

Die Interruptvektoren heißen in der iom8535v.h vom ICCAVR auch so -
siehe Anhang ganz unten.

Dein Vektor ist auf jeden Fall mit INT0 verkehrt, da es mit 6 nicht den
Vektor beschreibt, sondern das Enblebit im GICR.


MooseC

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MooseC,

wenn ich heute heimkomme, schau ich mir das nochmal genauer an.
Vorerst einmal vielen Dank für deine Hilfe. Irgendwie wirds dann schon
noch klappen.

Jürgen

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenn mich mit uController nicht gut aus.

Aber sollte nicht in der interrupt routine am ende ein "return "
stehen?

Ich vermute mal, da du die interupt routine vor main inizierst, dass
der Code im speicher des controllers vor der main steht und du dann
logischerweise immer am anfang der main landest nachdem der interrupt
ausgefürt wurde.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

an alle vielen Dank für die Unterstützung. Hat mir geholfen, Neues zu
lernen und mein Problem zu lösen.

@MooseC: Natürlich hast du recht, die Sache mit den Interruptvektoren
habe ich total verpeilt :)

Die Simulation mit AVR Studio hat nur nicht geklappt, weil man die
Datei \icc\libsrc.avr\iostudio.s aus dem icc-Ordner in den den
aktuellen Projektordner kopieren muss. Diese Information habe ich erst
heute in der Hilfe gefunden.

Trotzdem noch mal vielen Dank an alle.

Jürgen

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.