Hallo,
ATmega8 / AVR Studio / C
ich habe eine "integer-Strukture" wie folgt initialisiert:
union
{
int integer;
struct
{
int SV0 :1;
int SV1 :1;
int SV2 :1;
int SV3 :1;
int SV4 :1;
int SV5 :1;
int SV6 :1;
int SV7 :1;
int SV8 :1;
int SV9 :1;
} bit;
} SentVector;
Und greife auf ihre Elemente so zu:
SentVector.integer = 0b1000000000000000;
SentVector.bit.SV2 = 1;
Der Compiler meldet nichts an dieser Stette, und die Fachmänner? Ist es
alles ok?
Danke für Eure Meinung, Grüße
Michal
Michal schrieb:
> Der Compiler meldet nichts an dieser Stette, und die Fachmänner? Ist es> alles ok?
Wie 'gesetzteskonform' willst du es wissen :-)
Ist schon ok.
( :-) Wobei ich mich frage, wie der Compiler eine 1-Bit Variable mit
einem Vorzeichen realisiert )
(man darf seinen Quelltext hier auch gerne als C formatiert
reinkopieren, dann ist es auch lesbar...)
Das Thema taucht hier öfter auf.
Viele finden es so toll, mir gefällt es auch nicht.
Leider muß man zur Vermeidung etwas tricksen.
Die eine Variante ist, sich passende Makros zu definieren in der
Art SETBIT( PORTB, 1 ) o.s.ä..
Ich fände es eleganter, über den jeweiligen Port eine struct
mit Bitfeldern zu legen (ähnlich deiner obigen) und dann über
die Bitfelder die Bits anzufassen.
Jede Methode hat Vor- und Nachteile, und keine wird allen gefallen.
Richtig elegant geht es in C mit AVR leider nicht.
(Etwas schicker könnte man es in C++ machen, aber das ist
sicher auch nicht mehrheitsfähig.)
Hier bricht ganz einfach diese bitweise Betrachtung zusammen und ist
umständlicher, als wenn man die Betrachtung anstellt:
Hier ein Byte, dort 2 Empfägerbytes.
Wie muss ich schieben und maskieren um die gewünschten Bits
auf die Empfänger zu verteilen.
.. Ih habe kürzlich auch gelernt, daß man bei einem Union nicht eine
Variable schreiben, und anschliessend eine andere, überlappende, lesen
sollte. Das ist nämlich undefiniert. Jedenfalls in C (ich liebe Pascal
;-) ). Und es gibt tatsächlich derzeit einen BUG in AVR-GCC der
verhindert, daß es unter allen Umständen funktioniert.
Kurz gesagt, falls du das vorhattest: Vermeide es. Wirf die ganze Union
weg, die brauchst du sowieso nicht.
Michal schrieb:
> Ok, dann glaube ich doch dass meine Lösung doch übersichtlich ist und so> bleibt...
Und ich glaube, dass du den Aufwand scheust, dich in Bitmanipulationen,
Schiebereien, Maskierungen etc. einzuarbeiten :-)
1
tmp=PORTB&~(0x3E);
2
tmp|=(SentVector.integer&0x1F)<<1;
3
PORTB=tmp;
4
5
tmp=PORTC&~(0x1F);
6
tmp|=(SentVector.integer>>5)&0x1F;
7
PORTC=tmp;
Das hat dann auch den Vorteil, dass zumindest die Pins an einem Port
(nahezu) gleichzeitig neu gesetzt werden. Wenn an den Pins Hardware
hängt, die auf Flanken reagiert, kann das wichtig sein.
Nein, geschoben und maskiert habe ich schon, dabei aber:
man kriegt schnell dieselbe Zeilenanzahl,
die aber nicht so regulär und leicht zu lesen sind wie diese 10 fast
identische.
Und ich kann die Pins beim Device-Wechsel schneller anpassen.
@Krishna: komisch, in einem Paper auf Atmel-Website werden struct
empfohlen!
UNIONs auch ?
Für diesen Zweck ?
Egal, Fakt ist, es gibt diesbezüglich einen BUG AVR-GCC.
Ob der bei Deinem speziellem Fall zum Tragen kommen würde, weiß ich aber
nicht.
Aber google mal nach "union" und undefiniertes Verhalten.
Dann ist wenigstens nicht die ganze Performance beim Teufel
> @Krishna: komisch, in einem Paper auf Atmel-Website werden struct> empfohlen!
Structs mag sein.
Aber unions haben laut Sprachstandard mit einer derartigen Verwendung
meistens undefiniertes Verhalten (drum habe ich auch am Anfang gefragt
"wie genau du es wissen willst" :-)
Was man sich bei der struct-in-union-Geschichte bewusst machen
sollte, ist daß es nicht geregelt ist, in welcher Reihenfolge die
:1-Bits den Stellen in der int zugeordnet werden.
Das kann der Compiler machen wie er will, und insofern ist
das Programm nicht portabel.
Ich würde mich aber davon nicht irritieren lassen; der gcc
macht es in der Reihenfolge wie erwartet und portabel ist das
Programm sowieso nicht, wenn eine Zeile weiter auf AVR-Register
Bezug genommen wird.
In diesem Fall würde ich also nicht davon abraten.
Der Hinweis auf "undefiniertes Verhalten" ist aber berechtigt,
wenn man den Quelltext mal auf einem anderen System verwenden
will.
Michal schrieb:
> Bin ich so an der sicheren Seite?
Ja.
Mach dir ein paar Makros (inline Funktionen wären besser)
#define SET_BIT(where,which) ((where) |= (1<<(which)))
#define CLR_BIT(where,which) ((where) &= ~(1<<(which)))
#define IS_SET(where,which) ((where) & (1<<(which)))
was anderes macht der Compiler auch nicht.
Auch der Compiler muss letztendes den Einzelbitzugriff mit Maskieren und
Schieben implementieren
