Especially do not use such code in comparators. If not at first try, than later it will mess up things badly, as you rely on the variable, that will not be set because of the evaluation optimization.
This fact cost me three or four hours today…
A better solution (for those who look for usable code snippets):
In fall I began maintaining the parser of the VIATRA2 framework. Funny.
Mostly because it uses the LPG parser generator framework, and to make things worse, a very old version (v1.1) of it. Today it is available a new 2.0 version (since 2008), but they are not compatible at all, e.g. they define define packages in the LPG runtime. As the release was near, there was no chance of upgrading the parser, so we were stuck with version 1.0.
The problem with the old version is, that although it is written in C++, even its makefile uses explicitely the Visual C++ compiler, so simply compiling it for OSX is not possible. That means, every time I have to change the grammar file, I have to start a Windows binary. And I like to do it from Eclipse.
My two chances were Wine and VMware (not Parallels, because I don’t have a licence for it 🙂 ). The latter is too hard on resources and is so much harder to integrate with my Eclipse in OSX, so the first choice was Wine. Luckily the Wine developers did quality work, so the LPG generator binary can be run with wine.
The Eclipse integration is not too hard (at least in a basic way, that would work for a while), as there is support for running External tools using the appropriate icon from the toolbar (or from the Run menü).
Such an External tool can be parameterized using various variables of Eclipse, of which two are needed:
[cci]$resource_loc[/cci]: the file system path (not workspace-relative path) of the selected resource
[cci]$container_loc[/cci]: the the container folder’s (or directory) location, that holds the selected resource (also in the file system)
The tool will be the wine installation, as it will execute the lpg.exe binary, that will receive it as a runtime parameter. This way both the location of the lpg.exe binary and the lpg parameters have to be written to the tools parameters section. It is important to note, that the location of the lpg binary can be given using OSX paths, there is no need to translate them into Wine paths, Wine can handle native OSX paths.
LPG uses a working folder, where it puts the generated parser and AST classes. This will be defined using the [cci]$container_loc[/cci] variable.
LPG needs three types of information: the grammar file (that can be given as a parameter to LPG, we will use the [cci]$resource_loc[/cci] variable), an includes directory (for grammar snippets) and a templates directory (for parser and lexer templates).
The directories can either be found in the working directory (this is needed for local templates), given as parameters or set as environment variables. I choose the third one, as it seemed the most maintainable solution.
For this reason the [cci]LPG_INCLUDE[/cci] and the [cci]LPG_TEMPLATE[/cci] environment variables have to be set on the Environment variables tab respectively.
The described settings (except the environment variables) are shown on the following screenshot:
Running LPG with Wine on the current selection
After these settings are done, by selecting the parser.g file, it becomes possible to run this new tool, that will generate the various parser-related Java classes.
After running the tool, the console output of the lpg generator is shown, where all paths are listed beginning with [cci]Y:\[/cci], although the selected files appear in the folder structure of the Eclipse workspace.
There are some minor shortcomings of this integration: first I cannot use the pop-up menu to execute this tool, as the external tools are not listed. Another annoyance is, that the file has to be selected in Navigator view, the open editor is not enough.
This means, I have to select first the file in the Project Navigator (or Package Explorer, etc.), then run the tool manually from the Run configuration menu. Quite disturbing, but the grammar does not need to be changed too often.
Another problem is, that the error output of the generator is not back-annotated as Eclipse errors (problem markers), only a console output is available. For a brand new grammar this would be not the best solution, but for maintenance it is enough.
The LPG IDE of the IMP (IDE Metatooling Platform) project overcomes this challange by using a newer version of LPG, that is written in cross-platform C (or C++), and uses a builder (that automatically calls the LPG binary if the grammar files are changed), and the builder results are showed as proper error messages.
This means, the future for LPG development in Eclipse is the LPG IDE, but for legacy projects it cannot be used. In these cases my solution can become a good alternative.
Recently I experimented a bit with Eclipse packaging. At first it seems not very important, given that the folks at Eclipse work hard to produce executable packages. On the other hand, the Mac OSX packaging is not the best possible one.
The default folder structure of Eclipse applications on Mac OSX is something like follows:
[cc]eclipse
–configuration/
–dropins/
–features/
–p2/
–plugins/
–Eclipse.app/
–artifacts.xml[/cc]
In this structure Eclipse.app is a special folder, that acts as an executable item for OSX.
This structure is easy to produce, very similar to the ones of Windows or Linux, but there are some drawbacks. First, in the /Applications folder the folder icon is a generic folder, instead of an Eclipse icon (okay, this one is easy to resolve, as every folder can have a custom icon). More importantly, all indexer try identifies the executables by name. If there are multiple Eclipse instances installed, then every instance will have the same name displayed. If the path is also displayed, it is possible to distinguish between the instances.
Some time ago (~1 year) I tried simply renaming the Application bundle did not work, as there is seems to be some kind of configuration that won’t work after that. But this was quite a time ago.
Now I found another possible solution: there is an Eclipse repackager script shared in GitHub I could give a try.
The script is a simple bash script, with simple parametering:
A quick testing showed it does not handle dropins, so I hacked and shared a new version (and meanwhile I was able to test Git for the first time – btw. thanks for the fine tutorials, GitHub team 🙂 ).
To tell the truth, even the updated script has some serious issues: I could break the app two ways: the smallest issue was, that P2 could not install or remove anything, or in the worse case the bundle couldn’t even start.
So I have a quick question: does anyone has a working solution for creating proper, working app bundles for OSX from Eclipse? Or simply could help fixing the repackager script?
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.
Életünk első kalandozása a Shadowrun világában, mely egy ártatlan bevásárlásnak indult, és amelyben sajnos minden NJK-nak volt neve. Featuring: Timi hangokat halló kalóza, TeoZ gremlin-elf adeptje, D-nee tárgyalóképes fegyverspecialistája, Overander figyelemelterelő covert ops specialistája, Eversong troll riggere, és természetesen Stampie, mint egykor ember KM.
JK1 (gremlins negative qualityvel): Nem csoda, hogy nincs commlinkem. JK2: Persze, hiszen gremlin vagy. JK1: Nem gremlin vagyok, hanem elf.
JK (rigger): Milyen messze vagyunk a kocsimtól? KM: (hasból) …1 km-re. JK: Pont 1 km a hatótávolságom!
JK1: Ott valaki mozog. JK2: (miután perception testre dobott critical glitch folytán képzelődött) Én meg hangokat hallok!
JK: (NJK-król) Vagy egyszerűen nem álltak le gondolkodni. KM: Túl sok az augmentation…
JK1: (két kétajtós szekrénnyel való harc közben) Mekkora egy szekrény sebzése? JK2: Ez egy gyenge idegzetű szekrény.
JK: (miután elintéztük az összes ellent, de erről a karakter nem tudhatott, csak a játékos) Én felkiáltok, hogy nincs több… szerintem.
NJK: (frissen megmentve, félelemmel a hangjában) Kik vagytok ti? JK: Shadowrunnerek, akik éppen most fejezték be első moduljukat.