einfache Division mit Atmega AVR?

[SprinterSB]

@SprinterSB: es geht um eine 16bit/16bit Division (Wegkonstante ~ 5200, Zeit 1...2048 ergibt Weg in cm/s), meine bisherige Divisionsroutine ähnelt dem avr-gcc Code.

Mit 50 Ticks für 16/16 sind das ca. 3 Ticks/Bit. wo willst Du da was verbessern? Zeig doch mal den Code. Tricks sind immer drin.

[Gock]

...schließlich geht die Geschwindigkeit gegen unendlich, wenn die Zeit gegen null geht. Um die Geschwindigkeit gegen Null gehen zu lassen, muss prinzipiell eine unendliche Zeit vergehen.

Mit Grenzwerten kannst Du das Problem nicht lösen, weil wir uns hier im "quantisierten Raum" Raum bewegen. Wenn Du <1 oder >254 Zählerwerte misst, dann bist Du im nicht definierten Gebiet aber noch lange nicht im Grenzwert. Diese Fälle musst Du natürlich abfangen, indem Du ausschließt, dass sie zutreffen. Sollten sie durch einen Fehler zutreffen, müssen sie per Software abgefangen werden. In jeden Fall ist die Methode absolut linear.
Einen LookUpTable bei 16 Bit zu benutzen wird in keinem Fall zu einem "optimierten" Ergebnis führen, weil Du dann einen "Sortieralgorithmus" brauchst. Diese haben neben relativ hoher Rechenleistung den weiteren Nachteil, dass Du nie genau weißt, wie viele Takte im jeweiligen Fall benötigt werden.
"Schnell" ist was anderes und genau ohnehin, wenn Du bei 16Bit nur 2000 Werte nutzt...
Aber Du kannst es ja versuchen. Da wir die genauen Parameter nicht kennen (erlaubte Takte...) wird es langsam schwer einen weiteren guten Rat zu geben...
Viel Spass

...hat da etwa wer was gelöscht???....

[wolli_bolli]

@Sprinter: Ich habe nicht von 50 Taktzyklen sondern von einigen 50 Taktzyklen gesprochen.
@Gock: Das mit der Wertetabelle funktioniert bestens, da die Wertetabelle (2500 16bit Werte=>ca. 5kByte) im Flash ab einer bestimmten Adresse anfängt und sich dann kontinuierlich fortsetzt (von der geringsten Overflowanzahl bis zur höchsten). Jeder Wert ist genau einer Anzahl von Timeroverflows zugeordnet. Somit muss ich nur den Tabellenbeginn in den Z-Pointer laden, dann die doppelte Anzahl der Timer-overflows dazuzählen(wg. 16 bit) und den 16 bit Geschwindigkeitswert mit lpm auslesen. Ich sehe daher keinen Bedarf für einen komplizierten Sortieralgorithmus, da die Werte schon "gebrauchsfertig" im Flash liegen. Damit habe ich zu jedem für meinen Roboter sinnvollen Wert Timerwert den passenden Geschwindigkeitswert (Bereich: ca.9-0.2 km/h). Kleinere Werte werden als 0,00 km/h angezeigt, größere können aus hardwaregründen nicht entstehen, dennoch wird dann sicherheitshalber der Geschwindigkeitswert auf 0xFFFF gesetzt, dass man den Fehler feststellen kann. Der ganze Auslesemechanismus braucht geschätzte 15 Taktzyklen und funktioniert wunderbar.

Gruß Wolli_bolli

[Gock]

Ja ok, damit hast Du die ungültigen Fälle abgefangen, und einen Sortieralgorithmus umgangen, wenn auch 5kB für verbraucht.
Mit 16Bit hat das dann zwar nichts mehr zu tun, wenn Du nur 2500Werte speicherst, aber Du hast von vornherein nicht alle Vorrausetzungen genau genannt, sodass wir das hier nicht beurteilen können.
Ich denke trotzdem, dass Du keine 5kB bräuchtest.
Aber manchmal ist man einfach glücklich damit, dass es funktioniert...
Viel Spass dabei.
Gruß

[wolli_bolli]

Vorerst passt das so, evt. werde ich mich irgendwann später nochmal damit befassen (z.B. wenn mir der Flashspeicher ausgeht und ich zu geizig bin einen Atmega 624 zu besorgen).
Außerdem möchte ich mich nochmal bei euch für eure Bemühungen bedanken.
Gruß Wolli