Op 13 december 2020 15:33:59 schreef SparkyGSX:
[...]Hier doe je impliciet de aanname dat je software hebt die elke graad uitgevoerd moet worden; dat is natuurlijk onzin, waarom zou je het aansturen van de enige uitgangen die echt belangrijk zijn kwa timing in een idle loop zetten? je kunt prima 1x per 2 krukas omwentelingen berekenen wat de timing moet zijn, de start- en stoptijden in een tabel zetten, hardware timers gebruiken om de uitgangen aan te sturen, en dan in de timer interrupt de nieuwe compare value voor de volgende gebeurtenis laden.
Met hardware timers heb je 160.000 clocks in een krukas omwenteling, dus een resolutie van 0.00225 graden. Lijkt me genoeg.
Ik heb het over:
.1 evt interrupts van trigger wheel
.2 evt bdp berekenen als je een tand gemist hebt. ( Lees RPM is ineens 2* zo hoog)
.3 Rpm berekenen
.4 hoek berekenen
.4 komt elke (berekende) graad voorbij.
.1, 2 en 3 werk je elke puls bij, afhankelijk van tanden op trigger wheel..
Heb ik het dus nog niets eens over de inspuiting zelf..
.1 is interrupt in 10 klok cycli
Eruit ook zoiets.
.3 doe je eerst. Dus da's periodetijd tussen de 2 interrupts (kun je een capture voor nemen, maar check je overlows)
.2 als timing meer dan 2 x O lang was had je bdp..
Dus je bent al 20 cycliet interrupts bezig dan nog de check voor bdp is er ook 2
Heb je 300 cycli over voor Rpm berekening. Laat dat nog 50 in beslag nemen met een avaraging erin.
250 over.
Kijken naar wat gevraagd is (Adc??) Ook weer 20 cycli voor Adc ready vlag. Weer 40 cycli verder.
Nog ca 200 over.
Dan nog de hoek berekenen en je ken velden aflopen.. alleen hoek berekening schat ik al 100 in..
100 over voor je ken velden dus..
Succes.
Tuurlijk is dit worst case, want die interrupt komt hooguit om de 3 graden... Dus als je taken scheduled kom je er wel.
Maar interrupts in en uit kost ook tijd..