mikrocontroller.net

Forum: Compiler & IDEs Schleife


Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

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

Autor: Daniel (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel wrote:

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

Aua.

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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. M. (miszou)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: johnny.m (Gast)
Datum:

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

Autor: M. M. (miszou)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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



Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.