Go Down

Topic: Prozentrechnung ! (Read 2 times) previous topic - next topic

eldopa

Ich bekomme es nicht auf die Reihe !

Heir erstmal der Sketch :

Code: [Select]
#define clockPoti A2
int ClockSpeed = 0;
unsigned long clockPrev = 0;
int ledStatus = LOW;
//int gateLenght = 15;


#define gatePoti A3
unsigned long gateLenght = 0;
unsigned long gatePrev = 0;

int redLed = 13;







void setup(){
 
  pinMode(redLed, OUTPUT);
  clockPrev = millis();
 
  Serial.begin(9600);

}


void loop(){
 
  ClockSpeed = analogRead(clockPoti);
  gateLenght = analogRead(gatePoti);
  gateLenght = gateLenght / 1024;
 
  if((millis() - clockPrev) > ClockSpeed) {
    clockPrev = millis();
    digitalWrite(redLed, HIGH);
    gatePrev = millis();
  }
 
    if((millis() - gatePrev) > (ClockSpeed * gateLenght)) {
      digitalWrite(redLed, LOW);
     
     
    }
   
   
   
}


Mit gateLenght moechte ich prozentual einstellen koennen wie lange redLed (abhaengig von ClockSpeed) leuchtet.
Aber ich hab da wohl einen Denkfehler drin, so funktioniert es nicht.
Ich dachte, wenn ich gateLenght durch 1024 teile, hab ich bei maximal geoeffnetem poti = 1
1*clockSpeed waere also 100%, alles andere ist dann zwischen 0 - 100%

Ich hoffe, ihr versteht was ich meine und koennt mir auf die spruenge helfen.




Joghurt

gatelength müsste eine float oder double sein, damits funktioniert. ;)

eldopa

Danke !
So funktioniert es.
Manchmal kann das leben so einfach sein.
Wieso bin ich da nicht selbst drauf gekommen :smiley-red:

Joghurt


eldopa

XD so kann man es auch nennen.

uwefed



Ich dachte, wenn ich gateLenght durch 1024 teile, hab ich bei maximal geoeffnetem poti = 1
1*clockSpeed waere also 100%, alles andere ist dann zwischen 0 - 100%

Du mußt durch 1023 Teilen nicht durch 1024 um 100% zu bekommen. Der Maximalwert des ADC ist 1023.
Grüße Uwe

Udo Klein

Sowas geht auch ohne floats. Einfach nicht teilen, also

Code: [Select]

(millis() - gatePrev)*1024 > (ClockSpeed * gateLenght))


Und vorher gateLenght nicht durch 1024 teilen. Davon abgesehen schreibt man length mit "th".
Check out my experiments http://blog.blinkenlight.net

eldopa

ok, danke euch allen.
auf jeden fall funktioniert es schon mal und ich werde es noch auf 1023 ändern, oder von Udo die variante übernehmen.

macht es einen unterschied ob ich mit float, oder unsigned long arbeite ?
beide typen nutzen 4 bytes, aber vielleicht gibt es ja unterschiede in der geschwindigkeit der berechnung ??????


mkl0815

Ich würde aus dem Bauch heraus sagen, das Integer-Operationen immer schneller sind. Hat der Atmel eigentlich eine FPU? Falls nicht, würden Floatingpoint-Operationen in Software abgebildet, was dann deutlich langsamer wäre.

Joghurt

Zum Einen das, zum Anderen sind Ganzzahloperationen genauer und sicherer, was Rechenfehler angeht.

mkl0815

Ob nun Ganzzahloperationen wirklich immer genauer sind, wage ich mal zu bezweifeln. Ein "(int) 11/2" liefert ja schon mal 10% Fehler.

Joghurt

Aber wie Du gerade selbst bewiesen hast ist Dir der Sachverhalt in dem Fall klar. :)

uwefed

Quote from: http://arduino.cc/en/Reference/Float

Datatype for floating-point numbers, a number that has a decimal point. Floating-point numbers are often used to approximate analog and continuous values because they have greater resolution than integers. Floating-point numbers can be as large as 3.4028235E+38 and as low as -3.4028235E+38. They are stored as 32 bits (4 bytes) of information.
Floats have only 6-7 decimal digits of precision. That means the total number of digits, not the number to the right of the decimal point.


Quote from: http://arduino.cc/en/Reference/Long
Long variables are extended size variables for number storage, and store 32 bits (4 bytes), from -2,147,483,648 to 2,147,483,647.


Bei long hast Du bis zu 10 significante Stellen; bei float kannst Du grüßere Zahlen darstellen aber nur mit 6-7 significante Stellen.
Was ist genauer?
Grüße Uwe

Udo Klein

@mkl0815: Dein Beispiel stimmt nicht. 11/2 liefert 5 mit 0% Fehler. Der 10% Fehler liegt in Deiner Annahme, daß da 5.5 rauskommen sollte. Bevor Du argumentierst, daß 11/2 doch immer gleich 5.5 sein muß, denke mal kurz darüber nach wie groß der Fehler bei sqrt(4) ist. 0 oder 200%?

Auf was ich raus will: bevor man von Fehlern redet muß man erst einmal schauen was denn das erwartete Ergebnis sein soll.
Check out my experiments http://blog.blinkenlight.net

Fat D


@mkl0815: Dein Beispiel stimmt nicht. 11/2 liefert 5 mit 0% Fehler. Der 10% Fehler liegt in Deiner Annahme, daß da 5.5 rauskommen sollte. Bevor Du argumentierst, daß 11/2 doch immer gleich 5.5 sein muß, denke mal kurz darüber nach wie groß der Fehler bei sqrt(4) ist. 0 oder 200%?

Auf was ich raus will: bevor man von Fehlern redet muß man erst einmal schauen was denn das erwartete Ergebnis sein soll.

Die Quadratwurzel einer reellen Zahl ist aber als diejenige -positive- Zahl definiert, dessen Quadrat der Radikand ist. Von daher ist -2 KEINE Lösung von sqrt(2).

Und wenn du gebrochene Zahlen darstellen willst, dann packst du ja auch noch einen Skalierungsfaktor dazu. Wenn du dich mit floats im untersten Wertebereich aufhälts gibt es da auch Rundungsfehler.

Go Up