Archief - Deling Ontwijken

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Sick-Boy

Legacy Member
Om het toerental te berekenen van een motor gebruik ik een timer en op een interrupt (altijd in dezelfde motorstand) lees ik de waarde van de timer uit

om van timerwaarde naar RPM te gaan moet ik volgende functie gebruiken:

RPM = 60/(TimerIncrementTijd*InterruptTijd)

voorbeeld in mijn geval: 100 RPM = 60/(12,8µSec*46875)

om dit te berekenen moet ik een nogal onorthodoxe deling uitvoeren die bovendien sterk variabel is. Het gevolg is dat ik meer in mijn interrupt routine blijf dan ergens andders.

Mijn vraag is: hoe kan ik zo'n deling ontwijken?

Gurdt

Legacy Member
Het schijnt dat werken met doubles al een voordeel kan hebben, dus zodat je niet heletijd naar int's moet casten (bv niet 60 maar 60.0). Maar dat zullen de meeste compilers wel al fixen zeker?

En ik weet het niet zeker, maar is het niet efficienter om bv het volgende te doen: 60 000 000/(12.8 * 46875) omdat je dan niet zozeer met kommagetallen bezig bent :) Probeer het eens zou ik zeggen?
En als je dan toch bezig bent en als ik je opgave juist opvat (dus die 46875 is altijd hetzelfde?) dan kan je ook eens proberen: 1280/(12.8). Want als ik het goed heb is enkel die timer variabel en 60 000 000 / 46875 = 1280 ;)

edit: ik merk dat ik niet meteen op je vraag geantwoord heb dus bij deze: ik denk niet dat zo een deling zomaar te ontwijken valt. Het gaat dus echt om efficiënter maken van de code denk ik zo.

Sick-Boy

Legacy Member
Dat kan mij ook vooruit helpen :)
je hebt het bijna juist opgevat, het is niet de 46875 maar de 12,8 die constant is

om de 12,8µSec incrementeert de timer en de 46875 zou een timer-waarde kunnen zijn als de motor op exact 100 RPM draait.

maar de constante waarde had ik al afgezonderd :)

als ik cast naar double dan blijf ik met hetzelfde aantal instructies zitten (nl 306!)
tips om dit aantal te verkleinen zijn ook welkom.

Sick-Boy

Legacy Member
Nocturn zei:
ipv de rpm te berekenen, bereken je in de interrupt de periode. Dan kun je de deling vervangen door een vermenigvuldiging.
Buiten de interrupt kan je dan de conversie naar rpm doen indien nodig.
Op welke cpu werk je feitelijk?

Edit: als het een intel cpu is kan je ook queryperformancecounter (of in asm rtdsc) Je stored het verschil (64 bit getal) en buiten de loop moet je dan nog delen door de QueryPerformanceFrequency voor de periode ofwel omgekeerd voor een frequentie.
Ik schat dat zoiets in 20 a 30 asm instructie kan gedaan worden in de interrupt + als bonus heb je bijna nanoseconde precisie

Het is een PIC24H (16-bit van microchip)

kheb die rpm waarde nodig om andere dingen te berekenen
het ziet er naar uit dat ik idd met periode ga moeten werken

Sick-Boy

Legacy Member
GPIO zijn analoge/digitale input/output pinnen?

die zijn bijna allemaal gebruikt, een 2-tal heb ik nog vrij.
Het zit zo: die rpm wordt gebruikt om de injectiehoeveelheid en het ontstekingstijdstip van een verbrandingsmotor te bepalen (bv. tabel rpm-injectie in het geheugen en door interpolatie wordt de juiste hoeveelheid bepaald).

ik zou er dus misschien beter een tabel timer-injectie van maken, maar die interpolatie is ook met een deling.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan