Also ich geb auf. Seit ich auf die neue Version umstellen wollte, funktioniert nichts mehr, was vorher noch anstandslos ging: das LCD (auch die umgeschriebenen Dateien der Fleury -LCD-Treiber gingen nicht, sie liessen sich nicht mal pur compilieren...), die Tastatur (vorher konnte man mit char-Variablen wunderbar vergleichen, nun plötzlich nicht mehr...) ... ich hab ja schon bei der 3.2 gelesen, man soll besser die Finger davon lassen, aber das kann ja nicht der Sinn sein, da sind nun mal neue Funktionen drin, die man braucht, und nicht jeder ist so ein Crack, dass er sich diese Funktionen einfach so selbst schreiben kann... Ist das nur meine Unerfahrenheit mit C, oder müsste man wirklich sämtliche Routinen neu schreiben? Ich hab jetzt wieder meine alte Version und suche nach ner Möglichkeit einen Wert ins Ascii zu bringen und aufs LCD auszugeben... du muss mit der alten Version ja auch schon irgendwie gegangen seinm also werd ichs auch finden... (ach ja: dtostrf kannte die 3.3-Version auch nicht, wahrscheinlich hab ichs falsch aufgerufen...) Bis dann, Chris
Meine LCD-Library lässt sich einwandfrei unter WinAVR, bitte holt euch die neueste Version von meiner homepage: http://www.mysunrise.ch/users/pfleury/avr-software.html Betreffend dtostrf Benütze doch die Such-Funktion dieses Boards, dann hast du die Antwort. (Posting vom Joerg Wunsch) !
Die wesentlichste Änderung gegenüber früher ist eigentlich, daß seinerzeit outb() (oder war's outp()?) mit einer unlogischen Parameterreihenfolge gearbeitet hat: zuerst der Wert, dann der Port. Das wurde geändert, da man es als Fehler erkannt hat. Es wurde aber gleich noch mehr geändert :), am besten kommt man jetzt wirklich, wenn man bei allem alten Code all die outb, outp, inb, inp komplett eliminiert. Stattdessen direkte Zuweisungen benutzen: Früher mal: outp(myval, PORTA); (outb war ein Alias für outp) später mit geänderter Reihenfolge: outb(PORTA, myval); (zumindest die Reihenfolge jetzt logisch) jetzt aber am besten: PORTA = myval; Analog natürlich myval = PINA; um von PINA zu lesen. Das sollte man aber unbedingt mit einer Optimierung (> 0 ;-) übersetzen, ansonsten wird standardmäßig relativ umständlicher Code erzeugt. Hängt damit zusammen, daß für die neueren ATmegas (128 zumindest) ein Teil der IO-Register nicht mehr mittels INB/OUTB erreicht werden kann sondern nur noch über memory-mapped IO. Unoptimiert machen daher all diese Funktionen jetzt MMIO, erst der Optimierer kann dann (bei zur Compilezeit bekannten IO-Adressen natürlich) entscheiden, ob es auch mittels INB/OUTB geht. Auch die sbi/cbi-Funktionen gelten damit als "deprecated". Der Compiler optimiert Ausdrücke der Form: TIMSK |= _BV(TIOIE1); passend in den entsprechende SBI-Befehl, sofern das von den Operanden her zulässig ist. Kleiner Vorteil am Rande: alle anderen Compiler für den AVR benutzen diese Form schon immer, der Code wird also portabler.
@ Joerg: na damit können sicherlich viele, die nicht den tiefen Einblick haben, immer wieder was anfangen. Vielen Dank. @ Peter: nun mal keine Sorge. nur weil es bei einem mal nicht klappt, heisst das nicht, dass niemand mehr Deinen LCD-Treiber nimmt ;-) Ich habe einige ausprobiert, was meinst Du, warum ich an Deinem festhalte? zu itoa und Konsorten: die Beispiele aus dem Forum hab ich mir alle angeschaut (mach ich immer, BEVOR ich was maile, erstens weil es schneller geht, zweitens wei ich nicht mit Redundanz nerven will. Aber das Thema printf, itoa, etc. ist schon so oft durchgekaut worden, und immer wieder kapieren es nicht alle (wie ich)... da sollte endlich mal ne anständige, klare Funktion her... Ich seh gerade die Beipielzeilen in meiner Mail, die ich von Peter erbeten habe: ich habe die Befehle also richtig angewendet. Bei DTOSTRF bekomm ich trotzdem immer nur: "undefined reference to dtosrtf". Ich habe versucht den Link-Parameter "-rm" zu setzen, aber wo muss ich das machen? Ich benutze Ultraedit zum kompilieren, übertragen wird das Programm dann mit Ponyprog. Wo im makefile oder in Ultraedit muss ich "-rm" angeben? Lieben Gruss und danke für eure Hilfe, Chris
der Link parameter heisst "-lm" und muss natürlich im Makefile bei Variable LDFLAGS angefügt werden. dtosrtf() findet sich nicht in der normalen libc library, sondern in der Math-Library libm.
Komischerweise hab ich auch immer "-lm" genommen... hab mich nur hier
zweimal verschrieben...
Auf diese zeile im Makefile bin ich auch gekommen... eigentlich müsste
alles gehen (leider tut es das nicht).
Also ausführlich:
MAKEFILE:
Davor:
#linker flags
LDFLAGS = -Wl,-Map=$(TRG).map,--cref
Danach:
#linker flags
LDFLAGS = -Wl,-Map=$(TRG).map,--cref,-lm
--> Keine Reaktion, es kommt immer noch die Fehlermeldung. Und hier mein
Codeschnippsel:
Pitch(); //pitch wird berechnet
lcd_gotoxy (0,3);
dtostrf (pitch, 4, 1, pitchar);
lcd_puts (pitchar);
Nebenbei: ist dtostrf eigentlich richtig, wenn man auch eine
Nachkommastelle will?
Chris
FALSCH: LDFLAGS = -Wl,-Map=$(TRG).map,--cref,-lm RICHTIG LDFLAGS = -lm -Wl,-Map=$(TRG).map,--cref Als include genügt <stdlib.h>
Tut mir ja leid, dass Deine Bemühungen nicht fruchten, aber es will trotzdem nicht... genau an diesem Punkt war ich, als gestern die Odyssee mit Version 3.3 begann...
Das selbe wie vorhin... ich probier es gerade mit "itoa"... da wird eine Konstante (7.6) auch ausgegeben (7), aber ich brauch auch den Nachkommawert. (Im Endprodukt soll es natürlich keine Konstante sein, aber in der Rechenformel oder in der Logik oder bei der Vergabe der Datentypen ist was falsch; die Konstante setz ich nur, um zu sehen, ob die Ausgabe mit Nachkommazahl funktioniert). Chris
Also gut, auch nach abändern der LIB-Namen auf die alte Schreibweise, da kommt der alte Fehler bei raus... vermutlich ist meine AVRFreaks Version so alt, dass sie es einfach nicht drin hat (letzte Woche runtergeladen...). Ich werd mich jetzt an Deinen Rat halten, AVRFreak runterschmeissen, WinAVR installieren und dann das Ganze nochmal durchlaufen lassen... hat sonst keinen Sinn, ich verstrick mich in immer mehr Kleinigkeiten, ohne dass das Gerüst richtig steht. Vielen Dank für Deine Hilfe, Peter. Bis dann, :-) Chris
Nur zur Info... Ich hab die neue Version 3.3 nun drauf. Anfangs kamen beim kompilieren Fehler, Peter konnte mir aber helfen: beim zusammenstellen der Version 3.3 wurde vergessen, die SH.exe in den bin-Ordner zu kopieren. Nachdem ich mir die aus meiner alten avr-freaks-Edition geholt hab, wurde auch das kompilieren anständig mit Rückmeldung beendet... kompiliert wurde das Programm allerdings auch so davor, nur wurde es eben nicht mitgeteilt. Die LCD-Lib von Peter kompiliert sich einwandfrei, mein Programm übrigens auch :-) Vielen Dank noch mal an Peter, der mir immer wieder geholfen hat, bis es funktioniert hat. Chris
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.