Bitfeld funktioniert nicht

[Pascal (Gast)]

Hallo,

wollte nach meinem Beitrag zur Maststeuerung 
(Beitrag "Wendeschützsteuerung über Atmel ansteuern") nun mein 
Eingangssignalabbild in ein Bitfeld legen, dazu habe ich es deklarieren 
wollen gemäß:

  union {
    struct {
     unsigned char fUP:1;
     unsigned char fUPPER:1;
   unsigned char fDN:1;
   unsigned char fLOWER:1;
   unsigned char fPUSHER:1;
   unsigned char fSIG:1;
    };
    uint8_t a
  } flags_inputs;


aber leider will mein Compiler das nicht haben. Was mache ich da falsch?
Oder lege ich ein Eingangssignalabbild irgendwie anders und besser ab um 
es dann mit if oder switch/case zu verarbeiten?

Mfg
Pascal

[Karl H. (kbuchegg)]

Pascal wrote:

> aber leider will mein Compiler das nicht haben.

Dein Compiler wird ja wohl kaum als Ausgabe haben:

ERROR 007: Das will ich nicht haben.

Also: Wie lautet die Fehlermeldung?

> Oder lege ich ein Eingangssignalabbild irgendwie anders und besser ab um
> es dann mit if oder switch/case zu verarbeiten?

Bitfelder sind so schon in Ordnung. Persönlich mag ich sie nicht
so gerne, weil man leicht übersieht, was da eigentlich im Hintergrund
für ein Aufwand getrieben werden muss, um die einzelnen Bits
ansprechen zu können.

Ich mach gerne folgende Variante, wenn ich denn unbedingt ein
paar Bytes einsparen muss:

#define fUP     0x01
#define fUPPER  0x02
#define fDN     0x04
#define fLOWER  0x08
#define fPUSHER 0x10
#define fSIG    0x20

uint8_t flags_inputs;

#define SET(x)    ( flags_inputs |= (x) )
#define CLEAR(x)  ( flags_inputs &= ~(x) )
#define IS_SET(x) ( flags_inputs & (x) )

int main()
{
  SET( fUPPER );
  CLEAR( fSIG );

  if( IS_SET( fUP | fLOWER ) ) {
     ...
  }
}

Mir ist es aus irgendeinem Grund lieber, wenn ich sehen kann, was
da wirklich abgeht.
Mit der Bitfeld Lösung passiert im Grunde das Gleiche, nur erledigt
der Compiler die Bitmaskiererei im Hintergrund und damit für mich
nicht sichtbar.

[Falk B. (falk)]

@  Karl heinz Buchegger (kbuchegg)

>Mir ist es aus irgendeinem Grund lieber, wenn ich sehen kann, was
>da wirklich abgeht.

Me too!

>Mit der Bitfeld Lösung passiert im Grunde das Gleiche, nur erledigt
>der Compiler die Bitmaskiererei im Hintergrund und damit für mich
>nicht sichtbar.

Eben. Dann gibts nicht so böse Überraschungen wie hier.

Beitrag "Re: Little oder Big Endian im mega64?"

MFG
Falk

P.S. Dein Posting ist mal wieder druckreif. Du solltest das in einen 
Wikiartikel überführen, damit er der Nachwelt erhalten bleibt und man 
ihn schnell findet.

[Pascal (Gast)]

Hi,

das ist auch eine feine Idee von Dir.
Also der Compiler sagt immer wieder:

../main.c:71: error: request for member 'fUP' in something not a 
structure or union

usw.

Verstehe ich nicht.

Pascal

[Jörg W. (dl8dtl) (Moderator)]

Der Bitfield-Teil deiner union hat keinen Namen, folglich kannst du
darauf nicht zugreifen.

[Pascal (Gast)]

Hallo OM,

hab ich nun ein Brett vorm Kopf ;) ??
Hab dem doch den Namen flags_inputs gegeben? Oder sehe ich da irgendwas 
falsch? Man, ist schon länger her mit meiner C-Praxis...

Danke,
Grüße Pascal


Was für ein Buch wäre denn mal zum Auffrischen von C zu empfehlen, am 
besten in Bezug auf AVRs...

[Falk B. (falk)]

@ Pascal (Gast)

>hab ich nun ein Brett vorm Kopf ;) ??
>Hab dem doch den Namen flags_inputs gegeben? Oder sehe ich da irgendwas
>falsch? Man, ist schon länger her mit meiner C-Praxis...

Poste mal vollständigen Quelltext als Anhang.

>Was für ein Buch wäre denn mal zum Auffrischen von C zu empfehlen, am
>besten in Bezug auf AVRs...

Das Tutorial hier ist spitze. Grundlegende C-Fragen klärt jedes C-Buch.

AVR-GCC-Tutorial

MfG
Falk

[Pascal (Gast)]

So, hier mal die Datei... Ist aber noch lange nicht fertig. Nur weil es 
hier schon klemmt hab ich auch erstmal eine Pause gemacht.

Danke für Tipps und Infos.

Grüße Pascal

[Andreas K. (a-k)]

@Jörg: GCC kommt mit der anonymen struct klar, solange man ihn nicht auf 
"Standard" schaltet. Und dann heisst die Meldung anders.

[Andreas K. (a-k)]

Entweder
  flags_inputs.fUP = 0;
oder
  flags_inputs.a = 0;

[Falk B. (falk)]

Aus organisatorischn gründen würde ich Variablendeklaratione und stucts 
immer an den Anfang einer Funktion schreiben. Der Fehler ist aber AFAIK 
ein anderer

  union {
    struct {
     unsigned char fUP:1;
     unsigned char fUPPER:1;
   unsigned char fDN:1;
   unsigned char fLOWER:1;
   unsigned char fPUSHER:1;
   unsigned char fSIG:1;
    };
    uint8_t a
  } flags_inputs;

  flags_inputs.a.fUP = 0;
  flags_inputs.a.fUPPER = 0;
  flags_inputs.a.fDN = 0;
  flags_inputs.a.fLOWER = 0;
  flags_inputs.a.fPUSHER = 0;
  flags_inputs.a.fSIG = 0;

flags_inputs.a.fUP

gibt es gar nicht! das muss

flags_inputs.fUP = 0;

heissen.

MFG
Falk

[Andreas K. (a-k)]

Komisch finde ich allerdings, dass der Compiler die Zeile
  uint8_t a
frisst. Da fehlt nämlich was.

[Markus V. (valvestino)]

>Komisch finde ich allerdings, dass der Compiler die Zeile
>  uint8_t a
>frisst. Da fehlt nämlich was.

Sehe ich auch so.

[Frank B. (frank_b)]

Wenn ich z.b. hier gucke

http://www.csci.csusb.edu/dick/samples/c.syntax.html#Statements

sehe ich nicht, dass ein Semikolon an dieser Stelle erforderlich wäre.
Es ist eine Expression, mit nachfolgendem Blockende.

Der Compiler hat demnach recht, das nicht anzumeckern.

Oder irre ich mich ?

lg, Frank

Edit: Ich irre mich, lol. Ist keine Expression. Ausserdem kommt eine 
"Warning".
Schande auf mein Haupt :-)

[Rolf Magnus (Gast)]

> Es ist eine Expression, mit nachfolgendem Blockende.

... an einer Stelle, an der ein statement erwartet wird. In diesem Fall 
wäre es also ein expression_statement, das aus einer expression, gefolgt 
von einem Semikolon, besteht.

[Rolf Magnus (Gast)]

> Ist keine Expression.

Das außerdem.

[Jörg W. (dl8dtl) (Moderator)]

Es ist weder expression noch statement.  Es passiert alles innerhalb
einer Definition, aber ja, das Semikolon gehört da hin.

[Frank B. (frank_b)]

Jaja, schon gut, habs ja längst eingesehen :-)

lg, Frank