Hirdetés

Keresés

Új hozzászólás Aktív témák

  • válasz lanszelot #20283 üzenetére

    Nem tudom milyen enkódered van, de kénytelen leszel vagy interruptot használni, vagy ütemezőt, ahogy Aryes is írta.

    Ha az a tipik pozícióba billenős kattogós enkódered van, akkor hiába forgatod, mert annak a clock lába mindig ugyanaz a stabil állapotban.
    Mivel a kódod csak két villogás között mintavételez, ezért mindig csak az az állapot számít, ami a kék led kialvása + keses utáni DE a piros felvillanása előtti időben, azaz pár mikroszekundumban áll fenn. Tehát neked akkor kellene a CLK egy pillanatra más legyen. De ezt nagyon nehéz elkapni, leginkább lehetetlen, ezért a kódod folyamat azt látja, hogy a CLK változatlan, így nem tesz semmit a keses értékével.

    Interrupttal azt tudod csinálni, hogy a uC figyeli az inputot, és amint az változik, végrehajt egy kódot (esetedben a loop /*read current state of inputCLK*/)

    Ennek köszönhetően a kód nem marad le a váltásokról, mert az interrupt szépen kierőszakolja a futást minden váltáskor.

    Ütemezéssel pedig maradhat így a kódod, csak a delay-eket törlöd, és helyettesíted if() feltételekkel. Esetedben 4 ütemre van szükség: redOn, redOff, blueOn, blueOff. A kód elején meghatározod, hogy a piros először mondjuk a futás első másodpercében kell felvillanjon (redOn = 1000). Akkor kialudnia redOff = redOn+keses; időben kell. A blueOn ideje redOff+keses. blueOff = blueOn+keses. Ezután csak kitalálod if használatával, hogy a futásidő millis() éppen melyik ütemen belül van, és annak az ütemnek a feladatát hajtja végre. Mikor az utolsó ütemből is kilépsz, újra kell számolni az ütemek új időpontját. Így a loop nagyon gyorsan ismétlődik, és van esély, hogy nem marad le a futásod az enkóder mozgásáról. Igen, arra is van esély, hogy lemarad, főleg attól függően, hogy mennyire bonyolult marad egy-egy ütem.

Új hozzászólás Aktív témák