Forum: Mikrocontroller und Digitale Elektronik Problem mit Unterprogramm


von Florian S. (didi34)


Lesenswert?

Hallo, ich hebe ein Problem mit Unterprogrammen im AVR-Studio 6. Ich 
schreibe:
1
#include <avr/io.h>
2
3
void init()
4
{
5
  DDRB = 0xFF;
6
  
7
}
8
9
int main()
10
{
11
  init();
12
  PORTB =0xFF;
13
  return 0;
14
}

Ich habe eine LED an PB0. Die müsste dann dunkel sein, da sie gegen Vcc 
geschaltet ist, ist aber hell. Wenn ich folgenden Code schreibe welcher 
eigentlich das selbe machen sollte
1
 #include <avr/io.h>
2
3
void init()
4
{
5
  DDRB = 0xFF;
6
  PORTB =0xFF;
7
}
8
9
int main()
10
{
11
  init();
12
  return 0;
13
}
 funktioniert es und die LED leuchtet nicht. Wieso kann das sein?

von Reinhard Kern (Gast)


Lesenswert?

Hallo,

wie wärs wenn du das Unterprogramm mit return abschliesst?

Gruss Reinhard

von Florian S. (didi34)


Lesenswert?

Reinhard Kern schrieb:
> Hallo,
>
> wie wärs wenn du das Unterprogramm mit return abschliesst?
>
> Gruss Reinhard

Wieso? Ich kann doch nichts zurückgeben wenn mein Unterprogramm void ist 
oder?

von Josef D. (jogedua)


Lesenswert?

Was macht den dein µC, wenn er mit main() fertig ist?

von Thomas E. (thomase)


Lesenswert?

Reinhard Kern schrieb:
> wie wärs wenn du das Unterprogramm mit return abschliesst?
Wozu soll das gut sein?

Florian Schuller schrieb:
> Wieso kann das sein?
Merkwürdig. Keine Ahnung. Ich hab das eben getestet. Beide Versionen 
machen das erwartet richtige. Allerdings Studio 4.19.

In deinen Progrämmchen steckt allerdings ein kapitaler Fehler:

int main()
{
  init();
  return 0;
}

Das Programm auf einem µC darf nie beendet werden.

int main()
{
  init();
  while(1);
}

mfg.

von Reinhard Kern (Gast)


Lesenswert?

Florian Schuller schrieb:
> Wieso? Ich kann doch nichts zurückgeben wenn mein Unterprogramm void ist
> oder?

Du musst mit return auch nichts zurückgeben, du hast aber insofern 
recht, als bei void das return weggelassen werden kann, wenn der Code 
einfach bis zum Ende durchlaufen wird (sonst brauchst du nämlich eins). 
Aber was anderes fällt mir nicht ein ausser im Einzelschritt 
durchzusteppen.

Gruss Reinhard

von Thomas E. (thomase)


Lesenswert?

Florian Schuller schrieb im Beitrag #3099168:
> Nichts weiteres denke ich. Oder?
Autsch.
Ein Controller macht nur dann NICHTS wenn der Strom abgeschaltet wurde.

mfg.

von Florian S. (didi34)


Lesenswert?

Thomas Eckmann schrieb:
> In deinen Progrämmchen steckt allerdings ein kapitaler Fehler:

Thomas Eckmann schrieb:
> Das Programm auf einem µC darf nie beendet werden.

Ok. Danke für den Hinweis. Aber auch ohne Beenden funktioniert es nicht. 
Soll ich das AVR-Studio mal neu installieren?

von Reinhard Kern (Gast)


Lesenswert?

Thomas Eckmann schrieb:
> Das Programm auf einem µC darf nie beendet werden.

Bei einem ordentlichen Compiler kommt dahinter eine Endlosschleife, es 
wird also nichts mehr verändert. Könnte auch sein, dass ein Sprung auf 
Reset folgt, das erklärt aber das Phänomen nicht.

Gruss Reinhard

von Thomas E. (thomase)


Lesenswert?

Reinhard Kern schrieb:
> Bei einem ordentlichen Compiler kommt dahinter eine Endlosschleife, es
> wird also nichts mehr verändert.
Doch. Die Interrupts werden abgeschaltet. Ist in diesem Fall zwar nicht 
von Bedeutung. Aber es wird was verändert. Deswegen ist auslaufen lassen 
und while(1); eben nicht das gleiche.
Und schon gar nicht ist das Standard.
Wie du selbst sagst:
> Könnte auch sein, dass ein Sprung auf Reset folgt,

Aber eine Erklärung ist das alles trotzdem nicht.

@Florian Schuller
Zeig mal von beiden Versionen das lss File.

mfg.

von Florian S. (didi34)


Angehängte Dateien:

Lesenswert?

Thomas Eckmann schrieb:
> Zeig mal von beiden Versionen das lss File.
Hier sind sie.

von Reinhard Kern (Gast)


Lesenswert?

Hallo,

ich finde da nix auffälliges. Da hilft bloss durchsteppen und gucken, 
wann die LED angeht und ausgeht (möglichst im Assembler Befehl für 
Befehl).

Gruss Reinhard

von holger (Gast)


Lesenswert?

Ich tippe auf falschen Controller eingestellt.

Programm 1 funktioniert nicht weil der Stackpointer nicht stimmt,
bzw auf einer Adresse liegt die der verwendete uC gar nicht hat.
Beim verlassen von init() springt er in den Wald und führt
den Befehl zum setzen des Ports nicht mehr aus.

Programm2 funktioniert nur scheinbar weil der Port vor verlassen
von init() gesetzt wird. Danach springt er aber trotzdem in den
Wald. Könnte man mal testen indem man in der main() einen anderen Port 
setzt.

von Florian S. (didi34)


Lesenswert?

holger schrieb:
> Ich tippe auf falschen Controller eingestellt.

Ich verwende den Atmega128 und dieser ist auch eingestellt.

von holger (Gast)


Lesenswert?

>Ich verwende den Atmega128 und dieser ist auch eingestellt.

Dann mach mal die M103C Fuse weg;)

von Florian S. (didi34)


Lesenswert?

holger schrieb:
> Dann mach mal die M103C Fuse weg;)

Danke! Warum bin ich da nicht gleich draufgekommen. Hatte mit der Fuse 
schon mal Probleme. Warum ist die eigentlich standardmäßig gesetzt?

von Thomas E. (thomase)


Lesenswert?

Florian Schuller schrieb:
> Danke! Warum bin ich da nicht gleich draufgekommen
Na dann hat sich das ja geklärt.
Aber hättest du das gleich geschrieben, hätte vielleicht sofort bei 
irgendjemand die 109-Fuse-Glocke geläutet.

Florian Schuller schrieb:
> Warum ist die eigentlich standardmäßig gesetzt?
Warum gibt es die überhaupt?
Da hat wohl mal ein richtig großer Kunde die Muskeln spielen lassen.

mfg.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.