Zeiger in Hi u. Lo Byte aufteilen

uint16_t* p16;
uint8_t* p8;
uint8_t high, low;

p16 = deine_speicheradresse;
p8 = p16; // Bytezeiger zeigt auf gleiche Adresse wie Wordzeiger

memcpy(p8, &high, 1); // ein Byte von der Adresse auf die p8 zeigt in 
die Variable high kopieren
p8++; // Zeiger ein Byte weiter
memcpy(p8, &low, 1);

Thorsten schrieb:
> p16 = deine_speicheradresse;
> p8 = p16; // Bytezeiger zeigt auf gleiche Adresse wie Wordzeiger
>
> memcpy(p8, &high, 1); // ein Byte von der Adresse auf die p8 zeigt in
> die Variable high kopieren
> p8++; // Zeiger ein Byte weiter
> memcpy(p8, &low, 1);

naja nicht wirklich schön, dann ist es abhängig von der Platform in 
welcher Reihenfolge die Bytes kommen.

 p16 = deine_speicheradresse;

uint8_t low = p16  & 0xff;
uint8_t high = p16>>8  & 0xff;

Der Atmel-Assembler hat dafür ein paar vordefinierte Schlüsselwörter.

Hab mal nachgehen:
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_expressions.html#avrassembler.wb_expressions.Operands
Am Ende der Seite.

Amateur schrieb:
> Der Atmel-Assembler hat dafür ein paar vordefinierte Schlüsselwörter.

er will aber weg von ASM hin zu C.

Oliver S. schrieb:
> Hans Imglück schrieb:
>> Wie kann ich den Inhalt dieses 2 Byte Zeigers auf  2 einzelne uint8_t
>> Variablen aufteilen, so das ich Hi und Lo Byte der Adresse einzeln habe.
>
>

1

> int p = (uint16_t)pointer;

2

> volatile uint8_t lowbyte = (uint8_t) p;

3

> volatile uint8_t highbyte = (uint8_t) p << 8;

4

>

>
> Oliver

Wollen wir die Richtung der '<<' nochmal überdenken? ;-)

Das volatile ist auch unnötig.

1

void* p;

2

uint8_t lowbyte  = (uint16_t) p;

3

uint8_t highbyte = (uint16_t) p >> 8;

Hans schrieb:
> Das volatile ist auch unnötig.
>
>

1

void* p;

2

> uint8_t lowbyte  = (uint16_t) p;

3

> uint8_t highbyte = (uint16_t) p >> 8;

Wollen wir die casts noch einmal überdenken? ;-)

norbert@Entwicklung:/tmp$ gcc -Wall -Wextra -Wconversion -o x x.c
x.c: In function ‘main’:
x.c:16:15: warning: conversion to ‘uint8_t’ from ‘long unsigned int’ may 
alter its value [-Wconversion]
x.c:18:28: warning: conversion to ‘uint8_t’ from ‘long unsigned int’ may 
alter its value [-Wconversion]

‘long unsigned int’ nur weil ich's gerade auf 'nem 64bit System 
getrieben habe.

Sonst wär's wahrscheinlich  ‘unsigned int’.

Bezgl. -Wconversion: Hat der gcc früher (seinerzeit, zu meiner Zeit also 
einer schlimmen Zeit) per default bei -Wall gemacht, heute muß man es 
explizit angeben. Würde mich interessieren welcher Weltmeister auf die 
Idee gekommen ist, die Warnungen in neueren Versionen schlapper zu 
machen.



/* Kreuzzug für Warnungsfreie Compilerläufe ;-) */

Ach so, so geht's ohne Schlag auf den Hinterkopf vom compiler:

    lowbyte = (uint8_t)(uint64_t)p;
    highbyte = (uint8_t)((uint64_t)p >> 8);

bzw. auf einem 16bit System (ungetestet):

    lowbyte = (uint8_t)(uint16_t)p;
    highbyte = (uint8_t)((uint16_t)p >> 8);

Die Warnung dürfte auch weggehen, wenn man noch mit 0xFF verodert, oder? 
Das fände ich dann die schönere Variante, weils dann auch funktioniert, 
wenn der Datentyp auf der linken Seite mehr als 8 Bit hat.

1

void* p;

2

uint8_t lowbyte  =  (uint16_t) p       && 0xFF;

3

uint8_t highbyte = ((uint16_t) p >> 8) && 0xFF;

Hans schrieb:
> Die Warnung dürfte auch weggehen, wenn man noch mit 0xFF verodert, oder?
> Das fände ich dann die schönere Variante, weils dann auch funktioniert,
> wenn der Datentyp auf der linken Seite mehr als 8 Bit hat.
>
>

1

void* p;

2

> uint8_t lowbyte  =  (uint16_t) p       && 0xFF;

3

> uint8_t highbyte = ((uint16_t) p >> 8) && 0xFF;

Nö, das klappt nicht. Nach p and 0xff bleibt der Ausdruck uint16_t.

Sauber ist es erst, wenn ein cast aus dem 16bit breiten Zeiger einen 
16bit breiten uint16_t macht. Dann fummelt man sich das passende Byte 
heraus (das ist jetzt immer noch 16 bit breit) und castet das dann auf 
8bit.

Karl Heinz schrieb:
> Nur weil du mit irgendwas veroderst wird aus einem 16 Bit Wert nicht
> irgendwie magisch ein 8 Bit Wert.

Das nicht, aber der Wert geht dann sicher in 8 Bit, daher kein "may 
alter its value" mehr.

Gerade probiert:

1

#include <stdio.h>

2

#include <stdint.h>

3

4

int main(void)

5

{

6

  int i;

7

  int* p = &i;

8

9

  uint8_t lowbyte  =  (uint64_t) p       & 0xFF;

10

  uint8_t highbyte = ((uint64_t) p >> 8) & 0xFF;

11

12

  printf("p = %p, lowbyte = %#x, highbyte = %#x\n", p, lowbyte, highbyte);

13

14

  return 0;

15

}

Compiliert ohne Warnungen:

1

hans@hans:~/c$ gcc -Wall -Wextra -Wconversion -o x x.c

2

hans@hans:~/c$ ./x

3

p = 0x7fffbbc278d0, lowbyte = 0xd0, highbyte = 0x78

4

hans@hans:~/c$

P.S.: Es muss natürliche eine bitweise Verundung sein ...

Fand ich auch interessant, jetzt geht's aber noch weiter:

1

    uint8_t lowbyte;

2

    uint8_t highbyte;

3

4

    lowbyte = (uint64_t)p & 0xff;                       /* ze16 */

5

    highbyte = (((uint64_t)p >> 8) & 0xff);             /* ze17 */

6

    highbyte = (((uint64_t)p >> 8) & 0xff) | lowbyte;   /* ze18 */

x.c:18:44: warning: conversion to ‘uint8_t’ from ‘long unsigned int’ may 
alter its value [-Wconversion]


In Zeile 17 stellt der Compiler mit absoluter Sicherheit fest, das der 
Ausdruck auf der rechten Seite nur 8bit breit sein kann. KEINE Warnung.

In Zeile 18 wird der gleiche Ausdruck (8bit) mit einem anderen 8bit Wert 
ODER verknüpft. Jetzt gibt's wieder die Warnung.

Versteh's wer will...

Norbert schrieb:
> In Zeile 17 stellt der Compiler mit absoluter Sicherheit fest, das der
> Ausdruck auf der rechten Seite nur 8bit breit sein kann. KEINE Warnung.
>
> In Zeile 18 wird der gleiche Ausdruck (8bit) mit einem anderen 8bit Wert
> ODER verknüpft. Jetzt gibt's wieder die Warnung.
>
> Versteh's wer will...

Finde ich jetzt nicht so merkwürdig. Er prüft halt innerhalb eines 
Ausdrucks, ob der Wertebereich überschritten wird, aber wenn Variablen 
hinzugezogen werden, geht er halt nicht deren ganze Entstehungsgeschiche 
zurück, um festzustellen, welchen Wertebereich die überhaupt haben 
können.
An der Stelle ist lowbyte halt einfach ein uint64_t und damit potenziell 
zu groß.

Rolf Magnus schrieb:
> Finde ich jetzt nicht so merkwürdig. Er prüft halt innerhalb eines
> Ausdrucks, ob der Wertebereich überschritten wird, aber wenn Variablen
> hinzugezogen werden, geht er halt nicht deren ganze Entstehungsgeschiche
> zurück, um festzustellen, welchen Wertebereich die überhaupt haben
> können.
> An der Stelle ist lowbyte halt einfach ein uint64_t und damit potenziell
> zu groß.

Ja, ok, ist jetzt kein Showstopper. Wenn man es wie gehabt ordentlich 
castet ist es ja auch einwandfrei. Ich wunderte mich auch nur über die 
etwas eigentümliche Generierung von Warnungen.

Was meiner Meinung nach viel schlimmer ist:

1

int main(void) {

2

    uint16_t wert1;

3

    uint8_t wert2;

4

5

    wert1 = 12345;

6

    wert2 = wert1;

7

8

    return wert1+wert2;

9

}

So etwas generiert beim gcc heutzutage trotz "-Wall -Wextra" keinerlei 
Warnungen, das ist doch nicht gesund.
Ich weiss ja nicht wann man das beim gcc rausgenommen hat, aber vor 
einiger Zeit gab's für solch einen Sourcecode noch die Kelle vom 
Compiler.

Johann L. schrieb:
> Wenn einen die Warnungen stören kann man Casts dazu tun:

Da waren wir aber schon um 18:49h ;-)

Die Frage ist eher, warum generiert der Compiler keine Warnungen bei 
wirklich üblen Dingen? (siehe 21:48h)

Früher tat er das jedoch. (Wenn ich mich recht erinnere)

Norbert schrieb:
> Die Frage ist eher, warum generiert der Compiler keine Warnungen bei
> wirklich üblen Dingen? (siehe 21:48h)

Wahrscheinlich weil es in normalem Code ständig vorkommt. Genau wie 
Zuweisungen und Vergleiche zwischen signed und unsigned. Da jedes Mal 
explizit casten zu müssen ist auch nicht optimal.

Imo sollten Casts nur bei "ungewöhnlichen" Typumwandlungen wie hier 
zwischen Zeiger und Integer oder Zeigern verschiedenen Typs nötig sein 
und nicht bei impliziten Umwandlungen wie Integern verschiedener Breite. 
Denn wenn man sich deshalb notgedrungen angewöhnt, bei jeder Zuweisung 
zu casten, dann verliert irgendwann das Typsystem seine Wirkung, da man 
die wirklichen Fehler nicht mehr sieht.

Klar, mit viel Disziplin kann man den Großteil vermeiden. Wenn man viel 
mit fremden Code zu tun hat, ists aber leider nicht immer so einfach 
machbar.

Hans schrieb:
> Wahrscheinlich weil es in normalem Code ständig vorkommt. Genau wie
> Zuweisungen und Vergleiche zwischen signed und unsigned. Da jedes Mal
> explizit casten zu müssen ist auch nicht optimal.
>
> Imo sollten Casts nur bei "ungewöhnlichen" Typumwandlungen wie hier
> zwischen Zeiger und Integer oder Zeigern verschiedenen Typs nötig sein
> und nicht bei impliziten Umwandlungen wie Integern verschiedener Breite.
> Denn wenn man sich deshalb notgedrungen angewöhnt, bei jeder Zuweisung
> zu casten, dann verliert irgendwann das Typsystem seine Wirkung, da man
> die wirklichen Fehler nicht mehr sieht.
>
> Klar, mit viel Disziplin kann man den Großteil vermeiden. Wenn man viel
> mit fremden Code zu tun hat, ists aber leider nicht immer so einfach
> machbar.

OK, ich präzisiere noch einmal:

Wenn ich dem gcc mit den Optionen -Wall -Wextra meinem Wunsch nach 
Warnungen bei schlampiger Programmierung Ausdruck verleihe, dann will 
ich bei Zuweisungen wie zB. int16_t -> uint16_t und ähnlichen 
fragwürdigen Konstrukten gewarnt werden. Sollte das hin- und herhüpfen 
zwischen verschiedenen Typen tatsächlich gewollt sein, dann caste ich.

Wenn ich jedoch diese Art der Programmierung ohne explizite casts 
irrtümlicherweise für sauber und akzeptabel halte, so kann ich jederzeit 
die entsprechenden Warnungen abschalten.

Aber -Wall -Wextra ist meines Erachtens nach ein ziemlich 
unmissverständlicher Wunsch nach Informationen.

Wie gesagt, früher wurde man vom gcc bei so etwas gewarnt.

Frank M. schrieb:
> Ja, allerdings war Deine Version wesentlich "unportabler".

Allerdings ging es bei der Fragestellung nicht im Geringsten um 
Portabilität, sondern um Warnungen wenn keine casts eingesetzt werden.

...und darauf bezogen sich alle von den verschiedenen Postern bisher 
geschriebenen Beispiele.

Der Portabilitätsaspekt ist erst viel später eingeführt worden um das 
Thema zu verwässern und vom eigentlichen Problem abzulenken. ;-)

Um es vielleicht noch einmal von der 'anderen' Seite zu beleuchten:

Die Einführung von (uintptr_t) um verschiedene Pointerbreiten zu 
unterstützen hilft bei der Aufgabenstellung des Themenerstellers nicht 
im Geringsten.

Dann müsste nämlich auch noch eine Überprüfung der Pointerbreite 
stattfinden, die Aufteilung nicht nur in Lo/Hi Byte (16bit) sondern 
vielleicht in Lo/Hi/VeryHi/ExtremelyHi (32bit) sowie deren Äquivalente 
für alles >32bit Breite - das spar' ich mir hier mal - stattfinden.

Darum ging es hier aber nicht!