Bits aus Byte-Array extrahieren Alg.

lepper03 schrieb:
> Was ist der beste (schnell und optimiert) Algorithmus Eure Meinung nach,
> um diese Aufgabe zu erledigen?

Was hast du denn bist jetzt für einen 'schlechten' Algorithmus? Da kann 
man bestimmt darauf aufbauen. (Des besseren Verständnisses wegen.)

lepper03 schrieb:
> Die extrahierte Bytes/Bits soll ich in ein anderes Byte-Array hinkopieren
> (dsa für die extrahierte Länge passt).

Kann es ja ohnehin nicht, wenn die Gesamtlänge an "Nutzbits" nicht durch 
8 teilbar ist.

D.h. wer auch immer die Daten weiterverarbeitet, wird auch wieder darauf 
schauen müssen und braucht die Zusatzinformation, wieviele Bits denn 
genutzt werden sollen.

> Was ist der beste (schnell und optimiert) Algorithmus Eure Meinung nach,
> um diese Aufgabe zu erledigen?

Ich wüsste nicht, was man da viel optimieren kann. Zumal es vorrangig 
auf die Korrektheit der Ergebnisse ankommt.

Wenn es gerade mal um 256 Bytes geht, die insgesamt zu verarbeiten sind, 
dann dürfte damit so ziemlich jeder Mikrocontroller fix fertig sein. Es 
sei denn die Aufgabe muss Millionen Male pro Sekunde durchgeführt 
werden.

@OP:

Ohne semantische Zusatzinformationen kann man da konkret kaum was zu 
sagen, wie ein schneller Algorithmus aussehen kann / soll.

Mark Brandis direkt über mir hat schon darauf hingewiesen, dass selbst 
ein verschlafener ATtiny 25 über ein paar paarhundert Bits nur 
schmunzeln würde.

Wenn Du hingegen einen riesigen Datenberg durchzuschaufeln hast, geht 
es, wie auch andere schon geschrieben haben, um Muster, Bedeutung -- 
also Semantik. Wenn die Informationsblöcke immer gleich lang sind und 
nicht 2^(8n) lang sind, also keine n Bytes, sondern irgendwas krummes, 
von mir aus 777 Bits, könnte es allgemein je nach verfügbarem RAM sogar 
angebracht sein, in Assembler oder Low-Level-C über den Speicher zu 
rumpeln, ein Byte/Word/DWord etc. auszulesen, den Inhalt zu kopieren, 
mit Shift-Operationen das Paket rauszuholen (mitlaufender Zähler) und 
aus jedem Bit ein neues Byte(!) zu machen.

Warum? Damit Du danach in einer "vernünftigen" Sprache Deiner Wahl 
(Java(script), C#, Python...) den Verarbeitungsprozess pro Datenblock 
(die angenommenen 777 Bits) auf vielen, vielen Prozessorkernen parallel 
ablaufen lassen kannst. Hier reden wir dann aber schon über echt große 
Datenmengen, die schnell abgearbeitet werden müssen, also von 
irgendeiner Hardware vom Raspi 3 an aufwärts bis zu einem 
ausgewachsenen, massiv-parallelen Cluster. Und sowas ist sogar in C++ 
schon eine ausgesprochen hässliche Angelegenheit, geschweige denn in C 
oder ASM. Als alter "Microsoftie" würde ich das ganze in der 
DotNet-Umgebung laufen lassen (Mono), weil man dort ein echtes 
Schlaraffenland in Sachen Thread-Verwaltung findet, aber ähnliche 
Bibliotheken gibt es bestimmt auch für Java und andere neuere Sprachen.

lepper03 schrieb:
> die dazwischen liegende einfach kopieren. Eigentlich, das ist

Und was machst Du, wenn Du ein Byte, bestehend aus 8 Bit von 
Quellposition 0 an Zielposition 1 kopieren sollst?

Dann kannst Du das Byte nicht einfach kopieren.

Lauf durch die Quellbits und kopiere sie einzeln.
Vielleicht reicht Dir die Geschwindigkeit schon.

Geschwindigkeit gewinnen durch das Kopieren von ganzen Bytes kannst Du 
nur dann, wenn Quellposition und Zielposition bei der Division durch 8 
mit Rest im Rest übereinstimmen.

Anstelle über Optimierungen zu sinnen, solltest Du einfach den naiven 
Kopieralorithmus, bzw. die primitive Bitkopierschleife realisieren.

Die Experten hier haben dann bestimmt noch Ideen, wie sich der 
Kopiervorgang des einzelnen Bits beschleunigen lässt.

Achtung:

An welcher Position im Ziel landet denn Startbit 20?
Bei Bitposition Null oder anderswo?

lepper03 schrieb:
> ok, danke Euch, ich werde mir es jetzt am WE überlegen und mein Ergebnis
> hier posten.

 Die anderen Verfahren mögen zwar in C Programm schöner und kürzer
 aussehen aber Bitschifterei ist immer die schnellste Art.

lepper03 schrieb:
> Mir fällt nichts vernünftiges ein, alles scheint hoch kompliziert zu
> sein :(

Was ist hoch kompliziert? Das was Du hier beschrieben hast:

> startbyte = startbit / 8
> startBit  = startbit % 8
> endbyte = (startbit + length) / 8
> endBit  = (startbit + length) % 8

klingt doch nach einem Ansatz der funktionieren kann, wenn man ihn 
richtig ausprogrammiert.

Ansonsten gilt wie immer:
Teile das zu lösende Problem in kleinere Teilprobleme auf.

lepper03 schrieb:
> und dann die grenzeden Byte(s) (start/end) bearbeiten/extrahieren und
> die dazwischen liegende einfach kopieren. Eigentlich, das ist
> Randproblem.

Das geht nur in Spezialfällen und klappt im Allgemeinen nicht.

Quelle: Startbit Nr. 4 (die 1!)
Länge: 16

0000 1011   0011 1110 1111

Dann muss das Ziel so aussehen:

1011 0011   1110 1111

Wie Du siehst, kannst Du das das zweite Byte nicht einfach kopieren.

=> Probiere den naiven Algorithmus: Bit für Bit kopieren, also
"Bit einlesen, Bit schreiben"

lepper03 schrieb:
> Es geht um ANSI C und TC1797(Infineon)

Der hat doch genug RAM, nimm einfach uint8_t oder bool pro bit und nutze 
normale Arrays.

Fa bin ich ganz bei dir. Wir sind nicht mehr in den Zeiten von 
Mycro-Supra-Nenno-Prozessoren, die nur 64 Bytes zur Verfügung haben. 
Nicht umsonst übersetzt die GCC in der Regel bool in int.