Rotationssensor
Rotationssensor
Jag köpte en rotationssensor (med distinkta lägen) på Elfa, mest för att kolla hur en sådan funkar och för att eventuellt kunna använda den i ett kommande projekt.
Med en PIC och en LCD tänkte jag bygga upp ett menysystem och använda denna rotationssensor för att navigera i menyerna och ändra värden på diverse parametrar.
Men det är knepigt att läsa av denna med en mikrokontroller (PIC) samtidigt som den ska utföra en massa annat. För att inte missa någon puls måste programmet kolla efter extremt ofta. Som jag har det nu, missar den lätt pulser, vilket inte är speciellt snyggt om man ska bygga något seriöst...
Så jag undrar om det finns någon bättre metod att läsa av en rotationssensor än att låta mikrokontrollern göra det direkt. Kanske någon logikkrets kan tolka den?
En möjlighet är kanske att använda interrupt på mikroprocessorn, men det blir nog svårt eftersom det är två utgångar som man ska ha koll på?
Eller har jag hittat fel komponent för ändamålet?
Med en PIC och en LCD tänkte jag bygga upp ett menysystem och använda denna rotationssensor för att navigera i menyerna och ändra värden på diverse parametrar.
Men det är knepigt att läsa av denna med en mikrokontroller (PIC) samtidigt som den ska utföra en massa annat. För att inte missa någon puls måste programmet kolla efter extremt ofta. Som jag har det nu, missar den lätt pulser, vilket inte är speciellt snyggt om man ska bygga något seriöst...
Så jag undrar om det finns någon bättre metod att läsa av en rotationssensor än att låta mikrokontrollern göra det direkt. Kanske någon logikkrets kan tolka den?
En möjlighet är kanske att använda interrupt på mikroprocessorn, men det blir nog svårt eftersom det är två utgångar som man ska ha koll på?
Eller har jag hittat fel komponent för ändamålet?
-
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Om du kan offra tre pinnar skulle du kunna använda D-flip-flop som i http://www.interq.or.jp/japan/se-inoue/e_ckt10_3.htm (Up Down detection circuit) och sedan koppla in det utgångarna där till två pinnar på picen. Därefter OR'ar du ihop dom med två dioder och ett pull-down-motstånd och kopplar det till en interruptinång.
Vid interrupt kollar du vilken av pinnarna som är höga och minskar eller ökar din räknade.
Det borde kunna förkenklas till 2 pinnar genom att det är onödigt att kolla båda. Kommer det ett interrupt och pinnen inte är hög så är det åt ena hållet, är den hög så är det åt andra.
Vid interrupt kollar du vilken av pinnarna som är höga och minskar eller ökar din räknade.
Det borde kunna förkenklas till 2 pinnar genom att det är onödigt att kolla båda. Kommer det ett interrupt och pinnen inte är hög så är det åt ena hållet, är den hög så är det åt andra.
-
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
http://www.tech-tools.com/files/picapp.pdf Gå till avdelningen Reading Rotary Enoders.
Ska du koda PicBasic eller assembler?
Som ett alternativ till att ha ett externt interrupt från 'vridgrunkan' så skulle man kunna tänka sig ett vanlig regelbundet timerinterrupt istället.
Eftersom encodern ger 24 pulser per varv, vilket ger 40 mS mellan varje puls om man vrider ratten runt ett helt varv på en sekund. Sätter man upp ett timerinterrupt var 10mS eller något liknande så kan man enkelt polla de två bitarna från encodern utan att behöva ligga och anropa läsrutinen manuellt hela tiden.
Ska du koda PicBasic eller assembler?
Som ett alternativ till att ha ett externt interrupt från 'vridgrunkan' så skulle man kunna tänka sig ett vanlig regelbundet timerinterrupt istället.
Eftersom encodern ger 24 pulser per varv, vilket ger 40 mS mellan varje puls om man vrider ratten runt ett helt varv på en sekund. Sätter man upp ett timerinterrupt var 10mS eller något liknande så kan man enkelt polla de två bitarna från encodern utan att behöva ligga och anropa läsrutinen manuellt hela tiden.
Oj! Se där!
Du är allt en liten ängel, Mats
Jag hade förhoppningar om att kunna skriva en duglig interrupthanterare i PICBasic, men efter att ha läst på vad som gäller i detta språk, så insåg jag att det inte kommer bli bra; interrupt kan endast ske mellan högnivåkommandona, vilket inte gör så stor nytta.
Så den ända utvägen är assembler, och det kan jag inte koda
Edit:
Att polla hela tiden tycker jag inte verkar vara någon bra idé att göra i huvudprocessorn, då den ibland måste skicka ut långa seriella dataströmmar, vilket kommer hålla den upptagen. Förvisso vill man inte ha något input från "snurrmojen" just då...
Dessutom är ju vridhastigheten absolut inte konstant. Vad händer om man snurrar för snabbt eller väldigt sakta med denna metod som avläsning? (XOR kopplar inte så bra hos mig så här dax
)
Jag tror det banar iväg för den metod jag haft i bakhuvudet från början: Att låta nån gammal PIC16F84A idelt skanna "snurrmojen" och rapportera/skifta över datan till huvudprocessorn parallellt. Alltså blir denna en slav under huvudprocessorn. Förhoppningsvis kan man låta den kolla lite knappar eller något annat nyttigt så man inte slösar bort en hel mikrokontroller bara på en elak "snurrmoj"

Du är allt en liten ängel, Mats

Jag hade förhoppningar om att kunna skriva en duglig interrupthanterare i PICBasic, men efter att ha läst på vad som gäller i detta språk, så insåg jag att det inte kommer bli bra; interrupt kan endast ske mellan högnivåkommandona, vilket inte gör så stor nytta.

Så den ända utvägen är assembler, och det kan jag inte koda

Edit:
Att polla hela tiden tycker jag inte verkar vara någon bra idé att göra i huvudprocessorn, då den ibland måste skicka ut långa seriella dataströmmar, vilket kommer hålla den upptagen. Förvisso vill man inte ha något input från "snurrmojen" just då...
Dessutom är ju vridhastigheten absolut inte konstant. Vad händer om man snurrar för snabbt eller väldigt sakta med denna metod som avläsning? (XOR kopplar inte så bra hos mig så här dax

Jag tror det banar iväg för den metod jag haft i bakhuvudet från början: Att låta nån gammal PIC16F84A idelt skanna "snurrmojen" och rapportera/skifta över datan till huvudprocessorn parallellt. Alltså blir denna en slav under huvudprocessorn. Förhoppningsvis kan man låta den kolla lite knappar eller något annat nyttigt så man inte slösar bort en hel mikrokontroller bara på en elak "snurrmoj"

Senast redigerad av $tiff 1 februari 2004, 23:21:05, redigerad totalt 2 gånger.
-
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Fast hur många picbasic-instruktioner tar längre tid än nångra mS att utföra? Det kan inte vara många det. SLEEP är ju kanske et givet exempel förståss, och LCDout och.... hmmm... Det det kanske är några.
Men tror du att man märker att den hoppar över en 'räkning' ibland när man vrider? Man vrider ju till man får fram rätt tal/värde/meny på displayen. Ratten är ju 'relativ' och inte 'absolut' som en vanlig vridomkopplare är.
Jag tror inte att man märker av att det går lite ryckigt ibland, fast jag skulle nog vilja prova innan jag sätter några pengar på det.... :-)
Men tror du att man märker att den hoppar över en 'räkning' ibland när man vrider? Man vrider ju till man får fram rätt tal/värde/meny på displayen. Ratten är ju 'relativ' och inte 'absolut' som en vanlig vridomkopplare är.
Jag tror inte att man märker av att det går lite ryckigt ibland, fast jag skulle nog vilja prova innan jag sätter några pengar på det.... :-)
-
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Ja, fast nu när jag tänker på det så kan bittarna från encodern hinna ändra på sig innan interrupten hinner exekveras och porten läses av. Det kan i värsta fall innebära att en upp-puls plötsligt tolkas som en ner-puls eftersom encodern hunnit in i ett nytt fasläge.
Det problemet borde kunna minskas genom D-flopparna i Japanens bygge, då riskerar man bara att missa ett tick helt - och det är betydligt mindre otrevligt än att den plötsligt hoppar bakåt ett steg.
Hur som helst så skulle jag nog pröva att koppla upp encodern och en LCD till en pic och prova varianten med direktkopplad encoder och timerinterrupt i picbasic innan jag börjar fundera på nån mer avancerad variant.
Det problemet borde kunna minskas genom D-flopparna i Japanens bygge, då riskerar man bara att missa ett tick helt - och det är betydligt mindre otrevligt än att den plötsligt hoppar bakåt ett steg.
Hur som helst så skulle jag nog pröva att koppla upp encodern och en LCD till en pic och prova varianten med direktkopplad encoder och timerinterrupt i picbasic innan jag börjar fundera på nån mer avancerad variant.
>> mrmike
Jo, jag ska. Jag lär ju få det inmatat i skallen när(/om) jag börjar på högskola
>> matseng
Denna modellen är mjuk. Just nu kör jag direkt med axeln och det känns lagom (jag gillar hårt
). Sätter man på en ratt så lär det inte bli mycket till "snäpp". Om man finner det lustigt, så kan man ställa den mellan lägena. Hårdare än så är den inte...
Undrar hur jobbigt en utan distinkta steg är att läsa av, med tanke på att den kan ställa sig hursomhelst. Eller det kanske fungerar bra med de metoderna som jag inte behärskar
Jo, jag ska. Jag lär ju få det inmatat i skallen när(/om) jag börjar på högskola

>> matseng
Denna modellen är mjuk. Just nu kör jag direkt med axeln och det känns lagom (jag gillar hårt

Undrar hur jobbigt en utan distinkta steg är att läsa av, med tanke på att den kan ställa sig hursomhelst. Eller det kanske fungerar bra med de metoderna som jag inte behärskar

Nu har jag provat det jag babblade om igår.
Jag har satt ena utgången på encodern till RB0 på PICen (interrupt), så den flaggar när när en puls kommer från encodern. Problemet är, precis som jag befartade, att PICBasic-instruktionerna är för långa för att flaggan ska hinna tas om hand innan pulsen är försvunnen från encodern.
Min metod fungerar förvisso ibland, men det är de gångerna man har "tur" och flaggan hamnar precis mellan två PICBasic-kommandon.
Jag har satt ena utgången på encodern till RB0 på PICen (interrupt), så den flaggar när när en puls kommer från encodern. Problemet är, precis som jag befartade, att PICBasic-instruktionerna är för långa för att flaggan ska hinna tas om hand innan pulsen är försvunnen från encodern.

Min metod fungerar förvisso ibland, men det är de gångerna man har "tur" och flaggan hamnar precis mellan två PICBasic-kommandon.