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.
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
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?
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
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
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.
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.
