Gast
#4927839
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
1 | |
Die Variable Tick wird in einer Timerroutine jede 500ms um einen Wert hochgezählt --> Tick++ Wie könnten die beiden oberen Ausdrucke optimiert werden?
Gast
#4927848
Integer und keine Floats oder Double nutzen.
Gast
#4927849
Könnte die auch mit einer Schiebeoperation optimiert werden?
Warum wird die 1000 auf double gecastet? Kann man CYCLE nicht so skallieren, dass man anstatt 1000, 1024 nimmt um zu schieben?
Gast
#4927854
Ich brauche die Werte in Sekunden
Gast
#4927857
unsigned long Time_vorher = Time; Time = (unsigned long)(Tick>>1); // entspricht Tick/2 unsigned long difference = Time - Time_vorher; ...
Scaled int. Du speicherst 1sec als 10/100 (bedingt durch deine Genauigkeit von 500ms) in der Variable, hochzählen dann als +5 (entspricht 5/100).
Mein erster Ansatz wäre: 500 / 1000 = 1/2 Entspricht einem Shift nach rechts
Anm.: 10/100 = 10 hundertstel Um shift operationen zu verwenden, musst du auf unsigned int gehen. Mit signed geht das nur begrenzt, mit double gar nicht.
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.
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 | |
dieses
1 | |
oder einfach dieses
1 | |
schreibst. Der Compiler führt dann die Division bereits zur Compile-Zeit aus.
Gast
#4927971
Yalu X. schrieb: > 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. Und die Existenz dieses Threads sagt mir, dass das Gegenteil der Fall ist.
Noch etwas: Da Tick nur alle 500ms hochgezählt wird, brauchst du dir an dieser Stelle bzgl. Laufzeitoptimierung keine Gedanken machen. Oder geht es um die Optimierung der Programmgröße?
Gast
#4928012
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
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
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 :)
c.m. schrieb: > wenn ich richtig gerechnet habe, wären das 63 jahre bis zum überlauf. 68 Jahre bei 32bit und 2 Ticks pro Sekunde. Bei 64bit sind 292 mrd. Jahre. Nur als Vergleich. Das Universum ist grob 13.8 mrd. Jahre jung.
Gast
#4928040
Halt, 585 Mrd. Jahre.
Gast
#4928044
Nico W. schrieb: > Bei 64bit sind 292 mrd. Jahre. Nur als Vergleich. Das Universum ist grob > 13.8 mrd. Jahre jung. Das sind 2^64. Aber die anderen Bits können ja auch alle 1 sein, sind also 2^65-2. Das ist der Wertebereich eines uint64.
THOR schrieb: > 2^65-2. Das ist der Wertebereich eines uint64. Nö.
Gast
#4928212
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".
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
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.