amateur schrieb:> Ich sehe es erst jetzt:> Muss es nicht PORTA, PORTB oder so heißen?
Du weißt doch nicht mal um welchen Controller es geht. Spielt für die
Frage auch keine Rolle. Außerdem kann er seine Variablen und Makros
nennen wie er will.
Johannes Hofmann schrieb:> aber da meckerte mir der Compiler rum.
Aha, die Fehlermeldung lautet also:
"main.c:19: error: Der Compiler meckert rum"
Noch nie was von Copy&Paste gehört?
Johannes Hofmann schrieb:> PORT = 0b00001110
Abgesehen davon, daß Du vermutlich PORTF meinst, und das Semikolon am
Zeilenende vergessen haben wirst:
In C gibt es keine "Binärschreibweise". Das "0b"-Präfix ist eine
proprietäre Erweiterung mancher Compiler -- und sollte daher
vermieden werden.
Die Binärschrbeiweise kennt IAR nicht. Aber du kannst dir auf der
Homepgae Files runterladen, in denen die Makros für 8, 16 und 32 Bit
definiert sind. Musste nur einbinden, dann geht es. Sparste dir das
selber anlegen der 65536 Makros bei 16Bit... vielleicht war ja auch
32Bit dabei :-) ?
Dennis schrieb:> Aber du kannst dir auf der Homepgae Files runterladen, in denen die> Makros für 8, 16 und 32 Bit definiert sind.
Man könnte sich ja auch mal drei Tage nacheinander jeweils 10 Minuten
lang hinsetzen und die 16 Bitwerte für ein Nibble lernen.
Dann kann man Hexzahlen lesen, und muss nicht auf fehlerträchtige
Binärdarstellungen ausweichen.
Fehlerträchtig, ja:
0b000010000000001 ist halt nicht das gleiche wie 0b0000100000000001.
Da muss man schön viele Nullen zählen, um den Unterschied zu sehen.
0x0401 und 0x0801 sind irgendwie auffälliger unterschiedlich, nicht?
Da findest du entsprechende Makros zur Umrechnung. Man braucht übrigens
für 16-Bit-Konstanten keine 2**16 Makros, ein einziges genügt schon.
Aber wie schon geschrieben wurde: Binärkonstanten bringen mehr Nachteile
als Vorteile, und kein halbwegs erfahrener Embedded-Programmierer will
sie. Deswegen sind sie nicht einmal im allerneuesten C-Standard (C11)
vorgesehen.
Hexadezimal- und (in selteneren Fällen) Oktaldarstellung sind vollkommen
ausreichend.
Yalu X. schrieb:> Aber wie schon geschrieben wurde: Binärkonstanten bringen mehr Nachteile> als Vorteile, und kein halbwegs erfahrener Embedded-Programmierer will> sie.
Naja. Man soll nie „nie“ sagen … ich habe sie auch schon benutzt:
1
/*
2
* Diagnostic patterns.
3
*/
4
staticconstsegment_bitssbits[]PROGMEM=
5
{
6
// a aaaaaaaa aaaa aaaaaaaa aaaaa
7
// aaaaa1 11112222 2333 a 33322222 11111aaa
8
// xx135791 35791357 9135xxx2 42086420 86420864
9
{0b00000000,0b00000000,0b00000000,0b00000000,0b00000000},/* all off */
10
{0b00111111,0b11111111,0b11110001,0b11111111,0b11111111},/* all on */
Wäre hexadezimal nicht so übersichtlich.
> Deswegen sind sie nicht einmal im allerneuesten C-Standard (C11)> vorgesehen.
Das ist eher Ignoranz des C-Standard-Gremiums gegenüber popeligen
Embedded-Programmierern. Im C99 Rationale steht dazu lapidar, dass
der entsprechende Vorschlag “due to lack of precedence and
application” nicht mit aufgenommen worden war. Nun, da GCC das
offziell übernommen hat, können sie zumindest keinen “lack of
precedence” mehr konstatieren, wenn das mal wieder jemand aufs
Tablett legt.
Yalu X. schrieb:> Da findest du entsprechende Makros zur Umrechnung. Man braucht übrigens> für 16-Bit-Konstanten keine 2**16 Makros, ein einziges genügt schon.
Das ist ok, es gibt aber auch Lösungen im Netz per h.file, da werden 256
Konstanten definiert - aber dann muss man sich ganz genau an die
Schreibweise halten, und 16 Bit gibts eh nicht.
Gruss Reinhard
Jörg Wunsch schrieb:> Wäre hexadezimal nicht so übersichtlich.
Mag sein. Allerdings (vielleicht liegt an meinen Augen) fällt es mir
schwer, mit einem Blick zu erkennen, wo denn nun überall die 1-Bits
sind. Insofern ist der Vorteil für mich persönlich eher gering, da ich,
um diese Bitmuster zu verstehen, sowieso Zeile für Zeile abscannen
müsste.
Man könnte das Ganze auch ohne Verwendung von Binär- und Hexzahlen so
schreiben:
1
#define BITS(b) { \
2
(uint8_t)((b) >> 32), \
3
(uint8_t)((b) >> 24), \
4
(uint8_t)((b) >> 16), \
5
(uint8_t)((b) >> 8), \
6
(uint8_t)((b) >> 0) }
7
8
#define BIT(n) BITS(1ULL << (n))
9
#define BIT_RANGE(b, n) (((1ULL << n) - 1) << b)
10
11
#define BITS_NONE BIT_RANGE( 0, 0)
12
#define BITS_ALL_EVEN BIT_RANGE( 0, 17)
13
#define BITS_ALL_ODD BIT_RANGE(20, 18)
14
#define BITS_ALL (BITS_ALL_EVEN | BITS_ALL_ODD)
15
16
staticconstsegment_bitssbits[]PROGMEM={
17
BITS(BITS_NONE),BITS(BITS_ALL),
18
BITS(BITS_ALL_EVEN),BITS(BITS_ALL_ODD),
19
BIT(37),BIT(16),
20
BIT(36),BIT(0),
21
BIT(35),BIT(1),
22
BIT(34),BIT(2),
23
BIT(33),BIT(3),
24
BIT(32),BIT(4),
25
BIT(31),BIT(5),
26
BIT(30),BIT(6),
27
BIT(29),BIT(7),
28
BIT(28),BIT(8),
29
BIT(27),BIT(9),
30
BIT(26),BIT(10),
31
BIT(25),BIT(11),
32
BIT(24),BIT(12),
33
BIT(23),BIT(13),
34
BIT(22),BIT(14),
35
BIT(21),BIT(15),
36
BIT(20)
37
};
Für meine (schlechten) Augen wird dadurch auch die Systematik etwas auch
deutlicher.
Yalu X. schrieb:> Für meine (schlechten) Augen wird dadurch auch die Systematik etwas auch> deutlicher.
Ja, das ist gut zu lesen.
Der wesentliche Punkt der Binärschreibweise war, dass ich von den
Kommentaren darüber ausgehend die Einsen gesetzt habe. Also erstmal
im Editor ein Array angelegt, in dem alle Konstanten als 0b00000000
drin standen, und dann Zeile für Zeile die Einsen entsprechend der
Anodenreihenfolge (es geht um eine VFD-Ansteuerung) im Kommentar
gesetzt.
Es ging also eher um Schreibbarkeit denn Lesbarkeit. ;-)
Jörg Wunsch schrieb:> Es ging also eher um Schreibbarkeit denn Lesbarkeit. ;-)
Ok :)
Die Binärschreibweise ist aus dem gleichen Grund auch ganz praktisch zur
Definition von Zeichensätzen für Matrix-Displays. Besser lesbar wäre das
Ganze allerdings, wenn man statt 0b11001010 auch 0b11__1_1_ o.ä.
schreiben könnte.
In C++ kann man auch ein Stringliteral (z.B. "##--#-#-") von einem Makro
in eine Integerzahl umwandeln lassen. In C geht das leider (noch) nicht,
weil dort "##--#-#-"[3] nicht als konstanter Ausdruck angesehen wird.
Yalu X. schrieb:> Besser lesbar wäre das Ganze allerdings, wenn man statt 0b11001010 auch> 0b11__1_1_ o.ä. schreiben könnte.
Ja, das würde auch bei langen Dezimalzahlen zuweilen helfen. Statt
14745600 also 14_745_600.
Wer formuliert den Vorschlag für die WG14? ;-)