Byte verschieben und mit Eingang auffüllen.

[Philipp L. (viech)]

Hallo,

ich möchte gern ein Protokoll (DCC) auslesen.
Dazu frage ich bereits 87us nach der steigenden Flanke einen Eingang ab.

Der Ablauf soll wie folgt sein:
1: Eingang (PIN_D2) abfragen und negieren
2: Byte um eine Stelle nach links verschieben
3: rechte Stelle mit negiertem Eingang auffüllen

dccbit = ~(PIN_D2);
dccbyte <<= 1;
dccbyte |= dccbit;

Hier sind wohl ein paar Fehler enthalten, würde mich über eure Hilfe 
freuen!!

Danke,
Philipp

[Stefan F. (Gast)]

Ich glaube das ist die effizienteste Variante:

if (PIND & (1<<PD2))
{
    dccbyte = (dccbyte<<1);
}
else
{
    dccbyte = (dccbyte<<1)+1;
}

[Philipp L. (viech)]

Danke,

dieser Code sollte nun das gleiche machen, richtig?
dccbit = (~(PIN_D2) & (0x01));
dccbyte1 <<= 1;
dccbyte1 |= dccbit;

wie finde ich heraus, welcher Code effektiver ist?

[Stefan F. (Gast)]

Philipp L. schrieb:
> dieser Code sollte nun das gleiche machen, richtig?

Nein. Du musst das PIND Register Lesen und davon das Bit 2 
herausfiltern.

Und dann noch an die Position von Bit 0 verschieben, sonst klappt das 
mit anschliessenden oder-Operation nicht. Diesen Schritt bin ich durch 
den if() Ausdruck umgangen.

Du liest PIN_D2 (was auch immer das sein mag) und filterst davon das Bit 
0 heraus.

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Ich glaube das ist die effizienteste Variante:

Bedingte Sprünge sind eher selten effizient... wie wäre es damit das 
komplette Byte auf einmal zu negieren anstatt jedes Bit einzeln?

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> Bedingte Sprünge sind eher selten effizient...

Kannst du das am Assembler-Code des AVR konkretisieren?

> wie wäre es damit das komplette Byte auf einmal zu negieren
> anstatt jedes Bit einzeln?

Ja, das könnte eine Abkürzung sein.

[Philipp L. (viech)]

> Du liest PIN_D2 (was auch immer das sein mag) und filterst davon das Bit
> 0 heraus.

PIN_D2 ist doch mittels sbit.h der Eingang PD2 ?
diese beiden Zeilen ergeben daher das gleiche, oder nicht?

1: dccbit = (~(PIN_D2) & (0x01));
2: dccbit = (~(PIND) & (0x03));

> wie wäre es damit das komplette Byte auf einmal zu negieren

ich muss aber nach jedem Einlesen auf das einzeln negierte Bit 
reagieren.
Es reicht mir nicht das komplette Byte zu lesen und später als ganzes zu 
negieren.

[Stefan F. (Gast)]

Deine sbit.h kann ich nicht berücksichtigen, weil sie mir nicht 
vorliegt.

Unabhängig davon habe ich es ausprobiert:

void test1()
{
    uint8_t dccbyte=0;
    uint8_t dccbit;
    for (uint8_t i=0; i<8; i++)
    {
        dccbit = ~(PIND & (1<<PD2));
        dccbyte <<= 1;
        dccbyte |= dccbit;
    }
    PORTA = dccbyte;
}

00000034 <test1>:
  34:  28 e0         ldi  r18, 0x08  ; 8
  36:  90 e0         ldi  r25, 0x00  ; 0
  38:  80 b3         in  r24, 0x10  ; 16
  3a:  99 0f         add  r25, r25
  3c:  84 70         andi  r24, 0x04  ; 4
  3e:  80 95         com  r24
  40:  98 2b         or  r25, r24
  42:  21 50         subi  r18, 0x01  ; 1
  44:  c9 f7         brne  .-14       ; 0x38 <test1+0x4>
  46:  9b bb         out  0x1b, r25  ; 27
  48:  08 95         ret

void test2()
{
    uint8_t dccbyte=0;
    for (uint8_t i=0; i<8; i++)
    {
        if (PIND & (1<<PD2))
        {
            dccbyte = (dccbyte<<1);
        }
        else
        {
            dccbyte = (dccbyte<<1)+1;
        }
    }
    PORTA = dccbyte;
}

0000004a <test2>:
  4a:  98 e0         ldi  r25, 0x08  ; 8
  4c:  80 e0         ldi  r24, 0x00  ; 0
  4e:  82 9b         sbis  0x10, 2  ; 16
  50:  02 c0         rjmp  .+4        ; 0x56 <test2+0xc>
  52:  88 0f         add  r24, r24
  54:  02 c0         rjmp  .+4        ; 0x5a <test2+0x10>
  56:  88 0f         add  r24, r24
  58:  8f 5f         subi  r24, 0xFF  ; 255
  5a:  91 50         subi  r25, 0x01  ; 1
  5c:  c1 f7         brne  .-16       ; 0x4e <test2+0x4>
  5e:  8b bb         out  0x1b, r24  ; 27
  60:  08 95         ret

void test3()
{
    uint8_t dccbyte=0;
    for (uint8_t i=0; i<8; i++)
    {
        dccbyte = (dccbyte<<1) | (PIND & (1<<PD2));
    }
    PORTA = ~dccbyte;
}

00000062 <test3>:
  62:  28 e0         ldi  r18, 0x08  ; 8
  64:  80 e0         ldi  r24, 0x00  ; 0
  66:  90 b3         in  r25, 0x10  ; 16
  68:  88 0f         add  r24, r24
  6a:  94 70         andi  r25, 0x04  ; 4
  6c:  89 2b         or  r24, r25
  6e:  21 50         subi  r18, 0x01  ; 1
  70:  d1 f7         brne  .-12       ; 0x66 <test3+0x4>
  72:  80 95         com  r24
  74:  8b bb         out  0x1b, r24  ; 27
  76:  08 95         ret

Meine angeblich kürzere Variante ist tatsächlich einen Befehl grösser 
und enthält mehr Sprünge. Dr. Sommer hatte Recht.

Am Ende das ganze Byte zu negieren bringt keinen Vorteil.

[Stefan F. (Gast)]

Philipp L. schrieb:
> dccbit = ~(PIN_D2);

Ich denke das tut nicht, was du willst, weil es keine echten 
Bit-Variablen gibt. Du invertierst damit vermutlich alle 8 Bits.

Also 0b00000001 oder 0b11111110

Und hier passiert dann im zweiten Fall etwas völlig falsches:

> dccbyte |= dccbit;

[foobar (Gast)]

Der avr-gcc (4.8) Codegenerator ist nicht gerade der Bringer - er 
erzeugt häufig unnötig komplexen Code. Bei meinem "kanonischen" Ausdruck 
"x = (x<<1) + !(PIND & (1<<PD2))" erzeugt er miesen Code. Nen einfaches 
"if" bekommt er aber ganz gut hin:

uint8_t test()
{
    uint8_t i,x;
    for (i = 0; i < 8; ++i)
    {
        x <<= 1;
        if (~PIND & (1<<PD2))
            x |= 1;
    }
    return x;
}

test:
        ldi r25,lo8(8)

.L3:    lsl r24
        sbis 0x10,2
        ori r24,lo8(1)

        subi r25,lo8(-(-1))
        brne .L3
        ret

Bei höheren Optimierungsstufen (mit loop-unrolling) verkackt er's aber 
wieder ;-)

[Apollo M. (Firma: @home) (majortom)]

Stefanus F. schrieb:
> Ich denke das tut nicht, was du willst, weil es keine echten
> Bit-Variablen gibt.

immer dieser unsinn, das ist raten auf niedrigem niveau!

vielleicht mal die doku auch lesen ...

z.b. 328p page 22
I/O Registers within the address range 0x00 - 0x1F are directly bit-
accessible using the SBI and CBI instructions. In these registers, the 
value of single bits can be checked by using the SBIS and SBIC 
instructions.

die port register bits lassen sich alle in einer struct exact mappen und 
ansprechen!

viele kennen auch die avr gpioX register nicht und wie diese für flags 
eingesetzt werden.

eure code size kann ich leicht unterbieten, aber ich lass euch das 
selber  rausfinden. für avr verwende ich gcc v8.2!


mt

[Mark B. (markbrandis)]

Philipp L. schrieb:
> wie finde ich heraus, welcher Code effektiver ist?

Indem Du Dir den erzeugten Assembler-Code anschaust.

[Stefan F. (Gast)]

Stefanus F. schrieb:
>> dccbit = ~(PIN_D2);
>
> Ich denke das tut nicht, was du willst, weil es keine echten
> Bit-Variablen gibt. Du invertierst damit vermutlich alle 8 Bits.

Apollo M. schrieb:
> immer dieser unsinn, das ist raten auf niedrigem niveau!
> vielleicht mal die doku auch lesen ...

> I/O Registers within the address range 0x00 - 0x1F are directly bit-
> accessible using the SBI and CBI instructions. In these registers, the
> value of single bits can be checked by using the SBIS and SBIC
> instructions.

Ich habe von der Programmiersprache C (in der avr-gcc Variante) 
geschrieben, nicht von diesen Registern.

> die port register bits lassen sich alle in einer struct
> exact mappen und ansprechen!

Das ist aber etwas ganz anderes, als die Zeile Code auf die ich mich 
bezog.

Weisst du: Wenn man einzelne Sätze aus dem Zusammenhang reisst, kann man 
damit anstellen, was man will - völlig losgelöst von seiner 
ursprünglichen Bedeutung. Man kann aber auch einfach einen Fantasy Roman 
schreiben, da besteht immerhin die Möglichkeit, dass sich jemand daran 
erfreut.

[Stefan F. (Gast)]

Philipp, würdest du bitte mal die Deklaration der Variable "dccbit" 
zeigen?

[my2ct (Gast)]

Philipp L. schrieb:
> wie finde ich heraus, welcher Code effektiver ist?

Früher (tm) hat man dafür die Taktzyklen gezählt, die das Programm für 
die Ausführung braucht (z.B. im Simulator). Guck dir den Maschinencode 
an, dann siehst du es oder programmiere es gleich in Inline-Assembler.
Ist dein Prozessor am Limit oder warum ist Code-Effizienz bei den paar 
Takten ein Thema?

[Bernot (Gast)]

@ Apollo M.

Warum beachtest du die Netiquette nicht?

Wichtige Regeln - erst lesen, dann posten!

Groß- und Kleinschreibung verwenden

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Kannst du das am Assembler-Code des AVR konkretisieren?

Es geht um AVR? Da ist der Effekt aufgrund der einfachen Pipeline 
wahrscheinlich schwächer. Der Effekt ist jedenfalls hinlänglich bekannt, 
das kannst du einfach googeln.

[c-hater (Gast)]

foobar schrieb:

> Nen einfaches
> "if" bekommt er aber ganz gut hin:
[...]

Da fehlt de facto noch eine Instruktion, damit der Code tut, was er 
soll. Die Initialisierung von r24 auf null. Die dazugerechnet und den 
Callframe abgezogen ergeben sich 7*6+1*7=49 Takte für den Nutzcode. Das 
ist nicht gut, das ist schwach.

Der richtige Assemblerprogrammierer schreibt hier:

  ldi R24,1
loop:
  lsl R24
  sbis PIND,PORTD2
  ori R24,1
  brcc loop

Das macht dann 8*5=40 Takte, ist also fast 20% schneller. Soviel zum 
Thema: die C-Compiler sind heute so gut, dass man mit Assembler fast 
nichts mehr sparen kann. 1/5 der Rechenzeit ist ja wohl doch ein wenig 
mehr als "fast nichts".

> Bei höheren Optimierungsstufen (mit loop-unrolling) verkackt er's aber
> wieder ;-)

Noch mehr?!

[foobar (Gast)]

c-hater schrieb:
> Da fehlt de facto noch eine Instruktion, damit der Code tut, was er
> soll. Die Initialisierung von r24 auf null.

Ist nicht nötig - der tut auch so, was er soll.

[c-hater (Gast)]

foobar schrieb:

> Ist nicht nötig - der tut auch so, was er soll.

Stimmt. lsl schiebt unten natürlich immer eine Null rein. Mein Fehler.

OK, steht's also nur noch 40:48. Immer noch 16,7% Gewinn.

[foobar (Gast)]

> OK, steht's also nur noch 40:48. Immer noch 16,7% Gewinn.

Eigentlich steht's 3:3, denn es ging um "Byte verschieben und mit 
Eingang auffüllen".  Die Schleife drum herum gehört da nicht zu ;-)

[Peter D. (peda)]

Mit wieviel MHz kommen denn die Bits rein, daß Du über Mikrooptimierung 
nachdenken mußt?

[Mark B. (markbrandis)]

Peter D. schrieb:
> Mit wieviel MHz kommen denn die Bits rein, daß Du über Mikrooptimierung
> nachdenken mußt?

Wahrscheinlich ein klassischer Fall von "premature optimization"...

[Stefan F. (Gast)]

Peter D. schrieb:
> Mit wieviel MHz kommen denn die Bits rein, daß Du über Mikrooptimierung
> nachdenken mußt?

Ich glaube danach hat er gar nicht gefragt. Die Diskussion ist nur in 
diese Richtung abgedriftet, nachdem ich den Begriff "effizienteste 
Variante" einbrachte.