Buffer optimiert in C kopieren

Moin,

memcpy()

Gruss WK

Dergute W. schrieb:

memcpy()

Aber nur wenn der Bytesex richtig ist.

Danke, auf dem PC funktioniert memcpy(&buf_int16, &buf_uint8, 8) schon mal.

Alignment aufpassen! Wenn man Zugriffe mit 16 oder 32 bit grösse macht, etwarten viele Architekturen auch addressen die 16 oder 32bit aligned sind. Aus einer 8bit char buffer kann man deswegen nicht immer gleich 32 bit auskopieren. Klar wenn alignment stimmt geht.

Sonst ein memcpy müsste eigentlich das können. Gut implementationen sehen nach ob man am anfang oder ende noch 8bit weise kopiert. Dazwischen aber 32 bit weise. Teilweise gibt es architekturen wo der RAM eh 64bit breit ist (oder noch breiter) wegen ECC. Da kann man richtig gas geben, denn man kann 64bit weise kopieren.

Andras H. schrieb:

Teilweise gibt es architekturen wo der RAM eh 64bit breit ist (oder noch breiter) wegen ECC. Da kann man richtig gas geben, denn man kann 64bit weise kopieren.

Das landet doch sowieso zuerst in den CPU Caches, da wird der RAM vermutlich keinen unterschied sehen.

Danke für die Hinweise. Hat auch auf dem ARM funktioniert. Das Alignment müsste man vermutlich beim Anlegen des Buffers prüfen? Wäre jetzt davon Ausgegangen, dass der Compiler das nicht schräg über Wortgrenzen legt.

Geht um einen RP2350, also RPI Pico2. Ist 32Bit.

Wulf D. schrieb:

Das Alignment müsste man vermutlich beim Anlegen des Buffers prüfen?

Mei memcpy kannst du das alignment ignorieren, das braucht man nur bei hacks wie z.B. uint8_t x[2]; *(uint16_t*)x = 123;.

Aber ja, beim anlegen eines Arrays kann man das auch mitgeben, mittels alignas: https://en.cppreference.com/w/c/language/alignas.html

Wulf D. schrieb:

Gegegeben ist ein größerer uint8_t-Buffer der prozesssicher in einem Mehrkern-uC als Ringbuffer mit 16 Bit-Wörter gefüllt wird. Zyklisch werden bei ausreichendem Füllstand wieder 16-Bit-Werte entnommen.

Warum dann nicht gleich ein int16_t Array anlegen? Dann stimmt auch das Alignment.

Brauchst du wirklich eine kopie, oder reicht dir der Zugriff auf 8Bit bzw. 16Bit Ebene? Wenn es Keine Kopie sein muss, dann kannst du auch ein Union anlegen.

Falls es doch eine Kopie sein soll:

• kopieren via Pointer (Dann gleich mit maximaler Bitbreite kopieren(32Bit?)
• DMA (Falls der Prozessor das kann)

Wulf D. schrieb:

Danke, auf dem PC funktioniert memcpy schon mal.

Auch auf allen anderen Architekturen sollte man nichts eigenes machen. Die Compiler optimieren meist besser als man selber. Wenn du als Optimierung -O3 eingestellt hast, wird er vermutlich Intrinsic Funktionen nutzen.

Das einzige auf was man selber achten sollte ist das Alignment wie oben beschrieben.

Und den byte-order, in dem fall hier. Aber heute ist ja sowieso alles little-endian.

Wulf D. schrieb:

Gegegeben ist ein größerer uint8_t-Buffer der prozesssicher in einem Mehrkern-uC als Ringbuffer mit 16 Bit-Wörter gefüllt wird. Zyklisch werden bei ausreichendem Füllstand wieder 16-Bit-Werte entnommen.

Wulf D. schrieb:

Geht um einen RP2350, also RPI Pico2. Ist 32Bit.

DMA. Der Pico hat so viele Kanäle davon, dass man die sogar gefahr- und kostenlos nutzen kann.

Sorry für die verzögerte Reaktion, komme heute nur sehr sporadisch Zugriff zum Forum. Irgendwas hakelt.

Endian Mode dürfte in der Tat egal sein, da ja alles auf einem Prozessor läuft. Kann doch eigentlich nur beim Transport über Grenzen schief gehen. Denke, dass ARM big endian ist. Und x86 little endian. Jedenfalls sah die Byteanordnung im Testprogramm auf dem PC so aus.

Die Ringbuffer-Entnahmemethode ist so deklariert

1

RING_BUFFER_SIZE_TYPE ring_buffer_pop(ring_buffer_t *ring_buf, uint8_t* vals, RING_BUFFER_SIZE_TYPE maxvals);

RING_BUFFER_SIZE_TYPE ist uint16_t, uint8_t* vals mit dem eigentlichen Bufferspeicher verbunden. ring_buffer_t eine Struktur.

Letztlich gab es noch eine einfachere Variante die 16-Bit-Wörter aus dem 8-Bit Bufferspeicher zu ziehen, aber das konntet ihr mangels Infos nicht ahnen und ich bin mir nicht sicher ob der (uint8_t *)-Cast auf ein int16_t-Array guter Stil ist. Funktionieren tut es, decodebuf enthält die gewünschten 16Bit-Werte.

1

int16_t decodebuf[1920];

2

ring_buffer_pop(&ring_buffer, (uint8_t *)decodebuf, 1920*2);

Norbert schrieb:

DMA. Der Pico hat so viele Kanäle davon, dass man die sogar gefahr- und kostenlos nutzen kann.

eh, guter Tipp. Vier werden bereits benutzt, aber da ist noch Luft. Versuche ich beim Optimieren. Leider ist das SDK qualitätsmäßig so mies, dass man den Debugger nicht nutzen kann. stdio_init_all(); stürzt zuverlässig ab.

Normales Compilieren und Laden geht, aber ohne Debugger äußerst lästig.

Wulf D. schrieb:

So wie im Beispiel funktioniert die Sache, aber geht das nicht effizienter ohne schieben und addieren? Also direkt aus dem 8 Bit Buffer zwei Wörter zu einem 16 Bit Wort kopieren?

Müsste mit logischen Operationen gehen. Das Hintergrundproblem ist hier die Umwandlung des Datenformats. Schaut man sich ein wenig um, könnte man sich noch auf memcpy stürzen (schneller machen), bzw. sich auf das Allignment konzentrieren, und memcpy weitgehend weglassen. Teilweise sind die angesprochenen Sachen hier sehr Hardware- bzw. Compilerabhängig.

https://stackoverflow.com/questions/17498743/how-does-the-internal-implementation-of-memcpy-work hier verlinkt noch (was zum Downloaden): http://www.danielvik.com/2010/02/fast-memcpy-in-c.html

https://stackoverflow.com/questions/6842363/why-are-structures-copied-via-memcpy-in-embedded-system-code