Binär -- wie in C schreiben?

Bemüh mal die Forensuche ...
Soweit ich mich erinnere macht man das über Makros.

Im nächsten WinAVR dann auch einfach als 0b10011. :-))

0b10011. :-))


und so umgeht man das Problem mit Klammerebenen:


((-: .0b10011b0. :-))

Gruß M.

Eine weitere Lösung ist eine generierte Headerdatei mit
defines für B00000000 bis B11111111, siehe Anhang.

Die Datei habe ich per Excel erzeugt.
Damit entfällt die Schreibweise mit Klammer wie im obigen Beispiel.

Klaus

@Peter
Punkt bzw. Bit für dich! Aber B1, B01, B0010 geht bei dir auch nicht.
Eher B(1), B(01), B(0010)......

Ausserdem:
Bei meiner Variante meldet der Preprozessor Fehler, wenn
man eines der 8 Bits vergisst, sozusagen eine Plausibilitätskontrolle
ob die Binäzahl auch tatsächlich 8 Bit hat und da alle
Prozessorregister 8 bittig kann das von Vorteil sein.

Klaus

Hi,

was bewirkt eigentlich:
0##y
in dem Makro von Peter, so wie ich mir das vorstelle, müsste es doch
auch nur mit
y & 1 | ...
funktionieren.


Stefan

> was bewirkt eigentlich: 0##y

"##" ist der sog. "token merging operator" des Preprozessors.
Damit kann man zwei Tokens verbinden. Siehe C Handbuch.

> in dem Makro von Peter, so wie ich mir das vorstelle, müsste es doch
> auch nur mit
> y & 1 | ...
> funktionieren.

Nein tut es nicht. Eine der großen Stolperfallen in C ist die
Schreibweise
von Konstanten:
* Zahlen, die mit einer "0" beginnen sind Oktalzahlen
* Zahlen, die mit "0x" beginnen sind Hexadezimalzahlen

010 ist eben nicht 10 im Dezimalsystem, sondern 8.

Das Makro B8(y) fügt also eine "0" an eine Konstante. Die Zahl
B(10) wird mittels "0##y" zu 010. Die Klammer rechnet dann
den Zahlenwert 010 oktal in einen Zahlenwert 010 binär um.
Deshalb die seltsamen Schiebeoperationen.
Das Makro würde ohne führende 0 nicht funktionieren.

Klaus

@jens

ich rechne sowas immer in hex um und schreib's dann hin,
also 0xFF für 11111111.

Nach ANSI C kann man jedenfalls nur octal/hex/dezimal/float definieren
(gilt auch für C++, siehe Stroustrup). Ansonsten nur wie o.g. mit zus.
Headerdateien oder Macros.

Ref.:
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.2.html#const
http://www.phim.unibe.ch/comp_doc/c_manual/C/CONCEPT/constants.html

gruß,
mc-hack

@Jörg:

>Im nächsten WinAVR dann auch einfach als 0b10011. :-))

Klasse, vielen Dank, funktioniert prima :-)))

Viele Grüße, Stefan

>Im nächsten WinAVR dann auch einfach als 0b10011. :-))

ich hab mir hier die Toolchain unter Linux gebaut und da geht das
0b10011 leider nicht. Muss ich da noch einen Patch anwenden? Und gegen
was: die libc oder den gcc? Wo kann ich rausfinden welche Patches im
WinAVR drin sind? Die Homepage schweigt sich da leider aus -- gibts da
keine Übersicht?

> Muss ich da noch einen Patch anwenden?

Ja.

> Und gegen was: die libc oder den gcc?

Gegen den Compiler (eigentlich logisch, nicht? ;-).

Ich habe ihn mal hier mit abgelegt:

http://www.sax.de/~joerg/patch-binary-constants

Ich muss ihn wohl endlich mal offiziell als request for enhancment
einreichen, nachdem ich nun schon die ganze FSF paperwork hinter mir
habe.  Dafür muss ich aber auch noch die Doku schreiben.

> Wo kann ich rausfinden welche Patches im WinAVR drin sind?

Eric Weddington fragen, vermute ich mal.

> Gegen den Compiler (eigentlich logisch, nicht? ;-).

Eigentlich schon :) Nur leider klappt das mit dem Denken bei mir heute
irgendwie nicht so toll ... ich glaub ich brauch dringend Urlaub.

> Ich habe ihn mal hier mit abgelegt:

Danke!

Jörg, könntest du bitte den Patch hier nochmals hochladen? Der Link 
funktioniert nicht mehr -.-

> ich rechne sowas immer in hex um und schreib's dann hin,
> also 0xFF für 11111111.

Wenn man das ein paar mal gemacht hat, kennt man die Zuordnungen 
zwischen Hex-Digit und vierstelliger Dualzahl schnell auswenig, und man 
macht das ganz automatisch.

Mag sein. Mag auch sein, dass es wohl sinnvoll wäre sich umzugewöhnen, 
aber irgendwie fehlt mit atm die Lust dazu.^^
Wenn ich Zeit und Lust hab, werd ich mich umstelln, ich versprech's.