Stefan schrieb:>> Zahl = (unsigned long long int)&screen[0];> Wow , ein 64 Bit µC.> Stefan
Die Bemerkung ist unsinnig und mit großer Wahrscheinlichkeit fehlerhaft,
zumindest aber fehlerhaft hergeleitet.
Was ist denn screen für ein Typ? Und was genau willst du? Den Inhalt des
ersten Elements? Den Speicher, auf den das erste Element zeigt? Die
Adresse des ersten Elements?
Peter Zz schrieb:> wie kann ich die Adresse eines Pointers ausgeben?
Genau so wie die Adresse von anderen Objekten. Was ich in deinem
Beispiel vermisse sind allerdings die pointer selbst. Es mag auf deiner
Plattform zufällig so sein, dass ein "unsigned long long int" dieselbe
Grösse wie ein Pointer hat, aber es ist schlechter Stil und das casting
verschlimmbessert die Situation noch.
Abhilfe: Definiere explizit einen Pointer auf deinen Datentypen, und
weise dann die Adresse zu. Damit kannst du dann hantieren.
Guest schrieb:> Was ist denn screen für ein Typ? Und was genau willst du? Den Inhalt des> ersten Elements? Den Speicher, auf den das erste Element zeigt? Die> Adresse des ersten Elements?
Ich hätte gerne die Adresse des ersten Elements.
unsigned char screen[408];
Mein µC ist der ATtiny84, der hat laut Datenblatt 512 Byte RAM.
1
Zahl=(uintptr_t)&screen[0];//das erste Element
2
LCD_Anzeige_Zahl(1,12,Zahl,8,0);
Gibt die (dezimal) Zahl 174 aus!
1
Zahl=(uintptr_t)&screen[407];//das letzte Element
2
LCD_Anzeige_Zahl(1,12,Zahl,8,0);
Gibt die (dezimal) Zahl 581 aus!
581 ist aber grösser als 511,
trotzdem funktionieren meine LCD_Grafik-Routinen einwandfrei...
Mark Brandis schrieb:> braucht Du natürlich einen Pointer auf unsigned char:>> unsigned char* my_pointer = &screen[0]; // my_pointer zeigt auf das 1. Element
von screen
Ne, ja is klar,
1
unsignedchar*DPTR;
Die Frage war, wie mach ich aus dem Pointer wieder ne Zahl,
dies ist (teils) geklärt:
1
Zahl=(uintptr_t)DPTR;
Dazu aber noch ein paar Fragen:
1. In welcher Datei wird "uintptr_t" definiert?
2. Warum liegt mein Bildschirmspeicher nicht im Bereich von 0...511?
Ich habe mal einen Screenshoot von meinem LCD-Display gepostet.
Der untere Teil des LCD-Display's wird nach links gescrollt.
Deshalb ist das Bild da verwischt.
Peter Zz schrieb:> 1. In welcher Datei wird "uintptr_t" definiert?
stdint.h
> 2. Warum liegt mein Bildschirmspeicher nicht im Bereich von 0...511?AVR? 0..31 sind die Register, dahinter kommt der I/O-Bereich und dann
erst das RAM.
Peter Zz schrieb:>Die Frage war, wie mach ich aus dem Pointer wieder ne Zahl,>dies ist (teils) geklärt:> Zahl = (uintptr_t)DPTR;
Wozu denn der Cast?
Du hast einen Pointer, der auf eine Zahl zeigt, die Werte zwischen 0 und
255 annehmen kann. Also dereferenzierst Du den Pointer mit dem *
Operator.
Einen unsigned char Wert kann man problemlos jeder "größeren" Variablen
zuweisen (wie unsigned int etc.)
Danke erstmal :-)
Mein Wissen über die Programmiersprache "C" gleich einem Schweizerkäse
(Tilsiter oder Emmentaler?), alles voller Löcher.
Ein bis zwei dieser Löcher sind jetzt gerade gestopft worden ;-)
Peter Zz schrieb:> LCD_Anzeige_Zahl(1,12,(uint16_t)&screen[0],8,0);
das sollte aber das gleiche wie
LCD_Anzeige_Zahl(1,12,screen,8,0);
sein, maximal kommt noch eine warnung (die aber ok ist)
A. K. schrieb:> Autsch!
wieso? mit dem cast wird auch nur die warung unterdrückt es ändert sich
aber nichts an den zahlen. Ein pointer ist nun mal keine zahl.
Jo, und morgen kommt er mit einer Frage, bei der sich herausstellt, dass
er 345 Warnungen in den Wind schlug. Wieso? "Ja, hab ich hier so
gelernt, dass man die ignorieren kann". Eine davon aber nicht.
A. K. schrieb:> Jo, und morgen kommt er mit einer Frage, bei der sich herausstellt, dass> er 345 Warnungen in den Wind schlug. Wieso? "Ja, hab ich hier so> gelernt, dass man die ignorieren kann". Eine davon aber nicht.
und so schreibt er überall ein cast hin, weil er weiss das damit die
Warnungen verschwinden - ist natürlich viel besser.
Peter II schrieb:> und so schreibt er überall ein cast hin, weil er weiss das damit die> Warnungen verschwinden - ist natürlich viel besser.
Jep. Weil die eine wichtige dann nicht in 344 unwichtigen untergeht.
Klar, der Stein der Weisen ist das auch nicht. Denken muss er schon
noch. Aber nur einmal, nicht bei jedem Compilerlauf.
A. K. schrieb:> Peter II schrieb:>>> maximal kommt noch eine warnung (die aber ok ist)>> Autsch!>
Sieh's mal so, mit der Warnung weiß er zumindest, dass er da noch
Debugging output stehen hat, der wieder raus muss.