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
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:
1 | #define fUP 0x01
|
2 | #define fUPPER 0x02
|
3 | #define fDN 0x04
|
4 | #define fLOWER 0x08
|
5 | #define fPUSHER 0x10
|
6 | #define fSIG 0x20
|
7 | |
8 | uint8_t flags_inputs; |
9 | |
10 | #define SET(x) ( flags_inputs |= (x) )
|
11 | #define CLEAR(x) ( flags_inputs &= ~(x) )
|
12 | #define IS_SET(x) ( flags_inputs & (x) )
|
13 | |
14 | int main() |
15 | {
|
16 | SET( fUPPER ); |
17 | CLEAR( fSIG ); |
18 | |
19 | if( IS_SET( fUP | fLOWER ) ) { |
20 | ...
|
21 | }
|
22 | }
|
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.
@ 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.
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
Der Bitfield-Teil deiner union hat keinen Namen, folglich kannst du darauf nicht zugreifen.
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...
@ 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
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
@Jörg: GCC kommt mit der anonymen struct klar, solange man ihn nicht auf "Standard" schaltet. Und dann heisst die Meldung anders.
Aus organisatorischn gründen würde ich Variablendeklaratione und stucts immer an den Anfang einer Funktion schreiben. Der Fehler ist aber AFAIK ein anderer
1 | union { |
2 | struct { |
3 | unsigned char fUP:1; |
4 | unsigned char fUPPER:1; |
5 | unsigned char fDN:1; |
6 | unsigned char fLOWER:1; |
7 | unsigned char fPUSHER:1; |
8 | unsigned char fSIG:1; |
9 | };
|
10 | uint8_t a |
11 | } flags_inputs; |
12 | |
13 | flags_inputs.a.fUP = 0; |
14 | flags_inputs.a.fUPPER = 0; |
15 | flags_inputs.a.fDN = 0; |
16 | flags_inputs.a.fLOWER = 0; |
17 | flags_inputs.a.fPUSHER = 0; |
18 | flags_inputs.a.fSIG = 0; |
1 | flags_inputs.a.fUP |
gibt es gar nicht! das muss
1 | flags_inputs.fUP = 0; |
heissen. MFG Falk
Komisch finde ich allerdings, dass der Compiler die Zeile uint8_t a frisst. Da fehlt nämlich was.
>Komisch finde ich allerdings, dass der Compiler die Zeile > uint8_t a >frisst. Da fehlt nämlich was. Sehe ich auch so.
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 :-)
> 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.
Es ist weder expression noch statement. Es passiert alles innerhalb einer Definition, aber ja, das Semikolon gehört da hin.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.