GhoUl

Kicsit lassan haladok az önképzéssel, nehezen gyűjtöm össze a megfelelő mennyiségű szorgalmat, hogy a hétköznapi hajtás után egy-egy hétvégén pihenés helyett elővegyem a hardvereket a fiókból. Ezen a hétvégén kivételesen sikerült. Hogy pontos legyek, kezembe került egy inkrementális enkóder, ami (akinek nem ismerős a fogalom) arra jó, hogy forgó mozgás irányát, mennyiségét és esetleg sebességét meghatározzuk.

Az abszolút enkóderekkel ellentétben az inkrementális enkóderek nem képesek megadni a forgás pillanatnyi helyét, segítségükkel csak azt lehet meghatározni, hogy történt-e forgás valamelyik irányba. Viszont jelentősen olcsóbbak, és kevesebb lábat foglalnak el a mikrokontrolleren. Ez sem utolsó szempont, tekintve hogy pár óra kínlódás után rájöttem, hogy a kontrolleremen két láb halott..

Általában véve a forgási enkóderek működését a Wikipedia vonatkozó cikke jobban elmagyarázza, mint én tudnám, így erre nem térek ki részletesen. A lényeg csupán annyi, hogy egy egységnyi forgás alatt két kapcsoló zár az enkóderben egymás után, a forgás irányától függően. Ennek tipikus bekötése active-low jelleggel rendkívűl egyszerű, az enkóder C csatlakozója ráköthető a földre, az A és B lábak számára pedig kiválasztunk két portot a kontrolleren, az én esetemben ez RB6 és RB7 lett. Ezen kívül semmilyen más alkatrészre nincs szükség, hiszen a Pic16F690-es processzor integráltan tartalmaz felhúzó áramkört, ami képes magas szinten tartani az adott portot, és leföldelés esetén biztonságos szinten tartja az áramot.

A feladat tehát a következő: detektálni kell az enkóder kapcsolóinak a zárását, figyelembe véve a sorrendjüket, és ennek megfelelően kell egy változó értékét növelni, vagy csökkenteni. Ha az A kapcsoló zár előbb, és később a B, akkor növelni, ha fordítva akkor csökkenteni kell eggyel a változót. Az általam használt EC12E típusú enkóder 24 diszkrét egységre bont egy kört, azaz 15 fokonként képes érzékelni a forgást, tehát a változó értékét 15-el megszorozva megkapjuk a pontos forgást. Az enkóder mechanikus jellege miatt a használat közben számítani kell pergés előfordulására, aminek a kezeléséről gondoskodni kell.

A mikroprogram gyors időközönként leolvassa a kapcsolók állását, és ez alapján kell eldöntenie, hogy merre forgatjuk az enkóder karját. Mivel figyelembe kell venni a kapcsolók korábbi állapotát is, triviálisan adja magát egy állapotgép-alapú megoldás, ami a pergést úgy küszöböli ki, hogy megengedi az állapotok közötti oda-vissza ugrálást a pergést követve, a pergés stabilizálódásával pedig az állapot is a megfelelő értéken rögzül.

Az állapotgép bemenete a két kapcsoló állása és minden leolvasáskor végrehajt egy lépést:

Az állapotgép megfelelő élei biztosítják, hogy amíg valamelyik kapcsoló pereg, addig a megfelelő két állapot között lépkedjen. Az ábrán pirossal és kékkel jelöltem azokat a lépéseket, mikor is növelem vagy csökkentem a forgást mérő változó értékét.

A programot a gyakorlatban is kipróbáltam, assembly-ben írtam a Pic16F690-hez a kódot, és a pickit2 próbapanelen lévő 4 led segítségével jelzem a változó aktuális értékét:

#include <p16F690.inc>
     __config (_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOR_OFF & _IESO_OFF & _FCMEN_OFF)

     cblock 0x20
State		;state machine variable
Display         ;data to be displayed
     endc

     org 0
Start:
	clrf PORTB
     	bsf STATUS,RP0		; select Register Page 1
	bcf OPTION_REG,7
     	movlw 0xFF
     	movwf TRISA		; Make PortA all input
     	movwf TRISB
     	clrf TRISC		; Make PortC all output
     	clrf ANSEL 		; all pins digital

     	bcf STATUS,RP0		; back to Register Page 0
     	bsf STATUS,RP1		; Reg page 2

	movlw 0xFF
	movwf WPUB		; enable weak pull-up for Port B

	bcf STATUS, RP1		; Reg page 0

     	clrf Display
	clrf State

MainLoop:

;state table:
; input	|  000 	|  010	|  100	|  011	|  101	|
;  00	| 		->000			| == always ->000
;  01	|      ->010 	| ->000 | ->010 |->000- | == if state,0 ->000 (dec if 101), else ->010
;  10	| ->100	| ->000	| ->100 |->000+	| ->100 | == if state,1 ->000 (inc if 011), else ->100
;  11	| ->000 | ->011 | ->101 | ->011 | ->101 | == if state,0 ->101, else if state,1 ->011, else ->000

;decide current input: 00, 01, 10, or 11
;note that all input are active low

	btfss PORTB,6
	goto Input0
	goto Input1

Input0:
	btfss PORTB,7
	goto Input00
	goto Input01	

Input1:
	btfss PORTB,7
	goto Input10
	goto Input11

Input11: ;00
	clrf State		;state ->000
	goto Output
Input10: ;01
	btfss State,0
	goto I01B		;if 0xx
	goto I01A		;if 1xx
I01A:
		btfsc State,2	;if xx1
		decf Display,1	; decrement data
		clrf State	;->000
		goto Output
I01B:
		clrf State	;->010
		bsf State,1
		goto Output
Input01: ;10
	btfss State,1
	goto I10B		;if x0x
	goto I10A		;if x1x
I10A:
		btfsc State,2	;if xx1
		incf Display,1	; increment data
		clrf State	;->000
		goto Output
I10B:
		clrf State	;->100
		bsf State,0
		goto Output
Input00: ;11
	btfsc State,0		;if 1xx
	goto IA
	btfsc State,1		;or x1x
	goto IA
	goto Output
IA:
		bsf State,2 	;->uu1
	goto Output

Output:

     movfw     Display       ; Copy the display to the LEDs
     movwf     PORTC

     goto      MainLoop
     end

A dolgot összeállítva minden várakozásomat felülmúlva működött, a forgást pontosan és gyorsan méri, bár csak kézzel forgattam, így nem tudtam letesztelni, hogy mekkora szögsebességet képes még mérni. Mindenestre akár felhasználónak nyújtott bemeneti eszközként is remekül szerepelhet, mindenképpen kifinomultabb megoldás mint pl. egy potméter A/D átalakítóval. Digitális hifiken rendszeresen találkozhatunk ezzel a megoldással hangerő-szabályozás formájában.

Az előző kitérő után most térjünk vissza egy kis kocka témához. A minap érdekes felfedezést tettem, miközben véletlenül a GEF belső kódjába tévedtem debug közben. Alapvetően egyébként meg vagyok elégedve a GEF és általában az eclipse platform minőségével, ritka az az eset, hogy a fejemet fogom egy-egy megoldás láttán.

A következő kódrészlet ugyan működik és mivel a publikus api elrejti, az átlag fejlesztő nem találkozik vele, mégis érdemes rávetni egy pillantást. További szócséplés helyett következzék a kód, szerintem magáért beszél:

Akinek nem világos elsőre, kifejteném a problémát: láthatóan egy tömböt használ a java-ban alapértelmezésként elérhető “Map” funkcionalitásának a kiváltására. A tömb páros (és nulladik) helyén szereplő elem tárolja a kulcsot, az utána lévő páratlan helyen lévő elem az érték.

Minden elem hozzáadásakor dinamikusan növeli a tömb méretét, törléskor meg egyszerűen null-ra állítja a tömb megfelelő elemét. Ehhez még társul egy custom iterátor is, ami a tömb nem null elemeit listázza.

Őszintén nem értem a tervezési döntést, ami a tömb-alapú Map-hez vezethetett. A memóriaigénye a HashMap-nek nem sokkal több, és mivel jellemzően kis elemszámú esetek fordulnak elő, ez nem számottevő. A sebessége a HashMap-nek jobb, a “get” és “put” metódusok általános esetben konstans, de mindenképpen kevesebb a tömb végigjárásánál. Mindennek a tetejébe a fenti kód Map alkalmazásával kb. 3 sorra cserélhető, nem beszélve az osztály egyéb kódjáról, ami a tömböt piszkálja.

Egyetlen érthető mentségként csak arra tudok gondolni, hogy esetleg a kód korábban íródott, minthogy a java collections API-ba belekerült volna a Map. Ez viszont az 1.2-es verzióban történt meg, tehát elég régen. Nem tudom mennyi idős a GEF, így ezt nem tudom eldönetni.. Mindenesetre ez a kód nálam megütötte a WTF szintet.

Rég írtam, valóban. Hogy újra rávezessem magam a kedvenc munkán kívüli elfoglaltságomhoz, most egy egyszerűbb témát vetek fel, ami mégis okozott pár kobak-koppanást az asztalon. Nevezetesen arról szándékozom írni, hogy a Java hogyan sorrendezi egy objektum inicializálásában résztvevő kódokat. Mert bizony több lehet, és nem egyértelmű a lefutási sorrend, ahogy azt a követkető kódrészlet szemlélteti:

A példát igyekeztem egyszerűnek tartani, de talán megérdemel egy rövid magyarázatot: Két osztályt definiáltam, az egyik leszármazottja a másiknak. Érdekesség még, hogy az ős konstruktora kódot hív meg a leszármazottból absztrakt metóduson keresztűl. Egy “B” típusú objektum létrehozásához láthatóan három helyről kell kódot hívni: Az “A” és a “B” konstruktora, továbbá a “B” osztályban lévő, konstruktoron kívüli inicializálás. A probléma ezen három kódrészlet lefutásának sorrendje.

Első ránézésre a kóddal semmi probléma nincs azon kívül, hogy teljesen haszontalan. Mindkét mező final, így gondolnánk a konstruktor elött inicializálódnak, tehát nem okozhat problémát. Azonban a kód futtatásakor egy csinos NullPointerException kacsint vissza ránk. A futás kimenete:

Láthatóan a B.doSomething() első sora lefut hiba nélkül, a probléma utána keletkezik. Tehát az “s” változó már létezik, az “o” viszont nem. A konstruktorok lefutásának sorrendje tehát: s=..,A(),o=..,B(). A két mező között csupán az a különbség, hogy az “s” mező típusa megegyezik a futásidejű értékének típusával. Ez meghatározza, hogy a mező a szülő osztály konstruktora előtt vagy után kap értéket. Érdemes kipróbálni, ha az “s” mező elöl kivesszük a final kulcsszót, az azt okozza, hogy az is a szülő konstruktor hívása után kap értéket. Vajon hogy határozódik meg a pontos sorrend, mitől függ, hogy hova ütemezi be a java a mezők értékadását?

Nyílván valahogy igyekszik meghatározni, hogy az adott értékadás kiértékelhető-e az osztály örökölt részének inicializálása nélkül vagy sem. Ennek tesztelésére tettem még egy kísérletet, kicsit módosítva a példát:

Ez a kód is szépen elszáll, méghozzá a B.doSomething() első sorában! Azaz, az explicit hivatkozás egy szülő objektum-beli elemre azt eredményezi, hogy a mező értékadását a szülő konstruktor utánra ütemezi. Elég intelligensnek tűnik a dolog, de mégis beleütközik az ember, mert másra számít.

Persze elkerülhető a dolog ha a konstruktorból hívott absztrakt metódusokat anti-pattern-nek kiáltjuk ki, bár gyakran jól jön. Mégis pontosan mi határozza meg a sorrendet, és lehet-e befolyásolni valahogyan? Van valaki aki nálam sikeresebben guglizott?

Érdekes problémákba ütközik az ember, ha eclipse környékén fejleszt. Ezek nagyrészét ugyan már megoldották, de a megoldást külön művészet megtalálni a tengernyi dokumentációban. Mindenesetre legalább dokumentálták. A probléma, amiben pár napja az örömömet leltem, az az, hogy hogyan lehet egy nézet által kiválasztott elemeket átadni egy másik nézetnek, ami természetesen hasonló modell felett dolgozik. Konkrétan a Debug Visualisation projektem által definiált nézetet akartam összekötni a Variables View-vel és vice-versa.

Pár óra keresgélés és javadoc olvasgatás után rábukkantam a megoldásra: Minden view-t tartalmazó IWorkbenchPartSite lehetőséget biztosít egy ISelectionProvider regisztrálására, amely interfészt ad kiválasztási információk kinyerésére és átadására, továbbá listener-ek regisztrálására. A másik, csatlakoztatni kívánt view által megadott ISelectionProvider-nek az általunk generált kiválasztási eseményeket át lehet adni, illetve figyelni lehet az általa generált ilyen eseményeket.

A problémát csak az okoz, hogy egy adott view által generált és elfogadott kiválasztandó elemek az adott view modelljéből kerül ki, tehát ugyanezen modell elemeit kell neki átadni. Ha az általunk írt view más modellen, vagy ugyanazon modell felett máshogy definiálja a kiválasztást, akkor a kiválasztást konvertálni kell a modellek között. Ez természetesen csak akkor oldható meg, ha egyáltalán értelmezhető a közös kiválasztás.

Mindehhez persze az első lépés az, hogy megtaláljuk a csatlakoztatni kivánt view-t, amit az azonosítójának ismeretében tehetünk meg a következő módon:

ahol a viewID helyére a keresett view szöveges azonosítóját kell megadni. A Variables View azonosítóját az org.eclipse.debug.ui plugin egy IDebugUIConstants nevű publikus interfész elérhetővé teszi.

Mint az eclipse esetében általában erre problémára is egy jól kitalált megoldás létezik, ami megfelelően egyszerű ahhoz, hogy a módszer ismeretében könnyű legyen implementálni, a nehézséget csak a módszer megtalálása jelenti.

Aki fejlesztett már Eclipse PDE felett, az talán találkozott a lehetőséggel, hogy egy extension point tulajdonság típusa lehet “resource” is. Ez annyit tesz, hogy a kiterjesztésben megadhatunk egy, a plugin-nel csomagolt fájlt. De a másik oldalon, az extension point beolvasásakor hogyan is olvassuk ezt be? Hiszen fogalmunk sincs honnan jött, melyik plugin adja az extension-t, és hol keressük a fájlt. A megoldás nem triviális, és kell egy kis kutatást végezni, hogy rájöjjünk. Én ezt megtettem, és igyekszem közérthető formában továbbadni.

A probléma, kicsit formálisabban: adott egy extension point, melyen egyik attributúma resource típusú. Mikor egy plugin extension-t csatol ehhez a ponthoz, az adott attríbutúmnak úgy ad értéket, hogy a programozó kiválaszt egy fájlt, amit a pluginnel együtt csomagolva ad. Az extension point-ot adó plugin pedig az ilyen módon regisztrált fájlokat szeretné beolvasni.

Amikor beolvassuk ezt az értéket az extension-ből, a fájl relatív elérési útvonalát kapjuk meg a plugin csomagjában. Első feladatunk tehát, megtalálni a plugin csomagot ([[http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html|Bundle]]), ahonnan az extension jött, hiszen abban kell keresni a fájlt is. Ha megvan a csomag, kérhetünk tőle egy URL-t a fájlhoz. A kapott URL azonban nem szokványos, “bundleresource:” előtaggal rendelkezik. Korábban létezett egy asLocalUrl() függvény, ami az ilyen jellegű URL-t hivatott átalakítani abszolút “file:” URL-é. Azonban ez a függvény a 3.2-es verzióban @Deprecated megjegyzést kapott, tehát ez nem a megfelelő mód a megnyitásra. Szerencsére azonban az ilyen URL-ekhez implementálták az URL.openStream() metódust, ami nyit egy megfelelő adatfolyamot a számunkra. Kicsit egyszerűsítve a kód valahogy így néz ki: