Frage zu Software-SPI

[M. S. (elpaco)]

Hallo zusammen,

vor kurzem habe ich eine SPI in Software umgesetzt. Die Frage, die ich 
habe betrifft spezifisch das setzen/löschen der Bits auf dem Data-Port 
während des Sendevorgangs.

Hier im Forum sehe ich fast immer die Lösung, mit einer Maske zu 
arbeiten, die dann in jedem Schleifendurchlauf geshiftet wird um somit 
das Bit zu maskieren, das gesendet werden soll. Beispielsweise so 
(nächstbestes Beispiel, das ich gefunden habe):

void display_out(unsigned char out)
{
  unsigned char mask = 0x80;
  
  while(mask)
  {
    DISPLAY_PORT &= ~(1 << CLK);
    if(mask & out)
    {
      DISPLAY_PORT |= (1 << SDA);
    }
    else
    {
      DISPLAY_PORT &= ~(1 << SDA);
    }
    DISPLAY_PORT |= (1 << CLK);
    mask = mask >> 1;
  }  
}

Ich selbst habe es gelöst durch

...
if(data&(1<<i))
...

Das funktioniert auch soweit. Ich frage mich daher, warum man den 
"Umweg" über die Maske macht, also extra eine Variable einführt, die 
dann ebenfalls durch das Shiften CPU-Zyklen verbrät.

Kann mir da jemand weiterhelfen?

[Christian (Gast)]

viele Wege führen nach Rom...

Unterschied der beiden Methoden:
Du schiebst die Bits von rechts nach links raus, wenn du anderstrum 
schieben willst geht das natürlich auch.
Allerdings hast du schon mal die Anzahl der Schiebeoperationen gezählt, 
die für einen kompletten Schleifendurchlauf zusammenkommen?
28 versus 7 - damit ist die erste Methode, trotz einer temporären 
Variable, sicherlich schneller.

Christian

[Chris (Gast)]

Hallo elpaco,

du brauchst so oder so eine Variable, mit der du die Maske erstellt. 
Deine Lösung sieht auf den ersten Blick vielleicht "billiger" (in Bezug 
auf CPU-Zyklen) aus, jedoch benutzt du ja auch eine Variable (dein "i" - 
vermutlich von einer for-Schleife).

Ich kann dir jetzt nicht genau sagen, wie dein Compiler optimiert, aber 
die Lösung mit der Masken-Variablen sieht für mich so als, als ob sie 
effizienter wäre, da die Maske gleichzeitig auch die Schleifenbedingung 
darstellt.

KURZE (!) Gegenüberstellung der beiden Varianten:
Maske:
-INIT
-Schleifenbedingung überprüfen
-Pinwackeln
-Rechtsshift
-Rücksprung zur Schleife

for-Schleife:
-INIT
-Schleifenbedingung überprüfen
-Linksshift um i Stellen
-Pinwackeln
-Zählvariable verändern
-Rücksprung zur Schleife

Viele Grüße

[M. S. (elpaco)]

Okay, das heißt das (1<<i) ist im Endeffekt nichts anderes als eine 
Variable anzulegen und sie i-mal zu shiften. Und durch die Maske spart 
man sich das, jeden Durchlauf neu zu shiften. Man muss nur insgesamt N 
mal shiften und nicht

$$\sum_{n=0}^N n$$

 mal mit N = Anzahl der Schleifendurchläufe

[Fabian O. (xfr)]

Der teure Teil an Deiner Lösung ist das "1<<i". Auch wenn es harmlos 
aussieht, die meisten Mikrocontroller können den Wert nicht mit einem 
Maschinenbefehl berechnen. Ohne Barrel-Shifter kann der Prozessor pro 
Befehl nur um eine Stelle nach rechts/links shiften.

Der Compiler muss also eine Schleife bauen mit einer temporären Variable 
(Anfangswert 1), die er i-Mal um eine Stelle nach links shiftet. Und das 
in jedem Schleifendurchlauf neu. Das braucht deutlich mehr Zeit.

Falls der Compiler perfekt optimiert, könnte am Ende der gleiche Code 
wie in der Variante mit der expliziten Maske rauskommen. Drauf verlassen 
würde ich mich aber nicht.

[holger (Gast)]

>Ich frage mich daher, warum man den
>"Umweg" über die Maske macht, also extra eine Variable einführt, die
>dann ebenfalls durch das Shiften CPU-Zyklen verbrät.

Da kann man dir eigentlich nur den Tip geben mal den erzeugten
Assemblercode anzusehen. Zusätzlich dann vor der Schleife mal
einen Pin setzen und danach löschen. Das ganze dann auf einem
Osci ansehen oder mit dem Simulator mal CPU Zyklen zählen lassen.

Dann siehst du ob es einen Unterschied gibt oder nicht.

[SAMUEL (Gast)]

AVR Studio benutzen. beide Varianten Programmieren. Im Simulator laufen 
lassen und das Assemblerfenster anschauen. Am Ende bekommst Du noch die 
komplette Zeit deiner Routine angezeigt. Die Sauberste Lösung ist 
übrigens es direkt selber in Assembler zu programmieren und einbinden, 
wenn man meint es sei Zeitkritisch.

[Ast E. (vis)]

Fabian O. schrieb:
> Der teure Teil an Deiner Lösung ist das "1<<i". Auch wenn es
> harmlos
> aussieht, die meisten Mikrocontroller können den Wert nicht mit einem
> Maschinenbefehl berechnen. Ohne Barrel-Shifter kann der Prozessor pro
> Befehl nur um eine Stelle nach rechts/links shiften.

so sieht es aus :-)

[Peter D. (peda)]

SAMUEL schrieb:
> Die Sauberste Lösung ist
> übrigens es direkt selber in Assembler zu programmieren und einbinden,
> wenn man meint es sei Zeitkritisch.

Nä, wat hammer gelacht.

uint8_t shift_io( uint8_t b )   // send / receive byte
{
  uint8_t i;

  SPI_CLK_DDR = 1;              // set as output
  SPI_MOSI_DDR = 1;

  for( i = 8; i; i-- ){         // 8 bits
    SPI_MOSI = 0;
    if( b & 0x80 )              // high bit first
      SPI_MOSI = 1;
    b <<= 1;
    SPI_CLK = 1;
    if( SPI_MISO_PIN )
      b++;
    SPI_CLK = 0;
  }
  return b;
}

Und hier das Listing:

uint8_t shift_io( uint8_t b )   // send / receive byte
{
  uint8_t i;

  SPI_CLK_DDR = 1;              // set as output
  2e:  b8 9a         sbi  0x17, 0  ; 23
  SPI_MOSI_DDR = 1;
  30:  b9 9a         sbi  0x17, 1  ; 23
  32:  98 e0         ldi  r25, 0x08  ; 8

  for( i = 8; i; i-- ){         // 8 bits
    SPI_MOSI = 0;
  34:  c1 98         cbi  0x18, 1  ; 24
    if( b & 0x80 )              // high bit first
  36:  87 fd         sbrc  r24, 7
      SPI_MOSI = 1;
  38:  c1 9a         sbi  0x18, 1  ; 24
    b <<= 1;
  3a:  88 0f         add  r24, r24
    SPI_CLK = 1;
  3c:  c0 9a         sbi  0x18, 0  ; 24
    if( SPI_MISO_PIN )
  3e:  b2 99         sbic  0x16, 2  ; 22
      b++;
  40:  8f 5f         subi  r24, 0xFF  ; 255
    SPI_CLK = 0;
  42:  c0 98         cbi  0x18, 0  ; 24
  uint8_t i;

  SPI_CLK_DDR = 1;              // set as output
  SPI_MOSI_DDR = 1;

  for( i = 8; i; i-- ){         // 8 bits
  44:  91 50         subi  r25, 0x01  ; 1
  46:  b1 f7         brne  .-20       ; 0x34 <__CCP__>
    if( SPI_MISO_PIN )
      b++;
    SPI_CLK = 0;
  }
  return b;
}
  48:  08 95         ret

Bin mal gespannt, wie man das in Assembler noch besser optimiert.

[SAMUEL (Gast)]

Haha jenau ich lach mit.

1. War das Allgemein gemeint.
2. Eine gut geschriebene Assemblerfunktion ist <= Compiler
3. Komme ich zum rausschieben eines Bytes via SPI auf 12 instructions, 
bei deinem  Compiler Beispiel zähle ich 14.

             ;shift out a byte (r24) 
ShiftByte:   ldi  r20, 8                

SHIFT_LOOP:  cbi  PORTB, CLK            
             cbi  PORTB, SDI                    
                
             rol  r24                  
             brcc  SHIFT_LOW                  
             sbi  PORTB, SDI              
SHIFT_LOW:   sbi  PORTB, CLK                
        
             dec  r20                  
             brne  SHIFT_LOOP              

             sbi  PORTB, LCK              
             cbi  PORTB, LCK              
             ret

Haha

[SAMUEL (Gast)]

Ich muss mich korrigieren es sind bei mir sogar nur 10 Instrucktion's 
die letzten beiden:

sbi  PORTB, LCK
cbi  PORTB, LCK

gehören schon nicht mehr zu SPI-Routine. Also noch mal mehr hahaha...

[Peter D. (peda)]

SAMUEL schrieb:
> Ich muss mich korrigieren es sind bei mir sogar nur 10 Instrucktion's

Ich hätte gedacht, es wäre aus den Kommentaren ersichtlich, daß meine 
Routine etwas mehr macht.
Die zusätzlichen Befehle setzen die Pins auf Ausgang und lesen MISO ein.
Oft muß man einen SPI-Slave ja auch auslesen.

Wenn ich das weglasse, sinds auch 10.

[SAMUEL (Gast)]

Warum jedes mal aufs neue als Ausgang konfigurieren. In der Regel halten 
die ihren Zustand.

[Karl H. (kbuchegg)]

SAMUEL schrieb:
> Warum jedes mal aufs neue als Ausgang konfigurieren. In der Regel halten
> die ihren Zustand.

Dann nimms raus, wenn dir das nicht gefällt.
Das war doch gar nicht der springende Punkt, den PeDa angesprochen hat.

[Michael R. (Firma: Brainit GmbH) (fisa)]

SAMUEL schrieb:
> Eine gut geschriebene Assemblerfunktion ist <= Compiler

premature opti... jaja, schon gut, ich bin ja schon still...

[M. S. (elpaco)]

Im Endeffekt ist es dann auch ineffizient, bspw ADC-Register mit z.B. 
(1<<ADSC) zu setzen, sofern diese nicht I/O sind und somit sbi/cbi 
können? Da wäre dann ein immediate-Wert effizienter, wenn ich das 
richtig verstehe?

[Michael R. (Firma: Brainit GmbH) (fisa)]

M. S. schrieb:
> Im Endeffekt ist es dann auch ineffizient, bspw ADC-Register mit z.B.
> (1<<ADSC) zu setzen, sofern diese nicht I/O sind und somit sbi/cbi
> können? Da wäre dann ein immediate-Wert effizienter, wenn ich das
> richtig verstehe?

Der Compiler macht dir daraus schon einen immediate-Wert, solange beide 
seiten des << Operators konstant sind.

[Peter D. (peda)]

M. S. schrieb:
> Im Endeffekt ist es dann auch ineffizient, bspw ADC-Register mit z.B.
> (1<<ADSC) zu setzen

Konstante Ausdrücke werden schon zur Compilezeit ausgerechnet.
Du kannst daher ohne Bedenken Konstanten in float definieren, z.B. 
Faktoren für die Berechnung von Zeiten, Spannungen, Temperaturen usw..
Aber sicherheitshalber vor der Verwendung noch nach Ganzzahl (uint16_t) 
casten.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter Dannegger schrieb:
> Du kannst daher ohne Bedenken Konstanten in float definieren, z.B.
> Faktoren für die Berechnung von Zeiten, Spannungen, Temperaturen usw..
> Aber sicherheitshalber vor der Verwendung noch nach Ganzzahl (uint16_t)
> casten.

Wobei hier das Klammern noch wesentlich wichtiger als das casten ist.

z.B. wird

 
#define A 47.11
#define B 8.15
float y = x * A / B;

nicht durch eine Multiplikation mit der Konstante 5.78 (=47.11/8.15) 
ersetzt (musste ich schmerzhaft lernen). Der resultierende 
Assembler-Code enthält eine Multiplikation und eine (teure) Division

Der Code wird wesentlich schneller, wenn man nur eine Klammer setzt:

 
#define A 47.11
#define B 8.15
double y = x * (A / B);

Hier rechnet der Compiler wirklich eine Konstante und erzeugt nur eine 
Multiplikation.

Wichtig: das ist kein Fehler des Compilers, aufgrund der begrenzten 
genauigkeit von Fließkommazahlen (egal ob float oder double) muss er 
richtigerweise so vorgehen.