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

CANopen Master szoftveres implementálása

A részleges implementáláshoz szükséges információkat gyűjtöm itt össze. Nem célom a témát a teljes mélységéig feltárni, inkább csak az, hogy legyen egy áttekintés a főbb funkciókról.

A CANopen az OSI rendszerben a 7-ik rétegen, az alkalmazások rétegén helyezkedik el. Tehát a lényegi megvalósítás szoftveres. A protokoll fizikai megvalósulását (1..3 réteg) a CAN busz specifikálja.

A specifikáicó az eszközökben levő információk rendszerét adja meg mind az elérés, mind a tárolás szempontjából. Objektumokat, könyvtárakat és alkönyvtárakat definiál, amiket azok számával érhetünk el.

Az adatáramlás többféle lehet. Három fő kommunikáció objektumot különboztet meg:

1. Adminisztratív üzenetek: ilyenek például a hálüzat kezelési üzenetek (NMT).
2. Szerviz adat objektumok (SDO - Service Data Objects): nem real time adatok írására/olvasására. A kiolvasható adat hossza nem kötött, de 4 byte-on felül tördelni kell. Mindig on request és master-slave.
   
3. Folyamat adat objektumok (PDO - Process Data Objects): real-time adadtok forgalmazásához.
   

Az üzenetek felépítése:
Az üzeneteket framekbe (keretekbe) foglaljuk. Ennek egy részét a CAN vezérlő és driverei oldják meg, nekünk csak a CANopen által elvárt protokolláris bájtokkal kell foglalkozni. Egy üzenet a COB-ID-del (Communication Object ID - Kommunikációs objektum ID) kezdődik. A csomagolást a CAN driver végzi. A COB-ID két részből áll + 1 bit a CAN protokollból, a többit nem tárgyalom itt:

• 4 bit a kívánt funkció kódja (nmt, pdo, sdo írás/olvasás, vész üzenet, boot-up üzenet stb),
• 7 bit a node sorszáma (eszköz sorszáma)
• 1 bit a RTF: RemoTe Frame - Távoli Keret. Ez használjuk akkor, ha információt kérünk a távoli eszköztől. Ilyen esetben nincs adat a keretben.

A CAN buszon a logikai 0 (nulla) domináns, ami azt jelenti, hogy ha egy eszköz épp nullát ír a buszra, nem számít, hogy hány másik eszköz akar 1-est írni. Ebből fakadóan a buszon végezhető funkciók és az eszközök sorszáma (node id) is egyben prioritási rendszert adnak meg. (Alacsonyabb számnak magasabb a prioritása.)

A COB-ID tehát a kívánt funkció és a node id összege. Eztán 8 byte adat következhet. Ezt kell nekünk a CANopen szabvány által megformálni.

A CAN és a CANopen lehetőséget ad Broadcast üzenet küldésre is. Ennek három speicális fajtája van:

• Modul Control COB-ID: 0x000. Ezt használjuk az eszközök protokoll szintű vezérlésére (elindítás, leállítás, reset stb).
• SYNC COB-ID: 0x080. Szinkronizálás parancs.
• Time Stamp: 0x100. Idő béjeg.
  

Az eszközök feléledés után (Boot-up) egy feléledési üzenetet küldenek. Ez az üzenet 0x700+Node Id COB-ID-t és egy byte adotot tartalmaz, ahol az adat 0.
Alap esetben az eszköz Pre-Operational (működés előtt) állapotban ébred, ahonnan a Master a Start Remote Node modul control paranccsal tudja átbillenteni működési állapotba.


Mik az objektum könyvátrak (OB-k)?
Ezek a CANopenes elnevezései az egymással összefüggésben levő "regisztereknek". Tehát az elv hasonló a regiszteres megoldásokhoz, de itt az adott regiszternek megszabott tartalma van és az alknyvtár számozással összefüggésben van a könyvtárral. Például:
Objects and Data for the 1^st RxPDO

Ind.	Sub- index	Name	Type	Attr.	Map ping	Default value	Meaning
0x1400	0	Number of elements	Unsigned8	ro	N	5	Communication parameters for the first receive PDO. Sub-index 0: number of following parameters
	1	COB-ID	Unsigned32	rw	N	0x000002xy, xy=Node-ID	COB-ID (Communication Object Identifier) RxPDO1
	2	Transmission Type	Unsigned8	rw	N	255	Transmission type of the PDO
	3	Inhibit Time	Unsigned16	rw	N	0	Present for reasons of backwards compatibility, but not used in the RxPDO.
	4	CMS Priority Group	Unsigned8	rw	N	-	Present for reasons of backwards compatibility, but not used.
	5	Event Timer	Unsigned16	rw	N	0	Event-Timer. Watchdog time defined for monitoring reception of the PDO.

Az index adja meg a könyvtárat, míg a sub index az alá ágazó paramétereket. A feljebb látható könyvtár egy PDO adatait tartalmazza.

Az NMT üzenetek:
Ezek a legyegyszerűbb üzenetek és a hálózat kezelésére vannak. Felépítésük szerint.

COB-ID Byte0 Byte1

ahol:

• COB-ID = 0x00
• Byte0: CS (Command Specifier) maga a kívánt parancs.
• Byte1: az eszköz node id-je, amelynek az üzenet szól.

A CS, tehát a parancs a következők egyike lehet:

• 0x01: Start Remote Node : távoli eszköz elindítása
• 0x02: Stop Remote Node: leállítása
• 0x80: Enter Pre op. mode: távoli eszköz működés előtt módba léptetése
• 0x81: Reset Node: távoli eszköz újraindítása
• 0x82: Reset Communication: a távoli eszközzel való kommunikáció újraindítása

A CANopen lehetőséget ad Node Guardingra (Node felügyelet), de ezt most nem tárgyaljuk.

A PDO-k:
Fogadásuk lehet szinkron, asszinkron és esemény vezérelt vagy ezek kombinációja. Max. 8 bájtot forgalmaz. 512 db tx és rx lehet. A Tx PDO-k a 0x181 memória területtől kezdődnek, míg az RX PDO-k a 0x201-estől. Alap esetben a CANopen szabvány minimum 2 RX és 4TX PDO definiálását írja elő.

A PDOk paramétereit a feljebb látható módon adhatjuk meg a megfelelő könyvtárak használatával, míg a PDO csomagok adat tartalmát a 0x1A00 könyvártól felfelé adhajuk meg, természetesen az adott eszköznek megfelelően. Ezek a Mapping paraméterek. A sub index 0 adja meg, hogy az adott PDO hány bájtot forgalmaz és a továbbiak a forgalmazni kívánt bájtok helyét és azt, hogy hány bitet az adott bájtból. Így a sub index felépítése:
Index SubInd Szélesség.

Így pl, ha az adott PDO a 0x600-as könyvtár 0x02-es alkönyvtárának 8 bitjét forgalmazza, akkor az adott deklaráció így néz ki: 0x06000208.

Fontos, hogy a CANopen little endian adat továbbítást alkalmaz, ami azt jelenti, hogy a több bájt hosszú adatoknak mindig az LSB, tehát kisebb helyiértékű része kerül előre. Tehát, ha a megadott indexű könyvtár pl egy 16 bites adatot tartalmaz, akkor a válasz így fog kinézni:
[0x280+Node id] [a 16 bit adat LSB-je] [a 16 bit adat MSB-je]

Ha egy mapping könvtár 0 sub indexe nulla és a hozzá tartozó communicaton object 1 szubindexének 31. bitje egy, akkor az adott SDO ki van kapcsolva.

Az SDOk:
Ezeket az objektumokat a nem valós idejűséget igénylő, sokszor nagy mennyiségű, adatok mozgatásához használjuk. Az továbbított adat hossza szerint lehet expedited vagy segmented adatátvitel.
A CAN által engedett 8 byte-ból a nulladik bájt mindig az SDO Command Specifier (SDO parancs megadó), ami a következőket tartalmazza:

• letöltés / feltöltés
• kérelem / válasz
• szegmentált / egyben küldött adat
• hány adatbájtot hordoz ez a keret
• alternáló bit, amely minden szegmensnél vált.

Létezik még egy úgynevezett Blokk adatátvitel, de ezt most nem tárgyalom.

A letöltés mindig azt jelenti, hogy az ezsköz BE írunk, míg feltöltéskor az eszközTŐL várunk adatot. Így a távoli eszköz lesz az adatátvitel szempontjából a szerver.

Most csak a három legáltalánosabb parancsot ismertetem.
A "-" helyén álló bitek nem számítanak bele a parancsba, de hagyjuk őket nullának!

1. Letöltés kezdeményezése:

Bit	7	6	5	4	3	2	1	0
From Client	0	0	1	-	n		e	s
From Server	0	1	1	-	-	-	-	-

Ahol:

• n: csak akkor értelmezhető, ha e=1 és s=1, egyébként nulla. Azt mutatja, hogy az adat mezőből hány byte nem adat. (A negyedig bytetól 8-n ig adat bytok vannak.)
• e: normál átvtel, 1= expedited átvitel
  
• s: hossz indikátor, 0= nincs megadva, 1= megadva
• e=0, s=0: az adatájtokat későbbi használatra tarja fenn a CiA
• e=0, s=1: az adatbájtok byte számlálók. (LSB elől.)
• e=1: az adatbájtok a letöltendő adatot tartalmazzák.

2. Felöltés kezdeményezése:

Bit	7	6	5	4	3	2	1	0
From Client	0	1	0	-	-	-	-	-
From Server	0	1	0	-	n		e	s

A jelölések megegyeznek a letöltésben levőkkel.

3. Átvitel megszakítása:

Bit	7	6	5	4	3	2	1	0
From Client	1	0	0	-	-	-	-	-

Megszakításkor a 0 és 1 adatbájt az objektum indexét, a 2-es byte az alindexet és a maradék 4 byte a 32bites hibakódot, a megszakítás okát tartlamazza.

Egy példa
A 0x3FE érték letöltése a letöltése a 2-es nodban levő 0x1801 sub 0x3 ba:

Cob-ID	byte
	0	1	2	3	4	5	6	7
0x602	0010 1011 (0x2B)	0x01	0x18	0x03	0xFE	0x03	-	-

A válasz:

0x582	0110 0000 (0x60)	0x01	0x18	0x03	-	-	-	-

A hiba objektum:
A CANopen definiál egy hiba objektumot is. A 0x080+node id Command specifier kóddal tudunk hibaüzit küldeni az adott node-nak.
És van egy error regiszterünk is az index 0x1001 könyvtárban.
A hibakódokat nem másolom ide.

Ennyit kell tudni dióhéjban a CANopenről ahhoz, hogy meg lehessen kezdeni az implementálást.

Labview Load VI

Ha Labview standalone (EXE-be fordított) programba be akarunk hívni egy VI-t problémánk akadhat. Az LU azt jelzi, hogy a VI nem futtatható (Error 1003 occurred at Open VI Reference - The VI is not executable). De ezt el lehet kerülni!
Kétféle megoldás van:

1. A kívánt VI-ket fordítás előtt hozzá kell adni a projekthez. De ennek az a hátránya, hogy újra kell fordítani az egész programot.
2. Az igazi megoldás viszont az, hogy a később behívni kívánt VI-ket llb-be rakjuk, majd onnan "Save As"-zel kimentjük. A kimentett fájlokat a standalone exe be fogja tudni hívni fejlesztő környezet nélküli számítógépen is!

Referencia: http://lavag.org/topic/3292-calling-an-external-labview-vi-from-an-exe/

A BLDC motorok hajtása

A BLDC motorok semmilyen körülmények között nem képesek vezérlő nélkül működni. A mai mikrokontrollereknek viszont nem ellenfél egy ilyen hajtás vezérlése. A vezérlési startégia többféle is lehet. Azt, hogy mikor melyiket választjuk a típus és a funkció dönti el. Az egyetlen közös bennük az, hogy valamilyen módon a kommutációs szekvenciát kell követnünk. A kommutációs szekvenciát a gyártó az adatlapon közli. Ezen kívül az, hogy a meghajtó tudhat sebességet állítani (PWM jelekkel) vagy sem. Ha más sebességet is akarunk állítani, akkor a szabályozás lehet nyílt hurkú (nincs visszacsatolás) vagy zárt (visszacsatolás hall szenzorokon vagy EMF jeleken keresztül).

A maradék hasonlóság (azaz, inkább egyezés) a vezérlő felépítésében és a teljesítmény elektronikában van. Egy elvi felépítést mutat a következő ábra (amit egy nagyon jó cikkből emeltem át, nem nagy kedvem volt újra berajzolni egy ilyet, ezer van belőle a neten):
Tehát alapvetően 5 jól elkülöníthető részből áll:

1. vezérlő MCU
2. meghajtó fokozat
3. teljesítmény fokozat (végfok)
4. motor
5. visszacsatolás.

Vezérlési/Szabályozási elvek, stratégiák:

Legegyszerűbben a szenzorozott motorokat lehet meghajtani. A szenzorok kimenete adja meg, hogy mi a következő kommutációs lépés. Amikor bejön a szenzorokon a jel, mi egyszerűen kitesszük a kimenetre és a megfelelő tranzisztorokat kapcsoljuk. Az ilyen, sorozatos kapcsolgatással a motort csak maximum sebességen tudjuk járatni.
Szoftver szempontból kétféle lehet a megvalósítás:

• megszakítás alapon: a szenzorok jele olyan processzor lábakra érkezik, amelyek megszakítást generálnak a processzorban. A megfelelő kimenet beállítását a megszakítás függvény teszi meg. Ez a legkényelmesebb, legjobb megoldás, főleg hosszútávon.
• "polling" (folyamatos ellenőrzés) alapon: a program fő ciklusa folyamatosan ellenőrzi a bemeneteket és annak megfelelően állítja a kimeneteket. Előnytelen, mert gyakorlatilag semmi másra nem lesz alkalmas a vezérlő (főleg nagy sebességnél). Az általam készített vezérlő jelenleg sajnos pollingot használ, de lesz ez még máshogy :).

Apró információ, hogy a szenzorok kimeneti jele kétféle lehet: jöhetnek 60°-os csúszásban egymáshoz képest, vagy 120°-ban csúsztatva. Ennek nem igazán van nagy hatása az életünkre, leszámítva akkor, ha olyan vezérlőt készítünk, ami mind a két féle szenzorozás esetén működőképes. De ez esetben sem nagyon...

Ha a motor szenzor nélküli, a helyzet annyiban változik, hogy további áramkör részekkel kell kiegészíteni a vezérlőnket, amely képes az EMF jelek mikrovezérlőhöz való csatolására. Ezeket a jeleket a vezérlő komparátor lábaira kell kötni és a nulla átmeneteket kell vizsgálni. A feladat még tovább bonyolódik, mert az EMF jelek jelentős késéssel érkeznek csak meg, amit a firmwarenek képesnek kell lenni kompenzálni. Ezt úgy tehetjük meg, hogy a jelek időközeit timerrel mérjük, és már a nulla átmenet előtt megszakítást generálunk és a következő állapotba tesszük a kimenetet.

Ez a technika egyébként a szenzorozott esetekben is használhat és Phase Advance (Fázis siettetés) a neve. Növeli a motor nyomatékát és legfőképpen akkor használjuk, ha a névlegesnél magasabb fordulatokat akarunk elérni.

További nehézség a szenzorozatlan motor meghajtásánál, hogy álló helyzetben (és alacsony fordulatokon) nem ismerjük a rotor pozícióját. Ezért az ilyen esetekben a mozgatást nyílt húrkú vezérléssel kell kezdeni, ellenőrizni, hogy a rotor megmozdult-e (lock) és csak aztán lehet átállni az EMF jelek használatára, ha azok nagysága elegendő.

Sebesség beállítás
A motor sebességét a mágneses terek által kifejtett nyomaték adja. A nyomaték a tekercsekben folyó árammal arányos. Ha kevesebb áram folyik a tekercseken át, a motor lassabban fog forogni. Ezt legegyszerűbben a PWM (Impulzus szélesség moduláció) segítségével tudjuk elérni.

Vissza csatolatlan esetben a sebesség vezérlést U/f vezérlésnek is hívják. Ekkor nem foglalkozunk a motor valós sebességével, hanem arra építünk, hogy adott feltételek alapján a motor adott PWM jeleknél mindig ugyanazzal a sebességgel fog forogni és a sebesség a kitöltési tényezővel arányosan változik. A PWM jelekkel elég az alsó (v. felső) kapcsoló tranzisztorok jeleit modulálni.
Bár ez nem mindig igaz, sok esetben ennyi már pont elég. Mint pl. az általam készített vezérlőnél is a kezelő a potméterrel állítja be a kívánt sebességet és a feladat a sebesség tartásra nem érzékeny.

Egyszerűen tudunk visszacsolt rendszert készíteni, hiszen a hall szenzorok (vagy az EMF jelek) körülfordulásonként 3 jelet is adnak számunkra. Ha mérjük a közöttük eltelt időt, ki tudjuk számítani a motor sebességét és egyszerű szabályozó stratégiákkal, vagy pl egy PID szabályozó implementálásával a motorra a kívánt sebességet tudjuk kényszeríteni. (A szabályozó kimenete a PWM jel kitöltési tényezőjét állítja.)


A Mikéntek és Hogyanok miatt lásd a már elkészített vezérlőmet és nézz vissza később is, valószínűleg lesz még cikk erről.

A BLDC motorokról

A BLDC motorok elektronikusan kommutált motorok, nem használnak szénkefét, így a csapágyazáson kívül nincs bennük kopó alkatrész. Mivel nem szikráznak, mint a szén vagy fémkefés motorok, ezért robbanásveszélyes környezetbe is vihetők (ilyen esetekben természetesen tengersok egyéb követelményt is meg kell vizsgálnunk!). Megfelelő kommutálás mellett egyes típusaik 10-15ezres fordulatra is képesek, de általánosságban igaz, hogy a névleges fordulat 50%-ára lehet őket hajtani (természetesen nyomaték veszteséggel).

Rengeteg fejtörést okozott, hogy akkor ez most mitől is lesz DC? Hát, nem is DC :). Nevezik állandó mágnesű motornak is (PM - Permanent Magnet), állandó mágnesű szinkron motornak is (PMSM) és állandó mágnesű AC motornak is (PMAC).

A felépítésük abban tér el jelentősen a kefés DC motoroktól, hogy ezekben a forgó rész az állandó mágnes és az álló rész van tekercselve. Ezek formájától és kivitelétől függően léteznek szinuszos és trapezoid BLDC motorok. A trapezoid motorokban a tekercselés egyenletes és a forgórész mágnesei négyszög formájúak. A színuszoid BLDC motorok forgórészét kerekebbre formálják és a tekercselést szinuszoiddá teszik (a közép tájékon sürűsödik). A színuszos motorok színuszos vezérlővel jobban hatásfokra képesek és (mivel) alacsonyabb a mechanikai rezgésekklé alakuló teljesítmény.
A kommutálást mindig a rotor szögének megfelelően kell végrehajtani. Ezt segítendő a gyártók Hall szenzorokat építenek a motorba, 60°-os szögben eltolva egymástól, amiből mindig lehet tudni, hogy melyik tekercseket kell energetizálni. De manapság már elterjedtek a szenzor nélküli motorok (költség hatékonyság). Az ilyen típusok esetén a tekercsben a forgó mágneses tér keltette indukált feszültséget használjuk fel (félreértés ne essék, a szenzoros motorok esetében senki sem kötelez rá, hogy a szenzorok jelét használjuk, természetesen ez a technika ott is alkalmazható). Ez a back Electromagnetic Force azaz az EMF. A motor EMF jeléből megtudhatjuk, hogy az illető motor szinuszoid, vagy trapezoid felépítésű. És itt jön a DC/AC kérdésre a magyarázat. (Amit egyébként az edaboard egyik fórumán találtam meg, de az információt nem ellenőrítem!) A színuszoid motorokat általában a gyártók AC-nek jelölik és csak a trapezoid típusok a DC típusok. Ugye, a zavara ejtő hasonlóság a szinkron motorokkal, majd jön az, hogy hajtsuk színuszos feszültséggel. Tehát azok mégsem teljesen DC motorok. Viszont gyakorlatilag elegendő a megszaggatott DC feszültség a működéshez, valószínűleg innen a neve.

A BLDC motorok előnyei:

• magas élettartam
• alacsony karbantartási igény
• jó nyomaték/térfogat arány
• jobb hatásfok (a teljes tápfeszültség a tekercsen esik)
• könnyű rotor
• kisebb elektronikus zaj
• Egyenletes nyomaték karakterisztika

Legnagyobb hátránya az, hogy vezérlő nélkül nem moccan meg. Emellett ezek a vezérlők jó drágák :). Gyakran említik emelett, hogy gyártani is drága őket, de saját tapasztalatból ítélkezve én nem érzem olyan/sokkal drágábbnak, mint a sima DC motorokat. Nem beszélve a fémkefés DC-kről, amik simán túlszárnyalják árban őket.

Működése:
A működésének az alapja természetesen a mágnesesség, elektromágnesesség. Miszerint, az árammal átjárt vezető mágneses teret gerjeszt. Ha ebbe a térbe egy állandó mágnest helyezünk, akkor arra erő/nyomaték fog hatni.
A BLDC motorok tekercselését általában 6 részre osztják (60° helyezve egymástól), amiből egy időben 2 tekercset energetizálunk. Így forgatva mindig a következő pozícióba a rotort (állandó mágnest).



A BLDC motorokról a legösszefogottab ismertetőt a Micrchip AN885-ös számú BLDC Fundamentals cikk adja.

Linux, SPICE, Geda suite

A nemrég megkezdett traffipax jammer (zavaró) fejlesztési projektem keretében a jobb megértés és gyorsabb kisérletezés érdekében egy picit elmerültem a linux alatt SPICE rejtelmeiben. Ez nem az első ilyen próbálkozásom volt, de a Gschem kezdeti kényelmetlennek tűnő funkciói és az egész Geda suite pl. egy Orcadhoz mért kényelmetlensége mindig könnyedén eltántorított.

A nagy munka megkezdése előtt picit elvonta a figyelmem a Gschem egy-egy fura funkciója és a forráskódban való kis turkálás után apró átalakításokat eszközöltem. Tényleg nem sok minden,de fura módon sokkal használhatóbbá tette számomra a kezelést. Ilyen pl, hogy a net (összekötő) összekötő parancs hot-key (n) lenyomásakor ne kezdjen el azonnal vonalat húzni, mert úgy használhatatlan. Beletettem a mozgatás közbeni jobb klikkes forgatást, igaz, ez csak kényelmi funkció, inkább Eagleből jött megszokás. Hasonló apró módosítás, hogy az objektumokat forgatáskor a középpontjuk körül forgassa. (Ez egyébként sokkal hosszútávúbb lett, mint egy pár perces módosítás, mert a snap-to-grid szétszórta az alkatrészeket :D.) Sok többi funkciót meg megtaláltam, hogy már kész van :).
Sokat gondolkodom még a cross-hair kurzor megvalósításán és ami csúcs lenne, hogy az Easy spicehoz hasonlóan beírkálni a spice szimuláció munkaponti eredményeit az áramköri rajzra.

És már meg is kezdődhetett a munka! :)

A spice használatát először a Spice-gui és az Easy Spice segítségével akartam megkezdeni, de hamar belefutottam abba, hogy másra lenne szükség, mint ami elkészült ezekben a Gui-s verziókban. Ettől függetlenül mindenkinek ajánlom a megismerésüket, mert alap esetben nagyon hasznosak lehetnek.

Nem célom most egy összefüggő spice tutorial írása, ilyen igen sok van a neten. Inkább csak szemezgetés szinten.

Hogyan kezdjük:
Először is rajzoljuk meg az áramkört Gschemben. Használjuk a General és a Spice alkatrészeket. Nagyon fontos és nem elfelejtendő az áramkör nullájának jelölése a netname=0 paraméter dekralásával. Ha kész vagyunk, mentsük el az áramkört. Az áramkörből a gnetlist segítségével készítünk az ngspice által használható szimulációs fájlt.
# gnetlist -g spice-sdb -o [kimenete.net] [bemeno.sch]

A -g kapcsoló azt mondja meg a gnetlistnek, hogy milyen spice kimenetet generáljon, a -o a kimeneti fájl neve legyen és az sch az elkészített áramkör.
Én ngspice-t használok a szimulációra:
# ngspice [kimeneti.net]
És már előttünk is van a spice konzol. Használatát a cikk alján található linkeken keresztül ismerhetjük meg.

A subckt-k használata:
A spice modellezés lényege az lenne legtöbbször, hogy nem az alap spice modelleket használjuk, hanem azokat a valóságnak megfelelően paraméterezzük fel. Továbbá lehetőség van előzőleg elkészített (akár gschemmel) modellek felépítésére és azoknak behívható modullá (SubCkt) alakítására.
Ilyen aláramköröket úgy implementálhatunk az áramkörünkbe, hogy behívjuk a neki megfelelő spice alaktrészt és a paraméterei közé hozzáadunk egy
file = [subckt elérése]
value = [subckt neve]
A spice csak akkor fogja a subckt modellt használni, ha az alkatrész neve "X"-el kezdődik. Pl van egy tranzisztorunk, Q1, amit subckt modellként szeretnénk használni, akkor a netlistben nem Q1ként kell hogy megjelenjen, hanem pl XQ1-ként.
Ezt azért írom ki, mert a gschemből gnetlist-el generált netlistek nem kapják meg az X előbetűt! Így a spice mindig azt írja, hogy model not found és a default paramétereket használja. Ahhoz, hogy ezt elkerüljük két dolgot tehetünk. Az egyik az, hogy mindig futtatás előtt kézzel javítjuk a netlist fájlt. A másik, hogy a gschemben kézzel a név elé írjuk az X-et és a gnetlistet egy további "-n" kapcsolóval hívjuk.
# gnetlist -n -g spice-sdb -o [netlist.net] [schem.sch]
Ekkor a gnetlist nem javítja a típusnak megfelelően a modell neveket.

Step size too small hiba:
Ha sokáig érthetetlen módon "step size too small" hibaüzenetet kapunk érdemes egy picit megfigyelni a munkaponti értékeket. Ha nagyon nem stimmelnek (pl negatív feszültségek egy csak + tápot tartalmazó áramkörben) ellenőrizzük, hogy a dedikált 0 (nulla) referencia pont meg van-e adva. Éppígy én úgy jártam az ngspice-val, hogy volt egy kábelem n4-nek elnevezve és a 0-val összekötve. A gnetlist természetesen észrevette a dupla nevű kábelt és meg is szüntette nagybuzgón. A 0-t..... Tapasztalat: mindig használd a gnetlist DRC checket!

Ha mégsem ilyen jellegű a hibánk, előfordulhat, hogy csak nagyobb számítási felbontásra van szükségünk. Ilyenkor lérdemes a környezet paramétereit babrálni egy picit. Ezt (ngspice esetén) a set paranccsal vagy a .ckt fájlba .OPTIONS sorral tehetjük meg.

>> set KULCS=ÉRTÉK
vagy
.OPTIONS KULCS=ÉRTÉK

Megoldási kísérletek, zárójelben jelzem az ngspice alap értékeit.
Emeljük a relatí hiba tolerancia értékét: RELTOL=0.01 (def: 0.001 azaz 0.1%)
Emeljük az absz. hiba toleranciát: ABSTOL=1f (def: 1pico)
Emeljük a fesz. hiba toleranciát: VNTOL=10m (def 1m)
Az ITL paraméterek a konvergencia keresés maximális lépés számát határozzák meg. A tranzienssé a 4-es: ITL4=200 (def=50)

Ha minden kötél szakadt, a hibát a szimulált áramkörben kell keresned. Próbálj IC (initial condition)-ket megadni, vagy realisztikusabbá tenni a modellt. Tegyél be kábel és generátor belső ellenállásokat, szimbolikus szórt kapacitásokat. Próbáld meg darabolni az áramkört. Emelett, ha nem is sikerül a spicének végigszámolni, de találsz olyan paramétereket, hogy néhány mintát mégis kiszámol, mielőtt elhal, akkor mindenképpen plottoltasd vele az érdeksebb de akár a triviálisabb csomópontokat is.




Linkek:

Spice tutorial:
http://littletux.homelinux.org/knowhow/ngspice.pdf

Ngspice kézikönyv:
http://www-ti.informatik.uni-tuebingen.de/~bernauer/lehre/ti-1-0506/spice/ngspice.pdf

spice3 kéziköny:
http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/sec3.html

Egy másik Spice tutorial:
http://web.mit.edu/geda/arch/i386_rhel4/versions/current/share/doc/geda-doc/spice-sdb/intro.html

Minden geda cucchoz:
http://web.mit.edu/geda/arch/i386_rhel4/versions/current/share/doc/geda-doc

Ez is komoly spice leírás:
http://www.seas.upenn.edu/~jan/spice/spice.overview.html

Még spice:
http://www.brorson.com/gEDA/SPICE/t1.html

Érdekes spice modell ötlet:
http://www.ecircuitcenter.com/Circuits/vc_resistor1/vc_resistor1.htm

Spice modell lista
http://homepages.which.net/~paul.hills/Circuits/Spice/ModelIndex.html
Egy érdekes elektronikai könyv spice modellezéssel:
Electronic concepts: an introduction
szerző: Jerrold H. Krenz
http://books.google.com/books?id=Le9zdVoMEOEC&pg=PA146&lpg=PA146&dq=common+emitter+bias+spice&source=bl&ots=WLBrR9C-I3&sig=AXtLdFpM-N7ExJ41NB27Lgpbwoc&hl=hu&ei=dVG1SvXdDYaZ_QbSpN3GDQ&sa=X&oi=book_result&ct=result&resnum=10#v=onepage&q=common%20emitter%20bias%20spice&f=false

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!

Ékezetes fájlnevek konvertálása

Folyamatos vissza-vissza térő problémám, hogy az oprendszerem egyes részei képesek mind-mind más karakterkódolást használni. És persze az a legjobb, amikor egy külső eszköz még újabb karaktereket kever be. Ami akkor válik igazán érdekessé, amikor pl. fényképekről van szó és 50-60 fájlt kéne átnevezgetni ékezet nélkülire, vagy legalább olvasható ékezetesre.
Ilyenkor mindig nekiugrok az iconv parancsnak és hosszass böngészés után rájövök, hogy nekem nem az kell. Akkor mi is a másik? :D Google...
Előbb utóbb rá szoktam bukkanni erre az oldalra, ahol szépen leírják a convmv használatát. A két oldalas cikkből a számunkra érdekes rész mindösszesen:
# convmv -f [jelenlegi_karakter_készlet] -t [kívánt_karakter készlet] [fájlnevek]

A jelenlegit persze csak az isten tudja. Általában a sima iso-8859-2 vagy iso-8859-1 el szoktam próbálni és mivel eddig bejött, ezért sosem kerestem rá eszközt, ami kitalálná.
A kívánt nálam az utf-8 (de lehet iso-8859-16 meg bármi más is, a rendszeredtől függően).
A fájlneveket wild-card karakterekkel (*, ?, . stb) is megadhatjuk, de listát is írhtaunk belőlük.

Az első futtatásra csak bemutatja a program, hogy mit tenne. Ha az eredmény tetszetős számunkra, akkor futtassuk újra a --notest kapcsoló használatával.

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.

Mp3 normailzálás

Az mp3 normalizálás nem egy új technológia, de sokáig szkeptikus voltam vele szemben, de legfőképp a lecsökkenő hangerő miatt nem használtam. A normalizálás célja, hogy a normalizálnadó fáljok hangerejét egységesre állítja a számokon belüli hangerő arányokat megtartva. Viszont a hordozható lejátszók relatív korlátolt hangerejével szemben az autóerősítő mellett megengedheti magának az ember, hogy éljen a lehetőséggel. Megelőzi a túlerősítésből származó torzulást (clipping) és nem kell egyfolytában tekergetni a hangerőgombot.
A legegyszerűbb megoldásnak linux alatt az mp3gain nevű kis program. A használata is azonosan könnyű:
# mp3gain --auto *
a normailzálandó fájlokat tartalmazó könyvtárban. Megjegyezném, hogy a program ennél jóval több kapcsolót ismer, de szerintem az átlagos felhasználónak ez épp elég lesz.
Igaz, az mp3gain nem tesz visszavonhatalan változtatást az mp3 fájlokban, mégis ajánlom, hogy külön könyvtárba másolgassuk a felveendő zenéket.

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

Virtual CD Control Panel használata

A Virtual CDROM Control Panel egy, a Microsofttól szokatlan módonn, apró és mégis rendkívül hasznos program. Segítségével CD képeket tölthetünk be a rendszerben megjelenő virtuális meghajtókba.
Használata egyszerű:

Letöltés után kitörmörítjük valahova. Lényeges, hogy a programnak nincsen telepítője, ezért ne keressük a start menüben. Intézővel, jobb esetben Total Commanderrel kell elindítani.

Először a Driver controlban kell az Install Driver-re kattintani és kiválasztani a programmal együtt letöltött drivert (vcdrom.sys), majd a Start gombot kell megnyomni. Ezután OK gombbal visszatérsz a főmenüjébe.
Az Add Drive gomb egy új virtuális meghajtót csatol a rendszerhez. Azt a listából kiválasztva tudjuk használni.
A Mount gombbal lehet CD képet beletölteni. A Remount megismétli a betöltést. (Pl gép újraindítás után.)
Az Ejectel a már betöltött CD képet vehetjük ki.
Az OK gomb bezárja a programot,de a virtuális meghajtók megmaradnak.

Nagyon fontos megjegyezni, hogy ez a program nem indul el magától sem a windows indításakor, sem a cd képekre kattintva. Ezt mindig külön el kell indítani, ezért érdemes akár egy parancsikont kitenni belőle az asztalra (ctrl+shift-et nyomva tartva húzzuk az asztalra az ikonját az Intézőből).

Udf, iso, cdfs és rock formátumokat támogat (az UIF-et nem!).

SVN folytatás

Az SVN Red Bookkal folytattam az ismerkedést. Úgyhogy csak a legfontosabbakat.
A trunk és branch témát már egyáltalán nem értem, hogy honnan jött a wikinek, itt nincs róla szó. Viszont, lényeg a lényegben kezdő versioningosoknak az SVN lényege.

Miután szépen létrehoztuk a repot és importáltuk a programunkat létre kell hozni a helyi munkakönyvtárt is. Persze, eddig is volt munkakönyvtár, mondhatnánk, hiszen épp most importáltunk belőle. De ez nem ugyanaz :) Az új munkakönyvátrunkról az svn is tudni fog, ismerni fogja a file-ok revision számait és az utolsó módosításuk dátumát. Igen, pont ezek kellenek a követéshez. A munkakönyvtár létrehozása nem más, mint a repo letöltő parancs:
# svn checkout http://localhost/svn/Teszt

Ekkor az SVN letölti a repon található legfrisebb változatot. A sorok elején az 'A' betű az ADD, tehát hozzáadást jelöl.

Ha módosítást akarunk eszközölni a repon levő file-okban, azt az svn commit paranccsal tehetünk meg. Lehetőség van szöveges megjegyzés hozzáfűzésére is, és erősen ajánlott. Tehát, módosítsunk egy fájlt (a példa kedvéért: text.c-t) és próbáljuk meg feltölteni:
# svn commit text.c --message="Pl: kijavítottam a xxx fv-t."

Az előzőekben nem voltam biztos benne, hogy a létrehozott könyvtár tulajdonosának az SVN usernek (jelen esetben az apachenak) kell lennie. Ez a parancs rögtön rávilágított, hogy igen. Gyors chown után már simán le is futott.
Az svn commit üresen az összes módosított file-t feltölti.

Ha többen dolgoznak a projekten, akkor szükség lehet még az svn status és az svn update parancsokra. A status a file-ok állapotát mondja meg, míg az update frissíti a repon már módosult file-okat.

Fontos megjegyezni, hogy igaz, a munkakönyvtárunkban szabadon garázdálkodhatunk, szerkeszthetünk, törölhetünk és hozhatunk létre új file-okat, de pl a mozgatást vagy másolást nem szabad a rendszer mv paranccsával vagy a file böngészőnkkel eszközölni, hanem az svn copy, svn move parancsokat kell alkalmazni.

Subversion telepítés és repository létrehozás Gentoo alatt

Épp ideje verzió követőt telepíteni, az évek során sokszor hasznos lett volna. Rövid keresgélés után a subversion mellett döntöttem.
Gentoo alatt a telepítés megkezdése egy szempillantás, de azért én szeretek ránézni, hogy mi is fog települni és milyen USE flagekkel:
# emerge -a subversion
A -a parancs az 'ask', tehát nem kezd ész nélkül fordításba, hanem megmutatja, hgoy mit fog fordítani és milyen flagek vonatkoznak rá. Nekem jó, mehet. Bár a neon csomag frissítése még sok másik csomag frissítését vonja maga után, de ez van (aki ezt nem bírja, térjen át Ubuntura...).

Az emerge végén:
* Subversion Server Notes
* -----------------------
*
* If you intend to run a server, a repository needs to be created using
* svnadmin (see man svnadmin) or the following command to create it in
* /var/svn:
*
* emerge --config =dev-util/subversion-1.5.4
*
* Subversion has multiple server types, take your pick:
*
* - svnserve daemon:
* 1. Edit /etc/conf.d/svnserve
* 2. Start daemon: /etc/init.d/svnserve start
* 3. Make persistent: rc-update add svnserve default
*
* - svnserve via xinetd:
* 1. Edit /etc/xinetd.d/svnserve (remove disable line)
* 2. Restart xinetd.d: /etc/init.d/xinetd restart
*
* - svn over ssh:
* 1. Fix the repository permissions:
* groupadd svnusers
* chown -R root:svnusers /var/svn/repos/
* chmod -R g-w /var/svn/repos
* chmod -R g+rw /var/svn/repos/db
* chmod -R g+rw /var/svn/repos/locks
* 2. Create an svnserve wrapper in /usr/local/bin to set the umask you
* want, for example:
* #!/bin/bash
* . /etc/conf.d/svnserve
* umask 002
* exec /usr/bin/svnserve ${SVNSERVE_OPTS} "$@"
*
* - http-based server:
* 1. Edit /etc/conf.d/apache2 to include both "-D DAV" and "-D SVN"
* 2. Create an htpasswd file:
* htpasswd2 -m -c /var/svn/conf/svnusers USERNAME
*
* If you intend to use svn-hot-backup, you can specify the number of
* backups to keep per repository by specifying an environment variable.
* If you want to keep e.g. 2 backups, do the following:
* echo '# hot-backup: Keep that many repository backups around' > /etc/env.d/80
subversion
* echo 'SVN_HOTBACKUP_BACKUPS_NUMBER=2' >> /etc/env.d/80subversion


Valamiért a httpd2 alapú SVN-t választottam. Ez kisebb módosításokat igényel a /etc/apache2/httpd.conf fájlban.


DAV svn
# Nekem a gentoo alapból ide telepíti
SVNPath /var/svn/



DAV svn
SVNParentPath /var/svn


Ezután már el is érhető a repo a böngészőben (nekem készült egy repos nevű repo): http://localhost/svn/repos.
Ha az svnadmin -t használva létrehozunk egy repository-t, akkor az a /var/svn alá kerül be és az előző módon érhető el a böngészőből:
# svnadmin create Teszt

Aztán egy howto meglengette előttem a Trac használatát és én bele is vágtam. Ez egy picit eltolja a dolgok végét, mert a pythont és társait újra kell fordítanom sqlite USE flaggel.

Hm, addig is kis google után belefutottam egy nagy bajba: a gentoo-wiki elvesztette az adatbázisát (miért nem kérik le a lapokat a google-cacheből?!), viszont cachelve megtaláltam az SVN howtot. Mondhatni, talán a legjobb. Igen kár a wikiért! :(


Úgyhogy ennek segítségével el is kezdtem a folytatást: létre kell hozni három könyvtárt.

1. Trunk: ebben lesz mindig a legfrisseb stabil verzió.
2. Tags: Itt vannak a különböző lényegi verzióváltások (v1, v2, v3).
3. Branches: elágazások. Olyan esetekre, ha pl néhány fejlesztő későbbi feautre-on dolgozik. Így az a félkész rész nem kell, hogy bekerüljön a stabil verziókba.

# mkdir /var/svn/Teszt/{trunk,tags,branches}

Én nem tudom, hogy szükséges-e a fájlok tulajdonosának az apache felhasználót megadni, de megtettem (mivel az svn apachként fut nálam).

# chmod apache.apache /var/svn/Teszt/{trunk,tags,branches}

És most jön az első import. Ehhez az importálandó projekt gyökerében kell lenni! (Az importálás kezdete a '.'.)

 # svn import . file:///var/svn/Teszt/trunk -m 'Elso import'

Szerencsésen "Commited 1 revision." a végeredmény. A teszteléshez listáztathatjuk a fileokat:
# svn ls file:///var/svn/Teszt/trunk
Természetesen ezt akár a webszerveren keresztül is intézhetjük:
# svn ls http://localhost/svn/Teszt/trunk

Folytatása következik...

Omron PLC programozás

Van szerencsém, hogy az egyik új munkához Omron PLC-t kell használnom. Valójában nem örülök neki, kezd elég lenni a ismerd_meg_két_hét_allatt csinálj_kitűnő_programot és működjön_is felállású munkákból. És a PLC-k soha nem is voltak a szívem csücske. Viszont a program elvi változata már kész, muszáj implementálni, azt meg nehéz az új ismeretek nélkül.

Nnna, elég a nyafogásból. Hál istennek az Omron cég a fennállásának a 70%-át dokumentálással töltötte, ezt abból gondolom, hogy ritka az 1000 oldal alatti pdf-ük :), de 500 alá már tényleg csak a legritkább esetbe silányodnak.
Elég sok az új információ, ezért egy picit muszáj jegyzetelnem közülük, mert van, amit más másodszor olvasok át és a teljes újdonság hatásával él.

Szóval a Programming Manualból szemezgetek elsőként. Hagyjuk inkább a régen-tekercs, de ma-már-kártya jellegű program szerkezet megközelítést, ez röhej és szánalom és nem program struktúra.


Az interlock és a jump:
Erősen nem értem az Interlock koncepciót. Ennek az lenne a lényege, hogy kikapcsol programrészleteket. Egy nem túl bonyi kis programmal próbáltam megérteni a két megoldás lényegét: az interlock kikapcsolja a közbezárt programkódban definiált kimeneteket, ha azok aktívak, függetlenül az őket aktiváló parancs állapotától és ha megszűnik az interlock, akkor a parancsnak megfelelő állapotba térnek vissza. Emellett reseteli az időzítőket is. A Jump (JMP) parancs viszont, 100%-ban a nevének megfelelően működik: átugorja a közbezárt parancsokat (JME-hez ugrik), NOP-ot futtat helyettük. Ezáltal hangyányit gyorsabb lehet a program futása is. Így egyáltalán nem foglalkozik a közbezárt kimenetekkel, időzítőkkel stb...

Címzések
Na de mindegy is. Térjünk át inkább a címzés konvenciókra:
Bit szerinti címzésnél a WWWW . BB (W- word, B- bit) formáció a használatos, a WWWW nem csak szám lehet, hanem a PLC különböző memória területeinek valamelyike. Értelemszerűen wordre a .BB elhagyásával hivatkozhatunk.
Az '@' jel egy szám előtt azt jelzi, hogy Hexa értéket írtunk oda, míg a '*' használata BCD kódolású számot jelez.
Lehetőség van indirekt címzések használatára az IR tároló regiszter alkalmazásával, de ebbe nem mennék bele (és remélem nem is lesz most szükségem hasonlóra).

Konstansok beadása:
Ha egy szám elé '#'-et teszünk, a fordító előjel nélküli hexa számként fogja értelmezni, ha előjelet írunk elé, akkor előjeles decimális számnak, míg az '&' karakter előjel nélküli decimális számnak tünteti fel. BCD számot itt is a hexával megegyező módon jelölünk.
Vannak sztringek is, ezeknek a lezárása 00, vagy 0000-al történik.

Futtatási feltételek:
Számomra az első újdonság az a Differentiated jelző és jelentése volt. Egy differenciált művelet csak a bementi változó (felfele, jelölése '@') 0->1, vagy (lefele, jelölése '%') 1->0 változásakor egyszer fut le! Azért, ez még hasznos lehet. Ez lehet egy parancs előtt is, pl: @MOV, de lehet a kontaktusba építve is, amit a kontaktusba rajzolt fel/le nyíl.

Neurális hálózatok II.

Küszöbszintes hálózatok: Perceptron és Adaline

A Preceptront a kései 1950-es években publikálta Rosenblat. Ez egy egyrétegű hálózat, amely egy vagy több, a bemenetekhez wio súlyfaktorokon kersztül kötött, kimeneti o neuronból áll. Az összes kimeneti neuron az összes bemeneti neuronnal kapcsolatban áll. A legegyszerűbb esetben a hálózat csak két bemeneti és egy kimeneti neuronból áll. A kimeneti neuron bemenete a bemeneti neuronok súlyozott összege plussz a bias.

(A képre kattintva megtekintheted jobb minőségben.)

A kimeneti aktivációt az előző cikkben ismertetettek szerint a következő fv.-vel számíthatjuk:A hálózat küszöbszintes (Heaviside, sgn), mivel a kimenet állapota adott küszöb értéktől függ, ami jelen esetben a 0:A hálózat kimenete ezáltal a bemenetek állapotától függően +1 vagy -1 lehet, így besorolásra lehet használni. Ha az összegezett bemenet pozitív, akkor az egyik csoportba tartozik a bemeneit minta, ha negatív, akkor a másikba. Ez a felosztás egy egyenes menti felosztást eredményez, amelynek a függvénye:Ebből látszik, hogy a bias a besoroló egyenes ofszet értékét adja meg:

(A képre kattintva megtekintheted jobb minőségben.)

Megjegyzendő, hogy a súlyvektort is ábárzolni lehet a geometrikus megjelenítésben és az mindig merőleges az osztályozó függvényre.

A Perceptron tanulási folyamta:
Bemenő minták: X vector.
Kimenet: d(X), ami osztályozó feladat esetén általában +1 és -1.
Ilyen esetekben a perceptron tanulási szabálya egyszerű:

1. Véletlenszerűen kiválasztott súlyokkal kezdjük.
2. Az oktató csoportból kiveszünk egy X vektort.
3. Ha y != d(X) akkor a súlyokat d wi= d(X) * xi értékkel megváltoztatjuk.
4. Vissza a 2. pontba.

A kapcsolatok súlya mellett a küszöbszint súlyát is állítani kell, mégpedig úgy, hogy a változás legyen nulla, ha megfelelő a kimenet (d(X)) és legyen d(X) egyébként.

Neurális hálózatok I.

Az elkövetkezőkben több, a neurális hálózatokkal foglalkozó bejegyzés is várható, mert a fejembe vettem, hogy megismerkedem velük egy picit közelebbről. Elsődlegesen a neurális hálózatok alapjaival és software-s implementálásával akarok foglalkozni. Előrevezetném, hogy a témának vannak mélységei és (főleg matematikai) bonyolultságai. A legjobb kalauz, amit találtam hozzá Ben Kenrose An Introduction to Neural Networks (1996) című könyve. Kiemelném, hogy a cikkek, amiket írni akarok nem saját gondolatok gyűjteménye, hanem egy kivonat, jegyzet a könyvből.

Kiemelném még a Neural Networks at your Fingertips oldalt, ahol ANSI C-ben megvalósított neurális hálozatokat szimuláló programokat tett közzé Karsten Kutza. Sajnos a kommentezés szegényes (nincs), de rendezett a forráskód így könnyen követhető.

Jelölések: a jegyzetekben konzekvensen a könyv által megkötött jelöléseket fogom használni.

Bevezetés, alapfogalmak:
A neurális hálózatok alapelemei a neuronok. Ezek az emberi agyban megtalálható neuronok rendkívül leegyszerűsített modelljei. Ezek végzik az adat feldolgozását. Alapvetően három típusukat különböztetjük meg: bemeneti, rejtett (közbenső) és kimeneti neuront. A bemeneti neuronok feladata az információ fogadása a külvilág felől, itt nem történik feldolgozás. A közbenső és a kimeneti neuronok általában (az alap modell szerint) a bemeneti jeleiket adott súlyok alapján összegzik. Ez a súlyozás dönti el, hogy két neuron kapcsolatban áll-e és ha igen, akkor az mennyire szoros.
Bias: egy plusz bemenete a feldolgozó neuornoknak, amely mindig +1.
A kapcsolatot a következő képlet jellemzi:
, ahol teta a bias, wjk a j-ik neurontól a k-nak adott jele és yj a j-ik neuron kimenete.

Aktiváció és kimenet: a bemenetek súlyozott összegzése megadja a neuron aktuális aktivációs szintjét, amelyből egy függvénnyel kiszámítjuk a kimeneti jelet. A függvény lehet egy erősen hátoroló (kétértékű) például az sgn() függvény, lehet lineáris vagy fél-lineáris, vagy lehet finoman határoló. Finoman határoló függvények a sigmoid függvények. Ezek S alakúak. A legalapvetőbb sigmoid függvény a
Megjegyzendő, hogy léteznek olyan neuoronok is, amelyek kimenetét nem determinisztikus módon határozza meg a bemenetek állapota, hanem egy stochastikus függvény alapján a magas kimeneti érték valószínűségét határozzuk meg.

Hálózat típusok:
Előrecsatolt hálózatok: a hálózat több rétegből is állhat, de nem nem tartalmazhatnak visszacsatolást. A visszacsatolás az, amikor a neuronok kimenete a vele azonos rétegen belül van egy neuron bemenetére kötve, vagy egy (az adatfolyam iránya szempontjából) előrébb levő rétegben levő neuron bemenetére van kötve.
Visszacsatolt neurális hálózatok: tartalmaznak visszacsatolást.

A hálózatok tanítása:
A tanítás lehet direkt és relaxációs. Több módszer is létezik. Egyik mód az, hogy a súlyokat explicit módon a kívánt kimenetnek megfelelően állítjuk be, a priori (abból, ami volt) tudás felhasználásával. Másik mód az, hogy a renszert mintákkal tápláljuk és az maga állítja be a súlyokat adott szabályok alapján.
Így létezik:

• Felügyelt tanulás vagy Asszociatív tanulás. Be és kimeneti párokkal tanítjuk.
• Felügyelet nélküli tanulás vagy Önrendszerező tanulás. A rendszernek mintákat mutatunk amiből magának kell, hogy kialakítsa a döntést. Nincs a priori ismerethalmaz.

Legalapvetőbb súly változtatást számító képleg a Hebb szabály:ahol Gamma a tanulási ráta.
A delta-szabály, másnéven a Widrow-Hoff szabály figyelembe veszi a felügyelő által kívánt kimenet érétket is:ahol dk a kívánt kimeneti érték. A delta-szabályról a későbbiekben bővebben is lesz szó.

Bias, ofszet, küszöb értékek: jelentésük megegyezik és mindegyik egy konstans bemenetet jelent. Bár az utolsó kettőt néha az aktivációs függvényhez sorolják. Gyakorlatilag egy állandóan +1 bemenet az összes (nem bemeneti) neuronon.

Rétegek száma: előrecsatolt rendszerekben a bemeneti réteg nem végez feldolgozást, így azt nem számítjuk bele a rétegek számába. Így egy renszer bemeneti, rejtett és kimeneti réteggel két rétebű rendszernek számít.

Reprezentáció és a tanulás: a magas reprezentációs készsége egy rendszernek csak azt mutatja meg, hogy milyen pontossággal képes megközelíteni egy adott függvényt, ismerve, hogy az optimális súlyozás mellett is lesz kimeneti hiba. A második kérdés, ismerve, hogy minden rendszerben létezik optimális súlyozás, az, hogylétezik-e olyan módszer, amellyel ( iteratív módon) el lehet érni az optimális állapotot?

Piros LED, mint fotódióda?

Egy kollégám hívta fel a figyelmemet a hasonló című cikkre az EDN cikkei között. Bár tanulmányaink során megismerkedtünk a fotódiódák működésével, mégsem állt teljesen össze az ember fejében, hogy a sima, fénykibocsájtó, LED is használható fotódiódaként.

Ugye az elv röviden: ha egy elegendően nagy energiájú foton becsapódik a dióda PN átmenetének a kiürített rétegébe, vagy attól egy diffúziónyi hossz távolságba, a kiürített rétegből a többségi energiahordozók kiseprődnek a megnövekedett tértől. Így a foton kimozdít egy elektront és a helyén lyuk keletkezik, a kiürített rétegből egy lyuk az anódba mozdul és egy elektron a katódba. Az elektronok ezen mozgása a fotovoltaikus áram.

A cikk egy 7555-össel felépített sötétségérzékelő kapcsolást is tartalmaz, és a működési leírását. A rendkívül egyszerű kapcsolás így 5 alkatrészből áll. Működése könnyen megérthető.

Samsung D900i Linux alatt

Pár napja játszadozom a D900i telefonommal és nagyon nem tetszik, hogy csak windows alatt lehet (nagy nehezen) java alkalmazásokat áttölteni. Úgy döntöttem, hogy picit beleásom magam dolgok hátterébe, talán...

PPPOE:
Gyorsan rá is kerestem, hogy mi kell a pppoe kapcsolat felépítéséhez. A kernel beállításokat nem is taglalnám, úgyis fent van google-n :), a lényeg, hogy létre kell hozni a pppoe device-t, valahol talán a networking kategórián belül jelölgetve.
A nagy áttörést a Palm PPP over USB (http://www.palovick.com/palm/palm-ppp-usb.php) oldal hozta. A script egyszerű, érthető és könnyen használható.

A telefonba a *#52828378# -et beütve bejutunk egy szerviz menübe. (Tipp: ha a telefonnal kapott firmwaret használod és a bevitelt a szép tollas módon teszi a telefon, a * beütése után várd meg, amíg mozog a toll, különben lehetséges, hogy a teló érzéketlen lesz a kódra!) Itt az OTA type settings-en (2. menüpont) belül válasszuk a Serial bearer OTA beállítást. Majd ezt mentve menjünk vissza és a 3.-ik Seerial Test menüponton belül válasszuk az 1. PPP fel menüpontot és ezen belül az USB-t vagy a bluetooth-t. Eddig majdnem (a PPP-n kívül) ugyan így megy windows alatt is. A lényeg most jön, még nem tudom, hogy működni fog-e.

Egyszerű tcp sniffer segítségével (pl. Ultra Network Sniffer) kiderítettem, hogy a Java Uploader v1.1 egy, a 888-as porton csücsülő, webserver, ami nem csinál mást, mint fogadja a telefontól a http requestet egy getNextApp.jad fájlra és elküldi neki. Lássuk, sikerül-e leutánozni.

Thttpd
Azért esett erre a webserverre a választásom, mert pici és ez volt az első, amit a google kidobott :).
Annyiban megviccelt a dolog, hogy hiába hozott létre /etc/thttpd könyvtárt és benne a thttpd.conf fájlt, mégis a gentoo-s config fájlok között van a config, amit valójában használ (/etc/conf.d/thttpd). Nem sok dolgunk van, csak át kell írni a portot 8080-ról 888-ra.
Ezután létrehozzunk a (default) /var/www/localhost könyvtáron belül a test könyvtárt. Belemásoltam egy .jad fájlt átnevezve getNextApp.jad-nak és a hozzá tartozó .jar fájlt (nem kell átnevezni!).
Újraindítjuk a servert:
# /etc/init.d/thttpd restart

A server futásáról egy webböngésző segítségével, a címbe a 127.0.0.1:888-at írva győződhetünk meg.

Jöhet a mehet! :)
Nnna, most, hogy íly jól eljátszadoztunk, ugorjon a maki a vízbe! Én kékfogat fogok használni, mert tegnap ezzel sikerült jobban megismerkedni.
A telefon már párosítva lett, ezzel most itt nem foglalkoznék, sem a kernel modulokkal.
Egyik ilyen modul az rfcomm modul, gyorsan betöltjük:
#modprobe rfcomm

Miután az sdptool segítségével megtudtuk, hogy a telefon Serial Service-e a 2-es csatornán van és felkonfiguráltuk az rfcomm-ot, csatlakozunk:
#rfcomm connect 0

( Ehhez az rfcomm config fájl: /etc/bluetooth/rfcomm
#
# RFCOMM configuration file.
#

rfcomm1 {
# # Automatically bind the device at startup
bind no;
#
# # Bluetooth address of the device
# IDE PERSZE A SAJÁT MAC-ET KELL ÍRNI (a telefonét,
# amihez csatlakozni akarsz
device 00:1E:E1:E5:02:AA;
#
# RFCOMM channel for the connection
# SDPTOOL segítségével kell meghatározni
channel 6;
#
# # Description of the connection
comment "Obex file transfer";
}

rfcomm0 {
# # Automatically bind the device at startup
bind no;
#
# # Bluetooth address of the device

device 00:1E:E1:E5:02:AA;
#
# RFCOMM channel for the connection
channel 2;
#
# # Description of the connection
comment "Serial Service";
}

)

A telefon megkérdezi, hogy akarjuk-e, persze.
Ráeresztjük a ppp scriptet az eszközre.
Egyenlőre nem valami tökéj... De azt már észrevettem, hogy valójában a thttpd-nek a conf.d-és fájljában kell megadni, hogy a thttpd-s könyvtárban levőt használja.

Teszteltem USB-vel is. Sima ügy: a ppp scriptben az eszközt át kell írni /dev/ttyACM0-ra és meg is.

Sajna, ezt így kell befejeznem, semmi többre nem jutottam, egyszerűen nem jut el a kérés a serverig :( Lehet, hogy a probléma a pppd-vel van, nem tudom. De lesz még folytatás!