Fórum témák
» Több friss téma |
Fórum » Nextion érintőképernyős HMI, UART kommunikációval
Témaindító: Lamprologus, idő: Máj 5, 2016
Témakörök:
Bizony, Ő. Rámértem az RX és TX lábra, nem mutatott zárlatot. Aztán bedugtam a Power Bank-ba, ott már igen. Kiderült, hogy a Power Bank-ban volt összekötve a két középső láb. Mégegyszer köszönöm mindenkinek a segítséget!
A hozzászólás módosítva: Nov 5, 2017
Sziasztok!
Volna egy kérdésem, melyet nem tudom úgy megfogalmazni a Google számára, hogy az értelmes választ adjon, ezért fordulok hozzátok segítségért. Lehetséges a képernyőt kiterjeszteni? Úgy értem, ha van egy alap 240*320-as méret, de én pl 240*1000-et akarok, ami mivel nem fér ki, így lehet húzni jobbra-balja, így böngészve rajta?
A képernyő kiterjesztése szokványos dolog pl. számítógépek esetén de nem a HMI-k világában. Ehhez a trükkhöz jóval erősebb CPU, több memória stb. kell, mint amennyit általában az ilyen kijelzők tartalmaznak.
Mondjuk ebben lehet valami
Csak nem találtam lehetőséget a két oldal kötzi animált váltásra, ezért kerestem valami alternatívát. Minden esetre köszönöm az informálást.
A 3.2"-os basic kb. 4 fps sebességgel teszi ki a teljes képernyőt. Szóval alapban sebesség gond van, no meg nincs dupla frame-buffer. Képernyőváltásra én azt csináltam, hogy backlight elhalványodik=>átír=>fény vissza. A hátteret különben tudod tologatni, de kifutó élen az a gond, hogy az odaírt számnak nem tudsz negatív kezdő koordinátát beadni, tehát amint 0-nál még lépne, akkor eltűnik. Lehetséges még slider-el wipe effektet csinálni, bár szerintem flicker-es lesz. Sajnos a TFT belső regisztereihez nem lehet hozzáférni (? vagy csak a varázsszavakat nem tudom), mert azzal lehetne kis trükkel húzogatni a képet (megjelenítési kezdőpozíció regiszter bizergálása).
Egy dolgot erősen nem értek.
Van egy alap programom (én írtam [ez kérdés szokott lenni]), mely fordítás után 2,1 MB. Importáltam pár képet, melyek össz memória elfoglalása 325 kB. Fordítás után 4,6 MB lett a program...? Azt még értem, hogy hiába tudja az editor, hogy amire fejlesztek, csak 4 MB-s, de lefordítja, csak az eszköz tiltakozik ellene Lényeg a lényegben; Mitől ugrott meg ennyire az adatállomány?
Elemeztem a fordító adatait és ott áll feketén fehéren, hogy az a 4,6 MB csaknem egészét a képek foglalják el. De ha a fájlkezelőben megnézem az összes kép tulajdonságát, ott 244 kB van, elfoglalt lemezterület pedig 325 kB.
Azonban a képek importálásánál megjelenik az editorban egy konvertálási rész. Ez emelné meg a méretét ennyire?
Egy képet több formátumban is el lehet menteni. Pl. a jpg egy tömörített fájl, a BMP nem. Utóbbi cserébe jóval több helyet foglal igaz, az eszköz számára sokkal kézenfekvőbb, nem kell dolgoznia vele csak a memóriából áttölteni a kijelzőbe.
A TFT fájlba a képek RAW formátumban vannak, ugyanis a Nextion vezérlőben nincs annyi erőforrás, RAM, hogy azokat akkor tömörítse ki, mikor szükség van rá.
& Bakman
Valami ilyesmi lesz a gond. Átkonvertálva BMP-be egyből 9,8 MB lett. Valahogy azért csak megoldom
Próbáld meg a BMP színmélységét 16 bitesre konvertálni. Nyersz vele némi helyet.
Úgy elég sokat romlott a minőség. Így a 320*240-es méretét lecsökkentettem 240*180-ra, így már csak 2,4 MB az egész program. Viszont amit nem találok lehetőséget: ha beteszek egy képet, miért annak nem lehet az Editorban a méretét variálni? A behelyetett pic modult lehet, de benne a képet nem...
A *.png formátumot próbáltad már? Azt nem eszi meg?
Az sokkal kissebb helyet foglal, ha nem konkrét fényképet akarsz háttérnek, hanem csak egyszerű grafikát. A fényképekre a *.jpg formátumot találták ki, a grafikákra meg a *.png -t. Ez a két formátum egyébként tömörít, azért tudja kissebb méretben letárolni az adott képet... (A grafikát úgy kell érteni, hogy nem 16 millió színmélység, hanem kevesebb. Pngbe azok a grafikák tárolhatóak jól, aminek.: 1. kevés a színmélysége, 2. vannak benne olyan részek melyek színe közel azonosak vagy azonosak, 3. egyszerű grafikus elemeket tartalmaznak pl vonal, kör, négyzet stb, 4. sok ismétlődő pixel van benne.) Viszont a *.bmp a leg helyigényesebb, mert az nem tömörít, viszont natívan tárol minden információt pixelről pixelre, ebből következik a hátránya is, az óriási fájlméret... Egyébként ha a képméretet csökkented (nem natív méretet használsz), akkor homályosodni fog, ha felnagyítod majd a kijelző méretére programfutás közben. Azt viszont nem tudom, hogy az importált médiából a szoftver hogyan tárolja az adatot...
Tök mindegy, hogy a PC-n milyen formátumban tárolja, a Nextion akkor is RAW formátumba fogja tárolni a képeket, kvázi a program mérete nem fog változni.
"Egyébként ha a képméretet csökkented (nem natív méretet használsz), akkor homályosodni fog, ha felnagyítod majd a kijelző méretére programfutás közben." A Nextion-ban nincs nagyítási funkció (ahogy kicsinytés sincs). Amilyen méretbe elhelyezésre kerül a Nextion-ba a grafika, olyan méréetben lehet megjeleníteni.
Jah, én azt hittem, hogy ha lekicsinyíti, azt felskálátta a képernyőméretre, hogy "fullscreen"
legyen a háttér... D Wye, egyébként akkor valóban semmi értelme próbálkozni, marad a 8 bit (vagy esetleg 4) színmélység...
Nem teljesen értem a dolgot. Én, ha képet készítek egy HMI számára, akkor pontosan akkora méretben készítem el, amekkorában látni szeretném. Minden képet jpg formátumban mentek, 100 %-os minőségben, mégsem tűnt soha úgy, hogy túl sok helyet foglalnának a képek, túlságosan megdagadt volna a program mérete.
Húúú, szerintem te nagyon nem érted.
A Nextion 16 bites színmélységben, RAW-ban tárolja az adatok és minden esetben így tárolja a képeket. Ha te 8 (vagy 4 bites) színmélységű képet adsz be neki, akkor is ugyanakkora lesz a program mérete, mint ha 16 bites színmélységű képet importálsz be.
Valóban nem értem, de akkor annak mi értelme? Egy rosszabb minőségű képet felskálázni...
Különben ezt én sem értem.
Nekem az egyik projektben 350 kép van különböző méretben, amiből 15db 800x600-as, 30 oldalam van, kb. 30e sor a program és a program fájl mérete 16MB.
Semmi. A képeket pontosan akkora méretben kell elkészíteni, amekkorában kell a kijelzőn látszódnia.
A Nextion mögött nem egy 4GHz-es processzor van xGB RAM társaságában, hanem egy viszonylag egyszerű uC, ill. valami FPGA. Nincs erőforrás a képek skálázására, kitömtörítésére, stb. Az a legyegyszerűbb és leggyorsabb, ha a képernyő paramétereinek megfelelő (16bites) színmélységben, RAW formátumban tárolják az adatokat, mert így egyszerűen az EEPROM-ból ki kell olvasni az adatokat és már mehet is a kijelzőre (ponotsabban a képernyő bufferbe).
Ez egyértelmű, csak a színmélység nem volt tiszta...
Én is ugyan akkorába készítettem, eredetileg. JPG formátumban, 31 darab 320*240-es felbontásban, darabja ebben a formátumban 7-8 kB volt. BMP-be áthelyezve pedig darabja 300-320 kB. A program konvertál, így mindkettő esetben 4,6 MB lett a program.
Szerk.: Csak én tettem mindezt 100%-os minőségben 32 bites színmélységgel. A hozzászólás módosítva: Nov 10, 2017
Sziasztok!
Lehet növelni valahogy a virtuális háttértárat? Amióta foglalkozom az eszközzel, sokszor találkoztam már azzal a panasszal, hogy a rekurzív érték elérte a maximumot. Ilyenkor az eszköz (és a szimulátor is) kiakad, mint a sezlonrugó. A jelenlegi projektem szerint ez az érték akkor következik be, ha a háttérben való (megjelenítés előtt álló) számláló eléri a 10-et. Hogy kicsit tisztább legyek; Van egy változó, melynek folyamatosan számolnia kell. Ha ezt egy órába teszem be (ami meglehetősen lassú egy 48MHz-s eszközhöz [50 msec, a legutóbbi emulátor frissítés óta, azelőtt 400 volt], akkor nincsen semmi baj, csak az, hogy ~2mp kell neki, hogy eljusson 10.000-ig. Azonban ha ezt beteszem egy gomb programozási részébe úgy, hogy folyamatosan nyomogassa önmagát, akkor bekövetkezik a hiba. Hiba nyugtázását követően megy tovább, majd hiba. A kiiratásokkal figyeltem meg, hogy minden hiba után a számláló értéke 9-el emelkedik. Ez a változat nekem azért kéne, mert ezzel (elméletben) akár 1 msec is lehetne, hogy eljusson 10.000-ig. A legnagyobb gondom mégis az, hogy a határon áll. Ugyanis utóbbi módszerrel, ha képes lenne a háttérben 11-ig elszámolni, tökéletes lenne a programom számomra. Se sajnos nem tud, legalábbis ahogy eddig elnéztem. Ezért is szeretném megtudni, hogy ez a 'háttértár' növelhető-e, vagy sem?
Két változó nem megoldás? Az egyik a tizeseket, a másik az egyeseket tárolja. Így kilenc után egy és nulla lenne a két változó. Már ha jól értem a problémát.
Nem. Ugyanis valami hasonlót csináltam. 5.000-ig kell elszámolnia úgy, hogy az 5.000 4 különböző tárolóból épül fel. |5|0|0|0|. De csak 9-ig számol, utána hibára fut.
Már abban dolgozna, vagy ezt hogy érted?
Csak mert én próbálkozom azzal is, hogy HEX értékeket adok meg neki, de a fordító sem enged tovább. Valamiért csak DEC-ben számol már annak ellenére, hogy HEX adatokat képes kiküldeni UART-on. Vagy van erre beállítása?
A tárolók csak hétig menjenek. Nyolcnál már a következő helyiérték ugrik egyet, az alacsonyabbik pedig nullázódik. Így értettem a nyolcas számrendszert, így elméletileg a tároló nem éri el a kritikus értéket sem.
Esetleg az egész mizériát átrakni kontrollerbe. |
Bejelentkezés
Hirdetés |