40 Bit in 5 Bytes abbilden mit Bitfeld

Mathias G. schrieb:
>

1

>   typedef struct

2

>   {

3

>     /* 2 byte */

4

>     uint16_t status_display;

5

>     /* 5 byte */

6

>     uint16_t left1:5;

7

>     uint16_t right1:5;

8

>     uint16_t left2:5;

9

>     /* erster uint16_t belegt, 1 bit unbenutzt */

10

>     uint16_t right2:5;

11

>     uint16_t left3:5;

12

>     uint16_t right3:5;

13

>     /* zweiter uint16_t belegt, 1 bit unbenutzt */

14

>     uint16_t left4:5;

15

>     uint16_t right4:5;

16

>     /* dritter uint16_t belegt, 6 bit unbenutzt */

17

>   }  __attribute__((gcc_struct)) tx_data;

18

>

Implementierung ist generell compilerabhängig.

> Alternative wäre natürlich maskieren und schiften. Würdet ihr das auf
> einem 32Bit ARM generell vorziehen?

Immer dann wenn du das genaue Bitlayout benötigst.

Mathias G. schrieb:
> Alternative wäre natürlich maskieren und schiften. Würdet ihr das auf
> einem 32Bit ARM generell vorziehen?

Ja. Selbst wenn Du es hinbekommst, dass Deine Bitfelder exakt Deine 
Datenstruktur abbilden: Die Datenkompaktheit ist compiler-abhängig, das 
Ganze ist nicht portabel und passt je nach Alignment des verwendeten µCs 
nur zufälltig. Aber das wichtigste: Um die Daten auseinanderzuklamüsern, 
muss der Compiler selbst auch maskieren und shiften. Es gibt also keinen 
echten Gewinn. Dann mach ich das lieber selbst und ich weiß, was ich 
habe.

nachdem das jetzt geklärt wäre, noch was anderes:

Mathias G. schrieb:
> }  __attribute__((gcc_struct)) tx_data;

... ich glaube nicht, daß das Attribut gcc_struct auf ARM irgendwas 
(geschweige denn, was Sinnvolles) tut. Das würd' ich weglassen.

Mathias G. schrieb:
> Eine Frage ich Suche nach einer Möglichkeit 40 Bit in 5 Byte
> unterzubringen

Die Frage ist, wozu man sich das antun will?
Wenn es nur darum geht, RAM zu sparen, dann würde ich das sein lassen 
und einfach je 3 Bits verschenken.

Wenn es darum geht, externe 5-Bit Schieberegister abzubilden, dann würde 
ich dafür eine Funktion schreiben, die ein 8Byte-Array entsprechend aufs 
SPI ausgibt. Diesen Schrunz durch das ganze Programm zu ziehen, würde 
ich sein lassen.

Wenn es ein 5*8 Font werden soll, einfach um 90° gedreht abspeichern, 
also 5 Byte je Zeichen.

Vielleicht hilft:
typedef __packed struct { };

Hallo,

Vielen Dank euch allen.
Also nein ist für einen Datenübertragung und da müssen die Bits leider 
so kompakt aneinander liegen - ich habe das Protokoll nicht gemacht.

"packed" habe ich natürlich auch probiert - bringt nicht wirklich was.

Ich werde es klassisch machen mit maskieren und schieben.

Danke

Volle schrieb:
> __attribute__((packed))
> [...]
> für Kommunikationsprotokolle sehr wichtig!

Es ist eher wichtig daß man die Protokolle so designed daß alle Felder 
self-aligned sind und sich ohne krumme Offsets zu ergeben lückenlos 
zusammenfügen lassen, oder mit anderen Worten: es ist sehr wichtig daß 
man es so entwirft daß das packed überhaupt keinen Unterschied machen 
würde. Wenn Du irgendwo packed brauchst hast Du einen Designfehler.

:-) Ich werde es meine Chef sagen :-)
Ne aber stimmt vollkommen das Problem ist halt wenn man überall Bits und 
Bytes sparen will/muss

Mathias G. schrieb:
> "packed" habe ich natürlich auch probiert - bringt nicht wirklich was.

Ich habe es auch mal ausprobiert: Mit arm-none-eabi-gcc 6.2.0 und
__attribute__((packed)) und ohne das gcc_struct-Attribut (das auf dem
ARM sowieso keine Bedutung hat) ist die Struktur 7 Byte groß, d.h. es
verbleiben keine ungenutzten Bits.

Peter II schrieb:
> wie willst du das machen,

Einfach jedes Element an seiner eigenen Größe ausrichten. Bytes an 1ern, 
Zweibytige and 2ern, Vierbytige an 4ern, Achtbytige an 8ern, etc. So 
mögen das alle aktuell gängigen CPUs und auch die der letzten 30 Jahre 
am liebsten.

> eventuell muss man bei einer Plattform auf
> 256bit alignen?

Die will ich sehen. Und ich glaub nicht das zukünftige CPUs in 
irgendeiner Hinsicht wieder schlechter werden sollen als heutige.

Ganz egal ob Du es mit nem Struct machst oder sie einzeln aus dem Buffer 
herauskratzt, wenn die Daten bereits ordentlich aligned im 
Empfangspuffer liegen hat der Compiler ne realistische Chance die 
Zugriffe schön zu optimieren ohne umständliche Schiebereien und 
Verrenkungen anzustellen.