Mikrocontroller: Codeoptimierung

Gast #4927839
Lesenswert?

1
// Time: Datentyp unsigned long
2
// Tick: Datentyp uint64_t
3
// CYCLE = 500
4

5
// Zeitdifferenz
6
unsigned long difference = (unsigned long)((Tick*CYCLE)/(double)1000 - Time);
1
Time = (unsigned long)((Tick*CYCLE)/(double)1000);

Die Variable Tick wird in einer Timerroutine jede 500ms um einen Wert 
hochgezählt --> Tick++

Wie könnten die beiden oberen Ausdrucke optimiert werden?
#4927936
Lesenswert?

Dem MC ist es schnurz, ob die Zeitbasis exakte Sekunden zählt. Rechne 
einfach intern immer nur in Ticks und erst ganz zum Schluß für die 
Ausgabe für den Menschen in Sekunden um.
Und um zu vergleichen, ob eine bestimmte Zeit abgelaufen ist, rechne sie 
einmalig in Ticks um und vergleiche die Ticks.
Moderator #4927960
Lesenswert?

Dass du in FLoating-Point rechnen lässt, deutet darauf hin, dass der
Mikrocontroller eine FPU hat, die ähnlich schnell rechnet wie die
Integer-Einheit.

Du kannst aus den zwei Operationen eine machen, indem du statt

1
(Tick*CYCLE)/(double)1000

dieses

1
Tick * (CYCLE / (double)1000)

oder einfach dieses

1
Tick * (CYCLE / 1000.0)

schreibst. Der Compiler führt dann die Division bereits zur Compile-Zeit
aus.
Gast #4928012
Lesenswert?

Leonhard schrieb:
> Die Variable Tick wird in einer Timerroutine jede 500ms um einen Wert
> hochgezählt --> Tick++
>
> Wie könnten die beiden oberen Ausdrucke optimiert werden?

Indem man sie einfach wegläßt. Ich frage mich bloß, wer auf die Idee 
kommt, für eine interne Uhr auf Basis von 0.5 Sekunden einen unsigned 
int64 benutzen zu wollen. Das würde vermutlich ausreichen, bis unsere 
Sonne verglüht ist.

Wenn man das Ganze mit einem simplen 32 Bit Wort erledigt, dann reicht 
das immer noch für 2 Milliarden Sekunden, man spart sich das 64 Bit 
Rechnen und dort mit einem Gleitkommaformat arbeiten zu wollen ist 
obendrein unangebracht.

Warum nur kommen die Leute nicht darauf, mal zu überlegen, wofür welche 
Datenbreite eigentlich ausreichen würde? Ist das eine Folge der 
Einführung von uint64_t und Konsorten, daß über Datenlängen nicht mehr 
nachgedacht wird? So nach dem Motto "Hauptsache, ich benutze stdint.h, 
dann kann mir nichts mehr passieren und ich bin immer auf der sicheren 
Seite ohne noch drüber nachdenken zu müssen". OK, ist ja auch ein 
Standpunkt - aber was für einer!

W.S.
Gast #4928023
Lesenswert?

W.S. schrieb:

> Wenn man das Ganze mit einem simplen 32 Bit Wort erledigt, dann reicht
> das immer noch für 2 Milliarden Sekunden,

wenn ich richtig gerechnet habe, wären das 63 jahre bis zum überlauf.


> Warum nur kommen die Leute nicht darauf, mal zu überlegen

altbekanntes problem.
das ist jetzt gar nicht mal böse gemeint, sondern resignierend 
festgestellt.
Gast #4928036
Lesenswert?

W.S. schrieb:
> Indem man sie einfach wegläßt. Ich frage mich bloß, wer auf die Idee
> kommt, für eine interne Uhr auf Basis von 0.5 Sekunden einen unsigned
> int64 benutzen zu wollen. Das würde vermutlich ausreichen, bis unsere
> Sonne verglüht ist.

292 Mrd. Jahre wenn ich mich nicht verrechnet habe. Also sogar noch 
deutlich länger :)
Gast #4928212
Lesenswert?

W.S. schrieb:

> Das würde vermutlich ausreichen, bis unsere Sonne verglüht ist.

Und dann ist der Akku eines Nokia 3310 immer noch halb voll.

> Ist das eine Folge der Einführung von uint64_t und Konsorten

Nö. Vorher hieß der Algorithmus
- füge soviele 'long' ein, wie der Compiler noch nicht meckert.
- freue Dich, daß Du dann immer noch nicht auf Anhieb siehst, wie breit 
der Datentyp ist, aber sicher sein kannst, daß es ausreicht.

Alternativ dazu kann man übrigens auch mit int32_t arbeiten und Ticks 
zählen. Boeing hatte da vor zwei Jahren im 787 Spaß mit einem 
Generatorcontroller, der das mit Ticks von 10ms so gemacht hat. "Bitte 
rebooten Sie dieses Flugzeug alle 248 Tage".
Moderator #4928552
Lesenswert?

THOR schrieb:
> 292 Mrd. Jahre wenn ich mich nicht verrechnet habe. Also sogar noch
> deutlich länger :)

Obacht:

Die Multiplikation mit CYCLE=500 darf keinen Überlauf verursachen. Du
musst du die berechnete Zeitdauer also noch durch 500 dividieren und es
verbleiben nur noch 584 Mio. Jahre. So lange wird die Sonne ziemlich
sicher noch scheinen. Der TE hätte also besser ein 128-Bit-Integer
genommen. Mit nur 32 Bit wäre sogar schon nach knapp 50 Tagen Ende ;-)

Aber wahrscheinlich hat der TO unter den vielen Vorschlägen schon den
passenden ausgewählt. Wenn nicht, sollte er vielleicht erst einmal
folgende Fragen beantworten:

- Um welchen Mikrocontrollertyp geht es?

- Was genau soll optimiert werden (Laufzeit, Speicher, Größe des
  Quellcodes oder was auch immer)?

- Falls Laufzeit: Muss bei bei 0,5s Zykluszeit überhaupt etwas optimiert
  werden?

- Braucht man diese (aus Sicht des Mikrocontrollers) "krumme" Skalierung
  überhaupt?
Gast #4928899
Lesenswert?

Yalu X. schrieb:
> Die Multiplikation mit CYCLE=500 darf keinen Überlauf verursachen. Du
> musst du die berechnete Zeitdauer also noch durch 500 dividieren und es
> verbleiben nur noch 584 Mio. Jahre.

Was ist denn heut mit dir los?

Also, lies das mal GRÜNDLICH:

Leonhard schrieb:
> Die Variable Tick wird in einer Timerroutine jede 500ms um einen Wert
> hochgezählt --> Tick++

Eben.

In der Timer-Routine steht ein simples Inkrementieren eines unsigned 
int64 und das passiert alle 0.5 Sekunden.

Von was für einer Multiplikation redest du? Von einer völlig 
überflüssigen etwa? Wer die verflossenen Sekunden wissen will, teilt 
Tick durch zwei oder schiebt ihn um 1 Bit nach rechts und fertig ist die 
Laube.

Wer die Minuten wisen will, muß das dann durch 60 teilen .. na und so 
weiter. Dieser Kruscht mit "(unsigned long)((Tick*CYCLE)/(double)1000);" 
war von Anfang an völliger Mumpitz.

W.S.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren