LHSimulations
Home Cockpit => Home Cockpit Showroom => Topic started by: HARAM on March 22, 2013, 13:15:57 PM
-
Sziasztok,
Tervbe vettem egy általános panel elkészítését, amin a legfontosabb adatokat lehetne beállítani, megjeleníteni.
A blogomból mellékelem az infókat, és próbálom dokumentálni az el?re haladást. Remélem hamarosan el is készül, és minden FS rajongónak akit érdekel elérhet?vé válik a szerkezet.
http://www.ramirez.hu/blog/category/elektronika/pic/fs-multi-panel/ (http://www.ramirez.hu/blog/category/elektronika/pic/fs-multi-panel/)
Miközben dolgozom a 737-es MCP Panelen sok kompromisszumba és az otthoni kivitelezhet?ség korlátaiba, illetve nehézségeibe ütközöm. Többek közt annak a rengeteg 7 szegmenses kijelz?nek a meghajtásába.
A netet nézegetve találtam rá az Aerosoft oldalán egy multi panelre, amin LCD kijelz?kön összesítve jelennek meg a repülés adatai, információi. Természetesen az eszköz irreális áron elérhet?.
Ez szülte az elhatározást, hogy mind magamnak, mind az érdekl?d? FS rajongók számára készítek egy elérhet? árú, minden lényeges információt megjelenít? konzolt.
Sokat gondolkoztam a kezel? szerveken. Végül egy nagyon letisztult kép bontakozott ki. Két forgató gomb – “rotary encoder” – segítségével, amiken van egy-egy megnyomható nyomógomb funkció megoldható a teljes interakció is.
A Panel a következ?k megjelenítését és beállíthatóságát hivatott elvégezni:
Auto pilóta funkciók:
AP ON/OFF
Heading
Speed
Altitude
Vertical Speed
V1 course (esetleg majd a jöv?ben a V2 course is megvalósításra kerül)
COMM 1/2 rádiók
NAV 1/2 rádiók
ADF
NDB adatok: távolság, id?, sebesség
Transponder
Aktuális repülési adatok csak kijelzése (kis kijelz?):
Heading
Altitude
Speed
Vertical Speed
A project jelenlegi állapotában ott tart, hogy megvan minden alkatrész hozzá, már csak a munka van hátra!
-
Valóban nem egyszer? a sok 7 szegmens? meghajtása, de léteznek rá elektronikai megoldások.
Nem vagyok az elektronika mestere, én inkább a programozói oldalról nézem/látom a dolgokat, de itt egy hasznos animáció (http://www.inf.u-szeged.hu/~mate/swf/3.13.swf) a dekódoló áramkörr?l. Személy szerint szintén 737 MCP panelt készítek és ez az áramkör nagyon sokat tud spórolni a lábakon. Nálam a meghajtást Arduino alapokon futó mikrokontrollerek (ATTiny4313 és ATMega328) fogják végezni, mely végül USB-n fog csatlakozni a számítógéphez. Ennek nagy hátránya, hogy saját kez?leg kell megírni a windows-os programot is, ami majd az FS-hez csatlakozik.
Tetszik az elképzelésed, kíváncsian várom a következ? bejegyzést. ;) Üdv.
*UPD: most találkoztam az MCP projekted leírásával.
-
A 7 szegmenssel illetve az egésszel az a bajom, hogy egy panelre akartam tervezni mindent, amit otthoni nyák gyártással nehezen kivitelezhet?. Én vasalom ?ket és valahogy nem sikerült ilyen nagyban. A másik relatív probléma a sok meghajtáshoz tartozó kontroller port. Ehhez már TQFP-s IC kellenek. Azért gyártok saját eszközöket, és nem pl. az Ardunio jelleg? eszközöket használom, mert próbálom költség hatékonyan megoldani a dolgot. Több egyedi fejlesztéssel jár persze. Mondjuk a nyákot szívesen gyártatnám, de kis méretekben, és mennyiségben elég drágára jön ki. Pedig minden sokkal egyszer?bb lenne.
Nem baj hétvégén megterveztem a Multi Panel vezérl? lapját. A héten remélem kezd?dnek a tesztek, és postolok :)
-
No, azért én sem dobálok ki ezreket az ablakon, Arduino alatt azt értem, hogy C++-ban programozok, de alappanel nélkül (ami a húzós), így a tiny-k 100-200 Ft-ból megvannak, az USB soros adapter sem tétel. Bus rendszert kell végülis kialakítanom, hogy minden gomb és visszajelz? m?ködjön, ez tény, de nem tartom vészesnek így sem az árát. Valószín?leg azért is vonz jobban ez a megoldás, mert így többet kell majd programoznom... 8)
Viszont sikerült egész jól kinéz? fehér(!) 7 szegmens?t (9.14 mm) találnom itt (http://www.wayjun.com/index.php?main_page=product_info&products_id=882). Ezért már megéri megpróbálni, rendeltem bel?le, majd meglátjuk. ;D
Üdv.
-
Sziasztok...
Új vagyok itt, most kezdek foglakozni a témával.
Találtam egy nagyon kellemes kis programot ami soros porton kiküldi és fogadja az FS-FSX adatait, a fogadott adatokat bill. parancsokká alakítja a FS számára, remekül m?kodik. Bármit mögé lehet rakni ami tud soros portot kezelni (arduino, microcontroller stb.) Nézzétek meg hátha hasznos lehet.
http://www.jimspage.co.nz/intro.htm
-
Sziasztok...
Új vagyok itt, most kezdek foglakozni a témával.
Találtam egy nagyon kellemes kis programot ami soros porton kiküldi és fogadja az FS-FSX adatait, a fogadott adatokat bill. parancsokká alakítja a FS számára, remekül m?kodik. Bármit mögé lehet rakni ami tud soros portot kezelni (arduino, microcontroller stb.) Nézzétek meg hátha hasznos lehet.
http://www.jimspage.co.nz/intro.htm
Köszönöm az információt, valóban hasznos lesz az FS és a panel összedolgozására. ;)
-
Sziasztok!
A héten a kijelz?k meghajtásával dolgoztam. Az elmélet találkozott a gyakorlattal, és sikerült meghajtanom mind a két (három) kijelz?t a panelemr?l.
(http://www.ramirez.hu/blog/wp-content/uploads/2013/03/20130329_0050561-300x225.jpg)
Aztán rákötöttem az USB áramkört is, így már innen tudom kapni az áramot is, nem kell küls? táppal rácsatlakoznom. :)
Részletek: http://www.ramirez.hu/blog/category/elektronika/pic/fs-multi-panel/ (http://www.ramirez.hu/blog/category/elektronika/pic/fs-multi-panel/)
Hxm441 érdekes a link amit küldtél. Mondjuk én sok univerzális panelt, kapcsolást kerestem, néztem már évek alatt. Végül így jutottam arra a következtetésre, hogy mivel az FSUIPC-vel tudok kommunikálni közvetlenül, nem is nehéz, ezért olyan minél olcsóbb cél elektronikát gyártok ami pontosan azt csinálja amit szeretnék, és nem kell pl. a rendszer billenty?zetének beállításaihoz kötni magamat. Azokat fel tudom használni esetleg más vezérlésekre. Mondjuk olyan események kiváltására, amiket csak az egyéb gyártók termékei kezelnek, és az FSUPC közvetlenül nem éri el. Ilyenkor tényleg jó lesz egy ilyen program, ha nem tudom megoldani C#-ból.
Mivel az egész rendszert én irányítom akármilyen programmal kommunikálhatok, teszem azt X-plane-hez is jó lesz, csak a PC-s programot kell majd át/megírni.
Jeleket bevinni nem is olyan nehéz egy PC-be, pl. egy szétszedett joystick segítségével, vagy valamilyen HID beviteli eszköz segítségével, amin mindenféle univerzális gomb ráakasztási lehet?ség van. Nekem a küls? kijelz?k meghajtása volt a f? kérdés.
Ez a panel amit építek, ill. a rajta lév? kijelz?k sok adatot tartalmaznak. Hozzá kell szokni a használatához, de ez is olyan, mint egy új cockpit. Meg kell szokni. Viszont az az élmény, amikor pl. egy megközelítésnél csak "kinézek" az ablakon, és csak rá kell pillantanom a küls? m?szerekre, és nem kell átmozgatnom a képet közben, meg vissza. Meg amikor FreeTracket használok, és a gombokra nem lehet az egérrel rákattintani, mert minden mozog :D Szóval ez nagyon jó, és egyre valóságosabb érzetet ad.
Teszteltem is, az FS-ben kiraktam az adatokat balra fel a képerny?re, és csak azokat néztem, és 2D-s cockpit nézetben, vagy 3d-ben de jól megnagyítva, hogy csak az ablak keretek látszódjanak. Nagyon jó, hogy nem vonja el a figyelmemet a felesleges kép mozgatás!
Remélem hamarosan beszámolhatok az els? FS vezérlésekr?l :)
-
Hxm441 érdekes a link amit küldtél. Mondjuk én sok univerzális panelt, kapcsolást kerestem, néztem már évek alatt. Végül így jutottam arra a következtetésre, hogy mivel az FSUIPC-vel tudok kommunikálni közvetlenül, nem is nehéz, ezért olyan minél olcsóbb cél elektronikát gyártok ami pontosan azt csinálja amit szeretnék, és nem kell pl. a rendszer billenty?zetének beállításaihoz kötni magamat. Azokat fel tudom használni esetleg más vezérlésekre. Mondjuk olyan események kiváltására, amiket csak az egyéb gyártók termékei kezelnek, és az FSUPC közvetlenül nem éri el. Ilyenkor tényleg jó lesz egy ilyen program, ha nem tudom megoldani C#-ból.
SimConnect SDK ;) illetve most valami ESP SDK-nak hívják májkrószoftnál. Az FSUIPC tudtommal ugyanúgy ezt használja. Ha esetleg nem találod a neten ezt az SDK-t, mert bevallom nekem jó id?be telt, mire le tudtam tölteni, szólj. Mellékeltek hozzá VB projekteket bemutató gyanánt.
-
Megnezem majd! En olyasmire gondoltam hogy adott gyartok pl. PMDG esemeny kezelesei nem erhetoek el fsuipc sdk-n keresztul. Csak billentyu kombinacioval. Vagy a sajat hozza ferhetetlen dll-jukon keresztul... :-[
-
Megnezem majd! En olyasmire gondoltam hogy adott gyartok pl. PMDG esemeny kezelesei nem erhetoek el fsuipc sdk-n keresztul. Csak billentyu kombinacioval. Vagy a sajat hozza ferhetetlen dll-jukon keresztul... :-[
Ilyesmire (http://fsuipc.simflight.com/beta/Offset_Mapping_PMDG737NGX.pdf) gondoltál?
Létezik PMDG SDK, a következ? infót találtam róla: "The SDK will be installed when you install SP1c. It gets put into a subfolder in the PMDG folder and contains a pdf, a cpp file and a header file."
-
Wow, igen, valami ilyesmire :)
;D
Még küzdök az USB és a panelem kommunikációjával, de hamarosan megvagyok vele :)
-
Még küzdök az USB és a panelem kommunikációjával, de hamarosan megvagyok vele :)
Azon gondolkodom, hogy lehet érdemes lenne egy normális "common interface"-t csinálni az ilyen és hasonló panelokhoz. Tudom, léteznek hasonló megoldások, de ?k mind egy-egy termékhez vannak kötve, míg én inkább újra feltalálnám az RS232-t...
-
Pont az "univerzálisság" érdekében, és mert minden rendes mikrovezérl?n van UART (RS232) én az FTDI USB - UART átalakítóit használom mióta van FTDI. Korrekt SDK-val, ill. driverrel rendelkezik, és atom biztos, megbízható eszközöket gyárt.
-
Lehet rosszul fogalmaztam, de én arra gondoltam, hogy a windows <-> mikrochip kommunikáció parancsai és formája egységes legyen, azaz egy olyan protokoll, mely (akár open source) könnyen illeszthet? lenne újonnan épült és meglév? rendszerekhez.
Másképp fogalmazva, az adatcsomagokat szeretném egységesíteni, hogy kés?bb könnyedén lehessen b?víteni is és ne kelljen mindenkinek saját protokollt és fsuipc dll-t/plugint írnia.
-
Lehet rosszul fogalmaztam, de én arra gondoltam, hogy a windows <-> mikrochip kommunikáció parancsai és formája egységes legyen, azaz egy olyan protokoll, mely (akár open source) könnyen illeszthet? lenne újonnan épült és meglév? rendszerekhez.
Másképp fogalmazva, az adatcsomagokat szeretném egységesíteni, hogy kés?bb könnyedén lehessen b?víteni is és ne kelljen mindenkinek saját protokollt és fsuipc dll-t/plugint írnia.
Ha egy könnyen használható modult össze tudnál rakni, még árulhatnád is, kicsit támogatná a cockpit építés költségeit :)
-
Ha egy könnyen használható modult össze tudnál rakni, még árulhatnád is, kicsit támogatná a cockpit építés költségeit :)
Személy szerint egy olyan windows-os programra gondolok els?sorban, ami csatlakozna az FSUIPC-n keresztül az FSX-hez és felületet biztosítana arra, hogy soros vonalon érkezett parancsokkal vezérelje azt. Minden kapcsoló és érték egy-egy azonosítót kapna, ezzel hivatkozhat rá akár egy küls? panel mikrovezérl?je.
Így annyit spórolhat az, aki ezt a 'szabványt' használja, hogy nem kell a windows-os oldalon semmit sem programozni, csak a megfelel? protokollt kell megtanítania a panelja agyának.
A mai világban, ahol sajnos nem tehetik meg sokan azt, hogy 600€-ért komplett panelt vegyenek, nem hinném, hogy sikert aratna bármilyen fizet?s megoldás. Maximum adomány, de nem a pénzbeli nyereség vonz.
-
A kérdés az, hogy mindent a panel kérjen a programtól? Én például egy kifejezetten "buta" programot írok a vezérl?nek, hogy egy olcsó tokba, egyszer?en beleférjen, és elég gyors legyen. A legtöbb mindent a Windows-os program fogja végezni, mert a PC-n több az er?forrás, és nagyobb a sebesség, hogy elvégezzen számolási m?veleteket, eldöntend? elágazásokat pl. a kijelz? menürendszerében való mozgás közben. Persze majd a gyakorlatban közelíteni szeretném a két oldalt, hogy mi az amit még rá tudok bízni a panelre, és mikortól lesz problémás ott végeztetni a m?veleteket.
-
Olyan is eszembe jutott, hogy ok, van egy interface program, és kiszolgál egy elektronikát, egy soros porton (USB, mindegy) De egy elektronika nem lesz elég komplex megoldásokhoz (pl. egy teljes cockpit)... Vagy az elektronika oldalon is kell készíteni egy olyan panelt, ami minden eszközt lekezel amit a PC-s program tud illeszteni magán keresztül, és van egy csomó portja. De ez nagyon sok csatlakozást jelent, gyors vezérl?t - kezd drágulni az elkészíthet?ség. Vagy több példányban kell futtatni a PC-s programot elektronikánként, így több egyszer?bb olcsóbb elektronika szóba jöhet, de a PC-t?l veszünk el er?forrást, igaz talán olyan nagyon nem terhel le egy ilyen alkalmazás egy mostani gépet, de nem lesz túl optimális az egész. Nem tudom melyik a jobb megoldás. De jó lenne egy univerzális felület, tény, hogy könnyíteni az otthoni cockpit építést.
-
Egy kis helyzetjelentés, itt tart a projekt :P
http://youtu.be/8s2deC-V5sc
-
és hogy lehet megnézni?
-
Talán most...
-
wow :) tök jó! Gratulálok :)
-
Köszi...
-
http://youtu.be/8s2deC-V5sc
Szép, tetszik. Kérdés, látom van egy kis 'lag' az encoder és a pc között. Oda-vissza kommunikáció eredménye a 7 szegmens?n látható érték?
-
Olyan is eszembe jutott, hogy ok, van egy interface program, és kiszolgál egy elektronikát, egy soros porton (USB, mindegy) De egy elektronika nem lesz elég komplex megoldásokhoz (pl. egy teljes cockpit)... Vagy az elektronika oldalon is kell készíteni egy olyan panelt, ami minden eszközt lekezel amit a PC-s program tud illeszteni magán keresztül, és van egy csomó portja. De ez nagyon sok csatlakozást jelent, gyors vezérl?t - kezd drágulni az elkészíthet?ség. Vagy több példányban kell futtatni a PC-s programot elektronikánként, így több egyszer?bb olcsóbb elektronika szóba jöhet, de a PC-t?l veszünk el er?forrást, igaz talán olyan nagyon nem terhel le egy ilyen alkalmazás egy mostani gépet, de nem lesz túl optimális az egész. Nem tudom melyik a jobb megoldás. De jó lenne egy univerzális felület, tény, hogy könnyíteni az otthoni cockpit építést.
Én konkrétan adott példán keresztül mutatnám be az ötletem és direkt azért dobtam fel így, fórumon, hogy több szem többet lát alapon legyen ez megalkotva, ha más nem elméletben.
Adott egy protokoll, fix start és lezáró karakterrel. CRC szintén benne.
A windows-os program fogadja soroson ezt a jelet, és a parancsnak megfelel?en válaszol. Két parancs jut eszembe, read és write. Ha megnyomom a panelon a CMD A gombot, akkor kimegy a windows-os proginak egy jel, write CMD A gomb. A windows ellen?rzi a CRC-t, ha stimmel, leküldi a parancsot az FSX-nek és visszadobja a kontrollernek, adat fogadva, most már ez az érték (végülis read parancs válasz). A panel vezérl?je megkapja, azaz CMD A gomb bekapcsolva, és ? szépen kivilágítja a megfelel? LED-et. Encodernél ez trükkösebb, én személy szerint megvárnám, míg a tekerés abbamarad vagy nem is tudom... De ez részletkérdés.
Én csak konkrétan egy protkollt és az azt fogadó program elkészítésére gondoltam, az illesztés, azaz a mikrokontrollernek megtanítani a protokollt, az már az épít? dolga, de így is er?sen lecsökken a programozni való.
Konkrét adatcsomag példa: (soronként 1-1 byte)
0x02 //start
Action // read vagy write, azaz 0 vagy 1
Azonosító 1
Azonosító 2 // A kapcsoló/érték azonosítója 2 byte-on, azaz max 510 db (az elég, nem?)
érték 1
érték 2 //csak write-nál
CRC1
CRC2 // CRC 2 byte-on
0x04 // csomag vége
Valóban, ez a nem a "buta" megoldás, de ha egyszer elkészül a panelem, nem lesz referenciám arra, hogy valóban bevette-e a rendszer a parancsot (minek lenne akkor VC módban...). Ezért találtam ki ezt a megoldást, hogy effektív a gomb és a visszajelz? nincs összekötve, csak a "meger?sít?" adatcsomag vezérli a LEDet/kijelz?t, így innen tudom/látom, hogy az FS is tudja mit akarok. :)
UI: nemrég hozta a postás bácsi a 9.14 mm-es fehér 7 szegmens? kijelz?im... :)
(http://kepfeltoltes.hu/thumb/130418/20130418_104532_www.kepfeltoltes.hu_.jpg) (http://kepfeltoltes.hu/view/130418/20130418_104532_www.kepfeltoltes.hu_.jpg)
-
A CRC-t külön nem kell figyelni, azt a soros kapcsolati protokoll elintézi.
Mivel figyelni kell, hogy az FS-ben valaki, estleg vmilyen automatika lekpcsolta-e pl. a AP-t, akkor a LEDjét ki kell kapcsolni automatikusan. Tehát a mikro vezérl?nek minden egyes ledet, esetleg kijelz? végig kell kérdezni, hogy milyen állapotban van. Egy nagyobb project esetében nagyon sok lekérdezést jelenthet egyesével megoldani, ill. egy ilyen univerzális protokollra bízva lassú lehet, és látható késést okozhat. Persze, lehet, nem zavaró.
A héten már én is megoldottam a kommunikációs problémát. Csak nagyon "korán" lett :) Most jön az inicializálása a kijelz?mnek, ott majd nekem is kiderül, hogy milyen gyorsan tölti ki a 4x40 + 2x16 karaktert a PC-s progi, bár azt csak 1x kell egyben megcsinálni az elején. Aztán elkezdem küldeni a 2x16-osra az aktuális repülési értékeket.
Én csak akkor küldök az elektronikának adatot, ha valami változik. Jelen esetben egy egész kis byte sorozatban meg tudom határozni a küldött és fogadott adatokat. Ok két teker?m van és rajtuk 1-1 gomb. Ezt most 2bytban küldöm fel. Természetesen kiértékelve, hogy melyik gombot merre tekerték, vagy esetleg megnyomták. Vissza felé, meg egyszer?en megmondom melyik kijelz?n, sor-oszlopban mit írjon ki... Ennyi ez pedig 5byte+delimiter karakter.
-
A CRC-t külön nem kell figyelni, azt a soros kapcsolati protokoll elintézi.
Mivel figyelni kell, hogy az FS-ben valaki, estleg vmilyen automatika lekpcsolta-e pl. a AP-t, akkor a LEDjét ki kell kapcsolni automatikusan. Tehát a mikro vezérl?nek minden egyes ledet, esetleg kijelz? végig kell kérdezni, hogy milyen állapotban van. Egy nagyobb project esetében nagyon sok lekérdezést jelenthet egyesével megoldani, ill. egy ilyen univerzális protokollra bízva lassú lehet, és látható késést okozhat. Persze, lehet, nem zavaró.
Nincs állandó szinkronizálás. Inicializáláskor (FS betölt, vagy a gps koordináta hirtelen óriásit ugrott) összebúg, és utána már csak a változások mennének, legalábbis a terv ez. A windows-os progi ugyanúgy tárolná és figyelné az értékeket az FS-b?l, ha pl kikapcsol az AP, akkor eltérés adódik a memóriában tárolttól és már küldi is ki a jelet, hogy AP OFF, kapcsolja le a panel a LED-jét.
Szerintem az elv ugyanaz.
Milyen módon kapcsolódsz az FS-hez végül? Milyen programnyelv és 737NGX?
-
Egyel?re FSUIPC-t használom. Ez most egy generic általános multi panel lesz, ahogy indítottam is a topicot. Ezzel a projecttel egy általános felületet szeretnék csinálni. Két kijelz?, két teker? - minimal design, de minden fontos repülési adattal.
A kontrollert C-ben, a Win prog C#-ban van programozva.
-
Szép, tetszik. Kérdés, látom van egy kis 'lag' az encoder és a pc között. Oda-vissza kommunikáció eredménye a 7 szegmens?n látható érték?
Nem, a PC-s program csak elküldi az aktiális értéket, ezt jeleníti meg, illetve az encoder adatait elkülldöm a PC-s programnak. Bár így már oda vissza komunikáció, ha így érted.
-
Nem, a PC-s program csak elküldi az aktiális értéket, ezt jeleníti meg, illetve az encoder adatait elkülldöm a PC-s programnak. Bár így már oda vissza komunikáció, ha így érted.
Igen, erre gondoltam, köszönöm a választ. Ezt csak azért is jó volt látnom, mert így tudom, nálam is hasonló "csúszás" lesz a dologban, ami nagygépes repülésnél abszolút nem okoz gondot, hiszen percekre el?re gondolkozik az ember. Hasonló módon szeretném megoldani, de így legalább megnyugtattál, nem fog elkúszni/elcsúszni az érték látványosan.
-
Végre megérkezett a 4x20-as kijelz? ami az aktuális repülési adatokat jeleníti meg. Mivel a 2x20-as kijelz? drágább volt ezért ezt rendeltem. Azt hiszem így meg fogom rajta jeleníteni a futók és a fények állapotát is :)
(https://fbcdn-sphotos-b-a.akamaihd.net/hphotos-ak-ash4/253386_186680071488306_1395366901_n.jpg)
Az FS értékek már jönnek a bal oldali kijelz?re, de a jobb oldali vezérlés leprogramozására egyszer?en nincs id?m. Remélem a héten jutok végre valamire :)
-
Sziasztok!
Szabad kérdezni, hogy most hogy áll a panel project?
Zsolt
-
Kicsit lelassultam a nyáron. A PC oldali programon dolgozom. Már az FS is frissíti a kijelz?n az adatokat. Itt van egy kis bug, ezt ki kell javítani. Amint áttörést érek el postolok :)
Még várok egy kijelz?t, így az új felállás esetén 4db 4x20 karakteres kijelz?n még a fényeket és a rádió hangok kapcsolását is megoldom:
(http://www.ramirez.hu/blog/wp-content/uploads/2013/08/4x2x40_cover1-1024x128.jpg)
1. LCD 2. LCD 3. LCD 4. LCD
aktuális repülési adatok auto pilóta auto pilóta balszél rádió és transponder adatok
fények kapcsolói többi VOR info
rádió (hang/aktív) kapcsolók
-
Végre megjöttek a kijelz?k!
(http://www.ramirez.hu/blog/wp-content/uploads/2013/10/IMG_20131024_234002-1024x307.jpg)
Már csak be kell kötnöm ?ket, és a vezérl? IC-t átprogramozni, és mehet tovább a fejlesztés!
:)
-
Volt egy kis meló a negyedik LCD meghajtásával, de most már az eddigi funkciók újra jól m?ködnek, és kezd?dik az új funkciók aktiválása is.
Még nincsen aktív vissza jelzés az LCD-ken, de az is hamarosan m?ködni fog.
[youtube]http://www.youtube.com/watch?v=f4DLReaK7FU&feature=youtu.be[/youtube]