Code Optimierung

[Dennis (Gast)]

Ich habe einen ATtiny45 der mittels SPI Daten gefüttert bekommt, die die 
zwei PWM ausgänge steuern. Da es zu Doppelbelegung der Pins kommen würde 
nutze ich nicht die SPI Hardware Schnittstelle sondern toggle in 
Software, der Controller hat eh nichts anderes zu tun. Der Bus sollte am 
Ende natürlich schnellstmöglich sein. Ich frage mich vor allem bei 
folgendem Code ob man die Erkennung des Endes der Übertragung nicht noch 
verbessern kann. Ganz allgemein: Geht es schneller, gibt es 
optimierungen?

(Ich nutze den Arduino als Programmer und daher die IDE zum 
programmieren)

void setup() {
  //Pins 2,3 and 4 are input ports
  //DDRB2 is ChipSelect
  //DDRB3 is MOSI
  //DDRB4 is CLK
  DDRB &= ~( (1<<DDB4) | (1<<DDB3) | (1<<DDB2) );
  //Pins 0 and 1 are Output ports for PWM
  DDRB |= (1<<DDB1) | (1<<DDB0);

  //Set up timer to fast PWM operation (both Channels)
  TCCR0A = (1 << COM0A1) | (1<< COM0B1) | (1 << WGM00) | (1<<WGM01);
  //Top at 0xFF, noPrescaler
  TCCR0B = (1<<CS00);
}

void loop() {
  //While CS is low
  SPI_loop:
  while( !(PINB & (1<<PINB2)) ){
    //Wait for a rising edge at clk
    while( !(PINB & (1<<PINB4)) ){
      //Check again for CS low (end of transmission detection)
      if( PINB & (1<<PINB2) ){
        goto SPI_loop;
      }
    }
    //Move MOSI bit to data  
    data <<= 1;    
    data |= ( PINB >> PINB3 ) & 1;
    //Wait for a falling edge at clk
    while( PINB & (1<<PINB4) ){}  
  }
  //Refresh PWM
  OCR0A = 128; //50% duty cycle
  OCR0B =  63; //25% duty cycle
  
}

[Julian B. (julinho)]

Dennis schrieb:
> Geht es schneller, gibt es
> optimierungen?

Warum soll der Code schneller werden, wenn du eh auf den SPI Takt warten 
mußt?

[Dennis (Gast)]

Naja ich möchte den Bus natürlich so schnell wie möglich laufen lassen, 
wenn der Mikrocontroller jedoch gerade in der behandlung der if 
bedingung steckt während der Takt kommt hab ich momentan sorge das er da 
Bits nicht erwischt.

Ich habe es aber tatsächlich noch nicht ausprobieren können, dachte mir 
aber ich frag direkt doch mal die Profis um Fehler direkt aus der Welt 
zu schaffen.

[dunno.. (Gast)]

Wenn der controller eh nix anderes tut, ist optimieren irgendwie 
unsinnig.

Es gibt aber schon dinge, die deinen code lesbarer machen würden..

Defines für die pinfunktionen statt bezeichner der pins nutzen.

Kein goto für so eine simple Funktion verwenden. Ein Break sollte es da 
tun..?

Mehr könnte man eh erst sagen wenn der code auch sinnvoll wäre, so 
passiert ja nix. Streng genommen wäre das was du gepostet hast ja 
komplett wegoptimierbar, weil nie verwendet....

[Peter II (Gast)]

dunno.. schrieb:
> Kein goto für so eine simple Funktion verwenden. Ein Break sollte es da
> tun..?

nein, break springt nur aus der innersten schleife.

[Dennis (Gast)]

Ja data kommt natürlich noch an OCR0A/B ran. Da stehen nur zum PWM 
funktionstest fixe Werte atm.

Das goto fand ich auch unschön, mir fiel aber keine bessere Lösung für 
die Endbedingung ein.

[nicht“Gast“ (Gast)]

Moin,

Du benutzt den Arduino, den Arduino Bootloader, die Arduino IDE. Gibt's 
eigentlich einen tieferen Sinn, warum du dann nicht auch die API von 
Arduino benutzt?

Erscheint mir irgend wie unlogisch.

Grüße

[Dennis (Gast)]

nicht“Gast“ schrieb:
> Du benutzt den Arduino, den Arduino Bootloader, die Arduino IDE. Gibt's
> eigentlich einen tieferen Sinn, warum du dann nicht auch die API von
> Arduino benutzt?
>
> Erscheint mir irgend wie unlogisch.



Naja die IDE benutze ich da ich keinen anderen Programmer für den Attiny 
habe. Aber sowas wie digitalRead/digitalWrite ist einfach viel langsamer 
als die direkten Zugriffe auf die Ports/Register. Und hier kommt es 
nunmal auf Geschwindigkeit an

[nicht“Gast“ (Gast)]

Dennis schrieb:
> Naja die IDE benutze ich da ich keinen anderen Programmer für den Attiny
> habe. Aber sowas wie digitalRead/digitalWrite ist einfach viel langsamer
> als die direkten Zugriffe auf die Ports/Register. Und hier kommt es
> nunmal auf Geschwindigkeit an

Du sollst ja auch nicht SPI mit digitalRead/Write implementieren. Da 
gibt's bereits weint Klasse für. Die sollte schon schnell genug sein.

[chr (Gast)]

passt schon, wenn es um Geschwindigkeit geht ...
Die Arduino-IDE ist an manchen Stellen iemlich lahm.

VG,C.

[Ich (Gast)]

Dennis schrieb:
> Das goto fand ich auch unschön, mir fiel aber keine bessere Lösung für
> die Endbedingung ein.

Ich würde sogar eine extra Statusvariable einführen um das goto 
loszuwerden, denn mit goto sollte man nicht zurück springen, nur 
vorwärts. Zudem ist das Problem auch ohne goto ganz gut lösbar, daher 
würde ich es ersetzen.

[Grobi (Gast)]

Ich schrieb:
> denn mit goto sollte man nicht zurück springen, nur
> vorwärts.
Bitte Quelle oder kurze Erläuterung dazu angeben, oder ist das eher nur 
soetwas wie eine "urbane Legende"? Habe noch nirgendwoe gelesen / gehört 
das man mit goto nicht zurück springen sollte.
Der Ensatz von goto wird ja im allgemeinen in einer "strukturierten" 
Sprache wie C ja eher vermieden da es sich in 99,999999% der Fälle mit 
einer der Kontrollstrukturen ersetzen läßt.

[Sebastian L. (der_mechatroniker)]

> Bitte Quelle oder kurze Erläuterung dazu angeben, oder ist das eher nur
> soetwas wie eine "urbane Legende"? Habe noch nirgendwoe gelesen / gehört
> das man mit goto nicht zurück springen sollte.

Ich kenne das so als Merksatz auch nicht, aber ich kann mir denken, wie 
es zustandekommt:

Normalerweise programmiert man strukturiert, sprich, man nutzt für 
Schleifen, Verzweigungen und try-catch-finally-Konstrukte immer die 
entsprechenden Strukturen der verwendeten Programmiersprache und nur 
dann evtl. ein goto, wenn die Programmiersprache die gefragte 
Kontrollstruktur nicht bietet.

C bietet gleich 3 Schleifenkonstrukte, womit der Bedarf für 
"zurückspringende" gotos nicht gegeben sein dürfte. C (und schlanke 
C++-Implementierungen ohne Exceptions, etwa auf µC) bietet kein 
try-catch-finally, damit ist ein legitimer Bedarf für vorwärtsspringende 
gotos da.

[Ich (Gast)]

Sebastian L. schrieb:
> C bietet gleich 3 Schleifenkonstrukte, womit der Bedarf für
> "zurückspringende" gotos nicht gegeben sein dürfte. C (und schlanke
> C++-Implementierungen ohne Exceptions, etwa auf µC) bietet kein
> try-catch-finally, damit ist ein legitimer Bedarf für vorwärtsspringende
> gotos da.

Genau so ist es. Try catch Ersatz ist auch im Grunde der einzige 
Einsatz, wo man goto sinnvoll verwenden kann. Aber auch das kann man mit 
einem do{}while(0); und entsprechenden breaks eleganter lösen, da die 
Sprunggrenzen hier enger gesteckt sind nämlich nur genau an das Ende der 
Schleife. Wildes zurückspringen im Code verhindert im Allgemeinen nur 
eine saubere Lesbarkeit.

[Peter D. (peda)]

Es könnte auch helfen, sich erstmal einen Programmablaufplan zu 
erstellen, statt stur drauflos zu schreiben.
Dann kann man viel leichter programmieren und Gotos lösen sich oft in 
Luft auf.

[avr (Gast)]

Ich schrieb:
> Aber auch das kann man mit
> einem do{}while(0); und entsprechenden breaks eleganter lösen

Wenn man dann auch noch Statusveriablen dafür benötigt, finde ich ein 
goto kürzer und damit lesbarer und eleganter.

Das mit den gotos nach vorne steht übrigens in den neueren MISRA-Regeln. 
Ich meine es war 2008?

[Ich (Gast)]

avr schrieb:
> Das mit den gotos nach vorne steht übrigens in den neueren MISRA-Regeln.
> Ich meine es war 2008?

Stimmt, sind die MISRA 2012 Regeln:
Rule 15.2
The goto statement shall jump to a label declared later in the same 
function

Als Erklärung steht im Prinzip das oben genannte, dass Sprachkonstrukte 
genutz werden sollten statt goto.

[Daniel A. (daniel-a)]

Ich hatte bisher erst einen Anwendungsfall für gotos nach oben, bei 
welchem ich diese nicht sinvoll ersetzen konnte, das war hier: 
https://github.com/Daniel-Abrecht/DPA-UCS/blob/5e5378128d4e73b9449782cfe64f4a19588ab918/src/server/protocol/tcp.c 
zeile 555

Ich denke gewisse Dinge lassen sich einfach nur mit gotos schön lösen.

[Ich (Gast)]

Daniel A. schrieb:
> Ich hatte bisher erst einen Anwendungsfall für gotos nach oben,
> bei
> welchem ich diese nicht sinvoll ersetzen konnte, das war hier:
> https://github.com/Daniel-Abrecht/DPA-UCS/blob/5e5...
> zeile 555
>
> Ich denke gewisse Dinge lassen sich einfach nur mit gotos schön lösen.
Meiner Meinung nach ist das nachbilden von Exceptions so ein Fall aber 
auch das kann man wie unten mit do{...}while(0); umschiffen

Bin mir nicht sicher, ob es das gleiche tut aber auf die Schnelle kam 
das raus:

  DPAUCS_tcp_fragment_t** it = tcb->fragments.first;
  {
    do {
      do
      {
        if( chunck_len <= offset ){
          offset -= chunck_len;
          continue;
        }else{
          chunck_len -= offset;
          payload = (char*)payload + offset;
          offset = 0;
        }
        tcp_processDatas( tcb, payload, chunck_len );
      }
      while(0);

      if(!it){
        break;
      }else{
        it=(*it)->next;
      }
      if(it){
        payload = DPAUCS_getFragmentData(&(*it)->fragment);
        chunck_len = (*it)->fragment.size;
      }else{
        payload = last_payload;
        chunck_len = last_length;
      }
      continue; // Nicht nötig
    }
    while(1);
  }

[avr (Gast)]

Das ist nicht wirklich besser. Continue um eine do ... while(0) Schleife 
verlassen ist nicht wirklich gut lesbar. Da sollte eher ein break hin.

Ich finde das ist eher ein gutes Beispiel für Spaghetti-Code. Die 
meisten gotos kann man gut eliminieren. Ein unschönes break bleibt, wenn 
die Umformung stimmt.

DPAUCS_tcp_fragment_t** it = tcb->fragments.first;
      while(1)
      {
        if( chunck_len <= offset ){
          offset -= chunck_len;
        }else{
          chunck_len -= offset;
          payload = (char*)payload + offset;
          offset = 0;
          tcp_processDatas( tcb, payload, chunck_len );
        }

        if(!it)
          break;
        it=(*it)->next;
        
        if(it){
          payload = DPAUCS_getFragmentData(&(*it)->fragment);
          chunck_len = (*it)->fragment.size;
        }else{
          payload = last_payload;
          chunck_len = last_length;
        }
      }

[Daniel A. (daniel-a)]

Nungut, so wie's aussieht geht es auch ohne goto, aber welche variante 
ist Lesbarer und einfacher zu verstehen? Ist dies wirklich die bessere 
lösung?