hallo miteinander,
ich programmiere jetzt seit ein paar tagen kleine tests für den atmega8
in c mit oben genannten tool. ich hab jetzt ein kleines programm, dass
text bzw. zahlen an ein lcd ausgibt. soweit kein problem.
wenn ich allerdings mit itoa() integer in strings umwandle, dann
funktioniert das programm mal und mal nicht. sprich ich compiliere es
und es läuft fehlerfrei (zähler auf dem display, der bis 255 hochzählt
und dann von neuem beginnt).
kommentiere ich im quelltext die stelle mit dem zähler aus und setze was
anderes ein um was zu testen und mache das dann nach erfolgreichem test
wieder rückgängig, dann funktioniert der quelltext, der fünf minuten
vorher noch funktioniert hat, auf einmal nicht mehr, obwohl nichts
geändert ist. das ganze lässt sich dann auch durch mehrmaliges
neucompilieren nicht beheben. auch nicht wenn ich vorher alle dateien
bis auf die .c datei und das makefile lösche. ändere ich dann etwas im
makefile und compilere neu, dann funktioniert es manchmal.
textausgabe an das lcd funktioniert immer. auch der folgende
codeschnipsel funktioniert mal und mal nicht.
char textout;
int val=65;
itoa(val, textout, 10);
lcd_string(textout);
der haken muss irgendwo bei dem itoa befehl liegen, aber ich habe keinen
plan wie ich es lösen könnte.
danke schonmal!
mfg
--steffen
Kein Wunder, wenn val=65 ist, muss die Variable mindestens 3 char gross
sein ('6' '5' '\0') .
Zitat aus avr-lib user-manual:
The function itoa() converts the integer value from val into an ASCII
representation that will be stored under s. The caller is responsible
for providing sufficient storage in s.
der fehler tritt auch dann auf, wenn ich statt
char textout;
char textout[10];
schreibe, von daher liegt es nicht daran.
das problem gibt es auch, wenn ich val=1 setze.
mfg
--steffen
Tut mir leid, dass ich dieses alte Thema wieder aufrolle, aber ich habe
auch ein ähnliches Problem und bisher habe ich keine Lösung dafür
gefunden.
Mal ganz davon abgesehen, dass bei mir auch ab und zu oben genanntes
Problem auftritt, macht itoa() teilweise ziemlichen Müll.
Wenn ich 255 (dez) durch itoa jage, kommt teilweise über usart 0"255
raus.
Nach dem nächsten Aufruf von itoa() mit 30 (dez) kommt beispielsweise
5"30 raus. Also immer die letzte Ziffer der letzten konvertierten Zahl
gefolgt von doppelten Anführungszeichen und der eigentlichen Zahl.
Lustigerweise tritt dieses Verhalten auch auf wenn ich versuche itoa
simpel nachzubauen.
Du hast duich irgendwo beim char Array verhedeert, dass du wahlweise in
itoa oder eben in deinen Ersatz übergibst. Möglicherweise hast du auch
einen Pointer verschlampt, auf dem Weg von itoa bis dann endlich die
Ausgabefunktion aufgerufen wird.
Auf jeden Fall aber:
Das Problem liegt weder in itoa noch in dem von dir geposteten Code (den
ich nicht weiter studiert habe) sondern an der verwendenden Stelle bzw.
in den Funktionen die danach aufgerufen werden.
Und bitte Hijacke keine Uralt-Threads.
Du musstest dein Problem sowieso neu beschreiben. Also hättest du auch
gleich einen neuen Thread aufmachen können. Das du eine gleichlautende
oder ähnliche Überschrift gewählt hättest, ist noch lange kein Grund
solche Uralt-Dinger aus der Versenkung zu holen.
Auch wenn es ursprünglich ein alter Thread ist, kann er zumindest für
die Zukunft gelöst und beendet werden:
Also ich bin ja noch ein Anfänger, aber das Problem dürfte nicht bei
itoa() liegen. Wenn ich mit itoa() in ein char-array schreiben möchte
aber nur das erste Element beschreiben kann weil hier char textout; nur
Platz für einen char freigegeben wird, so ist gibt lcd_string() alles
aus bis zufällig ein '\0' kommt.
Konstantin schrieb:> Auch wenn es ursprünglich ein alter Thread ist, kann er zumindest für> die Zukunft gelöst und beendet werden:>> Also ich bin ja noch ein Anfänger, aber das Problem dürfte nicht bei> itoa() liegen. Wenn ich mit itoa() in ein char-array schreiben möchte> aber nur das erste Element beschreiben kann weil hier char textout; nur> Platz für einen char freigegeben wird, so ist gibt lcd_string() alles> aus bis zufällig ein '\0' kommt.
Mit anderen Worten:
Kauf dir ein C-Buch und studiere das Kapitel über String-Verarbeitung
ausgiebig und aufmerksam.
Ich mach jetzt den Thread mal dicht, ehe das Thema noch mal aufgewärmt
wird.
Ralf schrieb:> Patrick Stuckenberg schrieb:>> base^i> ???
(Auch wenn der Thread schon zu ist, das sollte man wohl noch
ergänzen.)
Warum drei Fragezeichen (was ja eine nicht definierte Trigraph-
Sequenz wäre ;-)?
^ ist doch klar definiert ein XOR. Allerdings hilft es nichts,
wenn man
1
number/base^i
vorn mit Leerzeichen und hinten ohne schreibt, der Operatorenvorrang
lässt es trotzdem zu
1
(number/base)^i
werden. ;-)
OK, weiter dann im neuen Thread, den Patrick ja vielleicht eröffnet.