Hallo,
ist mir unklar, wie ich den millis() Überlauf (Rücksetzen auf 0) handeln
kann und hab mir gedacht, ich zähle einfach die Zyklen.
Attiny85 läuft mit Internal 8 Mhz Clock und müsste - denke ich -
8.000.000x/sek die Loop-Schleife durchlaufen.
Obwohl im Code kein Delay vorhanden ist, entsprechen aber 125.000 Zyklen
ca. 5 sek, 250.000 Zyklen ca. 10 sek usw.
1
unsigned long Ticker=0;
2
3
...
4
...
5
6
void loop()
7
{
8
char recvChar;
9
while(1){
10
if(blueToothSerial.available()){
11
recvChar = blueToothSerial.read();
12
...
13
...
14
}
15
Ticker++;
16
...
17
...
18
}
19
}
Hängt das mit Bluetooth zusammen oder kann das bitte jemand einem
Anfänger wie mir erklären?
Danke für alle Antworten
Matthias
>Attiny85 läuft mit Internal 8 Mhz Clock und müsste - denke ich ->8.000.000x/sek die Loop-Schleife durchlaufen.
Selbst wenn dort nur
while(1)
{
}
stehen würde, sind das keine 8.000.000s/sek.
Matthias schrieb:> ist mir unklar, wie ich den millis() Überlauf (Rücksetzen auf 0) handeln> kann
Sollten wir da nicht ansetzen?
while(1) in Loop(), das ist keine gute Idee!
Matthias schrieb:> wie ich den millis() Überlauf (Rücksetzen auf 0) handeln> kann
Der Überlauf tritt 49 Tage nach dem Starten des Programms
auf. Wo ist das Problem?
Arduino F. schrieb:> while(1) in Loop(), das ist keine gute Idee!
Stammt aus diesem Beispiel
http://www.instructables.com/id/ATtiny85-Bluetooth/step3/Code/ und ich
hab mich auch schon gefragt, ob's das while(1) braucht - besser
entfernen oder besser drin lassen
Arduinoquäler schrieb:> Der Überlauf tritt 49 Tage nach dem Starten des Programms> auf. Wo ist das Problem?
Programm läuft permanent und geplant war die Berechnung eines Intervalls
z.B. if (millis()-prevmillis>irgendwas) - das ergibt bei einem Überlauf
ein falsches Ergebnis.
Ansonsten kein Problem. Ich frage mich nur, warum 125.000 Zyklen ca. 5
sek entsprechen und möchte verstehen. Brauche ja nur den Ticker auf
750.000 abfragen und habe meine geplanten ca. 30 sek. Warum das dann so
ist, weiss ich dann aber immer noch nicht.
Matthias schrieb:> z.B. if (millis()-prevmillis>irgendwas) - das ergibt bei einem Überlauf> ein falsches Ergebnis.
Solange wie "irgendwas" kleiner als 49 Tage ist, gibts keinen Fehler
beim Überlauf.
Und ja, bevor du fragst, ich bin sicher!
Matthias schrieb:> besser> entfernen oder besser drin lassen
So ist die Schleife flüssiger als Wasser!
Überflüssig.
> while(blueToothSerial.available()){
würde vielleicht ja noch Sinn machen...
Warum Einige nicht mal lesen vor dem Posten, wird sich mir nie
erschliessen.
Die Frage war NICHT "wie handle ich den Überlauf" sondern war "kann mir
jemand erklären, warum ein 8 MHz uC in 5 sek nur 125.000 Zyklen
durchläuft.
Jetzt machts ihm doch nicht so schwer.
Für eine deterministische Zeitmessung brauchst du einen Timer. Mit
Zykluszeit- bzw. Loopdurchlauf-Zähler wird das nichts, weil das dann
davon abhängig ist, was da noch so alles drin steht.
DanVet schrieb:> Jetzt machts ihm doch nicht so schwer.
Ich habe mich jetzt dazu entschlossen, dass ich die Frage noch nicht
verstanden habe.
Vielleicht ist ja auch die Frage schon falsch....
Matthias schrieb:> Die Frage war NICHT "wie handle ich den Überlauf" sondern war "kann mir> jemand erklären, warum ein 8 MHz uC in 5 sek nur 125.000 Zyklen> durchläuft.
Wurde bereits gesagt:
dummy schrieb:> Selbst wenn dort nur>> while(1)> {> }>> stehen würde, sind das keine 8.000.000s/sek.
Manche Befehle daueren eben länger als 1 Takt, auch "Ticker++". Und
"while()" muss auch noch behandelt werden ...
HildeK schrieb:> Manche Befehle daueren eben länger als 1 Takt, auch "Ticker++".
Da würd ich mal 20 Zyklen ansetzen (4*LD + 4*ADD + 4*ST).
Und die beiden Funktionsaufrufe sind bestimmt noch viel teurer.
Peter D. schrieb:> Da würd ich mal 20 Zyklen ansetzen (4*LD + 4*ADD + 4*ST).
Beim Tiny25 sind es 12 Assemblerbefehle - mit while(1)-Loop. Ich habe
aber nicht nachgeschaut, wieviele Takte LDD, ADC, ADIW, STD und RJMP
jeweils benötigen.
1
11: ticker++;
2
+00000020: 8189 LDD R24,Y+1 Load indirect with displacement
3
+00000021: 819A LDD R25,Y+2 Load indirect with displacement
4
+00000022: 81AB LDD R26,Y+3 Load indirect with displacement
5
+00000023: 81BC LDD R27,Y+4 Load indirect with displacement
6
+00000024: 9601 ADIW R24,0x01 Add immediate to word
7
+00000025: 1DA1 ADC R26,R1 Add with carry
8
+00000026: 1DB1 ADC R27,R1 Add with carry
9
+00000027: 8389 STD Y+1,R24 Store indirect with displacement
10
+00000028: 839A STD Y+2,R25 Store indirect with displacement
11
+00000029: 83AB STD Y+3,R26 Store indirect with displacement
12
+0000002A: 83BC STD Y+4,R27 Store indirect with displacement
Matthias schrieb:> Die Frage war NICHT "wie handle ich den Überlauf" sondern war "kann mir> jemand erklären, warum ein 8 MHz uC in 5 sek nur 125.000 Zyklen> durchläuft.
Nein.
Ein 8MHz uC durchläuft in 5s genau 5*8Mio Zyklen = 40.000.000 Zyklen.
Wieviele Befehle der uC in dieser Zeit abarbeiten kann oder wie viele
Schleifendurchläufe dieser uC schafft, ist eine ganz andere Sache.
1
if(blueToothSerial.available()){
oder:
1
recvChar=blueToothSerial.read();
sind keine Zyklen sondern Befehle, demzufolge kann so etwas von 1-1Mio
Zyklen dauern (oder noch länger wenn man eine Funktion aufruft).
DanVet schrieb:> Für eine deterministische Zeitmessung brauchst du einen Timer.
Nein, nicht nowendigerweise.
> Mit Zykluszeit- bzw. Loopdurchlauf-Zähler wird das nichts, weil das dann> davon abhängig ist, was da noch so alles drin steht.
Das ist zwar im Prinzip richtig, wenn man aber genau weiß, was da "noch
so alles" drinsteht, dann kann man auch ohne Timer zu einer
deterministischen Zeitmessung kommen...
Aber ja, bei der Arduino-Scheiße(*) würde ich auch nicht ernsthaft
versuchen, das ermitteln zu wollen. Mehr noch: ich würde sogar niemals
in Versuchung geraten, diese Arduino-Scheisse überhaupt ernsthaft für
eine Verwendung in Erwägung zu ziehen...
(*) gemeint ist natürlich das völlig räudige Software-Framework, nicht
die zumindest teilweise durchaus attraktive Hardware der
"Arduino-kompatiblen"...
c-hater schrieb:> (*) gemeint ist natürlich das völlig räudige Software-Framework, nicht> die zumindest teilweise durchaus attraktive Hardware der> "Arduino-kompatiblen"...
Beim Anwalt würde ich sagen: unzulässige Verallgemeinerung
Und: Ziel und Zweck betrachten. Außerdem besteht immer die Möglichkeit,
eine bessere Lösung anzubieten, zugänglich zu machen.
Und inhaltlich stimme ich Deinem ersten Absatz zu.... Ob das dem TO
hilft, kann er nur selbst entscheiden.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
