Port/Pin-deklaration

OP #1196502
Hallo

Im GCC-Tutorial ist die Deklaration ja so gelöst:
1
    DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

Nun meine Frage, ob man es auch in etwa so schreiben könnte:
1
  DDRB.1=0;
2
  DDRB.2=1;
3
    .
4
    .
5
  DDRB.7=0;
Einfach nur der Übersicht halber, damit ich das für mich schön 
auskommentieren kann, was an welchem Pin hängt.

Danke Euch!
#1196515
Johannes Hofmann wrote:
>
1
>   DDRB.1=0;
2
>   DDRB.2=1;
3
>     .
4
>     .
5
>   DDRB.7=0;
6
>
Das ist nicht standardkonform und wird vom GCC so nicht unterstützt. Man 
kann sich das über ein Bitfeld zwar selber "bauen", aber die im Tutorial 
benutzte Methode ist die ANSI-C-konforme und sollte auch benutzt werden.

Siehe auch Bitmanipulation
#1196516
Johannes Hofmann wrote:
> Hallo
>
> Im GCC-Tutorial ist die Deklaration ja so gelöst:
>
>
1
    DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) |
2
> (1 << DDB4);
>
> Nun meine Frage, ob man es auch in etwa so schreiben könnte:
>
>
1
>   DDRB.1=0;
2
>   DDRB.2=1;
3
>     .
4
>     .
5
>   DDRB.7=0;
6
>

könnte man, wenn dein Compiler (IAR?) die .-Snytax für Ports 
unterstützt. Der gcc machts nicht.

Aber selbst dann: Was hindert dich, das so zu formatieren:
1
      DDRB = (1 << DDB0) |      // Led an Pin 0
2
             (1 << DDB1) |      // noch ne Led an Pin 1
3
             (1 << DDB2) |
4
             (1 << DDB3) |
5
             (1 << DDB4);

> Einfach nur der Übersicht halber, damit ich das für mich schön
> auskommentieren kann, was an welchem Pin hängt.

Wenn du das kommentieren willst, dann gib den Pins zb per #define schöne 
Namen
1
#define PERIPHERY_DDR        DDRB
2
#define PERIPHRY_PORT        PORTB
3
#define ALARM_LED_PIN        PB0
4
#define READY_LED_PIN        PB1
5
#define BUZZER_PIN           PB2
6

7

8
int main()
9
{
10
  PERIPHERY_DDR =   ( 1 << ALARM_LED_PIN )
11
                  | ( 1 << READY_LED_PIN )
12
                  | ( 1 << BUZZER_PIN );
13

14
  PERIPHERY_PORT = ( 1 << READY_LED_PIN );
15

16
  ...
17

18
}


Das Ziel ist es immer, den Code so zu gestalten, dass du nach 
Möglichkeit keinen zusätzlichen Kommentar brauchst. Dann kann auch der 
Kommentar nie falsch sein und bei Änderungen nicht mehr zum Code passen.

Ganz abgesehen davon, dass du bei Hardwareänderungen (der Buzzer wandert 
vom Pin PB2 zum Pin PB5) nur mehr an einer Stelle ändern musst und der 
Rest des Programms passt sich bei einem Neukompilieren ganz von alleine 
an.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.