Knut B. schrieb:
> Ich finde PORTB5 weitaus intuitiver als PB5. Mir gefällt diese
> Schreibweise deutlich besser, da sie auch bei größeren und neueren
> Controllern zum Einsatz kommt. Abkürzungen sind nicht immer sinnvoll,
> schon gar nicht, wenn sie nur aus 3 Charaktern bestehen.
Aber wenn es sich um bits handelt ist es doch vollkommen egal, ob
PB5 oder PC6 oder PORTA4.
Am sinnvollsten wäre es gewesen, einfach b0..b7 zu definieren und dann
nur diese zu benutzen, also:
1 | PORTB &= ~(1 << b5);
|
2 | PORTC &= ~(1 << b6);
|
Und auch das nur, damit man weiss, dass es sich um eine Bitoperation
handelt und das man genau diese bits setzen oder löschen wollte.
Weder PB5 noch PORTB5 haben irgendetwas mit PORTB zu tun, bezeichnen
nur die bitwertigkeit.
Auch folgendes funktioniert:
1 | uint8_t DummyVar = 85;
|
2 | DummyVar |= (1<<PB5);
|
Und natürlich auch dieses:
Anstatt diese Bitdefinitionen für jeden Port und fast alle Register
dumm zu wiederholen, wäre eine einzige Definition am Anfang völlig
ausreichend, für alle CPUs.
Wenn es so ginge:
1 | PORTB5 = true; // oder _ON
|
2 | PORTD4 = false; // oder _OFF
|
dann wäre es noch irgendwie logisch.
Somit ist PORTB5 genauso überflüssig und verwirrend wie z.B. GPIOR24,
_UBRR0 aber dafür UBRR3 (ohne Unterstrich).
Nach dieser Logik müsste es auch UBRR0H1 geben, aber nein, beim
ATMEL ist das UBRR9.
Aber ATMEL wäre nicht ATMEL wenn es logisch wäre...
P.S.
Natürlich ist z.B. TXCIE oder UDRE sinnvoll und nötig, aber jeder, der
diese dumme und überflüssige RegisterOderPortnamenBitbezeichnungen
benutzt, ist selber schuld wenn sein Programm beim nächsten Typ nicht
compiliert wird.
Thread beobachten
Seitenaufteilung abschalten