AVR446 Woher kommen die ganzen Faktoren bei der C0 Berechnung? *100 /100 usw

OP #7610282
Lesenswert?

Hallo,

momentan versuche ich die Rampenberechnung aus der Atmel Anleitung nachzuvollziehen.

https://github.com/taitpthomas/AVR446/blob/master/code/IAR/speed_cntr.h

Dabei bleibe ich an den Faktoren zur Delay Berechnung hängen.

Zum Beispiel in speed_cntr.h ab Zeile 79

1
    // Set max speed limit, by calc min_delay to use in timer.
2
    // min_delay = (alpha / tt)/ w
3
    srd.min_delay = A_T_x100 / speed;
4

5
    // Set accelration by calc the first (c0) step delay .
6
    // step_delay = 1/tt * sqrt(2*alpha/accel)
7
    // step_delay = ( tfreq*0.676/100 )*100 * sqrt( (2*alpha*10000000000) / (accel*100) )/10000
8
    srd.step_delay = (T1_FREQ_148 * sqrt(A_SQ / accel))/100;
9

10
    // Find out after how many steps does the speed hit the max speed limit.
11
    // max_s_lim = speed^2 / (2*alpha*accel)
12
    max_s_lim = (long)speed*speed/(long)(((long)A_x20000*accel)/100);

Woher kommt z.B. das /100 im step_delay?

Sind das Anpassungen um dem µC die Rechenarbeit zu erleichtern?

Oder im Kommentar darüber die ganzen Faktoren die sich direkt wieder kürzen wenn man die mit unter die Wurzel nimmt...

Hat jemand eine Idee?

Andre

#7610299
Lesenswert?

Andre B. schrieb:

Hat jemand eine Idee?

Von welchem Typ sind die Variablen? Das sieht alles sehr nach Ganzzahlrechnung aus. Schreib dir bei den Größen einfach einmal den Skalierungsfaktor und die Einheit dahinter.

Sind das Anpassungen um dem µC die Rechenarbeit zu erleichtern?

Arbeit ist Kraft * Weg. So etwas wie "Kraft" oder "Weg" kennt ein µC nicht. Der kennt Taktzyklen und Taktzyklen pro Operation. Falls ein µC keine FPU besitzt, lassen sich durch Ganzzahlrechnung oft Taktzyklen gegenüber einer Floatingpoint Emulation in Software einsparen - kommt auf die Rechenoperationen an.

OP #7610919
Lesenswert?

Danke für die Hilfe!

Mit dem bestätigtem Verdacht, dass die Anpassungen erfolgten um den Code recheneffizienter zu gestalten und das ich das mal komplett durchgerechnet habe, ist vieles klar geworden. Die Erleuchtung brachte das Nachvollziehen wo die Ergebnisse verwendet werden.

1
if(srd.step_delay <= srd.min_delay){
2
      srd.step_delay = srd.min_delay;
3
      srd.run_state = RUN;

Mathematisch legitim wenn beide Variablen irgendwo mal durch 100 geteilt wurden. Aber wenn man erstmal nur step_delay betrachtet, weil dieses der Hauptpunkt ist bei der Rampenberechnung, ist das sehr verwirrend.

Halt der Unterschied zwischen Syntax kennen und programmieren können...

#7611083
Lesenswert?

Andre B. schrieb:

Danke für die Hilfe!

Mit dem bestätigtem Verdacht, dass die Anpassungen erfolgten um den Code recheneffizienter zu gestalten und das ich das mal komplett durchgerechnet habe, ist vieles klar geworden. Die Erleuchtung brachte das Nachvollziehen wo die Ergebnisse verwendet werden. if(srd.step_delay <= srd.min_delay){ srd.step_delay = srd.min_delay; srd.run_state = RUN;

Mathematisch legitim wenn beide Variablen irgendwo mal durch 100 geteilt wurden. Aber wenn man erstmal nur step_delay betrachtet, weil dieses der Hauptpunkt ist bei der Rampenberechnung, ist das sehr verwirrend.

Halt der Unterschied zwischen Syntax kennen und programmieren können...

Ich weiss ja, dass die Bewertungen hier im Forum totaler Humbug sind und nichts aussagen, aber ich frage mich dann schon, wieso ein Beitrag, wo der User sagt, dass er es kapiert hat, schlecht bewertet wird und keiner drückt auf +.

Die schlechten OK, Deppen, die gerne - klicken. Aber wo bleibt +?

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