Persze hogy photoshoppoltak a képek, nem is ez a lényeg hanem hogy állítva vannak a fotókon, ezzel jelezve hogy ezeket a kijelzőket állítva kell használni. A betekintési szögei ezt támasztják alá.

Magasak az elvárásaim? Nem hiszem. Az elvárásaim mindössze annyik hogy tűrhető képe legyen és rendesen működjön a touchpad. Ezeket az elvárásokat ez a 3,5 colos 480x320-as kijelző már teljesíti.

A 4,3 colos ami hibásan érkezett meg, annak kapacitív touchpadja van. Azzal szerettem volna játszani de így hogy maga a kijelző teljesen süket, nem foglalkoztam vele tovább. Ha időm engedi hogy ezzel foglalkozzam akkor rendelek majd egy ugyan ilyen 3,5 colost csak kapacitív touchpaddal.

Az XPT2046-al nekem eddig nem volt bajom. Az érintés utáni első pár mintát el kell dobni, a többit pedig átlagolni kell. Írtam rá egy tök jó kis függvénykönyvtárat, innentől nincs vele probléma.

Arról beszéltünk, hogy a 178-178°-os betekintési szögű kijelzők értelemszerűen drágábbak. Mi nem tudjuk megítélni, hogy neked mi a tűrhető kép, lényeg, hogy ezzel már meg vagy elégedve. (Ha nem lennél, akkor többet kellene költened kijelzőre )

Alacsonyabb sebességen nem kell hozzá függvénytárat írni. De lehet, hogy én fogtam ki hibás példányokat(3 db is ilyen volt). A megfelelő sebesség beállítása után szinte hajszálpontos kezelést lehet megoldani gyakorlatilag lineáris összefüggésekkel.

Rezisztív touchpadnál és XPT2046-nál lehet szerintetek fel lehet cserélni a touchpad két ellenállását egymással, illetve a polaritásukat is? Azaz:
Az XP-ből lesz YN,
az XN-ből YP,
az YP-ből XN
és az YN-ből XP.
Szerintem nem lehet akadálya hiszen a touchpad csupán két darab ellenállás, az XPT2046 elvileg nem is tudhat róla hogy hogyan, milyen polaritással van rá bekötve a két ellenállás.
A nyákterv leegyszerűsítése lenne a cél egyébként, különben meg kellene forgatnom a négy vezetéket...

Persze. Ahogy irod is, ez egymast keresztezo ket ellenallasdrot tulajdonkeppen.

Üdv
Nagyon néma ez az oldal Építési kedvhez kis adalék olcsó LCD .
Jön a Jézuska és ...... ?
Üdv

A linkednek mi köze az LCD-hez?

Terveztem egy PIC-es panelt a buydisplay.com-os 3,5 colos, 480x320-as TFT modulhoz. Ez a leghasználhatóbb és főleg a legjobb ár/érték arányú TFT kijelző amit találtam az eddigi kb 6-8 típusból amit megvettem az elmúlt években.
Tettem fel a házilag elkészített panelról képeket a ki mit épített topikba: Bővebben: Link
Ugyan ott írtam is róla néhány sort.

Gyártatni fogok ebből a panelból 10db-ot, melyből nekem 2-3db kell csak. Azért rendelek 10-et, mert így jön ki nagyon olcsóra (kb 430Ft/db). A maradék azonban nekem nem kell, ezért anyagárban odaadnám annak aki lát benne fantáziát. Egyenlőre eddig 6-7db panelre van jelentkező. Ha kell még valakinek akkor szóljon!
Továbbá felteszem ide a panel kapcsolási rajzát, hátha esetleg van valakinek ötlete hogy mit lehetne rátenni még a panelra, vagy mit lehetne jobban/másképp megoldani hogy jobb legyen. Még mielőtt elküldöm gyártatásba a gerber-fájlokat.

Szia!
Néhány gondolatomat megosztanám, amik a kapcsolási rajz nézegetése közben fogalmazódtak meg bennem.
1. Az LCD háttér világítását biztosító LED-nek nem látom az áramkorlátozó ellenállását.
2. Én célszerűbbnek látnám a Q3 pozícióba egy FET alkalmazását - a bipoláris tranzisztor helyett -, pl. olyat, mint a T1, mert a Q3 UCE feszültsége csökkentheti a kivezérelhetőséget.
3. Az LCD háttér világítását biztosító LED anódját talán jobb lenne az akkura kötni, mert ekkor ennek áramát nem kellene az MCP1825-ön átvezetni.
4. Lehet, hogy nem értem jól, de úgy tűnik, ha bedugjuk az USB csatlakozót, akkor a T1 lezár, tehát megszűnik minden eszköz 3,3V-os tápellátása.
5. Alacsony akkufeszültség esetén a PIC le tudja kapcsolni a terhelést az akkuról?
6. Elegendő a stab. IC terhelhetősége a WI-FI-hez?

Szia!

1.: Nem kell neki ellenállás. Először tettem oda neki egyet de teljesen felesleges, a gyári modulokon sincs. (Bővebben: Link)
2.: Van benne valami. Szerencsére ez utólag is megoldható, a nyáktervnek nem kell hozzá módosulnia.
3.: A TFT háttérvilágításának akkumulátor nélkül (külső táplálással) is működnie kell. Ennél a kis panelnél az akkumulátor opció, nem pedig kötelező alkatrész.
4.: Igen, ha bedugjuk a micro USB-s töltőt akkor T1 lezár, ezzel az akkumulátorról lekapcsol mindenféle terhelést. Az áramkör nem marad energia nélkül, hiszen a D1 diódán keresztül továbbra is kap energiát a stabkocka. Az MCP73832 ilyenkor el is kezdi tölteni az akkut.
5.: Nem, de miért is kellene tudnia lekapcsolni? Szerintem erre nincs szükség. Egyébként tulajdonképpen akár le tudja kapcsolni, hiszen a TFT-t el tudja küldeni aludni, ahogyan a WIFI modult és az SD-kártyát is, a kijelző háttérvilágítását pedig le tudja kapcsolni.
6.: Persze, 500mA-t legalább tud a stabkocka. A WIFI modul áramfelvétele átlagosan 70mA, de legrosszabb esetben 170mA. A kijelzővezérlő 15mA-t eszik, a háttérvilágítás 120mA-t maximális fényerőn. A mikrovezérlő a legnagyobb órajelen maximum 70mA-t. Az SD-kártya maximum szintén 70mA körül fogyaszt. A hangszóró is kb 70mA-t. Tehát abszolút maximum ha minden teljes gőzzel megy, akkor ez 515mA. Ennyit a stabkockának bírnia kell.

Szia!
Köszönöm a választ.
Nem kétlem, hogy megy ellenállás nélkül is a LED, hiszen biztosan van valamekkora ellenállása a soros elemeknek, amik korlátozzák az áramot, kérdés mennyi ideig élnek így a LED-ek. (az én gyári LCD panelomon 3R9 soros ellenállás van)
Az akku lekapcsolásának lehetőségét csak amiatt vetettem fel, mert már jártam úgy, hogy a heteken keresztül sleep módban lévő uC egyszer csak felébredt és a Lipo akku elhalálozott, felfújódott. De ha nálad csak opció az akkumulátoros mód, akkor értem miért nem kapcsolod le.
A Wi-Fi-s dolgot azért kérdeztem, mert itt a fórumon többen is jártak úgy - a kis áramú tápegységük miatt - hogy a uC újraindult a Wi-Fi nagy árama miatt letört tápfeszültség miatt. Nekem saját tapasztalatom ezzel nincs.

Szia!
Bocs, az ismételt zargatásért, de még valamit felfedezni vélek a rajzon.
A T1 P-MOSFET rajzjelén a dióda mintha fordítva állna, (a dióda katódjának a source-re kellene csatlakoznia, a kapcsolási rajz elég alacsony felbontású, de úgy látom, mintha az anód csatlakozna oda) Bővebben: Link és a FET is inverzbe van kötve.
A P-MOSFET legpozitívabb pontjának a source-nak kellene lenni.
A nyákrajz szerint is a drain van összeköttetésben az akku pozitív kapcsával.

A rajzon van fordítva (mintha N-es rajzjel lenne), a nyákon jól. Esetleg a gate lehúzó ellenállás lehetne nagyobb, ne terhelje a tápot feleslegesen, felhúzó pedig talán nem is kellene (rövidzár).

T1 rajzjele jó. Ha a dióda benne fordítva lenne, akkor ha csatlakoztatjuk az USB-t akkor a D1-en és a T1 diódáján keresztül áram folyna az akkumulátorba.

Amit egy korábbi témában leírtál az akku töltöttség figyelésre, az nagyon rossz és bonyolult megoldás. Olvass utána a coulomb counting után. Illetve valahol írtad, hogy 1,5 hét alatt megtanultál C-ben programozni és ezalatt az MPLAB-ot is megismerted. Én 6-7 éve kezdtem el C-ben programozni, azóta sem hobbi szinten űzöm és nem mondanám, hogy megtanultam. Mondjuk úgy, hogy 1,5 hét alatt az alapok elsajátíthatók.

Ezt kifejthetnéd!
Nagyon bonyolult? Hardveresen rendkívül egyszerű mert kettő darab ellenállás kell hozzá. Ha áramot (is) mérnénk, az minimum egy OPA-t igényel ami szerintem lényegesen bonyolultabb, legalábbis a két darab ellenálláshoz képest. Hogy szoftveresen bonyolultabb? Az tuti! De kérdem én; és akkor mi van? A szoftver elfér. Egyszer kell rá függvényt írni szépen, utána soha többet nem kell vele foglalkozni. Valóban, ennek a megírása már relatíve bonyolult, de én úgy vagyok vele hogyha valami hardveresen egy egységnyivel egyszerűsíthető száz egységnyi szoftveres bonyolultságért cserébe, akkor határozottan inkább a program legyen bonyolultabb! Pláne konkrétan ennél a kis (méretű) áramkörnél ahol hely igencsak kevés van a panelon.
Másrészt, mennyire nagyon rossz? A célom nekem az volt hogy az akku töltöttségét tíz szintben tudjam megkülönböztetni (0%, 10%, 20% stb.), de valójában akár négy szinttel is megelégedtem volna. Ez nem egy Tesla (mármint az autó), amelynél az akku töltöttsége egy létfontosságú adat.
Ráadásul az áramkör fix, ugyan azok az alkatrészek és eszközök vannak a panelon, ezek nem módosulnak! Az áramfelvételüket miért kellene folyamatosan mérni? Hiszen nem változik! Sőt, mérni sem kell hiszen pontosan specifikálva van mindennek az áramfelvétele. Innentől elég csak számolgatnia attól függően hogy éppen mi működik és mi nem. Persze ez nyilván nem lesz egy halálpontos dolog, de még egyszer mondom: nem is ez a cél!

Idézet:
„Illetve valahol írtad, hogy...”

Ez nem tudom hogy jön ide, de szívesen válaszolok. A 1,5 hét alatt eljutottam oda hogy mindent megtudtam csinálni C nyelven egy mikrovezérlővel amit addig assemblyben, illetve mindent amire az eddigi kb 7-8 évnyi mikrovezérlősködéseim során szükségem volt.
Értsd: megtanultam festeni vászonra, a falra, az aszfaltra, ismerem a színpaletta minden színét, de a Mona Lisát nem tudnám lefesteni.

Szerk.:
De hogy ne csak offoljunk; megrendeltem a paneleket, szerintem januárban megérkeznek.

Helló. Láttam a nyákod a ki mit építettben, egy dolog feltűnt: az USB csatit miért nem a szokványos megoldással tervezted a nyákra? Ki kell neki vágni egy fészket, a 4 karma pont ráül a nyákra, beforrasztható, az 5 kicsi érintkező úgyszintén. Sokkal jobban tart, már csak azért is, mert nincs hajligatva a fém feleslegesen.
Egyébként gratulálok, nagyon szép munkát hoztál össze!

Szia. Tudom hogy így kellene beültetni de viszont így nem kell marni a nyákot. A panelt úgy terveztem meg hogy házilag is elkészíthető legyen, ez esetben szerintem jobb ha nem kell kireszelgetni azt a kis darabot. Egyébként egy vezetősáv fut a csatlakozó alatt.

Már rémlik, plusz költség lenne ez a kis darabnyi marás, és irreálisan megnövelné a nyák gyártatás költségeit. Én ugyanezt az USB csatit használom, de én pofátlan voltam, és via-kkal körbeszórtam ott, ahol ki kellene marni, így nem kellett pluszköltséget fizetnem. Így csak simán kitörhető a kis négyzet. Ha pedig jól oldja meg az ember, reszelgetni sem kell. Nálam azért kellett kicsit igazítani.

Nem kerülne semmibe az a marás! Akár karácsonyfa kormájú panelt is marathatnék, ugyan annyiba kerülne mint egy téglalap.
A panel házilagos elkészítése lenne macerásabb ha tűreszelővel kellene kireszelgetni azt a darabot. Ezt nem szerettem volna, ezért hajtottam le a füleit. Teljesen jó így is.

Én is úgy csináltam a SIM kártya tartónál, hogy a megvezető-rögzítő marások helyén kifúrattam a céggel aki gyártja.

Bocs de ezt én sem tudom !
Ezt az oldalt csak olvasom , de van pár Nokiám 3310 stb és PIC16C628-am talán ráveszem magam és összedrótozom őket itteni instrukcióval . E-bike kijelző .
Azonkívül van egy ősrégi PIC vagy BASIC bélyeg ami 2 nagy-áramú kapcsolót (légmentes/vákumos ) vezérel , panelen van és gumiszerű kiöntőanyag maradványok rajta , valamikor programozgatta Q-basik nyelven , időm engedi talán és ha adatlapja is van a netten avval is foglalkozom .
Futni és sz... egyszerre nem lehet .
Rájöttem postagalambbal küldtem és itt esett le !

Kérdésem : van olyan 8 colos talán laptop LCD/TFT 20 vezetékes ( 8 digit 8 test ) világítás láb , avval érdemes-e foglalkozni elég-e a tudása a PICnek ?
Üdv

Sziasztok

Van valakinek infoja erről? JL-18C01-SD-A2

20 pin a legtöbb mp3/mp4 lejátszóba ez van.

Pic hez szeretném rakni de semilyen leirást nem találtam.


Köszi

Sziasztok,
Segítséget szeretnék kérni. Vettem egy FT800-ra épülő vm800b50a-bk EVE fejlesztő modult, szeretném használni PIC18F, ill. PIC24HJ MCU-val. Miután CCS C-vel dolgozom, az lenne a kérdésem, lenne-e valakinek az FT800-hoz CCS C-ben írt drivere és egy kis mintaprogramja, amelyen el tudnék indulni megtanulni a használatát. Vagy esetleg tud-e valahol a neten ilyenről (sokat kerestem, de nem találtam eddig), ha fizetős a csomag, az sem baj.
Előre is köszönöm a segítséget!

Mostanában ismerkedek az ili9341-es vezérlővel ellátott TFT-vel. Ez a klasszikus, Aurdino-hoz szánt 2,4"-os fajta.
Ebből én a kijelzőt kiforrasztva, csak magát a kijelzőt használom. A cél az, hogy kihasználva a 16bites interfészt, maximális sebességen hajtsam meg.
Hosszas kínlódás után sikerült csak megfelelő inicializáló kódot találni/alkotni hozzá, és most működik is jól, viszont egy két dolgot nem értek vele kapcsolatban.

Pl bár 16 biten használnám, mégis olyan a működése, mintha csak 8 biten lenne bekötve. Hiába olvasom az adatlapját, egyszerűen nem értem, hogy hogyan kell vele kommunikálni 16 biten ?!
A parancsok mind 8 bitesek, ez ok, de ha egy pixel színét akarom beállítani, ami 2byte-os adat lenne, elvileg a 16bites adatvonalon azt egyszerre le tudnám küldeni. ezzel szemben ugyanúgy két részre osztva tudom csak elküldeni, 8biten...
Vagy a pixel szín lekérdezés, adatlap szerint 3*8biten adja vissza a színt. Hogy lesz ebből 16bites üzemmód ?

A másik furcsaság, és ez nem csak ennél a kijelzőnél figyeltem meg, a 16 bites adatvonalát egy az egyben kötöttem egy 16bites portra. Érdekes módon, küldéskor és fogadáskor is meg kell cserélnem a felső byte-ot az alsóval. Ezt sem értem, hogy hogy lehet?!

Van ezekre valami ötletetek ?

Ezeknél az a flatribbon cable, ami olyan szép narancssárga és rendelkezik pár alkatrésszel is, ott vannak azok a jumperek (általában kis értékű, 603/402 méretű ellenállások), amik beállítják az interfészt. Talán az ili chip adatlapján segítséget kapsz ehhez, de a lényeg, hogy az a kábel 8 biteshez való és kész. ESETLEG kihozhattak EGYES esetekben vezérlő szintekhez, de nem jellemző. Kizárásos alapon meg tudod találni őket.

Honnan ez a határozott állítás, hogy 8 biteshez van és kész ?
Mint írtam, nem ez az első hasonló kijelzőm, pl az előző R61505 IC-vel ellátott volt. Mindegyik ezek közül 37 kivezetéses szalagkábellel rendelkezik, amelyen ott van a 16 bites adatbusz! Ez utóbbi kijelző meglehetősen másként van vezérelve, és azt simán 16 bites üzemmódban használtam is(az arduino panelen ugye mindegyik 8 bitesre van állítva). Ugyanis a szalagkábelben kivezetik általában az IM0 és néha az IM3-as interfészbeállító lábakat is.
De ennél a 9341-esnél nem vagyok semmiben sem biztos!

16 bites módhoz a szalagkábelen az IM3:0 bemeneteket 0001-re kell állítani, valamint a "pixel format set" regisztert (0x3A) 0x55-re.
Ez az rgb565 mód. Így működnie kellene az egy pixel/írásnak 16 biten.
A kijelzőtől való visszaolvasás (azt hiszem) mindig 3x8 biten adja vissza egy pixel színét, amit neked kell visszakonvertálni 16bites formátumba. Ezt egyszer próbáltam, de nem használom.
Üdv.

A pixel format 8 bites módban is ugyanúgy 0x55-re van állítva. Ami elvileg 16 bites belső színkezelést, és 16bites adat interfészt állít be. A gyári panelen keresztül hajtva, így 8 bitesen is ezzel a beállítással működik, és nem is nagyon rémlik, hogy láttam volna más értéket ennél a regiszternél. Ezért sem értem, hogy mi mi akar itt lenni....
Tehát azt mondod, hogy kiolvasásnál nincs, csak 3*8 bites mód ?! Akkor is ha 8 bites az adatbusz, akkor is, ha 16 bites ??! Mekkora pazarlás...és logikátlanság lenne ez...
Mondjuk, ez a 3*8 bites szín visszaadás is egy nagy blődség alapban, nem is értem, miért nem 16 biten adja vissza, mint mondjuk más, értelmesebb meghajtó...

Hogy az IM lábak csak a kijelzőből jönnek ki, a csatlakozóig nem jutnak el. Magán a kábelen van beállítva ellenállásokkal (rövidzárral.) Másfelől a kijelzők az interface mögött NAGYON heterogének, alig van két egyforma. Elképzelhető, hogy van, ahol kivezetik.

Heló!

Van egy ILI9488 TFT-m, + rezisztív érintő.
Ezt szeretném összehozni egy 16 bites PIC-el. (xc16 fordító) Milyen szerkesztővel lehetne megszerkeszteni az egyes képeket? Néztem a VGDD nevezetűt, de ebből csak demót találtam, megvenni meg nem tudom mert egy nemlétező oldalra irányít át. A cél az lenne először, hogy egy képet megjelenítsen.

Köszi!