Wie schreibt man Binärzahlen?

Es ist auch eine non-standard-Erweiterung, die allerdings von allerlei
Compilern im Microcontroller-Umfeld verstanden wird.  Es gab sie
bereits einige Jahre als Patch für den AVR-GCC, mittlerweile wurde
sie vom GCC als Erweiterung akzeptiert und ist seit GCC 4.3 nun
standardmäßig mit dabei.

> Kann dem Jungen mal jemand ein C-Buch schenken?
Ich schenk ihm einen Link, da steht das auch drin:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Detlaus wrote:
> Kann dem Jungen mal jemand ein C-Buch schenken?

Das würde nichts helfen, denn ein ordentliches C-Buch wird kaum die
GCC-Erweiterungen beschreiben.

Vielleicht ja 'ne sehr konservative Sichtweise, aber auf solche 
Erweiterungen sollte man sich nicht einlassen. Stattdessen sollte man 
lernen, mit hexadezimalen Zahlen zu arbeiten. Das ist nicht sehr 
schwierig, man muss sich gerade mal 16 Bitmuster einprägen.

Hat man das geschafft, dann sieht man die Bitmuster, wenn denn sie 
einen überhaupt interessieren.

Findet man das zu anstrengend und zu schwierig, sollte man sich 
vielleicht nach einem anderen Hobby umsehen - Briefmarken züchten oder 
Goldfische sammeln.

Noch schlimmer als die eigene Bequemlichkeit, mal was zu lernen, ist der 
so erzeugte nichtportierbare Quelltext.

Das ist Schrott.

Und das nur, weil jemand nicht 0xA anstelle von 0b1010 schreiben kann.

Meine Güte.

Für lernresistente ließen sich auch einfache Macros à la

#define B0000 0
#define B0001 1
#define B0010 2

...

#define B1111 15

oder das ganze auch achtstellig definieren.

Einfacher aber wäre es, sich auf $Körperteil zu setzen und die 16 
Bitkombinationen eines 4-Bit-Nibbles auswendig zu lernen.

Rufus t. Firefly wrote:
> Einfacher aber wäre es, sich auf $Körperteil zu setzen und die 16
> Bitkombinationen eines 4-Bit-Nibbles auswendig zu lernen.
Auswendig lernen ist aber eigentlich Käse. Besser versuchen, zu 
verstehen, wie Binär-, Dezimal- und Hexadezimalsystem funktionieren. 
Dann kann man sich das nämlich in Nullkommanix herleiten...

Läuft schnell auf's gleiche raus. Genauso wie man mit der Zeit die 
Zweierpotenzen mindestens bis 2^16 auswendig kennt.

A. K. wrote:
> Läuft schnell auf's gleiche raus. Genauso wie man mit der Zeit die
> Zweierpotenzen mindestens bis 2^16 auswendig kennt.
Ist zwar im Prinzip korrekt, aber man sollte Zahlensysteme wenigstens 
grundlegend verstanden haben. Und wenn man das Dezimalsystem versteht, 
dann versteht man auch schnell alle anderen. Leider hakt es da bei 
vielen...

@Peter Stegemann:
Ist richtig, die Portierbarkeit ist sowieso meist schon durch andere 
Dinge nicht gegeben (fängt schon bei den Bibliotheken an).

Allerdings verleitet die Binärschreibweise gerade Anfänger dazu, selbst 
Dinge, die man gut lesbar unter Verwendung der Bitnamen schreiben 
könnte, in 0bxxxxxxxx zu schreiben, was eine Fehlersuche bzw. Änderung 
am Code zur Tortur machen kann. Imho ist die Binärschreibweise wirklich 
nur da sinnvoll, wo es gewünscht ist, dass man ein Bitmuster direkt 
sehen kann. In den meisten Fällen ist, wenn es um das Setzen von Bits 
geht, die (1 << XYZ)-Schreibweise sinnvoller.

Die Binärschreibweise birgt auch die nicht zu unterschätzende Gefahr, 
dass man sich mit den Stellen verzählt und stundenlang nach dem Fehler 
sucht.

> > Einfacher aber wäre es, sich auf $Körperteil zu setzen und die 16
> > Bitkombinationen eines 4-Bit-Nibbles auswendig zu lernen.
> Auswendig lernen ist aber eigentlich Käse. Besser versuchen, zu
> verstehen, wie Binär-, Dezimal- und Hexadezimalsystem funktionieren.
> Dann kann man sich das nämlich in Nullkommanix herleiten...

Ich wollte die Messlatte nicht allzuhoch legen. "Verstehen" und 
"herleiten können", das ist doch noch viel komplizierter ...


> Also ziehe ich die angenehmere Lesbarkeit  ...

Ab einer gewissen Anzahl Stellen ist eine binärzahl nicht mehr 
"angenehmer" lesbar, das steigert nur die Fehlerrate.

Wer hat schon Lust, in einem Quelltext 16-Bit-Binärzahlen auf 
Vollständigkeit abzuzählen ?

Ich sehe da keinerlei "angenehmere Lesbarkeit".

Rufus t. Firefly wrote:

> Wer hat schon Lust, in einem Quelltext 16-Bit-Binärzahlen auf
> Vollständigkeit abzuzählen ?

Weiss grad nicht in welcher Sprache, aber irgendwo geht 
0b0001_0010_0100_1000 und das ist dann doch lesbar.

Aber persönlich verwende ich die (1<<x) Notation oder Hex, ja nachdem 
was besser passt. Zentral als Hardware-Konfiguration definiert, damit 
die Module nicht von der Portverteilung abhängen.

Johannes M. wrote:
> @Peter Stegemann:
> Ist richtig, die Portierbarkeit ist sowieso meist schon durch andere
> Dinge nicht gegeben (fängt schon bei den Bibliotheken an).

AVR-Code kann man durchaus portabel halten.

Komplexere AVR-Prgramme lass ich einfach für den PC übersetzen, da hat 
man ganz andere Analysemöglichkeiten als in einem Simulator. Einen 
kleinen Kompatibilitäts-Header, der Sachen wie avr/pgmspace.h etc. 
rausparametriesiert, und schon geht's los!

Ich hatte den Code ursprünglich auch mit 0b*** gespickt, aber ein 
Host-gcc mechert da rum. Bevor ich ewig rumsuche oder mir den Wolf 
scripte hab ichs also wieder rausgeschmissen und Standard geschrieben.

Auf 0b*** kann man nich nichtmal ein Makro definieren (falls man cpp 
verwendet und sich nicht den Horror mit m4 antun will).

Und bei großen Konstanten wie 0b11001101000010101000010111110011ul würd 
ich auch nicht sagen, daß das die Lesbarkeit fördert. Ein

1

0xcd0a85f3ul // 11001101 00001010 10000101 11110011

tut's doch auch.

Johann

Johann L. wrote:

> Ich hatte den Code ursprünglich auch mit 0b*** gespickt, aber ein
> Host-gcc mechert da rum.

Nun, du weißt doch, wie man einen GCC neu baut (also auch den für den
Host) :-).

> Auf 0b*** kann man nich nichtmal ein Makro definieren

Ja klar, sonst wäre es ja auch nie als language extension durch
gegangen.

A. K. wrote:

> Weiss grad nicht in welcher Sprache, aber irgendwo geht
> 0b0001_0010_0100_1000 und das ist dann doch lesbar.

Das dürfte Spin sein.
Da kann man in allen Zahlen solche Trennzeichen einfügen.

Ich verwende die b0101010 Schreibweise auch, aber nur da wo es wirklich 
sinnvoll ist, nämlich bei LCD Controllern.
Da werden in Datenblättern die Register üblicherweise alle in Binär 
angegeben, wieso also den Aufwand machen das im Kopf umzurechnen und 
eventuell noch einen Fehler einzubauen? Wenn das im Code genauso 
aussieht wie im Datenblatt, kann man auch viel besser vergleichen.

Benedikt K. wrote:

>> 0b0001_0010_0100_1000 und das ist dann doch lesbar.
>
> Das dürfte Spin sein.

Besser bekannt: Perl.

CAnfänger wrote:
> Wow, hier geht es ja heiß her..
>
> ich kann im Kopf von hex nach binär und umgehehrt, jedenfalls in einem
> Byte. Aber manchmal ist binär schreiben praktisch (siehe oben) Ich will
> ja in einer "Hochsprache" programmieren der Übersicht halber. Selbst in
> Assembler kann man binär schreiben..

Nunja, C ist eben keine Sprache die von Anfängern oder für Anfänger 
konzipiert wurde...

Jörg Wunsch wrote:
>
> Nun, du weißt doch, wie man einen GCC neu baut (also auch den für den
> Host) :-).

Ich hab noch nie einen canadian cross gebuildet, wär auch mal 
interessant zu sehen, wie das geht. Also ein gcc für das 
build-host-target Tripel linux-mingw32-mingw32 oder linux-mingw32-avr.

So wie ich das sehe ist WinAVR-avr-gcc kein canadian cross, sondern ein 
native build unter msys/mingw32?

Johann

Wobei Z80 in Oktal erheblich einfacher ist als in Hex.

Johann L. wrote:

> Ich hab noch nie einen canadian cross gebuildet, wär auch mal
> interessant zu sehen, wie das geht. Also ein gcc für das
> build-host-target Tripel linux-mingw32-mingw32 oder linux-mingw32-avr.

Verstehe ich nicht ganz.  Wenn du als Ziel ein mingw32 haben willst,
warum baust du dann den Compiler nicht gleich native dort?

Ich meinte das ja auch nur, weil du mit dem GCC 4.3 ohne Patches
in den ,,Genuss'' der 0b-Implementierung kommst ;-) und dann deine
Quellen wieder 1:1 portierbar sind.

> So wie ich das sehe ist WinAVR-avr-gcc kein canadian cross, sondern ein
> native build unter msys/mingw32?

Ja, das müsste dann mingw32-mingw32-avr sein, ggf. aber auch
cygwin-mingw32-avr -- so genau habe ich die build triplets nie
verstanden.  Ich glaube, Eric baut am Ende alles unter Cygwin, damit
er nicht in zwei verschiedenen Umgebungen bauen muss.  Manche Dinge
(wie AVaRICE oder Insight) brauchen die Posix-API-Emulation von
Cygwin (auch zur Laufzeit, d. h. sie hängen von der cygwin1.dll ab).
Andere Teile (binutils, GCC, AVRDUDE) werden aber so konfiguriert,
dass sie trotz Bauens innerhalb Cygwin zur Laufzeit pures Win32-API
benutzen, also mingw32 (und damit nicht von cygwin1.dll abhängen).

Peter Stegemann wrote:
> Bei mir z.B. bei den Farbdefinitionen fuer's Display.
Oder für Steuersequenzen für nen Schrittmotor oder für ein einfaches 
LED-Lauflicht. Aber da hört's dann auch schon auf...

> Bei der Hex-Schreibweise gibt es gar nix zu zaehlen, das ist nicht
> wirklich sicherer ;-)
Wie gesagt, es kommt drauf an, um was für Werte es sich handelt.
Bitmuster zur Ansteuerung eines Ports -> kann man durchaus in binär 
machen.
Bits setzen in Steuerregistern -> Bitte in (1 << 
FIRLEFANZ)-Schreibweise.
Belegen von Registern / Variablen mit Zahlenwerten -> Dezimal- oder 
Hexadezimalschreibweise, je nachdem, was für ein Wert es sein soll.