Code Optimierung

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.

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....

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.

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.

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

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

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.

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

VG,C.

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.

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. 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.

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?

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. 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:

1

  DPAUCS_tcp_fragment_t** it = tcb->fragments.first;

2

  {

3

    do {

4

      do

5

      {

6

        if( chunck_len <= offset ){

7

          offset -= chunck_len;

8

          continue;

9

        }else{

10

          chunck_len -= offset;

11

          payload = (char*)payload + offset;

12

          offset = 0;

13

        }

14

        tcp_processDatas( tcb, payload, chunck_len );

15

      }

16

      while(0);

17

18

      if(!it){

19

        break;

20

      }else{

21

        it=(*it)->next;

22

      }

23

      if(it){

24

        payload = DPAUCS_getFragmentData(&(*it)->fragment);

25

        chunck_len = (*it)->fragment.size;

26

      }else{

27

        payload = last_payload;

28

        chunck_len = last_length;

29

      }

30

      continue; // Nicht nötig

31

    }

32

    while(1);

33

  }

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.

1

DPAUCS_tcp_fragment_t** it = tcb->fragments.first;

2

      while(1)

3

      {

4

        if( chunck_len <= offset ){

5

          offset -= chunck_len;

6

        }else{

7

          chunck_len -= offset;

8

          payload = (char*)payload + offset;

9

          offset = 0;

10

          tcp_processDatas( tcb, payload, chunck_len );

11

        }

12

13

        if(!it)

14

          break;

15

        it=(*it)->next;

16

17

        if(it){

18

          payload = DPAUCS_getFragmentData(&(*it)->fragment);

19

          chunck_len = (*it)->fragment.size;

20

        }else{

21

          payload = last_payload;

22

          chunck_len = last_length;

23

        }

24

      }