bit invertieren

[hugo (Gast)]

Wie kann man am besten so "mal eben" ein Bit invertieren, um es so an 
einem Port auszugeben?!
Also aus 11101010 mach 01010111

[Peter II (Gast)]

hugo schrieb:
> 11101010

11101010 xor 11111111

xor passend zu deiner Programmiersprache suchen

[Christian H. (netzwanze)]

Das ist aber kein Bit, welches invertiert wird, sondern ein Byte, was 
gespiegelt wird.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

hugo schrieb:
> Wie kann man am besten so "mal eben" ein Bit invertieren, um es so an
> einem Port auszugeben?!
> Also aus 11101010 mach 01010111
Das ist ein invertiertes BYTE... :-o

Und das gabs schon oft hier im Forum. Die Suche wird dir helfen...
http://www.mikrocontroller.net/search?query=Byte+spiegeln&forums[]=1&forums[]=2

EDIT: Mist, Fenster zu lang offen... :-/

[ET-Tutorials (Gast)]

Ein einzelnes Bit kannst di ändern wie im Video gezeigt:
http://et-tutorials.de/1908/bitweise-manipulation/

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ET-Tutorials schrieb:
> Ein einzelnes Bit kannst di ändern
Thema verfehlt...   ;-)

[Stephan (Gast)]

CPL

[Christian W. (chrisw84)]

Werden immer die selben Bits invertiert?
Dann z.B. mit einer Bitmaske!

Viele Grüße

[ich (Gast)]

falls du einen xmega verwendest:

PORTx.OUTTGL = 0xFF; (alle Bits im Ausgangsregister toggeln)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ich schrieb:
> PORTx.OUTTGL = 0xFF; (alle Bits im Ausgangsregister toggeln)

Christian W. schrieb:
> Werden immer die selben Bits invertiert?
> Dann z.B. mit einer Bitmaske!

Stephan schrieb:
> CPL

An alle drei: Thema verfehlt.

Lest mal, was
hugo schrieb:
> Also aus 11101010 mach 01010111

[J.-u. G. (juwe)]

Lothar Miller schrieb:
> Lest mal, was
> hugo schrieb:
>> Also aus 11101010 mach 01010111

hugo schrieb aber auch:
> Wie kann man am besten so "mal eben" ein Bit invertieren, um es so an
> einem Port auszugeben?!

Offensichtlich weiß er selbst nicht was er will und weiß auch nicht was 
ein Bit und was ein Byte ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

J.-u. G. schrieb:
> Offensichtlich weiß er selbst nicht was er will und weiß auch nicht was
> ein Bit und was ein Byte ist.
Das geht offenbar vielen so, die das nicht wissen... ;-)
Nochmal der Link zur Suche, da sind auch ein paar solcher Kandidaten:
> Lothar Miller schrieb:
>> Die Suche wird dir helfen...
>> http://www.mikrocontroller.net/search?query=Byte+spiegeln

Und weil er es selbst nicht weiß, was er will, es aber beschreiben kann, 
gilt die Regel:

Es gibt 2 Arten von Menschen:
1. die, die auf der Basis unzureichender Information extrapolieren können

[Jürgen W. (juergen_w)]

>> Also aus 11101010 mach 01010111

    ldi    r16,0b11101010
    ldi    r18,8    ;8 mal schieben
loop:
    rol    r16
    ror    r17      ;Da kommt das Ergebniss rein
    dec    r18
    brne  loop
    ...

Nicht ausprobiert, deshalb ohne Gewähr ;-)


Grüsse

[hugo (Gast)]

Okay, Ihr habt Recht, ich wusste nicht genau was ich wollte :D.
Also ich will das Byte natürlich Spiegeln. Und das am besten in C.
Es war gestern glaub einfach schon zu spät xD

[Volker Z. (vza)]

char in = 0xEA;
char out = 0;
int loop;

for(loop=0;loop<8;loop++)
{
   if(in & 0x01)
   {
      out |= 0x01;
   }
   in  = in >> 1;
   out = out<< 1;
}

Ohne Gewähr.

Volker

[Jürgen W. (juergen_w)]

    ldi    r16,0b11101010    ;Soll gespiegelt werden
    sec
    rol    r16
lop:  ror    r17          ;Da kommt das Ergebniss rein
    lsl    r16
    brne  lop
    ...

Ist eleganter als oben. Diesmal mit Gewähr, habe es im Simulator 
getestet :-)

Es ist zwar C gefragt, aber vielleicht braucht es ja mal jemand in ASM.

[Klaus (Gast)]

IMHO ist in C eine Tabelle das Schnellste.

MfG Klaus

[Michael D. (etzen_michi)]

Warum schiebst du vor "lop" eine 1 in r16 rein?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

hugo schrieb:
> Und das am besten in C.
Mit meinem Link zur Forumssuche hättest du das gefunden:
Beitrag "Re: reihenfolge der bits in einem byte umdrehen"

[Jürgen W. (juergen_w)]

Michael Dierken schrieb:
> Warum schiebst du vor "lop" eine 1 in r16 rein?

R16 ist solange <>0 bis die 1 im Carry ist. Solange springt dann brne.
Man spart so den Schleifenzähler und ein paar Zyklen..

[Sascha W. (sascha-w)]

Klaus schrieb:
> IMHO ist in C eine Tabelle das Schnellste.
wenn man soviel Speicher übrig hat

Sascha

[Frank M. (ukw) (Moderator)]

Sascha Weber schrieb:
> Klaus schrieb:
>> IMHO ist in C eine Tabelle das Schnellste.
> wenn man soviel Speicher übrig hat

16 Byte reichen dafür. Die Nibbles kann man swappen.

[Christoph db1uq K. (christoph_kessler)]

http://en.wikipedia.org/wiki/Bit-reversal_permutation
"Bit reversal is most important for radix-2 Cooley–Tukey FFT algorithms"

nur um den englischen Begriff auch mal zu nennen

[Peter (Gast)]

Folgender Code auch recht effizient compiliert...

#define M1  (uint8_t)0x01
#define M2  (uint8_t)0x02
#define M3  (uint8_t)0x04
#define M4  (uint8_t)0x08
#define M5  (uint8_t)0x10
#define M6  (uint8_t)0x20
#define M7  (uint8_t)0x40
#define M8  (uint8_t)0x80

uint8_t rotate(uint8_t MyVal)
{
  uint8_t NewVal=0;
  if (MyVal & M1) NewVal |= M8;
  if (MyVal & M2) NewVal |= M7;
  if (MyVal & M3) NewVal |= M6;
  if (MyVal & M4) NewVal |= M5;
  if (MyVal & M5) NewVal |= M4;
  if (MyVal & M6) NewVal |= M3;
  if (MyVal & M7) NewVal |= M2;
  if (MyVal & M8) NewVal |= M1;
  return NewVal;
}

[Frank M. (ukw) (Moderator)]

Peter schrieb:
> Folgender Code auch recht effizient compiliert...

Stimmt! Obwohl er recht lang aussieht, sind es nur 178 Byte erzeugter 
Code beim avr-gcc - inkl. leerer main-Funktion:

Program:     178 bytes (1.1% Full)
Data:          0 bytes (0.0% Full)

Da habe ich das mal eben mit einer Tabelle ausprobiert:

uint8_t
bitsreverse (uint8_t val)
{
    //                      0000  1000  0100  1100  0010  1010  0110  1110  0001  1001  0101  1101  0011  1011  0111  1111
    uint8_t reverse[16] = { 0x00, 0x08, 0x04, 0x0C, 0x02, 0x0A, 0x06, 0x0E, 0x01, 0x09, 0x05, 0x0D, 0x03, 0x0B, 0x07, 0x0F };
    return (reverse[val & 0x0F] << 4) | reverse[val >> 4];
}

Ergebnis:

Program:     266 bytes (1.6% Full)
Data:         16 bytes (1.6% Full)

Das Programm "sieht" zwar kürzer aus, kostet aber doch einiges mehr an 
Speicherplatz...

Zuallerletzt habe ich Volkers Version getestet (mit kleinen 
Modifikationen, z.B. int -> uint8_t):

uint8_t
bitsreverse (uint8_t in)
{
    uint8_t out = 0;
    uint8_t loop;

    for (loop = 0; loop < 8; loop++)
    {
       if (in & 0x01)
       {
           out |= 0x01;
       }
       in  = in >> 1;
       out = out << 1;
    }
    return (out);
}

Ergebnis:

Program:     162 bytes (1.0% Full)
Data:          0 bytes (0.0% Full)

Damit liegt Volkers Version derzeit an der Spitze, was die Sparsamkeit 
an Speicherplatz angeht.

[Frank M. (ukw) (Moderator)]

Beim Austesten stellte ich fest, dass Volkers Version einen Fehler hat. 
Es fehlte das unterste Bit im Ergebnis.

Hier die korrigierte Version:

uint8_t
bitsreverse (uint8_t in)
{
    uint8_t out = 0;
    uint8_t loop;

    for (loop = 0; loop < 8; loop++)
    {
       out <<= 1;

       if (in & 0x01)
       {
           out |= 0x01;
       }

       in  >>= 1;
    }
    return (out);
}

Die Zeile "out <<= 1" musste lediglich vor das if-Statment gezogen 
werden.

Es bleibt aber bei 162 Bytes an Code.

[Michael K. (mmike)]

Und noch ne Funktion:

uint8_t ByteMirror (uint8_t n)
{
  n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa); 
  n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc); 
  n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0); 
  return n;
}

Grüße,
Michael

[Peter (Gast)]

Volkers Version ist etwas kürzer, dafür etwas langsamer bei der 
Ausführung. Bleibt beim Anwender zu entscheiden was für ihn wichtiger 
ist, Code-Size oder Code-Speed! ;o)

[Komisch (Gast)]

Lothar Miller schrieb:
> Lest mal, was
> hugo schrieb:
>> Also aus 11101010 mach 01010111

Es geht doch nichts über einen passenden Titel. Warum sagt er dann nicht 
gleich "Byte spiegeln" oder Bitfolge invertieren.
Invertieren bezogen auf ein Bit ist immer noch der Not-Operator.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hier mal ein Zwischenstand. Der Speicherbedarf wurde ermittelt, indem 
vorneweg alles mit mirror auskommentiert wurde, und danach der 
Speicherplatzzuwachs festgestellt wurde (Atmega32, -Os, avr-gcc 4.3.2):

#include <avr/io.h>

volatile uint8_t cnt;

unsigned char mirror( unsigned char a ) // 90 Bytes
{
  a = ((a >> 4) & 0x0F) | ((a << 4) & 0xF0);
  a = ((a >> 2) & 0x33) | ((a << 2) & 0xCC);
  a = ((a >> 1) & 0x55) | ((a << 1) & 0xAA);
  return a;
}


#define M1  (uint8_t)0x01
#define M2  (uint8_t)0x02
#define M3  (uint8_t)0x04
#define M4  (uint8_t)0x08
#define M5  (uint8_t)0x10
#define M6  (uint8_t)0x20
#define M7  (uint8_t)0x40
#define M8  (uint8_t)0x80

unsigned char mirror( unsigned char MyVal ) // 52 Bytes
{
  uint8_t NewVal=0;
  if (MyVal & M1) NewVal |= M8;
  if (MyVal & M2) NewVal |= M7;
  if (MyVal & M3) NewVal |= M6;
  if (MyVal & M4) NewVal |= M5;
  if (MyVal & M5) NewVal |= M4;
  if (MyVal & M6) NewVal |= M3;
  if (MyVal & M7) NewVal |= M2;
  if (MyVal & M8) NewVal |= M1;
  return NewVal;
}

unsigned char mirror( unsigned char in ) // 52 Bytes
{
    uint8_t out = 0;
    uint8_t loop;
    for (loop = 0; loop < 8; loop++) {
       out <<= 1;
       if (in & 0x01) out |= 0x01;
       in  >>= 1;
    }
    return out;
}

uint8_t mirror (uint8_t val) // 208 Bytes
{
    uint8_t out;
    //                      0000  1000  0100  1100  0010  1010  0110  1110  0001  1001  0101  1101  0011  1011  0111  1111
    uint8_t reverse[16] = { 0x00, 0x88, 0x44, 0xCC, 0x22, 0xAA, 0x66, 0xEE, 0x11, 0x99, 0x55, 0xDD, 0x33, 0xBB, 0x77, 0xFF };
    out  = reverse[val&0x0F] & 0xF0;
    out |= reverse[val>>4]   & 0x0F;
    return out;
}

/*****************************************************************/
int main (void)
{
    while (1)
    {
      cnt = cnt+1;
      cnt = mirror(cnt);
    } 
}

Komisch schrieb:
> Es geht doch nichts über einen passenden Titel. Warum sagt er dann nicht
> gleich "Byte spiegeln" oder Bitfolge invertieren.
Vielleicht, weil ihm der Begriff nicht geläufig war...

[Frank M. (ukw) (Moderator)]

Michael K. schrieb:
> Und noch ne Funktion:
>
>

> uint8_t ByteMirror (uint8_t n)
> {
>   n = ((n >> 1) & 0x55) | ((n << 1) & 0xaa);
>   n = ((n >> 2) & 0x33) | ((n << 2) & 0xcc);
>   n = ((n >> 4) & 0x0f) | ((n << 4) & 0xf0);
>   return n;
> }
>

Stimmt, die habe ich hier auf µC.net auch schon öfters rumschwirren 
sehen.

Ergebnis:

Program:     180 bytes (1.1% Full)
Data:          0 bytes (0.0% Full)

Das ist dann der 3. Platz... aber knapp :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lothar Miller schrieb:
> uint8_t mirror (uint8_t val) // 208 Bytes
Frank M. schrieb:
> Program:     180 bytes (1.1% Full)
Ich muß mal meinen Compiler updaten... ;-)

[Frank M. (ukw) (Moderator)]

Lothar Miller schrieb:
> Hier mal ein Zwischenstand. Der Speicherbedarf wurde ermittelt, indem
> vorneweg alles mit mirror auskommentiert wurde, und danach der
> Speicherplatzzuwachs festgestellt wurde (Atmega32, -Os, avr-gcc 4.3.2):

Erstaunlich, was bei Dir an relativen(!) Unterschieden rauskommt. Bei 
mir ist es ATmega168, -Os, avr-gcc 4.3.3.

[Frank M. (ukw) (Moderator)]

Lothar Miller schrieb:
> Lothar Miller schrieb:
>> uint8_t mirror (uint8_t val) // 208 Bytes
> Frank M. schrieb:
>> Program:     180 bytes (1.1% Full)
> Ich muß mal meinen Compiler updaten... ;-)

Da ist ein leeres main() auch mit drin. Das halte ich für legitim, da 
der Compiler auch bei Nicht-Aufruf die Funktionen NICHT wegoptimieren 
kann, da sie nicht als static deklariert sind. Wie ist das bei Dir? 
Zählst Du Deine (aufwendigere) main-Funktion mit?

EDIT: Bei mir frisst die leere main-Funktion 138 Byte, die müsste man 
also von meinen Werten abziehen. Dann sieht der 4.3.3er Compiler um 
einiges besser aus als Dein 4.3.2er.

[stru_aus (Gast)]

hübsche sammlung von verschiedenen ansätzen zum bitreihenfolge 
invertieren:

http://graphics.stanford.edu/~seander/bithacks.html#BitReverseObvious

geht als schleife, mit arrays, und ein paar andere "hacks".

die ganzen tipps da sind öfters recht praktisch.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Frank M. schrieb:
> Wie ist das bei Dir?
So sieht die "leere" main aus:

int main (void)
{
    while (1)
    {
      cnt = cnt+1;
     // cnt = mirror(cnt);
    } 
}

[Volker Z. (vza)]

Ich glaube wir haben Hugo (TO) etwas überfordert. Er meldet sich gar 
nicht mehr!

Hallo Huuuugooooo.
Konten wir dir helfen oder haben wir dich nur verwirrt?

volker

[hugo (Gast)]

Das ist ja echt der Wahnsinn xD
Ihr ward echt seeehr krass...
Naja das ganze ist so: Ich hab ein Display und das hängt direkt an einem 
Port. Aus Layout technischen Gründen müsste ich ALLE Leitungen kreuzen, 
was natürlich ziemlich dumm ist. Jetzt habe ich überlegt einfach immer 
das Byte zu spiegeln, damit ich es so übertragen kann. Ich denke aber 
bei einem Grafik LCD ist das totaler Quatsch, da der AVR ja 2/3 seiner 
Zeit nur damit verbringt Daten zu spiegeln. Da er später noch andere 
Dinger erledigen soll wäre das also dumm.
Nun bin ich am Überlegen einen SMD-Stecker zu nehmen, dann kann ich die 
Leiterbahnen von oben anfahren (kann Zuhause nur einseitige Platinen mit 
min. 8mil Leiterbahnen).

Aber ich finde diesen Thread echt klasse! Wenn wir nun vielleicht alles 
zusammenstellen und irgendwo festhalten wär das schonmal toll!

Danke euch!

[Peter (Gast)]

Anbei die reine Codegrösse für die Funktionen und die Anzahl CPU-Zyklen 
für die Verarbeitung (Function Call bis Return)

Bei mirror4() habe ich den Array auf static gesetzt, dann werden dessen 
Werte nur einmal im StartUpCode initialisiert und nicht bei jedem 
Funktions-Aufruf. (Codesize und CPU-Zyklen für diese Initialisierung 
sind nicht dabei)

#include <avr/io.h>

volatile uint8_t cnt;

unsigned char mirror1(unsigned char a ) // 42 Bytes, 28 Cycles
{
  a = ((a >> 4) & 0x0F) | ((a << 4) & 0xF0);
  a = ((a >> 2) & 0x33) | ((a << 2) & 0xCC);
  a = ((a >> 1) & 0x55) | ((a << 1) & 0xAA);
  return a;
}


#define M1  (uint8_t)0x01
#define M2  (uint8_t)0x02
#define M3  (uint8_t)0x04
#define M4  (uint8_t)0x08
#define M5  (uint8_t)0x10
#define M6  (uint8_t)0x20
#define M7  (uint8_t)0x40
#define M8  (uint8_t)0x80

unsigned char mirror2(unsigned char MyVal ) // 40 Bytes, 27 Cycles
{
  uint8_t NewVal=0;
  if (MyVal & M1) NewVal |= M8;
  if (MyVal & M2) NewVal |= M7;
  if (MyVal & M3) NewVal |= M6;
  if (MyVal & M4) NewVal |= M5;
  if (MyVal & M5) NewVal |= M4;
  if (MyVal & M6) NewVal |= M3;
  if (MyVal & M7) NewVal |= M2;
  if (MyVal & M8) NewVal |= M1;
  return NewVal;
}

unsigned char mirror3(unsigned char in ) // 24 Bytes, 81 Cycles
{
    uint8_t out = 0;
    uint8_t loop;
    for (loop = 0; loop < 8; loop++) {
       out <<= 1;
       if (in & 0x01) out |= 0x01;
       in  >>= 1;
    }
    return out;
}


uint8_t mirror4(uint8_t val)  // 34 Bytes, 26 Cycles
{
    //                             0000  1000  0100  1100  0010  1010  0110  1110  0001  1001  0101  1101  0011  1011  0111  1111
    static uint8_t reverse[16] = { 0x00, 0x88, 0x44, 0xCC, 0x22, 0xAA, 0x66, 0xEE, 0x11, 0x99, 0x55, 0xDD, 0x33, 0xBB, 0x77, 0xFF };
    uint8_t out;
    out  = reverse[val&0x0F] & 0xF0;
    out |= reverse[val>>4]   & 0x0F;
    return out;
}

/*****************************************************************/
int main (void)
{
    while (1)
    {
      //------------------------------
      cnt = 0xA5;
      cnt = mirror1(cnt);
      //------------------------------
      cnt = 0xA5;
      cnt = mirror2(cnt);
      //------------------------------
      cnt = 0xA5;
      cnt = mirror3(cnt);
      //------------------------------
      cnt = 0xA5;
      cnt = mirror4(cnt);
      //------------------------------
    }
}

[Frank M. (ukw) (Moderator)]

Peter schrieb:
> Anbei die reine Codegrösse für die Funktionen und die Anzahl CPU-Zyklen
> für die Verarbeitung (Function Call bis Return)

Welche avr-gcc-Version? Welche Optimierungsstufe? Wie wir gestern 
gesehen haben, gibt es allein bei der Version erhebliche Unterschiede im 
Ergebnis.

> Bei mirror4() habe ich den Array auf static gesetzt, dann werden dessen
> Werte nur einmal im StartUpCode initialisiert und nicht bei jedem
> Funktions-Aufruf.

Ohja, das hatte ich doch glatt übersehen. Damit liegt mirror4 mit der 
Ausführungszeit an erster Stelle und vom Speicherplatz immerhin noch an 
2. Stelle.

Interessant, dass mirror3() als kleinste Funktion auch die langsamste 
ist.

Danke für die Aufstellung.

Gruß,

Frank

[hugo (Gast)]

Also das ist ja super!
Wo speichern wir das jetzt ab?! ;-)

[MWS (Gast)]

hugo schrieb:
> Also ich will das Byte natürlich Spiegeln. Und das am besten in C.

Na, wenn nicht ausschließlich C, dann hat auch noch 'ne Bascom-Version 
Platz ;D

$Regfile = "m32def.dat"
$Crystal = 8000000
$hwstack = 32
$swstack = 32
$framesize = 32

Dim Var_In As Byte , Var_Out As Byte

Var_In = &B11011001
Print Bin(Var_In)

  !LDS  R16, {Var_In}
  !BST  R16, 0
  !BLD  R17, 7
  !BST  R16, 1
  !BLD  R17, 6
  !BST  R16, 2
  !BLD  R17, 5
  !BST  R16, 3
  !BLD  R17, 4
  !BST  R16, 4
  !BLD  R17, 3
  !BST  R16, 5
  !BLD  R17, 2
  !BST  R16, 6
  !BLD  R17, 1
  !BST  R16, 7
  !BLD  R17, 0
  !STS  {Var_Out}, R17

Print Bin(Var_Out)

End

40Bytes, 20 Cycles.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MWS schrieb:
> dann hat auch noch 'ne Bascom-Version Platz ;D
>   !LDS  R16, {Var_In}
>   !BST  R16, 0
Naja. Ich würde sagen, das fällt fast schon unter "Assembler-Doping"...

> 40Bytes, 20 Cycles.
Das ist jetzt aber noch keine richtige Unterroutine...
>> Peter schrieb:
>>> Anbei die reine Codegrösse für die Funktionen und die Anzahl CPU-Zyklen
>>> für die Verarbeitung (Function Call bis Return)

[Arc N. (arc)]

hugo schrieb:
> Das ist ja echt der Wahnsinn xD
> Ihr ward echt seeehr krass...
> Naja das ganze ist so: Ich hab ein Display und das hängt direkt an einem
> Port. Aus Layout technischen Gründen müsste ich ALLE Leitungen kreuzen,
> was natürlich ziemlich dumm ist. Jetzt habe ich überlegt einfach immer
> das Byte zu spiegeln, damit ich es so übertragen kann. Ich denke aber
> bei einem Grafik LCD ist das totaler Quatsch, da der AVR ja 2/3 seiner
> Zeit nur damit verbringt Daten zu spiegeln. Da er später noch andere
> Dinger erledigen soll wäre das also dumm.

Bei der Initialisierung des GLCD kann man auch entsprechende Konstante 
nehmen (und das kommentieren), die Fonts zur Textausgabe lassen sich 
auch vorher spiegeln/passend generieren und die Routinen zum 
Pixel-Setzen/Linien-Zeichnen kann man auch passend schreiben...

[MWS (Gast)]

Lothar Miller schrieb:
> Naja. Ich würde sagen, das fällt fast schon unter "Assembler-Doping"...

Da hast Du natürlich recht, da sich aber Assembler bei Bascom äußerst 
problemlos in Basic-Code einbetten lässt, so ist das legitim.

> Das ist jetzt aber noch keine richtige Unterroutine...

Das sind sie im C-Beispiel auch nicht. Nur mirror2 wird über einen CALL 
aufgerufen, alles andere wird vom Compiler Inline eingebaut (mit -Os).
Und zwar wiederholt, zweimal mirror1 aufgerufen wird auch zweimal als 
Inline compiliert. Wahrscheinlich weil bei der kleinen Codegröße der 
Funktion der Overhead unrentabel ist.

>>>> Anbei die reine Codegrösse für die Funktionen und die Anzahl CPU-Zyklen
>>>> für die Verarbeitung (Function Call bis Return)

Eine Bascom-Sub, die auch tatsächlich als Sub eingebunden ist, benötigt 
dann 39 Cycles, liegt daran, daß die Variablenzeiger auf den Frame 
gehen/von dort geholt werden müssen.

[Räuber Hotzenplotz (Gast)]

Also die Bascom Variante von MWS (Gast) gefällt mir doch sehr.
Wie könnte ich das auf C übertragen?
Geht das in C überhaupt, Werte an Assembler zu übergeben und 
zurückzubekommen?

[MWS (Gast)]

Räuber Hotzenplotz schrieb:
> Wie könnte ich das auf C übertragen?

Sollte per Inline Assembler gehen, ist aber im Vergleich zu dem 
Gezeigten relativ kompliziert, der C-Compiler hat's nicht gern, wenn man 
sich einmischt.

Vorteil meiner Version ist die völlig freie Bitzuweisung, somit lassen 
sich einfach die Anschlüsse intern "umverdrahten".

So entstand dieser Codeteil auch, wurde in ein Lib eingebunden um 
entsprechend einem anderes Platinenlayout für ein Display mit einem 
I2C-Expander PCF8574 die Pins frei zuweisen zu können.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MWS schrieb:
> Das sind sie im C-Beispiel auch nicht. Nur mirror2 wird über einen CALL
> aufgerufen, alles andere wird vom Compiler Inline eingebaut (mit -Os).
Das schon. Aber die Aufrufparameter sind frei wählbar.

> Eine Bascom-Sub, die auch tatsächlich als Sub eingebunden ist, benötigt
> dann 39 Cycles
Liegt damit annähernd gleichauf zur Lösung mirror2, wo ja auch beliebige 
Bits zugeordnet werden könnten.

[MWS (Gast)]

Lothar Miller schrieb:
> Das schon. Aber die Aufrufparameter sind frei wählbar.

Wenn man Speed braucht, dann ist's egal, ob die Aufrufparameter frei 
wählbar sind. Speziell für den Fall eine Pinbelegung "umzubiegen" wird 
dieser Codeblock in die ausgebende Funktion eingebaut, da brauch' ich 
keinen Call auf eine Funktion machen, und dann sind wir wieder bei 20 
Takten. Da beißt die Maus keinen Faden ab.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MWS schrieb:
> Da beißt die Maus keinen Faden ab.
Es ging ja nicht um den Faden der Maus, sondern um die 
Vergleichbarkeit... ;-)

[MWS (Gast)]

Lothar Miller schrieb:
> Es ging ja nicht um den Faden der Maus, sondern um die
> Vergleichbarkeit... ;-)

Ja, und mir ging's um die Verwendbarkeit im Sinnes des TEs :D

[MWS (Gast)]

Um auch das noch zu beantworten:

Räuber Hotzenplotz schrieb:
> Wie könnte ich das auf C übertragen?
> Geht das in C überhaupt, Werte an Assembler zu übergeben und
> zurückzubekommen?

unsigned char mirror5(unsigned char in ) // 21 Takte
{
   unsigned char out;

   asm volatile ( 
    "bst  %[in_reg], 0           \n\t"    
    "bld  %[out_reg],7           \n\t"    
    "bst  %[in_reg], 1           \n\t"    
    "bld  %[out_reg],6           \n\t"    
    "bst  %[in_reg], 2           \n\t"    
    "bld  %[out_reg],5           \n\t"    
    "bst  %[in_reg], 3           \n\t"    
    "bld  %[out_reg],4           \n\t"    
    "bst  %[in_reg], 4           \n\t"    
    "bld  %[out_reg],3           \n\t"    
    "bst  %[in_reg], 5           \n\t"    
    "bld  %[out_reg],2           \n\t"    
    "bst  %[in_reg], 6           \n\t"    
    "bld  %[out_reg],1           \n\t"    
    "bst  %[in_reg], 7           \n\t"    
    "bld  %[out_reg],0           \n\t"    
         : [out_reg] "=&r" (out), [in_reg] "+r" (in)
   );
   return out;
}

[Räuber Hotzenplotz (Gast)]

@MWS (Gast):
Ganz vielen Dank für die Mühe!   :-)
: [out_reg] "=&r" (out), [in_reg] "+r" (in)
verstehe ich nicht so ganz (bin Anfänger in C )
Werde es am Montag testen, wenn ich wieder in der "Firma" bin ;-)
Hoffentlich geht das mit AVRStudio4 und WINAVR...
Ich wär so froh   :-)

[MWS (Gast)]

Räuber Hotzenplotz schrieb:
> : [out_reg] "=&r" (out), [in_reg] "+r" (in)
> verstehe ich nicht so ganz

Nennt sich "clobber list". Ich fand's interessant wie's dem Compiler 
beizubringen ist, mach' normalerweise nichts in C-asm. Du kannst 
übrigens auch mirror2 nehmen, da wird sehr schöner und kurzer Code 
erzeugt. Funktional ist's gleich.

[Markus G. (thechief)]

Hallo Räuber, :-)

ich habs mal kurz für Dich getestet, damit Du am Montag beruhigt in die 
Firma fahren kannst:

unsigned char mirror5(unsigned char);  // Prototyp

int main (void)
{
  mirror5 (234);
}


unsigned char mirror5(unsigned char in ) // 21 Takte
{
   unsigned char out;

   asm volatile ( 
    "bst  %[in_reg], 0           \n\t"    
    "bld  %[out_reg],7           \n\t"    
    "bst  %[in_reg], 1           \n\t"    
    "bld  %[out_reg],6           \n\t"    
    "bst  %[in_reg], 2           \n\t"    
    "bld  %[out_reg],5           \n\t"    
    "bst  %[in_reg], 3           \n\t"    
    "bld  %[out_reg],4           \n\t"    
    "bst  %[in_reg], 4           \n\t"    
    "bld  %[out_reg],3           \n\t"    
    "bst  %[in_reg], 5           \n\t"    
    "bld  %[out_reg],2           \n\t"    
    "bst  %[in_reg], 6           \n\t"    
    "bld  %[out_reg],1           \n\t"    
    "bst  %[in_reg], 7           \n\t"    
    "bld  %[out_reg],0           \n\t"    
         : [out_reg] "=&r" (out), [in_reg] "+r" (in)
   );
   return out;
}

Getestet mit AVR-Studio 4.18 (Build 716) / Amtel 8515 Simulator, lässt 
sich einwandfrei compilieren!


Gruß

Markus

[Johann L. (gjlayde)]

Und warum Inline-Assembler???

#include <stdint.h>

uint8_t swap (uint8_t a)
{
    uint8_t c = a >> 7;
    
    if (a & (1 << 6))  c |= 1 << 1;
    if (a & (1 << 5))  c |= 1 << 2;
    if (a & (1 << 4))  c |= 1 << 3;
    if (a & (1 << 3))  c |= 1 << 4;
    if (a & (1 << 2))  c |= 1 << 5;
    if (a & (1 << 1))  c |= 1 << 6;
    if (a & (1 << 0))  c |= 1 << 7;
    return c;
}

Belegt nur 2 Register, das Input-Register bleibt erhalten und braucht 19 
Ticks + RET (deviceabhängig), hier avr-gcc 4.6.1:

swap:
  mov r25,r24
  rol r25
  clr r25
  rol r25
  sbrc r24,6
  ori r25,lo8(2)
  sbrc r24,5
  ori r25,lo8(4)
  sbrc r24,4
  ori r25,lo8(8)
  sbrc r24,3
  ori r25,lo8(16)
  sbrc r24,2
  ori r25,lo8(32)
  sbrc r24,1
  ori r25,lo8(64)
  sbrc r24,0
  ori r25,lo8(-128)
  mov r24,r25
  ret

In Assembler geht auch

LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest
LSL src  $  ROR dest