Elegante Pinabstraktion

[Franz (Gast)]

Hallo,

ich möchte meinen code etwas übersichtlicher und wartbarer machen.
Ich habe ein LCD Display an meinen XMega angeschlossen und möchte nun 
die einzelnen Leitungen benennen.

Beispiel: Für die LEDOff Leitung des LCDs welche die Beleuchtung steuert 
möchte ich
#define LCD_LED PA0

um anschließend im Code wie folgt die Beleuchtung steuern zu können

LCD_LED = 1;

Ist das überhaupt möglich?

Gruß Franz

[Phil J. (sunflower_seed)]

Ja in dem du Makros im Präprozessercode anlegst.
Beitrag "einzelne Prozessorpins per #define Ansprechen (ATmega16) AVR"

[Franz (Gast)]

Du hast mich nicht richtig verstanden.

Ich möchte die pins nur "Maskieren"

nicht nur für
LCD_LED = 1
sondern auch für
if(LCD_LED == 1)
{


Gruß Franz

[Franz (Gast)]

nichtmal

#define LCD_cmd  PORTA
#define LCD_nRST 0

LCD_data |= (1 << LCD_nRST);

funktioniert obwohl man es über die suche oft so findet.

invalid operands to binary & (have 'PORT_t' and 'int')

Kann mir niemand helfen?

Gruß Franz

[Ralf G. (ralg)]

da gibt's noch sowas:
Beitrag "Variablenwert(0/1) einem Ausgangspin zuordnen"

[MW (Gast)]

Hier ein paar Möglichkeiten:

http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass

[Rudi M. (rudimentaer)]

Franz schrieb:
> ... hast mich nicht richtig verstanden.
im ersten Teil hattest Du nichts anderes gefragt

> nicht nur für
> LCD_LED = 1
> sondern auch für
> if(LCD_LED == 1)

Codevision kann das. Macht den Code leider nicht besonders portierbar 
aber schön übersichtlich.

Rudi

[Verwirrter Anfänger (Gast)]

Franz schrieb:
> nichtmal
>
> #define LCD_cmd  PORTA
> #define LCD_nRST 0
>
> LCD_data |= (1 << LCD_nRST);
>
> funktioniert obwohl man es über die suche oft so findet.
>
> invalid operands to binary & (have 'PORT_t' and 'int')
>
> Kann mir niemand helfen?
>
> Gruß Franz

Das versteh ich nicht ganz, LCD_data ist nirgendwo definiert.

#define LCD_DATA PORTA
#define LCD_NRST PA0

LCD_DATA |= (1 << LCD_NRST);

sollte aber funktionieren.

[Achim M. (minifloat)]

Verwirrter Anfänger schrieb:
> #define LCD_DATA PORTA
> #define LCD_NRST PA0

es gäbe da auch noch:

#define LCD_NRST_SET() LCD_DATA|=LCD_NRST
#define LCD_NRST_CLR() LCD_DATA&=~LCD_NRST

//und schon heißt es im Code
LCD_NRST_CLR();
//und spaeter
LCD_NRST_SET();

Sollte auch jeder anständige C-Compiler mit klarkommen. Nicht sowas wie 
"sieht schön aus aber geht nur bei IAR"...
mfg mf

[Achim M. (minifloat)]

Es muss beim den üblichen AVR-defines natürlich heißen:

#define LCD_NRST_SET() LCD_DATA|=(1<<LCD_NRST)
#define LCD_NRST_CLR() LCD_DATA&=~(1<<LCD_NRST)

mfg mf

[Sven P. (Gast)]

Für GCC, Verwendung:

#define SOME_PORT BITWISE_CHAR(PORTD, 3)

/* ... */
SOME_PORT = 1;
if (SOME_PORT == 1)
  ;

[Achim M. (minifloat)]

Mini Float schrieb:
>  Nicht sowas wie "sieht schön aus aber geht nur bei IAR"...

Sven P. schrieb:
> Für GCC

Und auch nicht sowas wie "sieht schön aus aber geht nur mit GCC"...

Aber gut, wenn ihr nicht wollt, dass euer Code portabel ist, dann eben 
nicht.
mfg mf

[Sven P. (Gast)]

Mini Float schrieb:
> Aber gut, wenn ihr nicht wollt, dass euer Code portabel ist, dann eben
> nicht.
Über 'Portabilität' kann man sich in diesem Fall nun freilich drüber 
streiten...

[Sven P. (Gast)]

Mit noch mehr Präprozessor kann man es portabel eindampfen:

#ifndef IO_H
#define IO_H

#include <avr/io.h>

/* IO ports */
#define IO_STRAIGHT    0
#define IO_INVERT      1

#define BUZZER    B, B1, IO_STRAIGHT
#define RELAIS    B, B5, IO_STRAIGHT

#define __IO_SET(port, bit, invert, state)      \
  if ( (invert) ^ ((state) ? 1 : 0) ) {         \
    PORT##port |= _BV(PORT##bit);               \
  }                                             \
  else {                                        \
    PORT##port &= ~_BV(PORT##bit);              \
  }

#define __IO_GET(port, bit, invert)             \
  ( (PORT##port & _BV(PORT##bit)) ? (1 ^ (invert)) : (0 ^ (invert)) )


#define IO_SET(port, state)    __IO_SET(port, state)
#define IO_GET(port)           __IO_GET(port)

#endif

Verwendung:

IO_SET(BUZZER, 1);
IO_SET(RELAIS, 0);

Und bitte, keine weiteren Kommentare dazu :-}

[(prx) A. K. (prx)]

Sven P. schrieb:

> Mit noch mehr Präprozessor kann man es portabel eindampfen:

Inwiefern ist io.h eigentlich essentiell abhängig von GCC? Das 
Inline-Verbot ist für die Frage hier irrelevant und die structs müssten 
eigentlich auch ohne "packed" schon frei von Löchern sein. Der Rest ist 
normales C.

Dass Bitfields allgemein als schwach portabel gelten ist klar, aber ganz 
so schlimm ist es dann doch nicht, wenn man damit Portpins anspricht und 
damit die Architektur sowieso festnagelt.

[Rolf M. (rmagnus)]

Franz schrieb:
> nichtmal
>
> #define LCD_cmd  PORTA
> #define LCD_nRST 0
>
> LCD_data |= (1 << LCD_nRST);
>
> funktioniert obwohl man es über die suche oft so findet.

Dann versuch's doch mal mit:

 LCD_cmd |= (1 << LCD_nRST);

> invalid operands to binary & (have 'PORT_t' and 'int')

Da in dem Code gar kein & vorkommt, muß da wohl ein falsches Makro 
irgendwas seltsames tun.

[Sven P. (Gast)]

A. K. schrieb:
> Inwiefern ist io.h eigentlich essentiell abhängig von GCC? Das
> Inline-Verbot ist für die Frage hier irrelevant und die structs müssten
> eigentlich auch ohne "packed" schon frei von Löchern sein. Der Rest ist
> normales C.
Naja, das ist eigentlich der einzige Knackpunkt.

> Dass Bitfields allgemein als schwach portabel gelten ist klar, aber ganz
> so schlimm ist es dann doch nicht, wenn man damit Portpins anspricht und
> damit die Architektur sowieso festnagelt.
Darauf zielte ich nämlich weiter oben schon ab. Einen Abstraktionslayer 
zu abstrahieren, ist ziemlich sinnfrei. Irgendwo muss man ja an die 
Hardware anbauen.

Reine Lehre wäre dann wohl nur die vollständige Kapselung in Methoden, 
sodass man schlimmstenfalls noch mit etwas Programmlogik nachhelfen 
kann, wenn die Zuordnung der Ports nicht mehr direkt gegeben ist.

[Peter D. (peda)]

Franz schrieb:
> Du hast mich nicht richtig verstanden.
>
> Ich möchte die pins nur "Maskieren"
>
> nicht nur für
> LCD_LED = 1
> sondern auch für
> if(LCD_LED == 1)
> {

Geht doch.
Wie kommst Du darauf, das das nicht gehen soll?

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=835728#835728


Peter