4 Einzelbytes --> 32-bit Variable?

@Peter: umgekehrt - R4 soll das Highbyte sein usw...

So, endlich konnte ich eure Diskussionsbeiträge testen.
Es funktioniert wie folgt:

unsigend long x = ((unsigend char) PINC)|((unsigned 
int)TCNTL3<<8)|((unsigned long)TCNT3H<<16)|((unsigned long)R4<<24);

Diese Funktion ist aber nur die halbe Wahrheit. Ich habe die
Counterregister TCNT3L und TCNT3H zuerst in Variablen 
zwischengespeichert, und zwar erst das L-Byte und dann das H-Byte.

Aber dennoch, es gibt Probleme mit dem Auslesen der Counterregister.
Dazu werde ich im Forum 'Allgemein' einen Thread schreiben.

Erstmal vielen Dank für eure Hilfe    Norbert

für sowas ähnliches hab ich das mit einem union gelöst. Ist meiner 
Meinung nach wesentlich eleganter als diese Bitschieberei und zudem 
wesentlich performanter, da ja die 32-Bit Variable und eine Struktur mit 
4 chars den selben Speicherplatz belegen, d.h. nicht mehr umgelagert 
werden müssen.

Also z.B.

struct irgendwas
{
unsigned char highbyte;
unsigned char middle1;
unsigned char middle0;
unsigned char lowbyte;
};

union xyz
{
struct irgendwas wasweissich;
unsigned long lange_variable;
};

usw. usf.
Gruss,

Peter

alternativ ginge es auch so:

struct
{
unsigned long int lowbyte:8;
unsigned long int middle0:8;
unsigned long int middle1:8;
unsigned long int highbyte:8;
} lange_variable;

Gruss,

Peter

Setzt aber leider voraus, daß die Variablen hintereinander im Speicher 
stehen.

@schmittchen

> Setzt aber leider voraus, daß die Variablen hintereinander im Speicher stehen.

von welchen Variablen sprichst du? Ich kann dir leider an diesem Punkt 
nicht folgen, irgendjemand von uns beiden muss hier wohl etwas nicht 
richtig verstanden haben.

@P. Dannegger

> Der Code ist langsamer und größer, da Unions immer im RAM abgelegt werden.

Also ich weiss ja nicht woher du diese Annahme hast, aber da diese Sache 
mich persönlich sehr interessiert habe ich mir die Mühe gemacht und mal 
in meiner eigenen (umfangreichen) Literatur und auch im Internet 
recherchiert, irgendwas zu finden, dass deine Aussage belegen würde, -> 
Fehlanzeige.
Da ich jedoch weiss, dass solche Aussagen dann doch irgendwo bei den 
anderen Lesern im Hinterkopf auf einem gewissen "status quo" 
hängenbleiben, habe ich mir ganz einfach die Mühe gemacht und es an 
einem praktischen Beispiel mit dem avrgcc mal ausgetestet. Natürlich 
kann ich ein union mit dem Attribut register versehen und siehe da, es 
wurden auch entsprechend Register im übersetzten Code verwendet. Das 
Watch-Window des AVR-Studio belegte dies auch mit einer Anzeige des 
ersten Registers "(Reg) 24" und das Register-Window zeigte, dass die 
Register 24-27 bei meinem Versuch auch entsprechend bei einer Zuweisung 
genutzt wurden. Womit diese Behauptung nun wohl eindeutig widerlegt 
wäre.
> Eine Union aus verschiedenen Typen ist immer Compilerabhängig.

Diese Aussage ist so nicht ganz richtig. In einer durch einen C-Compiler 
angelegten Datenstruktur werden entsprechende Fraktionen immer in 
maschinenabhängig aufsteigender Werigkeit gefüllt. D.h. es ist abhängig 
davon, ob man sich auf einem big-endian oder einem little-endian System 
befindet.
Aber unabhängig davon, es dürfte doch wohl das geringste Problem sein, 
solch eine Frage einmalig in einem Versuch zu ermitteln, oder nicht?

Gruss,

Peter

Ich bin von Norberts Angaben ausgegangen. R4, TCNT3H, TCNT3L, PORTC 
liegen nicht im Speicher hintereinander. Deshalb kann keine Union 
darübergestülpt werden.... und extra nochmal eine Struktur (mit weiteren 
4 Bytes) zu verbrauchen, dachte ich zunächst sei auch nicht sinnvoll. 
ABER: Die mittels "|" zusammengestücktelte Variable verbraucht ja auch 
Speicher. Also alles wieder zurück.

> irgendjemand von uns beiden muss hier wohl etwas nicht richtig verstanden haben.
Hier, ich. :)

Schmittchen.

Hallo Namensvetter!

> Interessant wäre trotzdem, ob die OR-Verknüpfung nicht auch genau so optimal 
ist, wie die Union in Registern.

ok, aber diesmal bist du an der Reihe, den praktischen Test 
durchzuführen.

> Ich will nicht ausschließen, daß alle z.Z. verfügbare AVR-Compiler die gleiche 
Byteorder verwenden, aber vielleicht nimmt man ja Routinen auch mal auf anderen 
Maschinen, getreu dem Motto "C läuft überall".

Ok, hier hast du Recht, von solchen Konstrukten wird in Lehrbüchern 
abgeraten wenn es auf Portabilität des Codes ankommt.

> Mit der Byte-Order bin ich mal mächtig reingefallen und deshalb nehme ich das 
nie mehr.

Wenn das so ist, dürfte ich mich z.B. nie mehr mit Frauen befassen ;-)

Aber mal ehrlich, die Realität sieht doch etwas anders aus. Man lernt 
etwas dazu und macht halt eben das nächste Mal andere Fehler. Nicht 
wahr?

Mit :-) Gruss

Peter

> Aber welche Alternative hast Du zu Frauen ?

The System has detected an Internal Processing Error in module
REALITY.SYS.  Please shut down your universe and reboot.

Mehr fällt mir dazu nun auch nicht ein.

Gruss,

Peter