Virtualbox: FreeBSD magas CPU használat

Virtualboxban telepítettem egy freebsd-t és a végeredmény az lett, hogy 100%-ban idle guest esetén is magas volt a cpu használat. Ez egyébként nem kizárólag FreeBSD specifikus, több OS is képes ilyenre.

A legnagyobb javulást a HZ átállítása 100-ra jelenti, de találtam olyan tanácsot is, hogy csak 1 magot adjunk a guestnek, tiltsuk a memória virtualizációt, és úgy általában mindent, amire nincs szükségünk :D

A lényeg FreeBSD esetében itt van:

http://www.freebsd.org/doc/handbook/virtualization-guest.html

Ez a legfontosabb, a kernelnek indításkor meg kell adni, hogy 100Hz-el pollingolja a megszakításokat. Ezt a /boot/loader.conf: fájlban tehetjük meg. Írjuk a végére, hogy

kern.hz=100

És már kész is, restart :)

Cron hibák

Ha a cron által küldött jelentésekben az alábbi hibát találod, jó esélyed van rá, hogy a muninod nem szereti valamelyik plugint. Megtalálni elég nehéz, hogy melyik lehet az, ezért érdemesebb inkább "brute-force" mindet átalakítani.

A hibaüzenet:

(process:159888): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

A megoldás:

# cd /etc/munin/plugins

# find . | grep | xargs -i{} iconv -t iso8859-2 -o {}.new {}

# ls -C1 | grep new | cut -d \. -f1 | xargs -i{} mv {}.new {}

Centos 5.5 telepítes SW RAID 1E -re

NNa, ez megér egy misét! "Hogyan telepítsunk Centos-t RAID1E software raidre?" Mivel a telepítő csak RAID 0,1,10,5 és 6-ot támogat, nem enged a 10-nek extra opciókat adni, mint pl a layout.

Röviden: előre létre kell hozni a RAID10, o2 kötetet.

A könnyebb megértés kedvéért: a RAID1E az a megoldás, amikor 2 winchesteren csinálunk RAID 10-et. Ez azt jelenti, hogy először tükröz két blokkot aztán stripeolja őket. Ez az ok, amiért ez kell nekünk: a stripeolt RAIDek lehtőséget adnak arra, hogy a két winyó egyszerre mást és mást olvasson, így megduplázva az olvasási sebességet. Ezt sajnos kihagyták a sima RAID1-ből.

A linuxos mdadm a RAID1 -et f2, o2 layoutos RAID 10 konfigurációval éri el.

Én így oldottam meg:

Először is elindítottam egy telepítést és létrehoztam a telepítőben a RAID 1 -es és 0 köteteimet.

Pl így:

/dev/md0 125MB RAID1 /boot

/dev/md1 14Gb RAID0 swap

/dev/md2 1900Gb RAID10 /

A partíciók formázása képernyőnél restartoltam a gépet (mert az csak az ext3 fájlrendszert hozza épp létre) és újra a telepítőbe bootoltam.

Az Üdvözöljük a CentOS rendszerben képernyő után újra kiléptem az AltF2 konzolra és létrehoztam a RAID10, o2 kötetet:

mdadm /dev/md2 --create --assume-clean --chunk=256 --level=raid10 --raid-devices=2 --spare-devices=0 --layout=o2 /dev/sd[a-b]3

Majd meg is formáztam (de ez elhagyható, csak akkor a következő újraindítás után a telepítőnek meg kell adni, hogy formázza):

mkfs.ext3 /dev/md2

Újraindít, telepít.

Voila :)

Nálam valamiért úgy gondolta, hogy kihagyja az egyik HDD-t, ezt később adatam hozzá mdadm --re-add paranccsal. Ekkor egy szép, hosszú reconstructba kezdett. De nem baj, ennyit megért .)

Labview: Típustévesztés

Amikor először találkoztam a -2147352571 (hex 80020005) számú LabView hibával, nagyon sokáig törtem a fejem, hogy most mi baja van.

A hiba akkor áll elő, ha DLL-t fordítunk egy VI-ből, aminek be vagy kimenete Variant. A DLL Call Library Node-dal való hívásakro hibát kapunk, mert a DLL készítésekor alapértelmezetten nem LabView VAriantot állít be a LabView, hanem ActiveX Variantot. Állítsuk át LU Variantra és fordítsuk újra a dll-t.

Egyébként a Call Library node nem konfigurálható labview varianthoz, adapt to type-ot kell választani és rákötni egy variant konstatnst/kontrolt.

Advanetch CAN - Implementálás II rész

Több tapasztalat is összegyűlt :)
Az első nem is advantech, se nem implementálás jellegű, de megszívlelendő: mindig tartsd be az előírásokat. Ez úgy jött, hogy miután a kártya 1-es portja simán elbeszélgetett a 2-essel, a beckhoff CANopen fejegységgel sehogy sem akart. Ez a fejegység auto baud rate-s és ahogy elindult az üzi, kiállt hibára. Addig addig vakargattam a fejem, amig a leírásában megtaláltam, hogy ez bizony busz jellegű hiba. Keressünk szakadást, rövidzárt, ellenőrrizzük a lezáró ellenállásokat. Na, ekkor elhatároztam magam és ráforraszottam őket. Rögtön ment minden, mint a doxa óra.

Az implementálás maga jó hosszan és nehezen kezdődött. Először is meggyűlt a bajom a port írás/olvasásával. Ha asszinkron módon nyitunk meg egy fájlt/perifériát (CreateFile), akkor az írás-olvasás függvények (ReadFile, WriteFile) mindig várnak egy OVERLAPPED paramétert, amit általában előre nullázni kell. Ha ezt nem kapják meg, mindenféle hibaüziket küldenek, amikből csak az nem derül ki, hogy ez hiányzik nekik :). Az advantech függvény könyvtárakban az acCanOpen() függvény foglalja magába a port helyes megnyitását (CreateFile hívását a megfelelő paraméterekkel).

[code]
[..] //Deklarációs résznél
OVERLAPPED ov;
HANDLE hDevice;

[..]
hDevice= acCanOpen("can2", 1); // Az 1 azt jelenti, hogy asszinkron módon

ZeroMemory( &ov, sizeof(OVERLAPPED) );
ov.hEvent = CreateEvent( NULL,FALSE, FALSE, NULL );

ret=acCanWrite(hDevice, &pbyData, 1, &write_time, &ov);
ulErr= GetLastError();
if(ret!=0) printf("Writing can failed %d, %lu, wt %u\n",ret, ulErr, write_time);

[/code]

Az acCanWrite és acCanRead függvények az írás-olvasást teszik meg. Általáabn az advantechtől kapott header (.h) fájlban levő függvények és deklarációk érthetőek. Ez alól talán az üzenet szerkezet volt a kivétel.

typedef struct {
int flags; /* Flags, indicating or controlling special message properties */
int cob; /* CAN object number, used in Full CAN */
ULONG id; /* CAN message ID, 4 bytes */
short int length; /* Number of bytes in the CAN message */
UCHAR data[DATALENGTH]; /* Data, 0...8 bytes */
} canmsg_t;

Míg sima can esetében ez nem igazán volt probléma, elsőre nem tudtam, hogy a CANopen COB+ID-jét hova tenni. Rövid próbálkozások után (miután már működött a rendszer, és a lezáró ellenállások is a helyükön voltak;)) lokalizálódott: a COB+ID-et egyértelműen az ID mezőbe kell tenni. A többi tényleg egyértelmű és a commanetezés jól magyaráz. Megy minden, mint a karika csapás :).

Másik nagyon fontos, hogy ugye a CAN használ RTR flaget (Remote Request), az SDO uploadoknál nem kell RTR flaget használni, mert ha egy frameben az RTR flag = 1, akkor a controller az adat résszel nem foglalkozik és mindenféle fura adat jelenik meg, ha monitorral nézzük.

A SetBaud és hasonló beállításokat a kártyán levő chip reset módba lökése után lehetett elvégezni, így legyen itt egy minta erre:

[CODE]
int SetBaud(HANDLE ref, int nBaud)
{
int flag;
flag = acEnterResetMode(ref);
flag |= acSetBaud(ref, nBaud);
flag |= acEnterWorkMode(ref);
return flag;
}
[/CODE]

Advantech C + LabView
A labviewes wrapper fileoknál sem volt igazi probléma. Elsődlegesen a HANDLE típus passzolása nem akart rögtön menni, így ha nem is biztos, hogy gyönyörű, de jól működö megoldás az volt, hogy a LabView híváskor átadott egy int32 mutatót (32bites OS), a függvényem elkészítette a handlert és átadtad intnek castolva:

[CODE]
int CreateCanRef(unsigned int *ref, char *portName)
{
HANDLE r;

if (!ref) return -2;
r= acCanOpen(portName, 1);
if( r== INVALID_HANDLE_VALUE )
return -1;

*ref=(unsigned int)r;
return 0; // Lehetne a visszaadott érték is, akkor ez lenne itt: (unsigned int)r;
}
[/CODE]

A többi függvény értékként kapja meg a referenciát és a C fv. deklarációjában HANDLE-ként várjuk.
A különböző struktúrák átadásába nem mentem most bele, nem is azért, mert sok rossz tapasztalatom van, de inább azért, mert itt nem tűnt szükségesnek.
Nagy negatívum viszont, hogy a wrapperek használatával valamiért nagyon lassú a labview, és szinte azonnal el kezd laggolni. Gondolom memória kezelés, vagy hasonló miatt. Ezért át kell dolgoznom az egészet valahogy úgy, hogy a busz olvasás egy külön C-s thread intézi a busz forgalmat, de legalábbis az olvasást, és a labviewnek egy struct mutatót adok, amit pl íráskor felfűzök egy láncolt listára és az olvasó thread fogadott üzenetkor onnan kikeresi.

Protool nincs betű

Ha a protool elindítása után nincsenek betűk a virtuális billentyűzeten és a Text/Graphics alatt levő Text List-jeinkenk is üres/kék a listája ne törjük sokáig a fejünket. A teendők:

• Uninstall
• Registry Clean (én a Registry Clean Expertet használtam)
• Install

Nem nagyon találni rá más megoldást és a registry clean kihagyhatatlan. Anélkül nem segít a reinstall.

Windows XP CompactFlash (CF) kártyán

Mostanában jó néhány mini-itx és még kisebb géppel találkoztam, amiket, mivel beágyazott rendszerekként üzemelnek, mozgó alkatrész nélkülire, de legalábbis hagyományos merevlemez nélkülire kellett elkészíteni. Igaz, ma már a CF kártyák mérete nem akkora korlát, mint régen, azért egy-két trükköt lehetett alkalmazni.
Nagy tapasztalat, hogy hatalmas sebességbeli szórás van. Pl. sokkal gyorsabb az EPIA SN1800G alaplapra inategrált CF olvasója, mint a CF-IDE átalakítós megoldás volt. Míg a Pico-itx alaplapos gépet, mint a videón is látszik, már a CF-IDE átalakító rákötése is megölte. Máig nem értem, hogy miért.

Szóval, a tippek és trükkök:

Egyéni telepítés:
A windows telepítése közben lehetőség van egyedi komponens telepítésre. Használd ezt, hogy kisebb legyen a rendszer. A telepítésről még annyit, hogy annak probléma mentesnek kell lennie, kivéve egy, na jó, két esetet, amiről tudok. Az első eset, ami általános, ha nem lehet bootolni a CF-IDE átalakítóról. Ez típus függő, ha nem lehet, nem lehet. Annyit azért tudni érdemes, hogy ez lehet, hogy azért van, mert a Windows van olyan rendes, hogy nem hajlandó bootolni cserélhető lemezről. Tehát, ha egy működő gépre rákötöd az átalakítód a CF kártyáddal és azt látod, hogy a meghajtó között cserélhető lemezként jelenik meg, jó eséllyel nem fog indulni róla a rendszer. Erre egy egy kártya gyártója ad megoldást, de esetenként tehetetlen vagy. (A második eset az a Via Pico alaplap, ami egyszerűen belassul a CF kártya rákötésétől.)

Komponens eltávolítás:
A telepítés után is tudunk komponenseket eltávolítani, sőt, egy kis trükkel a rejtett, opcionális komponenseket is.
Ehhez nyisd meg a
C:\windows\inf\sysoc.inf
fájlt és töröld ki az összes HIDE szót (a vesszők maradjanak és ne legyen a két vessző között semmi).
Ekkor a Start -> Vezérlőpult -> "Programok telepítése és törlése" és válaszd ki a "Windows összetevők hozzáadása/eltávolítása" fület.

Még teljeskörűbb eltávolítást az XPLite fizetős szoftver segítségével tudsz elérni.

Tömörítés:
A jobb helykihasználás érdekében kapcsold be az NTFS tömörítést. Menj a sajátgépbe, kattints az NTFS meghajtóra jobb klikkel és válaszd a Tulajdonságokat. Pipáld be a "Meghajtó tömörítése helymegtakarítás végett".
Indexelés tiltása:
Ha már pont itt járunk, tiltsuk le az indexelést is, hogy ne használja feleslegesen a merevlemezt.

Rendszer beállítások:
Egy ilyen rendszernél nincs szükség se lapozó fájlra (virtuális memória), de legalábbis nem ajánlott, se rendszer visszaállítási pontra. Továbbá, ha tiltjuk a hibajelentés küldéseket, akkor gyorsíthatjuk a kifagyott programok leállítását és nem fog a windows dump fájlt írni. Én a Teljesítmény beállításokat is inkább a teljesítmény, mint a szépség javára szoktam beállítani.


Nyissuk meg a Rendszertulajdonságokat (jobb klikk a sajátgépen és Tulajdonságok, vagy a Start->Vezérlőpult->Rendszer). Menjünk a Speciális fülre és a Teljesítmény résznél kattintsunk a Beállítás gombra. Itt, igény esetén, válasszuk a "Legjobb teljesítmény" rádió gombot.

Válasszuk a Speciális fület és a Módosítás gombot. Kattintsuk be, hogy "Ne legyen lapozófájl" és kattintsunk a "Beállítás" gombra. OK és még egyszer OK.
Visszatértünk a Rendszertulajdonságokhoz. Kattintsunk a Hibajelentések gombra és a képen látható módon tiltsuk azt:
Talán ezek voltak a leglényegesebb feladatok, amik komolyabb veszély nélkül elvégezhetők.

Kiterjesztett írás szűrő (EWF- Enhanced Write Filter):
Na ez már egy picit kackiásabb, de ez adja meg a dolog ízét úgy igazán :). Külön cikkben itt.


Ha ezeket végig csináltad, már sokkal sokkal beágyazottabb a rendszered! :)

Windows prioritás mentése

A Dell touchpad miatt előkerült, hogy a hozzá tartozó szoftverek prioritását automatikusan kéne mindig valós idejűre venni. Erre találtam a Prio szoftvert.
A használata egyszerű, a linknél is le van írva. A CTRL+SHIFT+ESC billentyű kombinációval előhívjuk a futó folyamatok ablakot. Kiválasztjuk az állítani kívánt alkalmazás nevét és a jobb klikkes menüben beállítjuk a kívánt prioritást. Ha a "Save priority" be van pipálva, akkor a beállítás mentésre kerül. Így az adott program mindig a kívánt prioritással fog indulni.

Töltsd le a Priot a készítő saját oldaláról:
Permanently Set Process Priority in Windows Task Manager with Prio

Dell touchpad akadozik

Cégesként hozzám került egy Dell Latitude E5500 egy-két hete. Mit nem mondjak, tetszik ez a gép és egyike azoknak, amelyeknek van soros portjuk. De a touchpad igen gyenge és gyakran előfordul, hogy akadozik. Ez érezhetően elég kellemetlen, főleg LabView programozás közben...
Nem volt mit tenni, a szabad vasárnap délutánomon elkezdtem keresgélni a googléne, hogy mit szól ehhez, de csak azt talátam, hogy nem vagyok egyedül a világban. :)
Tovább keresgélve az Eszközkezelőben az Dell Touchpad driver tulajdonságaiban a második fülön a Speciális beállításokra bukkantam. Elkezdtem próbálkozni, hogy mi-min váloztat. Végeredményben arra jutottam, hogy a Mintavételezés sűrűségét levettem kisebbre és a puffert maximumra állítottam.
Ezt tettem közzé a dell fórumon is.
Azóta a probléma eléggé élhetővé vált, nem jött elő az akadozás és csak megfagyni is ritkán fagy meg a mutató (inkább bekapcsolás után).
Ha nagyon szaggat, akkor az Alps programoknak a prioritását Valós idejűre lehet venni, mint végső megoldás. De sajnos nem sikerült elérnem, hogy a windows bekapcsoláskor magától tegye ezeket a programokat valósidejűvé. Ha valaki tud rá megoldást, szóljon!
Remélem, hogy segít másnak is! :)
Frissítés:
A prioritás örök beállításának módját lásd itt: http://semirsworkblog.blogspot.com/2009/10/windows-prioritas-mentese.html

RS-232-n programozható termosztát

Egy régebbi projektem végére raktam ma pontot. Ennek örömére, gondoltam, mostmár fel is teszem ide a javított verziót.
Ez a termosztát már a V2 kialakítás. Az elsőnek az lett volna a feladata, hogy egy kenyérpirító hőmérsékletét szabályozza (ezért is van betervezve a KTY84/130 hőmérő ellenállás), de az a projekt átmenetileg befagyott.
A második körben a marató folyadék hőmérsékletének a szabályozására készült el. Ezt osztom meg itt. A szoftver még nem tart sehol, valójában többre mentem volna vele, ha ráteszek egy potit.... A soros interface is még az előző alkalmazásból maradt meg. A kezdeteknél jó volt, mert a segítségével lehet kalibrálni a hőelemet.A feladat méretéhez mérten nem akartam transzformátort tenni a panelre (és a V1-nél TRIAC került az áramkörbe, ott érzékelni kellett a hálózati feszültség 0 átmenetét). A transzformátor nélküli tápegység ötletét még a Microchip egyik adatlapján találtam. Csúcs ez az öltet de kéretik óvatosan bánni vele, hiszen a nyákon ezután mindenfelé 230V szaladgál! Akkoriban tettem próbát a rezisztív kialakításra is, de az önmagát a nyákból kiolvasztó munkaellenállás meggyőzött róla, hogy a kapacitív megközelítés, bár jobban terheli a hálózatot, mégiscsak kényelmesebb :D.

A hőmérsékelt mérést a KTY84/130 végzi. A KTY szobahőmérsékleten kb 0.6KOhm és 100°C-n kb 1kOhm. Szerintem nagyon jó kis cucc, alacsony áron hihetetlen hőmérséklet átfogással.

A hőmérséklet mérés tehát ellenállás változáson alapszik. Ebből rögtön jön, hogy az ellenállást konstans árammal kell meghajtani és akkor a mi kis PICünk simán méri a feszültséget rajta. A konstans áramot egy LM317 állítja nekünk elő. Az adatlapban is megtalálható áramkör kimeneti áramát az Iki = Vref / R adja, ahol Vref = 1,25V. Így a 2K2-es ellenállásunkkal 0,5mA-t engedünk át a mérőellenálláson. Így akár 300°C-ig is mérhetnénk vele :).

A táp méretezése:
A táp kimenti áramát a bemeneti impedanciájával tudjuk kiszámolni a jó öreg I=U/R képlettel.
A kondenzátor impedanciája:
Ezen esik az egy utasan egyenirányított hálózati feszültség:
, ahol Vz a Zener dióda nyitó feszültsége, Vcsucs a hálózate feszültség csúcs értéke, ami a négyzetes közép értéknek (itthon 230V) a gyök kétszerese.
Ezekből a táp bemenő árama (ami egy picivel nagyobb, mint a kivehető max):
Az áramkörnek kb 110-120mA-ra van szüksége a tekercs nagy áramával együtt. Ehhez C1-nek 3uF-nek kell lennie, ami igen ritka méret az ilyen kondiknál... Amikor a legutóbb nem kaptam 3uF-et a boltban, szigetelő szalaggal oldottam meg a problémát. Úgy értem, hogy hozzáragasztottam még 2-t :) Mondjuk a 3.3uF kondi akkora, hogy úgysem fér el :), ezért lengőben kell bekötni.
Az ilyen tápegység méretezésekor fontos figyelembe venni az alkatrészek szórását és a worst case-ra méretezni. Tehát, ha van egy 3.3uF 20%-os kondink, akkor a legrosszabb esetben csak 2.64uF!
Így a projektből tisztán látszódik, hogy ezek a trafó nélküli megoldások nem az ilyen esetekre vannak, hanem olyanra, amikor pár 10nF kapacitás elég a bemenetre. Ugyanis a 3.3uF kondenzátor simán akkora, vagy nagyobb helyet foglal, mint a nyákra ültethető transzformátorok és árban is hasonlók.

Soros kommunikáció:
Igen, azt eddig kihagytam, hogy csak az IC TX/RX pinjei vannak kivezetve. Ez nekem azért jó, mert csináltam egy kis önálló nyákot a híres neves MAX232-vel és a 4 1uF kondival, + két kábel, egyik D-Sub9 a másik meg a 3 pines hüvely. Így azt tudom használni a tesztelésekkor, tervezés alatt és az ilyen esetekben, amikor egy nyák nem igényel üzemszerűen soros kapcsolatot. Ezt a kis nyákot is fel fogom valamikor tenni.

A firmware:
A firmware nem nagyon tart még sehol, mert a marató folyadék hőfokszabályozáshoz nem kellett itthonra túl bonyolítani. Később beleírom, hogy legalább sorosról fogadja az új értéket. Úgyhogy érdemes lesz majd figyelni!

A jövö: az áramkörnek van jövője. Először is át fogom alakítani úgy, hogy egy kisebb, olcsóbb PIC elvigye az egészet, hiszen termosztát lévén nincs nagy szükség RS232 kommunikációra. Tehát rá kerül a nyákra egy poti is. Csinálok belőle kis trafós megoldást is.

A többi meg már csak a mese, beszéljenek inkább a fájlok :D

Letölthető fájlok:

• Eagle projekt tömörítve
• Áramkör (PDF)
• Nyákterv (PDF)
• Beültetési rajz (PDF)
• Firmware (Piklab projekt)
  

Az új verziókat mindig a dátum fogja jelezni.

És akkor mégegyszer:
FELELŐSSÉG KIZÁRÁS / DISCLAIMER
VIGYÁZZ! A nyák 230V-os betápot használ! Ne kösd ész nélkül rá a programozót és MINDIG SÜSD KI A KONDIKAT!
A balesetekért, károkért semmilyen felelősséget nem vállalok és nem is vagyok felelősségre vonható!
Mindenki kizárólag a saját felelősségére építheti meg.
Ez a blogon megjelent összes projektre igaz!

Gyorsabb portage fordítás

A Gentoo egyik nagy előnye az egyik legnagyobb hátránya is, bár ezt nem kell magyaráznom azoknak, akik már egy ideje használják ezt a rendszert és túl vannak már az első eufórián. Ez nem más, mint az összes program forrásból való fordítása. Ez mindenképpen sok időt emészt fel, akkor is, ha elég erős a gépünk

De gyorsabbá tehetjük úgy, ha a portage nem használja a winchestert! Errre való a ramdisk. A portage a /usr/tmp/portage könyvtárt használja a fordításokhoz az átmeneti fájlok elhelyezésére. Ha ennek a könyvtárnak a helyére mountolunk egy ramdisket, akkor a fordítás a memóriában fog megtörténni és nem a winyót nyúzza.
Ehhez vagy a kézi:

# mount -t tmpfs none /usr/tmp/portage

parancsot használhatjuk, vagy beírhatjuka /etc/fstab fájlunkba, hogy később egyszerűbb legyen előhívni pl így:

[fájl: /etc/fstab]
ptg /usr/tmp/portage tmpfs nodev,nosuid 0 0
[/fájl]

A tmpfs nagy előnye, hogy a tárhely nagysága szükség szerint automatikusan változik. Továbbá ha épp nem tartalmaz semmit, akkor egyáltalán nem foglal memóriát.

De érdemes figyelembe venni, hogy pl egy kdelibs vagy egy openoffice fordítása több, mint 1Gb-t igényel!

Eagle nem köt rá

Bizonyára mindenki ismeri a 4-es verziójú Eagle azon érdekes tulajdonságát, hogy nem mindig köti hozzá a terven a 'net' vezetékeket az alkatrészek lábaihoz. Kiváltképpen, ha raszter osztási probléma van. Ekkor megfogja az ember a 'MOV' paranccsal, leteszi újra és már rá is van kötve. És ugye, ezt mindig szépen egyesével. Ma viszont azt tapasztaltam, ha a 'GRO'-val csoportba tesszük az módosítandó részt és 'MOV', jobb klikkel mozdítjuk, ugyanúgy elvégzi a rákötéseket.

Piklab és C18 fordító újra

Ha véletlen sehogy sem akarna túljutni a Piklab, amikor Microchip C18 -cal (és persze wine-vel) akarsz fordítani és mondjuk olyanokról beszélne, hogy:

Error - could not find definition of symbol 'FSR2L' in file './main.o'.

ahol az 'FSR2L' helyén tetszőleges szó állhat, akkor van megoldás!

A trükk lényege annyi, hogy a C18 linkernek kell adni még 1 paramétert: /u_CRUNTIME

Az én jelenlegi linker beálltási sorom a projekt beállítás ablakban, ami kitűnően működik:

"c:\\mcc18\\bin\\lkr\\18f2431_g.lkr" /l/mnt/d/MCC18/lib/ /l"c:\\mcc18\\lib" /u_CRUNTIME /o%COFF /m%MAP %OBJS %LIBS

Remélem, hogy másnak is segítség lesz.

LabView Realtime FPGA

Már jó néhány hónap eltelt, mióta az NI real time moduljával dolgozom. Az elején rengeteg fejtörést okoztak az FPGA "kód" fordítása után visszakapott sekélyes és ködös hibaüzenetek, sok órá detailed log olvasgatás, amit csak hébe-hóba lehetett összeegyeztetni a rajzolt programkóddal. Egy szó, mint száz, sok probléma volt a kezdésnél, amire a (egyébként rendkívül készséges és segítőkész) support sem tudott válaszokat adni.
Az egyik legnagyobb ilyen probléma az, amikor a lefordított kód elvi maximális futási sebessége alacsonyabb, mint az órajel. Idegtépő volt, hogy felőlem akár tized akkora órajellel is futhatott volna, de nem tudtam megmondani a fordítónak, hogy ne erőlködjön a 40MHzen. Erre a megoldás a Timed Loopok alkalmazása volt, amiknek meg lehet adni, hogy mely órajelről működjenek. Persze, az élet nem fenékig tejfel, hiszen ezekbe a ciklusokba csak az 1 órajel alatt futtatható blokkok kerülhetnek be.
Emelett kiemelném, hogy tényleg komolyan gondolja az NI, hogy nem használjunk tömböket, ha elkerülhető. Az FPGA felépítéséből adódóan egy kapukból felépített flip-floppos leképzése van a tömböknek, ami tetemes helyet igényel majd a chipen és kivárhatatlan fordítási időket eredményez.
További tippek-trükkök:
Azt mondja a support, hogy a konverziókat a különböző számábrázolások között lehetőség szerint mindig oldjuk meg magunk és ne hagyatkozzunk az automata konverziót jelentő piros pöttyre.
Az FXP-ket gyorsan konvertálhatjuk úgy, hogy a To Boolean Array vi-vel át, majd az Boolean Array to Int vivel vissza alakítjuk.

Egy kis Excel makrózás

A héten sikerült egy kis Excel VB makró tapasztalatot gyűjtenem. Itt-ott vannak érdekességei, nehézségei, de a makró felvevő egy hihetetlen segítség és örök példatár ;).
A legtöbb fejtörést az 1004-es hibák okozzák. Ezek a hibák akkor jönnek elő, ha a VB makró olyan hiába ütközik, amit az Excel generál és így nem tartozik hozzá (használható) VB hibaüzenet.
Ilyen eset például az Excel függvény hívása VB makróból. Kiemelném, hogy ez pont egy olyan dolog, amit a makrófelvevővel nem lehet kipróbálni én is egy fórumon találtam rá a megoldásra (sajnos nem találtam meg a linkjét most újra). De a megoldás a következő, ha pl a HOL.VAN fv-t akarjuk hívni:

Application.WorksheetFunciton.Match(Mit, mRange)

ahol a Mit a keresett érték, az mRange viszont egy Range, aminek beállítása a következő

[...]
Dim mRange as Range
[...]
set mRange = Range("A1:A10")

Mint látható ilyenkor a függvények angol nevét kell megadni. Ezekhez a szótárt az office telepítési könyvtárában egy excel táblázatban megtalálod (ami általában: C:\Program Files\Microsoft Office\OFFICE11\ és ezen belül \1038\ alkönyvtárban van (2003-as office)) a FUNCS.xls fájlban.

Ha eleget teszteled a Match fv-t hamar belefutsz abba a hibába, hogy a keresett érték nem található a rangen belül és már kapod is a 1004-es hibát. Milyen jó is lenne ezt kezelni, nem? Lássuk is.
A VB ezen része igen silánynak tűnik számomra, főleg, hogy esetenként csak a GoTo-t használhatjuk. Bár pont a match fv esetében a következő kezelés is játszik:

On Error Resume Next
k = Application.WorksheetFunction.Match(0, mRange, 0)
If (Err = 0) Then
[... amt csak akartok ...]
End If

Maga a hibakezelés az On Error kulcsszavakkal történik, lehetséges folytatás még az :

On Error GoTo [Label]

amikor is a VB makróban a progmra futása a Label labeltől fog folytatódni.

A dumprep kikapcsolása

A windows kifagyott alkalmazás kilövésekor ("Bejejezés most") hosszasan gondolkodik a kilövés helyett. Pár hónapja észrevettem, hogy ilyenkor egy dumprep.exe programot indít el, amit ha a feladat kezelő segítségével kilősz, akkor a progarm azonnal kilép. Gondoltam, jó lenne ezt megszűntetni, hiszen így a kilövendő program mindig azonnal meg fog állni.
A módszer:
1. Start menü-> Vezérlőpult -> Rendszer (másik módszer: jobb klikk a Sajátgép ikonon-> Tulajdonságok)
2. Speciális fül
3. Az alján a Hibajelentés
4. Hibajelentés tiltása.

Tényleg érdemes végigcsinálni ezt a3 kattintást: eztán Alt+F4-re vagy a bezáró X -re kattintás után nincs várakozás, meg győzködés, hogy légysz küldj hibaüzit. A program egyszerűen bezáródik.

Have fun!

Apróság az Omron PLC-vel

Még a plc programozás kezdeteinek kezdetén apró informáicók hiánya nagyon zavart. Ez kifejezetten igaz a CP1L Omron PLC-re.
Ilyen volt például az analóg kiegészítő modul. A legelső bajom az volt, hogy a CX-One nem engedi, hogy további adjunk meg (ha van rá mód, kérem jelezze valaki). Így egyszerűen nem tudtam, hogy hogyan fogom rávenni az analóg modult a mintavételezésre. Persze a PLC útmutatója hamar választ adott rá. A trükk a címzésben van. Bekapcsoláskor a PLC végignézi, hogy vannak-e kiegészítő eszközök a buszon. Amiket megtalál sorban bemappeli a CIO memória területre csatornánként. Az,hogy egy eszköz csatorna igénye mekkora abból derül ki, hogy hány ki/be menete van. Az első csatornát (0.00-tól 0.15-ig bemenetek és 100.00-tól 100.15-gi kimenetek) a beépített periféri a foglalja el, tehát abban az esetben, ha csak egy analóg kiegészítő modul van csatlakoztatva, akkor a digitalizált érték mindig az 1-es word-on lesz megtalálható (feltéve, hogy a PLC bemenetei csak a 0-ás szót foglalják el).
A legnagyobb fejfájást számomra az "energia folyam" megértése okozta. Ez okozza a legnagyobb eltérést a PCs és a PLCs programok között. Hiszen, szerintem, ha ránéz valaki egy létradiagrammra, akkor az elágazásokat egy IF szerkezetnek fogná fel. Tehát azt feltételeztem, hogy a hamis ág nem kerül végrehajtásra. Ez részint igaz is. A hamis ágakba "nem folyik el" a zöld csík a monitorozás altt, az ott levő instructionok nem kerülnek végrehajtásra. Viszont az értékadó utasítások (tekercs) lefutnak! És a PLC kimenete mindig a program legutolsó kimenet kontakt parancs szerint áll be. Tehát szigorúan kell venni az egy kontakt egyszeri szerepeltetését a programban. Ezt csak a SETB, RSTB és SET, RSET parancsok alkalmazásával kerülhetjük meg. Nem igazán értem miért van ez így. Lehet, hogy a gyártók rájöttek, hogy ha ezt megváltoztatnák, túlontúl hasznos és egyszerűen kezelhetővé válnának a PLC-k...

LabView: Xnode is not executabe

Ez a hibaüzenet fogadott az első LabView Real-time projektem host programjának első próbaindításakor. A hibáról szerencsére nem találtam sehol megoldási leírást, kivéve a LabView helpet. De ez sajnos kimerül abban, hogy távolítsam el az Xnode-ot... (Ami jó lenne, de anélkül lőttek az fpga<>host kommunikációnak).

A megoldást abban találtam, hogy felültelepítettem a Developers Suite által telepített RT modult és új projektet kezdtem. Az új projektben már nem jelentkezett ez a hiba. Az, hogy a telepítés számított-e, sajnos nem tudom.

Update: valójában akkor dobja ezt a LabView, ha az fpga programot nem Targeten futtatod, hanem a pc-n (debug). A futtatást host-ra állítva, azonnal eltűnik a hiba.

Ruby on Rails

Kezdeti próbálkozások a RoR-el. Persze, rögtön hibába futottam: hiányolta az sqlite3 libraryt. Ez először furcsa volt, hiszen fel volt telepítve, de szükség volt a ruby sqlite3 csatolóra. Ezt feltelepthetjük a ruby saját installerével (gem), de én inkább az portage-t használtam:
# emerge sqlite3-ruby

A RadRailssal való rövid ismerkedés után visszaváltottam a jól megszokott és kiváló JOE szerkesztőre. Hírtelen hátrányának éreztem, hogy nem ismerte a szintaxis kiemelője a RoR-t. De rövid google keresgélés után egy blogon találtam hozzá megfelelőt: itt. Ezúton is köszönöm!

Kis apróság a Rubihoz. Az ismerkedést az Agile Web Developmnet with Rails 3rd edition-nel kezdtem meg és az Ajax résznél hiányoltam valamit: megoldottuk, hogy az Add to Cart-ra kattintva szépen, AJAX módra frissüljön a kosár, de a form_remote_tag -et nem sikerült a képekre is alkamaznom. A megoldást a link_to_remote adta:
<%= link_to_remote (image_tag(product.image_url),
:url => {:action => :add_to_cart, :id => product} ) %>
Ez még bárkinek hasznos lehet akár :D.

RadRails hiba induláskor

Akartam tenni egy próbát a RadRail Studio editorral, de indításkor a kezdő kép bemutatása után hibával kiléppet. A log alapján kezdtem el nekiindulni.
A hiba a logban "!MESSAGE Missing required bundles **még szöveg**".
A hiba oka az volt, hogy 1.7-es Blackhawk java JRE van nálam feltéve. Miután a gentoo eselect parancs segítségével átállítottam a rendszer JRE-jét a még fent levő Sun-jre 1.6-ra, rögtön működni kezdett.