Debug Visualisation 0.6.0 released

Release version 0.6.0 of Debug Visualisation viewRelease version 0.6.0 of Debug Visualisation view

After many hours of work we finally managed to release a new version of the Debug Visualisation project! This release is a complete rewrite of the previous version (0.5.X), and now it is built upon the JFace API and other standard eclipse technologies instead of different custom hackings. We expect improved stability and maintainability from the new techniques, which means that we can implement more advanced features in the plugin.

Currently, the new version does not include all functionality what the old version did, but we’re sure we will manage to reach it soon. For more information about this release, please refer to the release announcement.

Kiválasztás átvitele eclipse nézetek között

É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.

É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:


PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().findView(viewID).getSite().getSelectionProvider();

ahol a [cci_java]viewID[/cci_java] 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 [cci_java]IDebugUIConstants[/cci_java] 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.

Resource fájlok eclipse plugin extension-ben

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.

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:


//Listázzuk az extension point-hoz csatolt extension-öket:
IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionPoint point = registry.getExtensionPoint("ExtensionPointID");
for (IExtension extension : point.getExtensions()){
//Így kell lekérni az extension-t adó plugin csomagot:
Bundle bundle = Platform.getBundle(extension.getNamespaceIdentifier());
for (IConfigurationElement element : extension.getConfigurationElements()){
//A csomagon belüli relatív elérési út:
String path = element.getAtribute("resourceAttrib");
URL url = bundle.getResource(path);
InputStream is = url.openStream();
//...Olvasás...
}
}

Eclipse update site az oldalon

Aki figyelemmel kisérte a nem rég [[Debug vizualizáció Eclipse-hez|bejelentett]] projektet, az már tudhat róla, hogy pár hónapja működik egy eclipse update site a honlapon. Az említett projekt [[http://code.google.com/p/debugvisualisation/|honlapján]] egy ideje már bejelentettük a létezését, de az itteni kihirdetés idő és kedv hiányában késett egy kicsit.

Tehát a lényeg: az eclipse menüben Help/Software Updates../Available Software/Add Site..: http://eclipse.cubussapiens.hu

Aki figyelemmel kisérte a nem rég [[Debug vizualizáció Eclipse-hez|bejelentett]] projektet, az már tudhat róla, hogy pár hónapja működik egy eclipse update site a honlapon. Az említett projekt [[http://code.google.com/p/debugvisualisation/|honlapján]] egy ideje már bejelentettük a létezését, de az itteni kihirdetés idő és kedv hiányában késett egy kicsit.

Tehát a lényeg: az eclipse menüben Help/Software Updates../Available Software/Add Site..: http://eclipse.cubussapiens.hu

Jelenleg egyetlen feature található rajta, de ahogy az időnk engedi, ez a kör bővülhet. Addig is használjátok egészséggel ezt az egyet, és nyugodtan küldjetek hibajelzést/kivánságot a projekt oldalára.

Jelenlét-érzékelés infravörös fény segítségével

Végre hosszú idő után előkerült a PICkit a fiókból. Az [intlink id=”559″ type=”post”]el%u0151z%u0151 PIC[/intlink]-es próbálkozásom után most egy kicsit bonyolultabb probléma megoldására vállalkoztam. Konkrétan arra, hogy a kütyü képes legyen érzékelni valakinek a jelenlétét. Erre a leggyakrabban alkalmazott módszer infravörös fényt vetít a vizsgált térrész felé, és méri a visszaverődött fény mennyiségét. Minél több fény verődik vissza, annál közelebb van a tárgy, amiről visszaverődött. Az elmélet egyszerű, és mint azt a továbbiakban olvashatjátok, a gyakorlat se sokkal bonyolultabb.

Az első probléma ami felmerült, az a jelentős háttérzaj kérdése. Az infravörös tartományban a nap és a legtöbb mesterséges fényforrás is sugároz, ráadásul sokkal erősebben, mint egy ilyen alkalmazásban szóba jöhető infra-led. A háttérzaj és az infra-led jelét szétválasztani csak úgy lehet, ha modulált jelet sugározunk a térbe, és ezt a modulált jelet keressük a mért értékekben is. Léteznek olyan infra-vevők, melyek hardveresen támogatják a modulált jel érzékelését (pl. TSOP), de hasonló alkatrészt tucatnyi boltot körbejárva sem találtam (ha tud valaki olyan boltot, ahol vásárolható ilyen, kérem írjon). Ilyen célezköz hiányában a modulációt szoftveresen oldottam meg.

A szoftveres moduláció miatt a hardver rendkívül egyszerű lett, a következő alkatrészekre volt szükségem:

  • Pic16F690
  • 1db infra led
  • 1db fotodióda
  • 1db npn tranzisztor
  • 4db 1kOhm ellenállás
  • 2db vörös led (egy a bekapcsolt állapotot jelzi – folyton világít, egy pedig a végeredményt adja meg, hogy érzékel-e jelenlétet az eszköz)

A munkát minimalizálandó felhasználtam a programozóhoz adott próbapanelt, amin beépített ledek állnak rendelkezésre, ezeket felhasználtam az állapotjelzések számára, így csak a fotódiódát és az infraledet kell hozzákötni, ami egy breadboard segítségével könnyedén kivitelezhető. Az infra-ledet a PIC rc0 kimenete fogja meghajtani, egy ellenállással bekötve ez a rész készen van. A kimenetet jelző led az rc1, a power-led az rc2-re van kötve hasonló módon. A fotódiódát a tranzisztorral erősítve kötjük a beépített A/D konverter bemenetére, hogy erősebb jelet kapjunk, ezzel megnövelve az érzékelés felbontását. A további félreértések rövidre zárásához felraktam egy kapcsolási rajzot:

pdetector.png

A szoftver ezzel a következő módon tud együttműködni: az alapötlet az, hogy kikapcsolt infra-leddel lemérjük a bejövő fény mennyiségét, majd bekapcsoljuk az infrát, és újra mérünk. A bekapcsolt illetve kikapcsolt infra-led melletti mérések különbsége adja meg az infra-led által leadott és visszavert fény mennyiségét. Ha ez a különbség több iteráció után is meghaladja a küszöbértéket, akkor a kimeneten jelezzük az érzékelt jelenlétet. Azaz két paraméter a küszöbérték (mekkora különbséget várunk el kikapcsolt és bekapcsolt infra-led melletti mérések között), és a kitartás (hány iteráción át kell tartani ezt a különbséget).

És íme, a kód. A dolog nehézségét jelzi, hogy a legtöbb időt két érték összehasonlítása vette el. A kódban szereplő makrót a Microchip MPasm leírásából vettem, én egy kétszer olyan hosszú megoldást csináltam elötte.


#include __config (_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOR_OFF &
_IESO_OFF & _FCMEN_OFF)

;presence detector code.
;assumed peripheres:
; infra-led on RC0
; photo-diode connected to AN0
; detected proximity output on RC1
; power led on RC2
;
;we measure input on photo diode, while infra-led is turned off.
;then we measure again with turned on infra-led.
;if the infra-ray is reflected from anything, the second measurement
;should return a higher value

;=================================================
;========VARIABLES================================
;=================================================

cblock 0x20
offmeasure ;stores measurement without infra led
onmeasure ;stores measurement with infra led
output ;output bits
waitcount ;wait count
surecount ;make sure that something is there and not moves
endc

OUT_ILED EQU H’0000′ ;bit for infra led
OUT_RES EQU H’0001′ ;bit for output
OUT_POWER EQU H’0002′ ;power led

THRESHOLD EQU H’0002′ ;threshold for measurment gain

SURENESS EQU H’000C’ ;number of measurements before we’re sure in the result

;===================================================
;==============macros for selecting banks
;====================================================
SELECT_BANK0 macro
bcf STATUS,RP0
bcf STATUS,RP1
endm

SELECT_BANK1 macro
bsf STATUS,RP0
bcf STATUS,RP1
endm

SELECT_BANK2 macro
bcf STATUS,RP0
bsf STATUS,RP1
endm

SELECT_BANK3 macro
bsf STATUS,RP0
bsf STATUS,RP1
endm

;==============================================
;=====MACRO TO WAIT=============================
;==============================================

WAIT macro us
local a = 0
while a < us
nop
a += 1
endw
endm

;============================================
;========EXECUTE A MEASUREMENT===============
;============================================

MEASURE macro
WAIT 5
bsf ADCON0,GO ; start conversion
btfsc ADCON0,GO ; this bit will change to zero when the conversion is complete
goto $-1

movf ADRESH,w

btfsc output,OUT_ILED
goto $+3
movwf onmeasure
goto $+2
movwf offmeasure
nop
endm

;========================================
;=======SWITCH output led================
;========================================

SWITCH_ILED macro
movlw 0x01
xorwf output,F
endm

;========================================
;========REFRESH OUTPUT==================
;========================================

REFRESH_OUTPUT macro
movfw output
movwf PORTC
endm

;======================================================
; compare file to constant and jump if file
; >= constant.
;======================================================
cfl_jge macro file, con, jump_to
movlw con & 0xff
subwf file, w
btfsc STATUS, C
goto jump_to
endm

;===============================================
;==============MAIN PROGRAM=====================
;===============================================
org 0
Init:
;set variables to zero
movlw 0x00
movwf output
movwf onmeasure
movwf offmeasure

;set powerled on
bsf output,OUT_POWER

;initialize devices
SELECT_BANK1
movlw 0xFF
movwf TRISA ; Make PortA all input
clrf TRISC ; Make PortC all output
movlw 0x10 ; A2D Clock Fosc/8
movwf ADCON1
SELECT_BANK2
movlw 0xFF ; we want all Port A pins Analoge
movwf ANSEL
SELECT_BANK0
movlw 0x01
movwf ADCON0 ; configure A2D for Channel 0 (RA0), Left justified, and turn on the A2D module

Loop:
MEASURE ;measure with light off
SWITCH_ILED ;turn light on
REFRESH_OUTPUT
call SubWait ;wait a bit

MEASURE ;measure with light on
SWITCH_ILED ;turn light off
call DecideOutput ;decide output
REFRESH_OUTPUT
call SubWait ;wait a bit
goto Loop

;==============================================
;=====Decide output============================
;==============================================
DecideOutput:
;onmeasure-offmeasure >= threshold
movfw offmeasure
subwf onmeasure,F
cfl_jge onmeasure,THRESHOLD,DecideYes
goto DecideNo
DecideYes:
;bsf output,OUT_RES
incf surecount,F
goto DecideOutputReturn
DecideNo:
clrf surecount
bcf output,OUT_RES
DecideOutputReturn:
cfl_jge surecount,SURENESS, SwitchOn
goto SwitchOff
SwitchOn:
bsf output, OUT_RES
return
SwitchOff:
bcf output, OUT_RES
return

;===========================================
;===========Subroutine for long wait========
;===========================================
SubWait:
movlw 0xFF
movwf waitcount
StartWait:
WAIT 100
decfsz waitcount,F
goto StartWait
return

;===============================================
;=====PROGRAM END===============================
;===============================================
end

A kütyüt felprogramoztam, a perifériákat megépítettem, és pár iteratív hibajavítás/paraméterfinomítás után eljutottam arra az állapotra, amit elégségesnek neveztem a koncepció működésének a bizonyítására.

dscf1957_small.jpeg

A fenti köntörfalas megfogalmazás nem költői önkifejezés, és nem is véletlen. Az eszköz működik, de épp hogy. A környezet által kifejtett fényerő fehérzajként adódik a rendszerhez, és csak magas “kitartás” és “küszöbérték” paraméter mellett lehet kiszűrni a téves jelzéseket. Ennek az az eredménye, hogy kb. két másodperc után jelzi ha 5cm-nél közelebb teszem a kezemet az infra-led+fotódióda pároshoz. 10cm-nél már bizonytalan a mérés, és akkor is előfordul egy-egy téves jelzés, ha nincs semmi a közelben.

Ezen problémák orvoslására több ötletem is van, egy részük azonnal megoldódna, ha találnék egy rendes infra adó-vevőt. Persze ötleteket, javaslatokat, hasonló problémákban szerzett tapasztalatokat szívesen fogadok.

http://ww1.microchip.com/downloads/en/DeviceDoc/33014g.pdf