|
Anzeige
|
Schleife
Gast
#449815
Hallo, ich habe fogendes Problem: Programmiere ich folgende Zeilen, so zeigt mir das Display ein falsches Ergebnis:
aber wenn ich folgendes schreibe habe ich das richtige Ergebnis
Warum? Das ganze zeigt sich auch bei einer for-Schleife. Page 0-15 sind die 16 Zeilen eines Display. .. folgt eine Buchstabenausgabe Bei ersten Code fehlt in der Zeile Null Deine erste Schleife ist eigentlich eine Endlosschleife. unsigned char page=15; while( page >= 0 ); Ein unsigned Typ ist per Definition immer größer gleich 0.
Gast
#449822
while(page>=0); ist bei unsigned char page=irgendwas; immer wahr und du baust eine Endlosschleife. Der Compiler sollte dir eine Warnung geschickt haben...
Gast
#449824
Danke, daran habe ich nicht gedacht. Hätte mir selbst einfallen können Habe es in char page=15 abgeändert Gruß Daniel wrote: > Habe es in > char page=15 > abgeändert Aua. Bitte nimm int8_t (aus <stdint.h>).
Gast
#449854
Etwas besser, zumindest für portablen Code, wäre eigentlich noch int_fast8_t. int8_t ist zwar beinahe genauso portabel (könnt ja sein, dass es keinen 8-bit-Typ gibt), aber int_fast8_t ist der schnellste Typ, der mindestens 8 Bit hat, im Gegensatz zu int8_t, der immer exakt 8 Bit breit ist. Bei 16- oder 32-bit-Prozessoren sind die größeren Typen oft schneller. Hi gibt es eine Möglichkeit "int8_t" in der gleichen Farbe (syntax highlighting) wie "char" anzeigen zu lassen? Entwichklungsumgebung AVRStdudio (4.12.498 Service Pack 4) und WINAWR (20060125). Gruß MISZOU
Gast
#449898
@M.M.: Nein, da "int8_t" kein C-Schlüsselwort ist. Hi thx, ja hab ich gewußt. Gerade wollte ich noch weiter fragen. Nachdem mir eingefallen ist, dass ich bei AVR Studio suchen muss. In der AvrStudio_c.ini ist alles hinterlegt. Also hat es sich erledigt. Jetzt kann ich endlich (u)intN_t verwenden,GG Gruß MISZOU Rolf Magnus wrote: > Etwas besser, zumindest für portablen Code, wäre eigentlich noch > int_fast8_t. ...oder int_least8_t. ;-) Nehmen sich wahrscheinlich beide nicht viel. Es ist aber interessant, wenn man mal nach uint8_t gugelt, so ist AVR-GCC mittlerweile wohl im vorderen Feld derer zu finden, dessen Nutzer sich an die <stdint.h>-C99-Datentypen gewöhnt haben. > dessen Nutzer sich an die <stdint.h>-C99-Datentypen gewöhnt haben.
An die muss ich mich erst noch gewöhnen.
Ein alter Hund lernt nur schwer neue Tricks.
Gast
#449987
>> Etwas besser, zumindest für portablen Code, wäre eigentlich noch >> int_fast8_t. > >...oder int_least8_t. ;-) Nehmen sich wahrscheinlich beide nicht > viel. Im Prinzip halte ich es für am besten, die int_fastX_t im Normalfall zu benutzen. Falls das Sparen von Speicher besonders wichtig ist, die _least_-Version, und nur, wenn man exakte Größen braucht, weil man z.B. ein wraparound benötigt oder mit Hardwareregistern fummelt, die intX_t-Variante mit genau definierter Größe. Bei Mikrocontrollern benutze ich aber auch meistens auch nur die letztere oder halt einfach int. Bisher hatte ich auch noch kein AVR-Programm, das ich auf eine ganz andere Plattform (16, 32, 64 Bits) portieren mußte. > Es ist aber interessant, wenn man mal nach uint8_t gugelt, so ist > AVR-GCC mittlerweile wohl im vorderen Feld derer zu finden, dessen > Nutzer sich an die <stdint.h>-C99-Datentypen gewöhnt haben. Naja, selbst fast 8 Jahre nach Einführung von C99 und Ableben von C89 ist die Unterstützung wohl immer noch recht mau. Auf größeren Plattformen braucht man selten Typen mit exakt 8 Bit, deswegen ist es nicht so verwunderlich, dass AVR-GCC da ziemlich weit vorne mitspielt. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
