Bits spiegeln in Hardware oder in Software?

spess53 schrieb:
> Hi
>
>>Frage 2: wie spiegelt man effizient am AVR (in C!)
>
> Beitrag "Re: LCD Datenleitungen invertieren"
>
> MfG Spess

S U P E R ! Danke! (nach "invertieren" hab ich natürlich nicht 
gesucht...)

>dafür ein kleiner Alptraum beim layouten (wird einseitig).
Wenn Dir das schon Albträme bereitet, dann solltest Du Deinen 
Beruf/Hobby wechseln!

Das einzige Richtige: Schliesse das Teil richtig an!

-Display oder uC auf die andere LPL-Seite?
-Anderen uC Port benutzen mit passender Pin folge?
-Signale von "innen" bzw. von der anderen Seite auf das Display führen?
-Drähte (schlimmstenfalls)

Eine Frage noch zur mirror() Funktion vom Peter:

1

unsigned char mirror( unsigned char n )

2

{

3

  n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa); 

4

  n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc); 

5

  n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0); 

6

  return n;

7

}

gibts einen Trick die Funktion in ein Preprozessor-Makro zu wandlen, 
damit der Preprozessor bei Aufruf mit konstanten Werten gleich das 
Ergebnis errechnet?

Michael Reinelt schrieb:

> gibts einen Trick die Funktion in ein Preprozessor-Makro zu wandlen,
> damit der Preprozessor bei Aufruf mit konstanten Werten gleich das
> Ergebnis errechnet?

1

#define mirror(bits) __builtin_avr_insert_bits (0x01234567, bits, 0)

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/AVR-Built_002din-Functions.html#AVR-Built_002din-Functions

Johann L. schrieb:

>

1

#define mirror(bits) __builtin_avr_insert_bits (0x01234567, bits,

2

> 0)

ich bin sprachlos....

da musste ich doch sofort mal ein testprogramm mit drei varianten 
machen:

V1:

1

uint8_t mirror1( uint8_t n )

2

{

3

  n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa); 

4

  n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc); 

5

  n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0); 

6

  return n;

7

}

wird zu

1

  mov r18,r24

2

  ldi r19,0

3

  lsl r18

4

  rol r19

5

  andi r18,170

6

  lsr r24

7

  andi r24,lo8(85)

8

  or r24,r18

9

  mov r18,r24

10

  ldi r19,0

11

  lsl r18

12

  rol r19

13

  lsl r18

14

  rol r19

15

  andi r18,204

16

  lsr r24

17

  lsr r24

18

  andi r24,lo8(51)

19

  or r24,r18

20

  swap r24

21

  ret

V2:

1

uint8_t mirror2( uint8_t n )

2

{

3

    return __builtin_avr_insert_bits (0x01234567, n, 0);

4

}

wird zu

1

  lsl r24

2

  adc r24,__zero_reg__

3

  mov __tmp_reg__,r24

4

  bst r0,1

5

  bld r24,7

6

  bst r0,2

7

  bld r24,6

8

  bst r0,3

9

  bld r24,5

10

  bst r0,5

11

  bld r24,3

12

  bst r0,6

13

  bld r24,2

14

  bst r0,7

15

  bld r24,1

16

  ret

Und der test mit konstantem Wert:

1

uint8_t mirror3 (void)

2

{

3

    return __builtin_avr_insert_bits (0x01234567, 0x12, 0);

4

}

wird zu

1

  ldi r24,lo8(72)

2

  ret

Sieht doch gut aus, oder?

@Volker
>Was für ein Blech Du da redest...
>Wahrscheinlich müsste seine Platine größer werden, um das einseitige(!)
Ich denke wenn man etwas Hirnschmalz investiert, würde die Platine weder 
teurer noch grösser!

Alle Konstanten, also auch Zeichensatztabellen kann man schon zur 
Compilezeit durch das Macro jagen.
Da kostet das Spiegeln also keine zusätzliche Laufzeit.

Peter

Peter Dannegger schrieb:
> Alle Konstanten, also auch Zeichensatztabellen kann man schon zur
> Compilezeit durch das Macro jagen.
> Da kostet das Spiegeln also keine zusätzliche Laufzeit.

Da hatte ich meine Zweifel, da deine Funktion ja streng genommen kein 
Makro ist, und sich auch schwer in ein solches umwandlen lässt (weil n 
mehrmals zugewiesen/verwendet wird).

Allerdings steigt meine Hochachtung vor dem gcc:

1

uint8_t mirror1( uint8_t n )

2

{

3

  n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa); 

4

  n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc); 

5

  n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0); 

6

  return n;

7

}

8

9

uint8_t test4 (void)

10

{

11

    return mirror1(0x12);

12

}

er macht tatsächlich folgendes aus test4:

1

  ldi r24,lo8(72)

2

  ret

Michael Reinelt schrieb:
> Da hatte ich meine Zweifel, da deine Funktion ja streng genommen kein
> Makro ist, und sich auch schwer in ein solches umwandlen lässt (weil n
> mehrmals zugewiesen/verwendet wird).

Daher macht man sowas auch eher mit einer Inline-Funktion. Wenn man ganz 
sicher gehen will, dass der Compiler sie inlint, kann man es auch 
erzwingen:

1

static inline __attribute__((__always_inline__)) uint8_t mirror1( uint8_t n )

2

{

3

  n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa); 

4

  n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc); 

5

  n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0); 

6

  return n;

7

}

Man kann die Entscheidung aber auch dem Compiler überlassen und ihm nur 
mit dem Wörtchen "inline" einen Tipp geben. Bei nicht-konstanten Werten 
kostet der Funktionsaufruf ja im Vergleich zur Codegröße nicht viel 
zusätzliche Zeit, aber ggf. recht viel Programmspeicher, wenn man ihn 
oft kopiert.

Wichtig ist auch noch, dass die Funktion in der gleichen 
Compilierungseinheit (C-Datei) definiert ist, um die Optimierung zu 
ermöglichen. Daher würde ich sie als "static inline"-Funktion in eine 
Headerdatei packen.

Bronco schrieb:
> Hat den Nachteil, daß es mehr Ressourcen frißt als eine perfekte
> Durchoptimierung, aber den Vorteil, daß Du Deine Display-Module
> unabhängig von der Hardware sind, und logisch und einfach
> nachzuvollziehen bleiben.

Wenn man die Hardwareabstraktion ebenfalls in einer Header-Datei mit 
Inline-Funktionen macht, kostet das praktisch keine Ressourcen. :-)

Fabian O. schrieb:
> Daher macht man sowas auch eher mit einer Inline-Funktion. Wenn man ganz
> sicher gehen will, dass der Compiler sie inlint, kann man es auch
> erzwingen:

Streng genommen hat das gar nichts mit inlining zu tun, sondern mit 
"constant folding". Und das hat mich überrascht, wie gut dieses constant 
folding funktioniert.

Wenn man 256 Byte Flash übrig hat, könnte es auch eine Lookuptable tun. 
Die Wird bei der Ausführung mit dynamischen Argumenten keine 8 Takte 
brauchen...
mfg mf