Funktionsaufruf

[Udo S. (Firma: allround) (1udo1)]

Hallo,

habe in meinen bisherigen Programmen zahlreiche Funktionen geschrieben, 
die auch funktionieren.

Aber diese simple Funktion void wait() klappt nicht. PC0 wird nicht 
angesprochen. Wo ist der kapitale Fehler?

#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
#define  F_CPU  12000000


volatile int16_t  waiter;


void wait()
{
  waiter++;
  
  if(waiter==30000) // 30 000 mal 0,17ms = 5,1 Sekunden
    {
    PORTC ^= ( 1 << PC0 );
    waiter=0;
    }
}


//###################### TIMER 0 #######################################

ISR(TIMER0_OVF_vect)    // TOV alle 170µs bei 12 MHZ und Teiler 8
{
  void wait();
  PORTC ^= ( 1 << PC7 );
} // Ende ISR


// ##################### TIMER0 initialisieren ############################

void init(void)
{
  TIMSK =  (1<<TOIE0) ;
  TCCR0 = (1<<CS01);    // Takt/8

  DDRC=0xff;
  PORTC= 0xff;
  sei();
}

// ###################################### main ###########################

int main(void)
{
  
  init();
  
  while(1)
  {
  }
  return 0;
} // Ende main


//########################################################################

[Stefan E. (sternst)]

  void wait();

  init();

Fällt dir da nicht irgendwie ein Unterschied auf?

[123 (Gast)]

Welchen Wert hat waiter, wenn du wait() aufrufst?

[Karl H. (kbuchegg)]

@TO

Stefan meint diese Stelle

ISR(TIMER0_OVF_vect)    // TOV alle 170µs bei 12 MHZ und Teiler 8
{
  void wait();
  PORTC ^= ( 1 << PC7 );
} // Ende ISR

Das ist KEIN Funktionsaufruf!
Das ist die Vereinbarung einer Funktion, ein Prototyp.

[Peter II (Gast)]

> void wait()

also so würde ich es nun nicht schreiben, keine ahnung ob das ein 
Problem ist.


wait();

so ist es zumindest üblicher.


Außerdem ist es sehr ungünstig in der ISR selber noch eine funktion 
aufzurufen, damit müssen alle Register gesichert werden. Das sollte man 
vermeiden.

waiter muss auch nicht volatile sein.

[Udo S. (Firma: allround) (1udo1)]

Danke Euch allen! Funktioniert.

Manchmal läuft man neben der Spur!!

[Dirk (Gast)]

Peter II schrieb:

> Außerdem ist es sehr ungünstig in der ISR selber noch eine funktion
> aufzurufen, damit müssen alle Register gesichert werden. Das sollte man
> vermeiden.
Quatsch!
Es wird nur das gerettet was notwendig ist!

[Peter II (Gast)]

Dirk schrieb:
> Quatsch!
> Es wird nur das gerettet was notwendig ist!

nein, sobal ein funktionsaufruf drin ist, werden alle Register gerettet. 
Der compiler weiss das nicht mehr was gebraucht wird.

[Karlo (Gast)]

Der TE hat nur eine Kompiliereinheit, mit Optimierung sollten nur die 
wirklich notwendigen Register gesichert werden, anstatt alle.

[Peter II (Gast)]

Karlo schrieb:
> Der TE hat nur eine Kompiliereinheit, mit Optimierung sollten nur die
> wirklich notwendigen Register gesichert werden, anstatt alle.

ja, weil due funktion hoffentlich ge-inlined wird. Dann ist es aber kein 
funktionsaufruf mehr. Sobald ein funktionsaufruf nach der optimierung 
drin bleibt werden alle Register gesichert.

[Karl H. (kbuchegg)]

Karlo schrieb:
> Der TE hat nur eine Kompiliereinheit, mit Optimierung sollten nur die
> wirklich notwendigen Register gesichert werden, anstatt alle.

Wenn der Compiler die Funktion inlined, dann schon.
Wenn nicht, dann sichert er alles.
Ein C-Compiler ist nicht verpflichtet, den Inhalt anderer Funktionen zu 
analysieren, wenn es darum geht, was der Aufrufer zu tun hat und was 
nicht.

Und im Falle des gcc gibt es ein API, welches besagt, dass es eine Reihe 
von Registern gibt, die eine Funktion benutzen darf, ohne sie selber 
sichern und wiederherstellen zu müssen.

Damit geht der gcc im nichtinline Fall pragmatisch vor, und sichert am 
ISR Anfang genau diese Register und stellt sie am Ende wieder her. Das 
einzige was sicher ist: wenn es keinen Funktionsaufruf gibt und die 
Register auch sonst in der ISR nicht benutzt werden, dann müssen sie 
auch nicht gesichert/restauriert werden.

[LassWonadersDefinen (Gast)]

Peter II schrieb:
>> void wait()
>
> also so würde ich es nun nicht schreiben, keine ahnung ob das ein
> Problem ist.

Mensch Peter, ob I oder II, les doch mal den Kommentar von Karl Heinz 
vor deinem!!

                          P R O T O T Y P !!!

[Peter II (Gast)]

LassWonadersDefinen schrieb:
> Peter II schrieb:
>>> void wait()
>>
>> also so würde ich es nun nicht schreiben, keine ahnung ob das ein
>> Problem ist.
>
> Mensch Peter, ob I oder II, les doch mal den Kommentar von Karl Heinz
> vor deinem!!
>
>                           P R O T O T Y P !!!


schau dir mal die Zeiten an und überlege was passiert sein könnte? Es 
haben alle zur gleichen Zeit den Kommentar verfasst. Dabei kann so etwas 
passieren.

[LassWonadersDefinen (Gast)]

Peter II schrieb:
> ... keine ahnung ob das ein Problem ist.

Nix da Freundchen, keine Ausflüchte(siehe Zitat).
Bei uns hieß es immer, wenn man keine Ahnunge hat, einfach mal die 
Klappe halten.

[Peter II (Gast)]

LassWonadersDefinen schrieb:
> Bei uns hieß es immer, wenn man keine Ahnunge hat, einfach mal die
> Klappe halten.

Ich hatte die Lösung noch mit geschrieben, und ja ich bin wirklich nicht 
sicher was passiert wenn man ein Prototype innerhalb ein funktion 
deklariert. Denn C oder C++ unterstützen meines wissens keine "Nested 
function".

[Karl H. (kbuchegg)]

Peter II schrieb:

> Ich hatte die Lösung noch mit geschrieben, und ja ich bin wirklich nicht
> sicher was passiert wenn man ein Prototype innerhalb ein funktion
> deklariert. Denn C oder C++ unterstützen meines wissens keine "Nested
> function".

Das hat damit nichts zu tun. Funktionsdeklarationen bzw. Prototypen 
kannst du schreiben, wo du willst.

In meiner Anfangs Kernighan&Ritchie Zeit war es (für mich) gang und gebe 
zb zu schreiben

#include <stdio.h>

int main()
{
  double a;
  double cos();

  for( a = 0; a < PI; a += 0.01 )
  {
    printf( "%f %f\n", a, cos(a) );
  }
}

* math.h wurde nicht inkludiert.
* Der Protoyp war notwendig, damit der Compiler wusste, dass die 
Funktion cos keinen int liefert, sondern einen double. Bei Funktionen, 
die sowieso einen int lieferten, wurde auf die Funktionsdeklaration 
komplett verzichtet.
* Auf die Datentypen der Argumente wurde geschi... verzichtet, da der 
Compiler das double-Argument sowieso aus dem Aufruf ermitteln konnte.
* void? Was ist void? void gab es noch nicht. Also brauchte man sich 
auch keinen Kopf darüber zu machen. Alles was der Compiler irgendwie 
annehmen musste, war automatisch ein int.

Tja. Nachdem ich dann oft genug damit auf die Schnauze gefallen war, bin 
ich dann dazu übergegangen:
Header Files zu inkludieren, wenn es sie gab.
Funktionsdeklarationen und später dann Protoypen an den Anfang der 
C-Datei zusammenzufassen.

Dann wurde es besser. Die Fehler aufgrund fehlerhaften Argumente an 
Funktionen nahmen drastisch ab.

Das war übrigens keineswegs irgendwie verpönt. Funktionsdeklarationen 
mitten unter den restlichen Variablendefinitionen waren damals gang und 
gäbe und nichts, worüber man sich groß gewundert hätte.
Irgendwo muss ja der schlechte Ruf, der C heute noch nachhängt, ja auch 
herkommen :-)

Damit da keine Missverständnisse aufkommen. Das war 1987/88/89. In 
meiner Sturm und Drang Zeit.
Heute ist sowas völlig inakzeptabel.

[J.-u. G. (juwe)]

Peter II schrieb:
> Denn C oder C++ unterstützen meines wissens keine "Nested
> function".

Du hast vollkommen recht. Da wir uns aber hier im gcc-Unterforum 
befinden, sei die Bemerkung gestattet, dass gcc "nested functions" 
mittels Erweiterung unterstützt (für C).

[Druckkopfschmerz (Gast)]

Jouuu: gefunden auf gcc.org

6.4 Nested Functions
A nested function is a function defined inside another function. Nested 
functions are supported as an extension in GNU C, but are not supported 
by GNU C++.

[Druckkopfschmerz (Gast)]

http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html