24 Einzelne Bits zu 3 Byte zusammen fügen in c++?

1

uint32t value=0;

2

if (pin 32 is set)

3

  value|=(1<<32);

4

if (pin 31 is set)

5

  value|=(1<<31);

6

...

7

if (pin 0 is set)

8

  value|=(1<<0);

Die Ausdrücke in den Klammern kriegst du selber hin, oder?

- Definiere die "richtige" Reihenfolge der Bits
- Lese die einzelnen Bits und schiebe sie in die
richtige Position
- ver-odere alle einzelnen Bits in eine Long Variable

>if (pin 32 is set)
>  value|=(1<<32);

Buhaha;)

holger schrieb:
> Buhaha;)

Hauptsache Stefanus kann als erster seinen Mist beitragen.

Markus S. schrieb:
> und habe 24 I/O Pins die nicht in einer Reihe
> sind definiert

Stefanus kennt auch schon die Reihenfolge der Bits. Seine
Glaskugel arbeitet hervorragend.

Markus S. schrieb:
> value|=(0<<32);    löscht aber kein Bit oder?

Lässt sich in jedem C-Tutorial oder C-Lehbuch nachlesen.

Bist du zu faul das zu tun?

> Buhaha;)

Nach 6 Wochen weichgekochtem Hirn bei 28-36°C solltest auch du solche 
Flüchtigkeitsfehler verzeihen können. Egal ob du noch im Kindergarten 
spielst oder älter bist.

> gibt es eine Verknüpfung die sowohl
> ein Bit als 0 aus 1 setzen kann?

Nochmal auf deutsch bitte.

man kann erst alles auf 0 setzen und dann verodern

Man kann auf die if Ausrücke verzichten, indem man ellenlange wahnwitzig 
verschachtelte Ausdrücke benutzt. Aber dieser Code wäre sehr schlecht 
lesbar und vermutlich nicht einmal schneller.

Man könnte Markos benutzen, finde ich aber auch nicht gut:

1

#define isset(port,bit) (((port) >> (bit)) & 1)

2

3

uint32_t value =

4

  (isset(registerX,24) << 31) | 

5

  (isset(registerX,7) << 30) |

6

  (isset(registerX,0) << 29) |

7

  ...

8

  (isset(registerX,12) << 0);

Wenn da ein Tippfehler passiert, spuckt der Compiler sicher eine 
herrlich unverständliche Fehlermeldung aus.

Markus S. schrieb:
> Ne variante ohne 'IF' wird dann wohl nicht gehen oder?
>
> value|=(1<<32);    setzt ein Bit
> value|=(0<<32);    löscht aber kein Bit oder?

Nein. Entweder, Du initialisierst Deinen uint32 immer mit 0 und setzt 
dann nur die nötigen Bits (wie Stefan demonstriert hat), oder Du machst 
das mit &=~.

>> Buhaha;)

>Nach 6 Wochen weichgekochtem Hirn bei 28-36°C solltest auch du solche
>Flüchtigkeitsfehler verzeihen können.

Kein Problem. War halt lustig;)

>Egal ob du noch im Kindergarten
>spielst oder älter bist.

Das hättest du dir jetzt auch verkneifen können.

> value|=(1<<32);    setzt ein Bit
> value|=(0<<32);    löscht aber kein Bit oder?

OMG, nicht noch mehr 32. Das geht nicht! Dieses Bit fliegt raus.
Passt nicht in 32 Bit.

>Wenn ein SIG.. Port auf 0 ist dann passiert ja nix oder?

Ja, 0 oder 0 ist 0. So ein bisschen Digitaltechnik solltest du dir
schon mal reinziehen.

Markus S. schrieb:
> uint32t value=0;
> value|=(SIG24<<23);
> value|=(SIG23<<22);
> value|=(SIG22<<21);
> ...
> value|=(SIG1<<0);

Mit den Variablen wird das doch zur Laufzeit geschoben.
Du füllst doch irgendwo die SIGn Variablen, pack da doch gleich den Wert 
rein statt Null oder Eins.

if(pinset(x) SIG12 = 4096;

value = SIG1 + SIG2 + SIG3 ...

Ein if(SIG6) ist dann immer nuch nur wahr oder falsch.

Also ehrlich, der erste Code von Stefan ist klar, sauber, sauschnell, 
lesbar und maximal flexibel. Bei einem Controller mit wenigen 100 Pins 
macht was "schlaues" wenig Sinn.

Alternativ wäre statt bitbanging noch bitfelder in gleicher Weise 
möglich, wenn man bitfelder nicht für Teufelszeug hält.

Ergänzung: statisch analysierbar, dann fallen die meisten 
Flüchtigkeitsehler auch auf

Markus S. schrieb:
> ich benutze einen 32Bit MC und habe 24 I/O Pins die nicht in einer Reihe
> sind

..aber du verrätst niemandem, welcher µC das ist. Dann mußt du dein 
Problem eben allein lösen.

Tip: bei manchen 32 Bittern aus der Cortex-Riege gibt es mehrere 
Zugriffsmöglichkeiten für die Ports. Eine davon ist ein Alias-Feld 
(offizieller Name fällt mit grad nicht ein), wo jedes Portpin als eine 
Boolean-Variable dargestellt ist. Und das wahlweise als 8, 16 oder 32 
Bit longbool.

Wo sowas vorhanden ist (z.B. LPC11E12), kannst du etwa so schreiben:

1

#define GPPB    0x50000000

2

#define W0  (*((volatile unsigned long*) (GPPB + 0x1000)))

3

#define W1  (*((volatile unsigned long*) (GPPB + 0x1004)))

4

...

5

6

MyVector =

7

  (W0  << 1) |

8

  (W27 << 2) |

9

  (W3  << 3) |

10

   ... usw.

Wo sowas nicht geht, mußt du zwangsläufig auf
((PortX >> nummer) &1) << bitpos) |
zurückgreifen.

W.S.

Markus S. schrieb:
> Habe sie jetzt auch fertig programmiert und sie funktioniert
> einwandfrei!

Das ist gut.

Im einer kontemplatuven Stunde nach ein paar Tagen empfehle ich dennoch, 
mal zu überleben, wo die Vorteile von Stefans Version mit If liegen. Für 
den Compiler und den Leser.

Die wohl einfachste/schnellste/übersichtlichste Lösung ist diese:

1

uint32t value=0;

2

value|=(SIG24<<23);

3

value|=(SIG23<<22);

4

value|=(SIG22<<21);

5

...

6

value|=(SIG1<<0);

einfach: ja
übersichtlich: ja
schnellste: nein

Denn so werden immer alle 32 Makros ausgeführt, dann das Bit geschoben, 
dann mit value verodert. Mein Vorschlag mit der if-kette verkürzt die 
Sache etwas bei den Bits, die 0 sind.

Jetzt sollte man natürlich noch diese SIGxx Makros verkürzen, dass sie 
bei Low Pegel eine 0 liefern und bei High pegel irgendeine höhere Zahl.

Momentan hat er die Makros ja so geschrieben, dass 0 oder 1 bei raus 
kommt. Für diese if-Kette würden sie damit eine unnötige 
Schiebe-Operation enthalten.

Das wird doch eh alles wegoptimiert. Lieber das Übersichtlichste nehmen 
und schauen ob der generierte Code nicht vielleicht sogar optimal ist...
Auf >= Cortex-M3 wären das die Instruktionen UBFX und BFI, wenn die Bits 
komplett durcheinander sind.

Wobei ich die Variante mit "if" nicht so schön finde - die Ziel Variable 
wird mehrfach verändert (mutable), wodurch das ganze relativ weit weg 
von funktionaler Ausdrucksweise ist und daher m.E. unübersichtlicher. 
Sollte es tatsächlich nicht wegoptimiert werden, sind bedingte Sprünge 
je nach Prozessor auch ineffizient.

Stefanus F. schrieb:
> Mein Vorschlag mit der if-kette verkürzt die
> Sache etwas bei den Bits, die 0 sind.
Nur wenn der betreffende µC keinen "Barrel Shifter" hat.
(Aber das dürfen wir ja nicht erfahren)

Arduino Fanboy D. schrieb:
> Nur wenn der betreffende µC keinen "Barrel Shifter" hat.

Welcher 32 Bit Prozessor hat denn keinen? Und außerdem auch noch keine 
Pipeline, welche durch bedingte Sprünge ausgebremst wird?

Falls noch jemand wissen wollte, warum C Programmierer auch ein bisschen 
Assembler können sollten: Dieser Thread zeigt es.

Das stimmt allerdings... Bei manchen Cortex-A kann das 50 Takte pro 
Zugriff dauern, weil hier der Cache umgangen werden muss und der 
Peripherie Bus viel langsamer als der Core sein kann.

> es hilft, solchen Code lesen zu können

Das meinte ich ja.

C fehlt ein Set/Unset Operetor.

Mit # als Operatorzeichen etwa so:

port # 1 # 2;

Setzt das LSB und loescht das Bit darueber.


Traditionell ginge das wohl so:

port = (port | 1) & ~2;


oder:

result = var # 1 # 2;


Bei einem:

port ## 2 oder: port #1 #

koennte der Compiler das jeweils unnoetige schonmal herausoptimieren.

> C fehlt ein Set/Unset Operetor.

Ich glaube, du brauchst hier nicht die Programmiersprache zu erklären. 
Die kennen wir alle gut genug.

A. K. schrieb im Beitrag #5516903:
> ... und jetzt bitte nochmal für Normalsterbliche.

Man kann in manchen Sprachen den Zugriff auf als public definierte class 
member steuern, indem man den get- und set-Operator verwendet.
Dabei wird bei einer Zuweiung der set-Operator verwendet und beim 
Auslesen der get-Operator.
Um willkürlichem Schreibzugriff entgegenzuwirken, kann man den 
set-Operator private definieren und den get als public.
Dann kann von überall lesend auf die Variable zugegriffen werden, aber 
nur innerhalb der Klasse schreibend.
Die Operatoren arbeiten wie Funktionen (get endet mit einem return, set 
hat als quasi unsichtbares Argument die Variable "value").
Innerhalb dieser Operatoren kann man auch noch Programmcode abarbeiten 
lassen.

> Wenn SIG1..SIG24 nur den Zustand 0 und 1 haben

Leider spielt der TO nicht mit offenen karten, so daß wir alle nicht 
wissen, wie seine SIGxx Makros aussehen.

Das man kein if "braucht", habe wir längst festgestellt. Wir sind schon 
einen Schritt weiter und vergleichen die Performance diverser Varianten.

Was aber - wie nun klar ist - ohne die Makros und den µC zu kennen zu 
keiner konkreten Empfehlung führen kann.

Es wurde alles dazu gesagt, nur nicht nicht von jedem. Mal sehen, wie 
viele Leute noch die selben Vorschläge wiederholen und dann die selben 
Bedenken dazu äußern.

Operator schrieb:
> C fehlt ein Set/Unset Operetor.

Da es ja um C++ geht, steht es dir frei das selbst zu implementieren... 
# ist schon belegt. Aber so etwas könnte man sich bauen:

1

RegisterXY[7] = 0;

2

RegisterYZ.BitBlubb =1;

Mit einer cleveren Umsetzung ist das dann auch genau so effizient wie 
das direkte Hinschreiben. C(++) sind halt Hochsprachen und nicht primär 
für Treiber Entwicklung gemacht, weshalb solche Dinge nicht direkt 
kompakt unterstützt werden. Nach dem Grundsatz:
Oft benutzte Dinge einfach machen, alle Dinge möglich machen.

1

#include <cstdint>

2

#include <biset>

3

4

uint32_t read_io()

5

{

6

    std::bitset<24> bits

7

8

    bits.set( 0, SIG1 );

9

    bits.set( 1, SIG2 );

10

    // ...

11

    bits.set(23, SIG24);

12

13

    return bits.to_ulong();

14

}

http://www.cplusplus.com/reference/bitset/bitset/

Vincent H. schrieb:
> Daran ist gar nichts übertrieben. Das ist nämlich die einzige Variante
> die Lauf- und Compilezeit Werte unterstützten könnte.

Es ist die einzige Variante, die geradezu blind ist für die 
zugrundeliegende Hardware. Man bedenke mal, daß das Zusammenklauben von 
wild in der Peripherie verstreuten Bits prinzipiell derart hardware- und 
projekt-nah ist, daß man mit Templates und dergleichen an dieser Stelle 
eigentlich GARNICHTS Gutes bewirken kann.

Will man einen hochästhetisch aussehenden Quellcode oder einen 
hocheffektiven Maschinencode?


Stefanus F. schrieb:
> Falls noch jemand wissen wollte, warum C Programmierer auch ein bisschen
> Assembler können sollten: Dieser Thread zeigt es.

Wenigstens ein wenig Assembler sollte JEDER µC-Programmierer können. 
Aber das reicht nicht. Man sollte auch die Peripherie des betreffenden 
µC soweit kennen, daß man sie auch benutzen kann.

Wer mit irgendwelchen Makros versucht, Portpins in eine generalisierte 
Form zu bringen, vergeigt fast immer wesentliche Möglichkeiten, die der 
betr. µC bietet.


Operator schrieb:
> Bei einem:
> port ## 2 oder: port #1 #
> koennte der Compiler das jeweils unnoetige schonmal herausoptimieren.

siehe oben. Das ist ein glatter Fehlgedanke. Der Compiler kann beim 
gestellten Thema überhaupt nichts herausoptimieren, denn es geht 
darum, 24 wild in der Prärie liegende Pinzustände in eine einzige long 
Variable zu befördern. Also müssen alle 24 Zustände irgendwie abgefragt 
werden und man kann keinen davon mal eben wegoptimieren.

Schlußendlich habe ich den Eindruck, daß hier mal wieder eine völlig 
falsche Aufgabenstellung zelebriert wird. Der TO hat genau so etwas vor 
und fragt nur nach, wie er das am besten kann, aber wie schon so oft in 
diesem Forum erweist sich wohl auch dieses als falscher - weil 
uneffektiver - Denkansatz, der bei besserer Gesamtplanung des 
zugrundeliegenden Projektes schlichtweg überflüssig wäre.

W.S.

W.S. schrieb:
> Man bedenke mal, daß das Zusammenklauben von wild in der Peripherie
> verstreuten Bits prinzipiell derart hardware- und projekt-nah ist, daß
> man mit Templates und dergleichen an dieser Stelle eigentlich GARNICHTS
> Gutes bewirken kann.

Der Code wird ggf. übersichtlicher. Die Definition der Funktion ist 
etwas kryptisch, dafür ist der Aufruf ziemlich kurz und es ist leicht 
ersichtlich, wie die Pins definiert sind.

W.S. schrieb:
> Will man einen hochästhetisch aussehenden Quellcode oder einen
> hocheffektiven Maschinencode?

Compiler sind heutzutage sehr gut im Optimieren. Der abstrakte, lesbare 
Code wird in einen anwendungsspezifischen optimalen Maschinencode 
übersetzt. Man muss ggf. noch ein bisschen mit "restrict" und 
"always_inline" nach helfen.

Siehe z.B. die im Artikel Serialisierung vorgestellte Bibliothek. 
Diese ermöglicht sehr abstrakten, übersichtlichen und wartbaren Code. 
Dieser wird aber sehr effizient übersetzt. Genau das ist der Spagat, für 
den es C++ gibt.

Niklas Gürtler schrieb:
> Compiler sind heutzutage sehr gut im Optimieren.

Du hast kein einziges Wort verstanden.

Ganz egal, ob ein Compiler den ihm vorgesetzten Code optimieren kann 
oder nicht, kann er (der Compiler!) die zugrundeliegende Hardware der 
Peripherie nicht kennen. Er weiß daher nicht, ob dessen Peripherie nicht 
nur eine einzige Art Zugriff auf die Portpins kennt, sondern ggf. auch 
noch andere Zugriffsarten, die dann eben weitaus effizienter sind für 
den gegebenen Fall.

Siehe z.B. auch das hier in diesem Forum ewige Thema "Setzen eines 
Portpins zu hi oder lo", was bei manchen Chips auf dramatisch bessere 
Weise (BSRR Register o.a.) als sonst üblich getan werden kann. So etwas 
kann kein Compile dieser Welt optimieren, denn dafür ist hardware- und 
projekt-nahes Wissen vonnöten.

W.S.

W.S. schrieb:
> Du hast kein einziges Wort verstanden

Und du meinen Code nicht gelesen. Da ist überhaupt kein Peripherie 
Zugriff drin. Den macht der Aufrufer selbst, so wie es optimal ist. 32 
Bits auf einmal Lesen dürfte ziemlich optimal sein (besser als Bit 
Banding). Und wenn man es drauf anlegt, kann man das selbstverständlich 
auch mit Templates modellieren - wenn nur genau 1 Bit gebraucht wird und 
das an Stelle 0 stehen soll, automatisch auf die Bit Banding Region 
zugreifen. In anderen Fällen dürfte das sonst keinen Vorteil bieten. Bei 
anderen Architekturen gilt das dann analog.

... gilt natürlich auch für die Ausgabe per BSRR o.ä., aber um die ging 
es hier überhaupt nicht.

W.S. schrieb:
> kann er (der Compiler!) die zugrundeliegende Hardware der Peripherie
> nicht kennen.

Und wer kennt sie dann?

Weil's so schön und etwas anders ist ;-)

1

    uint32_t value = 0;

2

    value = (value<<1) | !!SIG24;

3

    value = (value<<1) | !!SIG23;

4

    value = (value<<1) | !!SIG22;

5

    ...

6

    value = (value<<1) | !!SIG3;

7

    value = (value<<1) | !!SIG2;

8

    value = (value<<1) | !!SIG1;

9

    return value;