large integer implicitly truncated to unsigned type

Falls I2C_FORMAT_7_BIT_ADDRESS eine Funktion ist, hängt es von deren 
Prototyp ab.

Falls I2C_FORMAT_7_BIT_ADDRESS ein Makro ist -- was die Namenskonvention 
vermuten läßt -- hängt es von der Definition des Makros ab.

Grüße von der Kristallkugel...

Ach so das pielt auch mit rein

#define I2C_FORMAT_7_BIT_ADDRESS(v,a,r) ( (v).address=(a), (v).rw=(r) )

Klar, und nun weiß jeder wie diese Dinger deklariert sind.

.address ist ein Bit-Feld der Größe 7 (der Name des Makros sagt es doch 
schon). Mit keinem Trick der Welt kannst du da ein 0xD0 rein stopfen.

Dein 0xD0 ist vermutlich bereits die I2C-Adresse inklusive des 
RW-Bits.

Jetzt checke ich auch das dieses Makro zusammen mit der union funzt, 
aaaah.

Wir haben hier also das R/W Bit am ende und davor eine 7 Bit Adresse.

Laut Datenblatt (MCP3422 Seite 20) besteht die 7Bit Adresse aus

4Bit Device ID 1101
und

3Bit Address Bits
000

Also: 1101000 entspricht einem 0x68 ?

David Mueller schrieb:
> Also: 1101000 entspricht einem 0x68 ?

Was denn auch sonst? Die am weitesten rechts stehende Ziffer einer 
ganzen Zahl hat immer die Wertigkeit "Basis des verwendeten 
Zahlensystems hoch Null".

Sicher könnte man irgendwas anderes definieren wenn man wollte, aber das 
wäre dann doch etwas seltsam ;-)

Mark Brandis schrieb:
> David Mueller schrieb:
>> Also: 1101000 entspricht einem 0x68 ?
>
> Was denn auch sonst? Die am weitesten rechts stehende Ziffer einer
> ganzen Zahl hat immer die Wertigkeit "Basis des verwendeten
> Zahlensystems hoch Null".

Also Eins :-)

Johann L. schrieb:
> Also Eins :-)

Ja. Außer bei null hoch null. ;-)

Mark Brandis schrieb:
> Johann L. schrieb:
>> Also Eins :-)
>
> Ja. Außer bei null hoch null. ;-)

Null als Basis für ein Zahlensystem ist nicht wirklich sinnvoll.

Johann L. schrieb:
> Null als Basis für ein Zahlensystem ist nicht wirklich sinnvoll.

Ich mach am besten noch (null geteilt durch null) weitere Smileys dazu.