schreiben von neg Zahlen auf LCD

Wenn Du in C programmierst, nimm mal sprintf(Buffer[],"Zahl: %d",Wert);
Danach mit Deiner LCD-Funktion den Buffer[] auf das Display schieben.

unn tschuess
B.

Danke Holger,

Ich dachte, dass ich nur den wesentlichen Auszug aus dem Gesamtprogramm 
mache, der sich mit dem Thema beschäftigt. Zusätzlich habe ich den 
EEPROM-Inhalt heruntergeladen und leserlich gemacht. Deshalb das 
Word.doc, das nicht so umfangreich ist. Im Dokument konnte ich dann auch 
die wesentlichen Passagen nur FETT herausstellen.

Danke Bernhard,

Mit "sprint" habe ich das Ganze noch nicht probiert. Ist ein guter Tipp. 
Nur muß ich das ganze Programm umschreiben, weil ich die Formatierung ja 
an vielen Stellen im Gesamtprogramm benutze und ich dann überall mit 
spront arbeiten muß. Dann ist mir auch noch unklar, ob ich mit sprint 
über den USART schreiben kann, was ich mit der Routine "Raw_INT()" 
mache.
Ich werde das schon interessehalber versuchen.

mfG frewer

Werner Freytag schrieb:
> Deshalb das
> Word.doc, das nicht so umfangreich ist.

Lach, Quelltext ist immer wesentlich kleiner.
Für 35kB mußt Du schon ne Menge Programm schreiben.

Jeder Programmierer hat seine Liebling-IDE mit Syntax-Highlighting und 
nur damit guckt er Programme an.

Eine IDE ist aber extrem allergisch gehen DOC, die versteht nur C oder 
ASM.

Also kein C -> kein Angucken.


Peter

Hi,
schau mal hier:

1

static unsigned char tmp_temp[4];

2

....

3

signed int vh= tmp_temp[i];

vh ist +-15Bit breit und tmp_temp ist 8Bit breit, passt also naht los in 
vh rein!

versuch mal folgendes:

1

signed int vh= (signed char)tmp_temp[i];

jetzt ist der Inghalt von tmp_temp nur noch 7Bit breit und kann auch 
negative Werte darstellen.

Mach dir bei sowas DebugMsg rein, dann hättest du gesehen das tmp_temp 
Werte aufweisst die größer 7Bit sind!!!

Stephan

Hallo Stephan,

die Erklärung verstehe ich und hab auch gleich mal das Programm 
geändert. Werde sehen, ob das das Problem ist. Komisch war für mich, 
dass an anderer Stelle der Aufruf von LCD_Int(...) mit neg Zahlen 
funktioniert und zwar ohne den "casr" Operator allerdings auch nicht aus 
dem EEPROM.
Melde mich mit dem Ergebnis.

mfG
frewer

Hi
bei RAW_INT() ist der Temperaturwert ein signed Wert, die Funktion 
sollte richtig sein!

Aber:
Bei VerbrauchsMenu() ließt du den Wert aus dem EEPROM mit einer unsigned 
Var, also wird der Wert als pos. interpretiert!
Bei der Zuweisung zum signed int passt der positive Wert komplett rein, 
also bleibt er positiv!

Schau dir nochmal die Zahlenbereiche an und dieses:
http://en.wikipedia.org/wiki/Signed_number_representations#Two.27s_complement

Du hast im EEPROM die Werte:

0xFD 0xF9 ....

0xFD -> 253 dez. (unsigned Wert)
0xFD -> -3 dez. (signed Wert)

Stephan

Hallo Stephan,

Deine Kommentierung habe ich verstanden, dennoch bringt die Anwendung 
von signed int vh = (signed char)tmp_temp[i] nicht die Lösung.
Was passiert:
Im VerbrauchsMenu läuft jetzt die Erkennung, dass vh<=100 ist, denn in 
der Anzeige wird aus der Routine Raw_Int() das +?? angezeigt. Das wird 
daher rühren, daß ich in die Routine Raw_Int() wieder mit tmp_temp[] 
ohne cast wechsle. Deshalb habe ich nun im VerbrauchsMenu tmp_temp[] mit 
signed char definiert und bin gespannt, ob dann die Fehler behoben sind. 
Wenn nicht, dann muß ich doch dort jeweils einen 'cast' (signed 
char)tmp_temp[] einführen.

Bin langsam selbst gespannt. Vielen Dank für Deine Erklärung, man muss 
da ja teuflisch aufpassen. Interessant ist, dass ich das Programm aus 
Codevision in WinAVR übersetzt habe und in der entsprechenden 
Codevision-Routine werden weder 'cast' verwendet noch das Array als 
signed char definiert. Aber mir ist nicht bekannt, ob im sog Original 
die Darstellung richtig funktioniert.

Gruß
frewer

Hallo Stephan,

also noch einmal vielen herzlichen Dank für Deine Hilfe. Es klappt jetzt 
perfekt. Das ganze Problem war also die richtige Definition des Array im 
VerbrauchsMenu() mit signed int tmp_temp[]. Und was habe ich da 
erfolglos rumprobiert. Präzises Nachdenken hilft halt scheinbar!

Gruß
frewer