Zwei Bytes zusammenfassen

[Fridel (Gast)]

Wie ist es möglich aus 2 Bytes ein Byte zu gewinnen, indem jedes zweite 
Bit ausgelassen wird. Als Controller habe ich den ATTiny2313.

Kennt jemand einen schnellen Algorithmus?

Byte 0          Byte 2
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Neues Byte
7 5 3 1 7 5 3 1

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

neues_byte = byte0&0x80 + ((byte0&0x20)<<2) + ((byte0&0x08)<<4) + ...

[Amateur (Gast)]

Möglicherweise wäre ein Beispiel, mit zwei signifikant unterschiedlichen 
Bytes, nicht verkehrt.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

(byte0 & 0xcc) | (byte1 & 0x66)

[Klaus (Gast)]

Wenn 256 Bytes Platz im Flash ist, kann man eine Tabelle verwenden:

neues_byte = (table[byte0] << 4) + table[byte2];

Das Schieben könnte man auch noch einsparen, wenn man nochmal 256 Bytes 
Flash spendiert.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Uwe B. schrieb:
> (byte0 & 0xcc) | (byte1 & 0x66)

Das ist falsch, die Bits werden abwechselnd geschoben, oder hab ich da 
was übersehen?

[Knut B. (Firma: TravelRec.) (travelrec)]

bst Byte2, 7
bld Byte0, 7
bst Byte2, 5
bld Byte0, 6
bst Byte2, 3
bld Byte0, 5
bst Byte2, 1
bld Byte0, 4
bst Byte1, 7
bld Byte0, 3
bst Byte1, 5
bld Byte0, 2
bst Byte1, 3
bld Byte0, 1
bst Byte1, 1
bld Byte0, 0

[Kirsch (Gast)]

Fridel schrieb:
> Byte 0          Byte 2
> 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
>
> Neues Byte
> 7 5 3 1 7 5 3 1

Byte A
a7 a6 a5 a4 a3 a2 a1 a0

Byte B
b7 b6 b5 b4 b3 b2 b1 b0

Neues Byte
a7 a5 a4 a3 a1 b7 b5 b3 b1


Das geht nicht einfach, da must du jedes Bit manuell an die richtige 
Stelle schieben:

Wolfgang R. schrieb:
> neues_byte = byte0&0x80 + ((byte0&0x20)<<2) + ((byte0&0x08)<<4) + ...

[Karl M. (Gast)]

Naja,

Neues Byte
a7 a5 a4 a3 a1 b7 b5 b3 b1

sind neu Bits...

[npn (Gast)]

Karl M. schrieb:
> Naja,
>
> Neues Byte
> a7 a5 a4 a3 a1 b7 b5 b3 b1
>
> sind neu Bits...

lass a4 weg, dann passt es :-)

[Fridel (Gast)]

@ Wolfgang

Das Prinzip funktioniert. Verschlingt allerdings 50 Bytes.

nb  = (b0 & 0x80)
   + ((b0 & 0x20) << 1)
   + ((b0 & 0x08) << 2)
   + ((b0 & 0x02) << 3)
   + ((b1 & 0x80) >> 4)
   + ((b1 & 0x20) >> 3)
   + ((b1 & 0x08) >> 2)
   + ((b1 & 0x02) >> 1);

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Der Lookup-Table verschlingt vermutlich mehr... ;-) Dafür ist er 
deutlich schneller.

[Fridel (Gast)]

Wolfgang R. schrieb:
> Der Lookup-Table verschlingt vermutlich mehr... ;-) Dafür ist er
> deutlich schneller.

Man könnte ja noch auf Assembler umsteigen. Das obige Beispiel von Knut 
werde ich mir auch noch ausprobieren.

[Klaus (Gast)]

die bst/bld-Lösung ist schön.  Da lohnt die Tabelle höchstens noch, 
wenn's wirklich auf jeden Takt ankommt.

[beric (Gast)]

Keine Ahnung :-)

; result in R0, byte 1 in R1, byte 2 in R2
; destroys R1 and R2 ! 22 CLKs!

rol R1  ; bit to carry
rol R0  ; carry to result

rol R1  ; skip one bit
rol R1  ; bit to carry
rol R0  ; carry to result

rol R1  ; skip one bit
rol R1  ; bit to carry
rol R0  ; carry to result

rol R1  ; skip one bit
rol R1  ; bit to carry
rol R0  ; carry to result

rol R2  ; bit to carry
rol R0  ; carry to result

rol R2  ; skip one bit
rol R2  ; bit to carry
rol R0  , carry to result

rol R2  ; skip one bit
rol R2  ; bit to carry
rol R0  ; carry to result

rol R2  ; skip one bit
rol R2  ; bit to carry
rol R0  ; carry to result

[c-hater (Gast)]

beric schrieb:

> Keine Ahnung :-)

Stimmt, hast du nicht.

> 22 CLKs!

Und was soll daran besser sein als die 16 Ticks der bld/bst-Lösung?

[C-Beginner (Gast)]

Hallo,

ernsthafte Frage (ganz ohne Ironie):

Fridel, wofür soll das gut sein? Was kommt da heraus ausser das ein Byte 
verschwindet - steckt da irgendeine clevere Logik dahinter?

mfg
C-Beginner

[Yalu X. (yalu) (Moderator)]

In C (mit AVR-Builtin __builtin_avr_insert_bits):

#include <stdint.h>

uint8_t oddbits(uint8_t byte0, uint8_t byte2) {
  byte0 = __builtin_avr_insert_bits (0x7531ffff, byte0, byte0);
  byte0 = __builtin_avr_insert_bits (0xffff7531, byte2, byte0);
  return byte0;
}

Das ergibt:

oddbits:
  mov r0,r24
  bst r0,1
  bld r24,4
  bst r0,3
  bld r24,5
  bst r0,5
  bld r24,6
  bst r22,1
  bld r24,0
  bst r22,3
  bld r24,1
  bst r22,5
  bld r24,2
  bst r22,7
  bld r24,3
  ret

[c-hater (Gast)]

Yalu X. schrieb:

> In C (mit AVR-Builtin __builtin_avr_insert_bits):
[...]

D.h.: Mit der doch recht speziellen Kenntnis einer einzigartigen 
Besonderheit des AVR-GCC kann man in C immerhin (nicht ganz) die 
Performance erreichen, die in Assembler möglich ist, wenn man einfach 
nur die rund hundert simplen Instruktionen des AVR kennt und beherrscht 
(statt der hunderte Seiten füllenden Details von C an sich und der 
weitere hunderte Seiten füllenden Beschreibungen eines speziellen 
Compilers bezogen auf ein spezielles Target-System)?

Außerdem: Sollten die angeblich doch so hocheffizent optimierenden 
C-Compiler nicht einfach alleine herausfinden können, wann der Einsatz 
der spezialisierten Macros sinnvoll wäre? Algorithmisch sehe ich da 
jedenfalls kein Problem. Es muß also wohl daran liegen, dass die 
Compiler doch nicht so gut sind, wie die C-Apologeten immer behaupten, 
dass sie es wären...

[Fridel (Gast)]

> D.h.: Mit der doch recht speziellen Kenntnis einer einzigartigen
> Besonderheit des AVR-GCC kann man in C immerhin (nicht ganz) die
> Performance erreichen, ...

Deinem Beitrag entnehme ich, dass es in Assembler noch besser umzusetzen 
ist (kürzer?, schneller?). Kannst du ein Programm posten?

[S. Landolt (Gast)]

Das von Knut Ballhause. Wenn man wie Yalu X. ein Quellbyte mit dem 
Zielbyte überschreibt, dann kann man Byte0 durch Byte2 ersetzen, die 
ersten beiden Zeilen weglassen, und ist bei 14 Takten.