Schleife

[Daniel (Gast)]

Hallo,
ich habe fogendes Problem:
Programmiere ich folgende Zeilen, so zeigt mir das Display ein falsches 
Ergebnis:

unsigned char page=15;
do 
{
   LCD_SET_PAGE(page);
   ..
   page--;
}
while(page>=0);

aber wenn ich folgendes schreibe habe ich das richtige Ergebnis

unsigned char page=16;
do
{
   LCD_SET_PAGE(page-1);
   ..
   page--;
}
while(page>0);

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

[Karl heinz B. (kbucheg)]

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.

[Stefan (Gast)]

while(page>=0); ist bei unsigned char page=irgendwas; immer wahr und du 
baust eine Endlosschleife. Der Compiler sollte dir eine Warnung 
geschickt haben...

[Daniel (Gast)]

Danke,
daran habe ich nicht gedacht. Hätte mir selbst einfallen können
Habe es in
char page=15
abgeändert
Gruß

[Jörg W. (dl8dtl) (Moderator)]

Daniel wrote:

> Habe es in
> char page=15
> abgeändert

Aua.

Bitte nimm int8_t (aus <stdint.h>).

[Rolf Magnus (Gast)]

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.

[M. M. (miszou)]

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

[johnny.m (Gast)]

@M.M.:
Nein, da "int8_t" kein C-Schlüsselwort ist.

[M. M. (miszou)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Karl heinz B. (kbucheg)]

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

[Rolf Magnus (Gast)]

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