16-Bit-Array in 8-Bit-Array zerlegen

[Type Pun Intended (Gast)]

Guten Morgen,

ich habe ein 16-Bit-Array, das ich in ein 8-Bit-Array doppelter Länge 
verpacken will, also so:

void put8(uint8_t data[], size_t len);


void foo(void)
{
    // Existiert schon:
    uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

    // Soll so gelesen werden:
    uint8_t var2[] = {0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC};
}

Meine Plattform (ARM32) ist little-endian, also fällt eine einfache 
Kopie mit memcpy weg. Immerhin scheint das Array dicht gepackt. Der 
folgende kleine Test macht zumindest das, was ich erwarte:

enum {
    big_endian    = 0,
    little_endian = 1,
    unpacked      = 2,
};

uint_fast8_t checkTypPunning(void)
{
    uint16_t tst1[] = {0x1234, 0x5678, 0x9ABC};
    uint8_t *tst2 = tst1;
    bool be0 = (tst2[0] == 0x12);
    bool be1 = (tst2[1] == 0x34);
    bool be2 = (tst2[2] == 0x56);
    bool be3 = (tst2[4] == 0x78);
    bool le0 = (tst2[0] == 0x34);
    bool le1 = (tst2[1] == 0x12);
    bool le2 = (tst2[2] == 0x78);
    bool le3 = (tst2[3] == 0x56);

    if( be0 & be1 & be2 & be3 )
        return big_endian;
    else if( le0 & le1 & le2 & le3  )
        return little_endian;
    else
        return unpacked;
}

Das einzige, was mir standardkonform einfällt, wäre:

    // Existiert schon:
    uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

    // Konvertierung
    size_t len = sizeof(var1);
    uint8_t *var2 = (uint8_t *) malloc(len);
    for( size_t i = 0; i<len; i++ ) {
        var2[i] = ntohs(var1[i]);
    }

    // Nutzung
    put8(var2, len);

malloc() würde ich allerdings gern weitestgehend vermeiden; das Array 
darf auch zerstört werden.  Was ist jetzt die richtige™ Vorgehensweise?

Grüße
Punny

[Dirk B. (dirkb2)]

Type Pun Intended schrieb:
> Immerhin scheint das Array dicht gepackt.

Das ist eine Grundvoraussetzung für Arrays.

> Das einzige, was mir standardkonform einfällt, wäre:

 var2[i] = ntohs(var1[i]);

ntohs gehört zum Posix-Standard und nicht zum C-Standard.

Du kannst dir aber selber eine Funktion mit Bitoperationen basteln.

Deine Konvertierung funktioniert so aber nicht.
Du holst 16-Bit-Werte raus und schreibst sie nach 8-Bit.
Dabei gehst du über die Grenzen deines 16-Bit Arraya hinaus.


> das Array> darf auch zerstört werden.

for( size_t i = 0; i<sizeof(var1)/sizeof(*var1); i++ ) {
  var1[i] = ntohs(var1[i]);

[A. (Gast)]

Wenn auch folgendes erlaubt sein darf:

uint8_t var2[] = {0x34, 0x12, 0x78, 0x56, 0xBC, 0x9A};

Dann interpretiere die Variable einfach als uint8_t Array.

uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};
uint8_t * pvar2 = &var1[0];

//hier dein code z.B:
if(pvar2[0] == 0x34){
//..
}

Dann musst du halt überall wissen, dass die Bytes verkehrtherum 
angeordnet sind. Dann könntest du z.B. eine Zugriffsfunktion schreiben 
(finde ich jedoch unelegant!), wie:

uint8_t get(uint8_t * arr, uint8_t pos){
  if(pos % 2 == 0)
    return arr[pos + 1];
  else
    return arr[pos - 1];
}

Alles nicht geprüft.

[A. (Gast)]

Nachtrag:

Es geht dann z.B. auch folgendermaßen. Dann kommt man ganz ohne memcpy 
aus und das Array wird auch nicht zerstört. Wenn du hingegen viele 
Zugriffe hast, würde ich mir schon überlegen das Array zu formatieren, 
braucht man weniger Rechenleistung.

uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

uint8_t get(uint8_t * arr, uint8_t pos){
  if(pos % 2 == 0)
    return arr[pos + 1];
  else
    return arr[pos - 1];
}

uint8_t x = get((uint8_t*) &var1[0],2);

[Jonas B. (jibi)]

>if( be0 & be1 & be2 & be3 )

Unabhängig vom Problem, das macht sicher nicht das was du denkst...

Gruß J

[Markus F. (mfro)]

Du versuchst, die "strict-aliasing"-Regel zu erfüllen. Das ist 
grundsätzlich sehr löblich, hier jedoch völlig unnötig (zumindest in C).

Hier darf man ungestraft jeden beliebigen Zeigertyp auf einen 
char-Zeiger casten (nur andersrum nicht):

var2 = (uint8_t *) var1;

wär' hier also völlig ausreichend.

Ob die Bytes in der für dich richtigen oder falschen Reihenfolge stehen, 
ist ein anderes Problem und mit ntohxxx()-Funktionen nicht sauber zu 
erschlagen. Die können nur (weil sie eben so definiert ist) von 
Network-Byteorder (big endian) auf Host-Byteorder wandeln. Auf einer 
Big-Endian Plattform machen die folglich einfach genau nix (was 
wahrscheinlich nicht das ist, was Du haben willst).

[Jim M. (turboj)]

Markus F. schrieb:
> Auf einer
> Big-Endian Plattform machen die folglich einfach genau nix (was
> wahrscheinlich nicht das ist, was Du haben willst).

Doch, genau das wollte der OP laut seinem 1. Beitrag haben.

[A. (Gast)]

Markus F. schrieb:
> Du versuchst, die "strict-aliasing"-Regel zu erfüllen. Das ist
> grundsätzlich sehr löblich, hier jedoch völlig unnötig (zumindest in C).

Ich behaupte jetzt mal einfach etwas:

Sowas passiert, wenn man ursprünglich aus der PC-Programmierung kommt, 
nur vorgefertigte Bibliotheken nimmt, die einen ST z.B. für die STM32 
zur Verfügung stellt und noch nie auf Registerebene programmiert hat.
Ich persönlich programmiere z.B. komplett ohne HAL und Stdlib etc.

Auf µC-Ebene sind eben auch sehr direkte Wege erlaubt.

[Type Pun Intended (Gast)]

Dirk B. schrieb:
> Du holst 16-Bit-Werte raus und schreibst sie nach 8-Bit.
> Dabei gehst du über die Grenzen deines 16-Bit Arraya hinaus.

Jetzt, wo ich meinen Kaffee hatte, sehe ich's auch.

Das ist gemeint:

    for( size_t i = 0; i<len; i+=2 ) {
        uint16_t tmp = var1[i/2];
        var2[i]   = tmp>>8;
        var2[i+1] = tmp & 0xFF;
    }

Und dann sollte ich noch etwas nachliefern, sonst bin ich den ganzen Tag 
nervös:

    free(var2);

Jonas B. schrieb:
>>if( be0 & be1 & be2 & be3 )
>
> Unabhängig vom Problem, das macht sicher nicht das was du denkst...
Ja.... vielleicht hätte ich vorher richtig wach werden sollen.


A. schrieb:
> Wenn auch folgendes erlaubt sein darf:
> uint8_t var2[] = {0x34, 0x12, 0x78, 0x56, 0xBC, 0x9A};

Neee, das ist genau nicht gewünscht. Eine Zugriffsfunktion im 
Pilgerschritt wird mich spätestens bei der übernächsten Codeänderung 
verwirren.

Dirk B. schrieb:
> Das ist eine Grundvoraussetzung für Arrays.

Ich finde im C-Standard lediglich, dass Zeiger-Arithmetik immer den 
tatsächliche Abstand der Elemente berücksichtigt. Wo finde ich denn, 
dass sizeof(uint16_t[2]) == sizeof(uint8_t[4]) ?

Markus F. schrieb:
> Auf einer
> Big-Endian Plattform machen die folglich einfach genau nix (was
> wahrscheinlich nicht das ist, was Du haben willst).

Hm... ich gehe davon aus, dass auf eine Big-Endian-Plattform meine 
16-Bit-Arrays schon von sich aus richtig herum im Speicher liegen. 
Brauche ich echt noch einen zweiten Kaffee?

[Type Pun Intended (Gast)]

> Brauche ich echt noch einen zweiten Kaffee?
Meine Rechtschreibung spricht da vermutlich eine klare Sprache.

[Markus F. (mfro)]

A. schrieb:
> Auf µC-Ebene sind eben auch sehr direkte Wege erlaubt.

Mit µC oder nicht hat das nicht das Geringste zu tun. C ist C - hier wie 
dort.
Was das mit Registern zu tun haben soll, erschliesst sich mir 
ebensowenig.

[A. (Gast)]

Na, wahrscheinlich programmierte er bisher nur dicke Anwendungen für 
Windows/Linux.

Nun kommt er daher und will einen µC programmieren. Ist doch super, 
sowas wie CubeMX initialisiert einen alles so wie man will und man macht 
nur noch Klicki-Bunti.

Und dann kommen solche Fragen! Auch auf einem ARM32 benutze ich kein 
malloc oder ähnliches. Hier reicht eine einfache Zeigerarithmetik, 
Kopierfunktion, Transformationsfunktion oder Zugriffsfunktion.

Wenn man auf Registerebene programmiert setzt man sich häufig auch mit 
der Struktur von µC auseinander und man lernt effizient zu 
programmieren.

[Markus F. (mfro)]

Type Pun Intended schrieb:
> Hm... ich gehe davon aus, dass auf eine Big-Endian-Plattform meine
> 16-Bit-Arrays schon von sich aus richtig herum im Speicher liegen.
> Brauche ich echt noch einen zweiten Kaffee?

Definiere "richtig herum" (auch wenn ich selbst zur m68k-Generation 
gehöre, der little endian immer noch wie Teufelswerk vorkommt...).

Ich bin davon ausgegangen, dass Du eine universelle 
"Byte-verdreh"-Routine suchst, die abhängig von der Host-Byteorder immer 
das richtige tut.

Die gibt's nicht fertig.

[Dirk B. (dirkb2)]

Type Pun Intended schrieb:
> Ich finde im C-Standard lediglich, dass Zeiger-Arithmetik immer den
> tatsächliche Abstand der Elemente berücksichtigt. Wo finde ich denn,
> dass sizeof(uint16_t[2]) == sizeof(uint8_t[4]) ?

Der C-Standard verlangt, das bei Arrays von Objekten keine zusätzlichen 
Füllbytes eingebaut werden - die sind dann schon im eigentlichen Objekt 
vorhanden.

Du möchtest auf der einen Seite einen 16-Bit Typ haben, auf der anderen 
einen 8-Bit Typ. 16 = 2*8
Wenn es einen davon nicht gibt, meckert der Compiler.
Anders sieht es bei uint_fast8_t oder uint_least8_t. Die können auch 
mehr Bits haben.

[Dirk B. (dirkb2)]

Type Pun Intended schrieb:
> Das ist gemeint:    for( size_t i = 0; i<len; i+=2 ) {
>         uint16_t tmp = var1[i/2];
>         var2[i]   = tmp>>8;
>         var2[i+1] = tmp & 0xFF;
>     }

Das ist die standardkonforme und kompatible Vorgehensweise.
Moderne Compiler erkennen das und machen daraus dann auch ein 
Assembler-Byteswap, wenn es nötig ist.

[Type Pun Intended (Gast)]

Hier scheinen wieder menschliche Wesen den Turing-Test nicht zu 
bestehen. Sobald das Wort "ARM" fällt, wird direkt auf "Klicki-Bunti", 
"CubeMX" und Wasweisich geschlossen. "Ein richtiger Commander kennt jede 
Schraube und jede Schweißnaht seines Schiffes und ein richtiger 
Programmierer arbeitet grundsätzlich mit Registern." Nein. Das ist alles 
nicht das Thema.

Es gibt ein Array, das von der Größe so Richtung 1/10 SRAM geht. Also 
gross genug, dass es sinnlos ist, in Registern zu denken, und noch klein 
genug, dass es schön wäre, eine Kopie zu vermeiden, aber nicht absolut, 
um jeden Preis notwendig ist.

Das Problem ist so elementar, dass es garantiert ziemlich tief im 
Quelltext-Berg verschwindet und irgendwann einmal, wenn vielleicht alle 
µC auf irgendeinem SPARC18-Kern basieren, garantiert nicht mehr als 
Fehlerursache vermutet wird. Oder alternativ schon nächste Woche wieder 
gelöscht sein.

Also suche ich die 
Jetzt-und-dann-Ruhe-für-immer-richtige™-Vorgehensweise.

[A. (Gast)]

Es gibt hier kein falsch oder richtig. Viele Wege führen nach Rom. Über 
die Randbedingungen wissen wir hier ja nichts.

Du kannst das Ding kopieren und dabei gleich richtig formatieren. Du 
kannst auch das bestehende Array formatieren und überschreiben. Du 
kannst auch eine Funktion nehmen um die bestehenden Daten formatiert 
auszulesen, auch ok. Auch kannst du gar nichts machen und das Array als 
8bit interpretieren (hier musst du gar nichts rechnen, nur müssen deine 
restlichen programmcodes wissen, dass es big endian ist).

Was du machst liegt doch in deiner Entscheidung? Ich (also .. ich) würde 
den Weg gehen, der am wenigsten Rechenzeit verbraucht, also entweder 
einmal formatieren oder die Daten einfach so lassen und bei jedem 
zugriff formatieren (wenn es die Rechenleistung zulässt).

Was du machst, das liegt bei dir..

[Franz D. (h4z3l)]

Vorschlag:

union array {
     uint16_t all;
     uint8_t u8[2];
}

union array var1[] = {0x1234, 0x5678, 0x9ABC};

[Type Pun Intended (Gast)]

Dirk B. schrieb:
> Das ist die standardkonforme und kompatible Vorgehensweise.
> Moderne Compiler erkennen das und machen daraus dann auch ein
> Assembler-Byteswap, wenn es nötig ist.

Danke für die Info. Ich erwarte allerdings irgendwelchen unterwarteten 
Ärger, wenn ich die Ersetzung In-Place vornehme:

    // Existiert schon:
    uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

    // Konvertierung
    size_t len = sizeof(var1);
    uint8_t *var2 = var1;
    for( size_t i = 0; i<len; i+=2 ) {
         uint16_t tmp = var1[i/2];
         var2[i]   = tmp>>8;
         var2[i+1] = tmp & 0xFF;
    }

    // Nutzung
    put8(var2, len);

Ich verletze an der Stelle ja die Strict-Alias-Regel. Würde ich das 
Ganze nur über eine Variable machen, um die Regel nicht zu verletzten 
also so:

    // Existiert schon:
    uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

    // Konvertierung
    size_t len = sizeof(var1);
    bool byteswap = // Ausdruck, der zur Compilezeit berechnet wuerde, waere toll
    if( byteswap ) {
       for( size_t i = 0; i<len/n; i++) {
            uint16_t tmp = var1[i];
            var1[i]   = (tmp>>8) | (tmp<<8) ;
        }
    }


    // Nutzung
    put8(var2, len);

bräuchte ich ja irgendeinen Ausdruck, mit dem ich feststellen kann, ob 
die Vertauschung überhaupt notwendig ist. Am besten irgendetwas, was 
schon vom Compiler ausgewertet werden kann.

[A. (Gast)]

Type Pun Intended schrieb:
> Danke für die Info. Ich erwarte allerdings irgendwelchen unterwarteten
> Ärger, wenn ich die Ersetzung In-Place vornehme:

Warum? Interrupts, die zwischendurch auf die Daten zugreifen wollen?

[Markus F. (mfro)]

Vielleicht habe ich ja das Problem noch nicht verstanden.

ist es

- ein int16_t-Array von (irgendeiner) byte order in ein int16_t-Array 
mit Host-Byteorder
- ein int16_t-Array von Network-Byteorder in ein int16_t-Array mit 
Host-Byteorder
- ein int16_t-Array in ein int8_t-Array

zu wandeln? Oder nochmal was anderes.

Oder in anderen Worten: wo kommen die Daten her und was willst Du damit 
machen?

[Markus F. (mfro)]

Type Pun Intended schrieb:
> bräuchte ich ja irgendeinen Ausdruck, mit dem ich feststellen kann, ob
> die Vertauschung überhaupt notwendig ist. Am besten irgendetwas, was
> schon vom Compiler ausgewertet werden kann.

Das ist simpel:

static inline bool host_is_be(void)
{
    const uint16_t check = 1;

    if ( ((uint8_t *) (&check))[1] == 1)
        return true;
    return false;
}

Daraus macht der Compiler bei Optimierung einfach ein true oder false, 
je nach Host-Plattform.

[Type Pun Intended (Gast)]

Markus F. schrieb:
> Das ist simpel:

Danke! Habe den Baum vor lauter Ästen nicht gesehen. Dann ist mein 
Problem gelöst.

void msbFirst16(uint16_t *array, size_t len)
{
    // Byte-Order feststellen
    const uint16_t check = 1;
    bool lsbfirst = ((uint8_t *) (&check))[1] == 1;

    // Bei little-endian Byte-Order vertauschen
    if( lsbfirst ) {
       for( size_t i = 0; i<len; i++ ) {
            uint16_t tmp = *array;
            *array   = (tmp>>8) | (tmp<<8) ;
            array++;
        }
    }
}

void foo(void) 
{
    // Existiert schon:
    uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

    // Konvertierung
    size_t len = sizeof(var1)/sizeof(uint16_t);
    msbFirst16(var1, len);

    // Nutzung
    put8((uint8_t*) var1, len/2);
}

[A. (Gast)]

Wenn du von Anfang nur wissen wolltest, ob eine Konvertierung notwendig 
ist, warum fragst du dann nicht direkt nach so einer Funktion?

1. Ist Konvertierung notwendig?
2. Dann konvertieren.

Letztendlich hast du dich dann jetzt für ein swap entschieden, also die 
bestehenden Daten zu konvertieren - falls dies notwendig ist.

Was war die ursprungsfrage nochmal?

[Type Pun Intended (Gast)]

Type Pun Intended schrieb:
> bool lsbfirst = ((uint8_t *) (&check))[1] == 1;

Fehler meinerseits:

bool lsbfirst = ((uint8_t *) (&check))[0] == 1;

ist richtig.

[Axel S. (a-za-z0-9)]

Type Pun Intended schrieb:
> ... das ist genau nicht gewünscht. Eine Zugriffsfunktion im
> Pilgerschritt wird mich spätestens bei der übernächsten Codeänderung
> verwirren.

Dann verkapsele sie halt hypsch.

uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};

#ifdef PLATFORM_IS_LITTLE_ENDIAN
#define var1_as_byte(i) ((uint8_t *)var1)[(i)^1]
#else
#define var1_as_byte(i) ((uint8_t *)var1)[(i)]
#endif

for (size_t i=0, j=0; j<sizeof(var1)/sizeof(uint16_t); i+=2, j++ )
{
   printf("Wort: %x, 1. Byte: %x, 2. Byte: %x\n", 
          var1[j], var1_as_byte(i), var1_as_byte(i+1));
}

Nachtrag:

/tmp $cat test.c 
#include <stdio.h>
#include <stdint.h>

#define as_byte(i) ((uint8_t *)var1)[(i)^1]

int main(void)
{
  uint16_t var1[] = {0x1234, 0x5678, 0x9ABC};
  for (size_t i=0, j=0; j<sizeof(var1)/sizeof(uint16_t); i+=2, j++ )
  {
    printf("Wort: %x, 1. Byte: %x, 2. Byte: %x\n", 
           var1[j], as_byte(i), as_byte(i+1));
  }  
}

/tmp $gcc -std=gnu99 -Wall test.c 
/tmp $./a.out 
Wort: 1234, 1. Byte: 12, 2. Byte: 34
Wort: 5678, 1. Byte: 56, 2. Byte: 78
Wort: 9abc, 1. Byte: 9a, 2. Byte: bc

[Dirk B. (dirkb2)]

Bei der Längenermittlung von einem Array, dividiert man nicht durch die 
Größe vom Typ, sondern durch die Größe eines Elementes vom Array.

sizeof(var1)/sizeof(var1[0]);
oder
sizeof(var1)/sizeof(*var1);

Das kann man dann auch als Makro machen

#define SIZEOFARRAY(array) (sizeof(array)/sizeof(*array))

Dann braucht man den Typ nur bei der Definition ändern.