rollover save timer in c

danvet schrieb:
> also bei UINT Werten kann man doch einfach subtrahieren, das stimmt auch
> bei einem Überlauf:
>
>

1

> UINT8 startTime;

2

> UINT8 delay = 20;

3

> 

4

> startTime = currentTime();

5

> 

6

> while( (currentTime() - startTime) < delay);

7

>

>
> Oder habe ich das bisher immer falsch gemacht?

Nein, ist richtig.
entscheidend ist das unsigned.

danvet schrieb:
> UINT ist doch unsigned ???

ja. Sag ich doch, dass es richtig ist.
Es gibt aber auch Zeitgenossen, die mitlesen und nicht erkennen, wo der 
springende Punkt liegt. Viele sehen in Datentypen nicht mehr als eine 
Art 'schmückendes Beiwerk'.

ch schrieb:
> In Mikrocontrolleranwendungen gibt es oft das Problem, eine Schleife mit
> konstanter Frequenz durchlaufen zu lassen.

Die bessere Variante ist es allerdings, nicht solange Däumchen zu 
drehen, bis eine bestimmte Zeit (voraussichtlich) um ist. Wobei es auch 
Ausnahmen gibt, wenn die Zeiten sehr kurz sind und nicht mit 
UNterbrechungen zu rechnen ist.

Die weit aus bessere Variante ist es, den Timer so aufzusetzen und so zu 
verwenden, dass er in den gewünschten regelmässige Zeitabständen das 
Startsignal für die nächste Abarbeitung von Funktionalitäten gibt.

Georg schrieb:
> die meisten in Prozessoren verwendeten Timer können das ohne weiteres
> und ohne langes Nachdenken des Programmierers: vom eingestellten
> Startwert wird heruntergezählt auf 0, ein IRQ ausgelöst und der
> Startwert wieder geladen. Die IRQs folgen also äquidistant aufeinander
> ohne jeden Programmeingriff.
>
> Das Problem existiert also eigentlich garnicht.

Genau so ist es. Man muss in der Software keine Probleme lösen, die man 
schon von der Hardware erschlagen bekommt.

ch schrieb:

> uint8_t Start;
> uint8_t Delay;

Vergessen.

uint8_t ist keine gute Idee.

Der springende Punkt ist das unsigned. Machst du aber Rechnungen mit 
uint8_t so wird das int (und zwar signed int) gerechnet. Genau das 
kannst du aber nicht brauchen! Du willst und musst die Berechnung 
unsigned halten.

Wozu das ganze? millis liefert dir einen unsigned long. Ob du den jetzt 
wie ein wilder runter castest oder gleich alles in unsigned long machst, 
schenkt sich nichts.

ch schrieb:
>>Der springende Punkt ist das unsigned. Machst du aber Rechnungen
> mit
>>uint8_t so wird das int (und zwar signed int) gerechnet
>
> Danke für die Antwort. Bist Du Dir aber sicher?
>
> int8_t   Signed
> uint8_t Unsigned
>
> https://en.wikibooks.org/wiki/C_Programming/C_Refe...

Das Problem ist nicht der Typ sondern die Berechnung. Siehe hier: 
http://en.cppreference.com/w/cpp/language/implicit_cast

Entsprechender Auszug:
unsigned char or unsigned short can be converted to int if it can hold 
its entire value range, and unsigned int otherwise.

ch schrieb:
> Danke für die Antwort. Bist Du Dir aber sicher?

Ich bin mir sicher, dass sich Karl Heinz sicher ist. Die Datentypen 
selbst sind zwar unsigned, die Berechnung wird in diesem Fall jedoch als 
signed int durchgeführt. Kompiliere ich folgenden Code,

1

uint8_t Value =3;

2

Value = 2 * Value;

so erhalte ich eine Warnung:

1

warning: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Wconversion]|

Das ganze nennt sich integral promotion.

Konkret geht es um diese Zeile:

1

while( (systemTime()-Start ) < Delay );

Alle Operanden sind ein uint8_t und werden somit zu einem signed int 
gecastet. Dementsprechend wird die Berechnung als signed durchgeführt.

be s. schrieb:

> Alle Operanden sind ein uint8_t und werden somit zu einem signed int
> gecastet. Dementsprechend wird die Berechnung als signed durchgeführt.


Und damit natürlich auch der Vergleich.

> Bist Du Dir aber sicher?

Ja, ich bin mir absolut sicher. So sind nun mal die C Regeln.
In einer Operation werden alle beteiligten Operanden immer auf den 
höchsten Types eines der beiden Operanden hochgehoben, mindestens aber 
int.

ch schrieb:
> Der oben gepostete Code war mit UINT8.
> Mein Code ist mit uint8_t.
> Seht Ihr da einen Unterschied?

Nein. Sollte an und für sich beides auf unsigned char hinauslaufen.

Aber der Ansatz an sich ist zweifelhaft. Von daher solltest Du lieber 
das konkrete Problem beschreiben, welches du eigentlich lösen willst.

ch schrieb:
> a= 255
> b= 4
> Is (b-a < 6) true or false?
>   it is true

Genu hier liegt dein Denkfehler:
x - 255 mit x[0...255] ergibt immer eine negative Zahl oder null. Somit 
ist deine Bedingung immer wahr. Daher musst du dafür sorgen, dass die 
Subtraktion als unsigned Operation durchgeführt wird.

ch schrieb:

> Hmm, ich hätte gedacht, dass die Berechnung folgendermaßen durchgeführt
> wird:

Nein.
Genau deswegen gibt es Literatur, in der die Regeln genau und 
ausführlich vermittelt werden.

Kurz gesagt: Nein, C funktioniert nicht so.

> a= 255
> b= 4
> Is (b-a < 6) true or false?
>   it is true

4 - 255 ergibt -251. Und das ist selbstverständlich kleiner 6.

Und genau das willst du nicht haben. Du willst nicht haben, dass das 
Ergebnis ein Vorzeichen besitzt. Dazu muss aber die ganze Berechnung und 
der ganze Vergleich unsigned durchgeführt werden.

Das ist prinzipiell kein Problem, solange man berücksichtigt, dass in C 
niemals in einem kleineren Datentyp als int gerechnet wird. In diesem 
Zusammenhang spielt es daher keine Rolle, dass a und b als unsigned char 
definiert sind. Denn beide werden zuerst auf den Datentyp int 
hochgehoben, ehe die Berechnung überhaupt startet. Wichtig: int(!) - 
nicht unsigned int! Denn die Regeln sagen auch, dass in so einem Fall 
der erste Datentyp genomen wird, der alle Werte aufnehmen kann. Und das 
ist nun mal ein int. Ein unsigned char hat einen Wertebereich von 0 bis 
255 - passt perfekt in einen int hinein, womit sich über die Hintertür 
wieder ein Vorzeichen einschmuggelt, welches selbstverständlich dann in 
weiterer Folge berücksichtigt und ausgewertet wird.

ch schrieb:

> scheint dann zu funktionieren, wenn man in die Zeile mit dem while einen
> typecast einfügt:
>
> while( (UINT8)(currentTime() - startTime) < delay);

Und jetzt lehnst du dich zurück, denkst noch mal über alles nach, was 
dir heute erzählt wurde und lässt dir durch den Kopf gehen, WARUM in 
diesem Fall das richtige passiert.

Es ist wichtig das du verstehst, was da warum passiert.

W.S. schrieb:
> Hab ich heut schon zuviel Rotwein intus, oder..?

Um 18:34 Uhr schon? ;-)

ch schrieb:

> und erwähnt dass in Beispiel von davnet der typecast fehlt, wäre auch
> alles etwas schneller gegangen.

Da hast du recht. Allerdings muss ich gestehen, dass ich da auch zu spät 
geschaltet habe.

W.S. schrieb:
> Karl H. schrieb:
>> while( (currentTime() - startTime) < delay);
>
> Ähemm.. sind ja alles vorzeichenlose Bytes, also beispielsweise:
>
> currentTime = 254;
> starttime = 250;
> delay = 150;
>
> Hab ich heut schon zuviel Rotwein intus, oder..?

Mag sein. Aber bei einem unsigned char soll es auch schon mal 
vorgekommen sein, dass ein Überlauf zwischendurch passiert und 
currentTime dann effektiv kleiner als startTime ist.

Was an und für sich keine Rolle spielt, solange die Arithmetik unsigned 
durchgeführt wird. Was sie hier allerdings nicht wird, da da noch die 
"es wird nicht kleiner als int gerechnet" Regel mit ins Spiel kommt.
Sobald die uint8_t auf mindestens uint16_t geändert werden, ist dieses 
Problem keines mehr und das ganze läuft auch ohne unsigned cast des 
Subtraktionsergebnisses völlig richtig ab.

ch schrieb:
>> [64 bit]
> Damit verschiebst Du das Problem in die Zukunft.

500 Millionen Jahre bis die ersten Reklamationen eintrudeln, bis dahin 
sollte Version 2 und ein kostenloses Update auf nen 128 bit Zähler 
ausgerollt sein.