POW funktioniert nicht

[Benno Müller (Gast)]

Salve!

Aus einem mir unerfindlichen Grund kennt er bei meinem Programm die 
Funktion POW() nicht. MATH.H habe ich included, trotzdem bekomme ich vom 
GCC folgende Fehlermeldung: undefined reference to 'pow'

Was mache ich falsch??

<schnipp>
#include <IO.H>
#include <IO2313.H>
#include <MATH.H>

char zeichen_einlesen(void);

int main(void)
{
  while (1)
  {
    if(strcmp(zeichen_einlesen(), '$') == 0)
    {
    }
  }
}

char zeichen_einlesen(void)
{
  char ch = 0;
  double i;
  double wertigkeit;

  for(i = 0; i < 8; i++)
  {
    if(bit_is_set(PORTD, PIND5))
    {
      wertigkeit = pow(2, i);
      ch += wertigkeit;
    }
    //delay ...
  }
  return ch;
}
<schnapp>

[Benno Müller (Gast)]

Hat sich erledigt:

Lag an einem kleinem Parameter im makefile:

#linker flags
LDFLAGS = -Wl,-Map=$(TRG).map,--cref -lm

Habe das -lm hinzugefügt und dann gings. bin irgendwo im AVRfreaks Forum 
darauf gestoßen. Also falls wer ähnliche Probleme mit <MATH.H> hat ... 
;-)

Jetzt würde mich aber noch interessieren wie ich den DELAY realisieren 
könnte. Ich lese an PORTD, PIN5 seriell Zeichen ein, sprich Bit für Bit. 
Habe ich ein Bit muss eine gewisse Wartezeit rein bis das nächste Bit am 
Pin anliegt. Aber wie lange muss diese sein?

Ich verwende einen ATMEL AT90S2313, 4Mhz.

[Benno Müller (Gast)]

Muss mich korrigieren:

Die Baudrate beträgt 9600 bps bei 8Mhz, nicht 4Mhz!

[Reiner (Gast)]

Hi,
danke für die info mit der math.h. Und ich glaub ich kann dir auch 
helfen.
Bei einem PIC hatte ich mal in Assembler eine serielle Infrarot 
programmiert und die läuft jetzt seit mehr als drei Jahren tag für Tag 
fehlerfrei.

Also wenn die Baudrate 9600 beträgt puzeln die Bits mit 9600Hz ein. D.H. 
pro Bit vergeht eine Zeit von rund 1/9600Hz = 104.2us. Wenn Du auf das 
Datentelegramm richtig reagieren willst, empfielt es sich auf den Start 
des Telegramms, das Startbit zu warten. Tritt es auf, testest Du ob es 
nach der halben Bit Zeit ca. 52us noch ansteht. Ist das nicht der Fall 
kannst Du es als Störung (spike) verwerfen. Ist das aber Startbit ok, 
wartest Du jetzt eine Bitlänge 104us und triffst damit genau in die 
Mitte des ersten Datenbits. Alle weiteren Bits werden auch in der Mitte 
ihrer Gültigkeit erfasst. Der Vorteil die Bits in der Mitte zu erfassen, 
liegt in der Sicherheit. Zwei asynchrone Systeme können nie genau die 
gleiche Frequenz haben, was ein Auseinanderlaufen der Erfassung zur 
Folge hat. Legt man die Mitte fest, kann bis zum Ende der Telegramms 
zumindest ein Fehler von einer halben Bitlänge toleriert werden. Bei 10 
Bits (1xStartbit 8xDaten 1xStop) kann dann bei 9600 immerhin knapp 0.5% 
Fehler geduldet werden.
Ich hoffe es war das was Du wissen wolltest.
Reiner

[Benno Müller (Gast)]

Danke für die sehr verständliche Erklärung!

Die einzigen Bedenken habe ich eigentlich nur noch wegen der Zykluszeit 
der Befehle. In Assembler hätte ich diese mir ja besorgen können, aber 
inwiefern muss ich diese in C berücksichtigen?

[Reiner (Gast)]

hi,
erstmal muß ich mich korrigieren es sind nicht 0.5%, sondern 5% in der 
Toleranz.

Ich denke Du brauchst Dir auch in C keine Sorgen zu machen da der AVR 
mit 8MHz oder 125ns pro Befehl zuschlägt. Also 416 Befehle in 52us! 
selbst wenn da mal ein Interrupt Bearbeitungszeit verbraucht, wird es 
wohl keine Störung hervorrufen. Ansonsten kannst Du ja auch die Bitmitte 
mit einem zyklischen Timerinterrupt erfassen, dann kannst Du Dir sicher 
sein (Beim PIC so realisiert).
Reiner

[Benno Müller (Gast)]

Naja am besten ich teste das mal.

Danke nochmal für die Antwort. Bringt mich mit meinem Projekt gut 
weiter!

[Michael Kauffmann (Gast)]

Hi,

habe das Problem mit pow() und math.h ebenfalls. Allerdings arbeite ich 
mit dem MSP430 C-Compiler (war beim Eval-Kit dabei).
Habe dazu leider keine Erklärung gefunden. Irgendwelche Anregungen?

Danke

[Joerg Wunsch (Gast)]

Nun, daß man für die math-Funktionen -lm braucht, steht auch
in der FAQ.

Einige delay-Funktionen befinden sich mittlerweile in
<avr/delay.h>.  Die Zyklenzahl muß man sich aber noch selbst
ausrechnen (d. h., den Compiler rechnen lassen).

Ansonsten bitte keine klemmenden CAPS LOCK Tasten: der Header
heißt <math.h>, nicht <MATH.H>.  Auf Dateisystemen, die zwischen
Groß- und Kleinschreibung unterscheiden, erlebst Du sonst
irgendwann Dein blaues Wunder.  Ebenso heißt die Funktion pow(),
nicht POW() -- C unterscheidet ja grundsätzlich zwischen Groß-
und Kleinschreibung.

Der MSP430 gcc unterstützt (nach der letzten Aussage, die ich
von seinem Autor mal gelesen habe) derzeit noch gar keine
math-Bibliothek.

[Michael Kauffmann (Gast)]

Das man -lm benoetigt habe ich auch gelesen, allerdings finde ich kein 
makefile, da ich nur auf Icons klicken muß (in der IAR Workbench).
Solche Dinge wie Gorß/Kleinschreibung habe ich beachtet.

Wie bereits erwähnt: ich nutzte nicht den MSP gcc, da ich unter Win2k 
damit Probleme habe (bei der In-Circuit-Simulation). Nutzen tue ich den 
mitgelieferten C-COmpiler im MSP-FET430P120 Eval-Kit (IAR Workbench), 
der leider eine 400Zeilen Codebeschraenkung hat.