Elvileg ha a szerkesztőprogram frissül, akkor a kijelző alapprogramja is. Pontosan nem jártam utána, de a kijelzőre feltöltendő fájl eleve a firmware-t is tartalmazza, ha minden igaz. Ami logikusnak tűnik, mert a letölthető program egyre többet tud, a kijelző viszont nem változik. Egy példával tudok szolgálni: Bővebben: Link.

A gyártó oldalán van letöltés. Minta kódok a gyártó fórumán vannak. De én is töltöttem ide fel egy keyboard mintát.

Nincs garmadával, de azért lehet gyűjtögetni, ha nem is olyan csodákat, de alapokat.
A firmware automatikusan töltődik le, ha régebbi verziót tartalmaz a kijelző (1x ugye).
Kérdés, hogyan lehet egy objektumnak megmondani, hogy induláskor ne látsszon? Utána már "vis"-el el tudom tüntetni, csak arra nem jöttem rá, induláskor ezt hogyan kell. Eddig azt hittem, a szimulátor/program tökéletes, de most van olyan, ami másként működik szimulátorban (jól) mint a kijelzőn, de majd kivesézem...meg én is bénázok ám még sokat.

Ilyen 3.2"-os HMI kijelzőt rendelt már valaki? 10 dollárért megtudnám venni, de jó lenne tudni, hogy kompatibilis-e a Nextion szoftverével. Ha működne vele, akkor 12 dollárral olcsóbb lenne mint Nextion-tól rendelni...

Ez nem Nextion gyártmány, hanem TJC. Állítólag valahogy rá lehet erőszakolni a Nextion Editor által generált fájlt, lásd itt: Bővebben: Link.

Így már tudom mit kell keresni.
Itt írnak a turpisságról, lehet érdemes lenne kibogarászni belőle a megoldást. Egy dll-t kellene csak lecserélni ha minden igaz.

Sikerült már valakinek megfejteni az addt parancs működését?
Mire jó, és hogy kell használni?

Ez még nekem nem sikerült.. Úgy érteémeztem, hogy egy paransban több adatot tudnék küldeni a wave formnak, de gyakorlatban még nem sikerült életre keltenem az addt parancsot.

Sziasztok!
Az addt működik, csak nem úgy, ahogy le van (nincs) írva.
Én br@y terminált használok, ott a "#" jelenti, hogy az utána következő kódot kell kiküldeni, nem mint ASCII karakter:
Tehát:
addt 2,0,11#255#255#255 (definiáltam egy 200x200-as id=2, 0. csatorna vackot és
kiküldenék rá 11db adatot)
Ez kimegy, akkor egy fe-FF-FF-FF-el válaszol, hogy jöhetnek az adatok (ha elég nagy a puffer üres területe, lehet, hogy nem kell ezt megvárni, de ezt nem próbáltam, szerintem meg kell várni)
Utána mehetnek az adatok és nem hexában, hanem binárisban egymás után, nincs space meg vessző meg cicafarka...
#000#011#022#033#044#055#077#088#099#180#030
Na, ha ezt a 2 sort bevésed a br@a macro gombjába, akkor egymás után nyomva ennek meg kell jelennie. Amint látszik, az adatokat tartalmazó sor végén nincs FF-FF-FF, mert tudja a darabszámot.
Remélem tudtam segíteni.

Hopsz! Na erre a variációra eddig nem gondoltam. Amint alkalmam lesz kipróbálom.
Köszi a tippet.

Kipróbáltam, illik megvárni a választ, akkor foglalja le szerintem a memóriát az adatsornak, 9600bps-al hiba, ha csak egybe beömlesztem.

Én eleve az addt paracs magyrázatát félre értettem. Azt hittem egyből mnnek az adatok is.
Próbáltad nagyobb adat sebességgel is?

Most kipróbáltam, 115kbs-al is működik. Nekem az volt a megtévesztő, hogy azt írta a leírás, hogy hexadecimális adatokat fogad, más utasításnál meg a hex adatfolyam ilyen volt: "ab cd 9f 5a", itt meg bináris adatokról van szó (nézve más utasításokat lazán elképzelhető lett volna az ASCII/hex formátum is). Azért ráment egy kis idő, mire kitököltem, "mire is is gondolt a költő".

igen. néha én is úgy érzem el kéne mennem egy gondolat olvasó tanfolyamra.

Köszi! Hamarosan én is kipróbálom!
Az add parancsal mire kiment a 4 görbe 200-200 adattal, addig a PIC csak "gondolkodott"!
Azt hiszem ez azért lényegesen lerövidíti az adatküldés idejét!
Ha jól számolom adatonként 11 karakter helyett csak 1-et kell küldeni! + előtte az addt parancs ... szóval kb tized annyi idő !

És mi a helyzet, ha egyszerre több görbét szeretnék megjeleníteni?
Ki tudom küldeni az adatokat egymás után, többször meghívva az addt-parancsot, majd a választ megvárva az adatokat? Nem törli ki az előző görbe adatait?
(Sajnos most nincs lehetőségem kipróbálni... de elgondolkodtatott a dolog)

Kipróbáltam...huhhh, megpróbálom elmagyarázni csekély szókincsemmel: (2ch van)
Tehát ha a 0. csatornára írok (addt), akkor megjelenik, majd az 1.-re, akkor az is, de az előző nem rotálódik. Ez eddig jó. Ha kifut a 0. adatfolyam, akkor az sem rotálódik, hanem elölről kezdi tölteni a görbe területet. Viszont, ha (add)-al küldök ilyenkor adatot, akkor a 0. shiftel, de az 1. görbe helyben marad. Valami olyasmi a dolog, hogy az (addt) feltöltésre való az (add) meg megjelenítésre. Ha csak az 1.-re adok (add)-al adatokat, akkor mögötte a másik mozdulatlan marad. Ez mondjuk így elég jó, nem vonszolja az egyik görbe a másikat (mint ha 2 layeren lennének). Ezekkel biztos jól el lehet játszani, ha kihasználjuk, hogy az (addt) átfordulóst játszik az írások folyamán, nem tili-toli-t. Valahogy így működhet...

Azért sikerült belemennem pár csapdába ...
Megpróbáltam kiküldeni 255db-nál több adatot ... nem sikerült! az a maximum amit csatornánként elfogad!)
Rosszul índexeltem a ciklust ami kiküldi az adatokat ( kevesebbet küldött ki mint amit beállítottam). Cserébe a kijelző lenyelte a következő kiküldött parancs elejét, a görbe végén zagyvaságot jelenített meg, és reklamált, hogy hibás parancsot küldtem, miközben én azt vátam hogy végrehajtsa az utasítást!

Most már rendben működik, és így tényleg jóval gyorsabb a grafikonok megjelenítése!

Igen, a puffer alul/túlcsordulás és az adatfolyam hosszának nem megfelelő beállításából adódó hibák nálam is hétköznapiak sajnos, de szoktam magamat kényeztetni azzal is, hogy átállítom 0 vagy 1 kezdőértékűre a tömbök pointereit, aztán elfelejtem, hogy ma mi is a módi. A 255 adatlimit szerintem belső változó határ, illetve a 4 görbe megenné asz összes belső puffert. Nekem sajnos csak a kicsi TFT-m van, kíváncsi lennék egy nagyobb teljesítményűre / nagyobb RAMosra, de majd...egyszer... No, akkor mit is nem tudunk még erről a kijelzőről? Még 1-2 napig nálam lesz ez az egy darab. Valami kerekítési problémára rájöttem, de még nem tudom pontosan reprodukálni a dolgot (ez kb. olyan, mint hogy nem lehet páros átmérőjű kört rajzolni ugyebár), valami a slider kurzor pozíciójánál volt 1 pixelnyi eltérés...

Az alvó üzemmóddal játszom ...

thsp ... Ha nincs érintés ennyi idő múlva lép alvó üzemmódba (ha jól fordítottam)
Nekem úgy tűnik, hogy a soros porton érkező adatok is ébren tartják ... vagy csak én nézek el valamit?

Nekem 3,5" -os van. De mostanában nem sok időm van. De belefogtam egy olyan soros terminál program írásába ami tud hozzáfűzni rendesen hexa adatokat is. Akár a küldendő string elé is. Esetleg valami script kezelési lehetőséget is. Akkor válaszolhatna magátol a bejövő adatra. De ez még csak halvány gondolat. És ha időm engedi még USB HID terminálnak is fekészítem a progit. Bár lehet, hogy azt inkább külön.
Ezel nem kéne mindig PIC re is fordítanom.

Tegnap olvastam valamit erről és igen, a soros kommunikáció ébren tartja. Talán azt lehetne csinálni,
hogy az ébredési folyamatnál (amikor frissíti az 1. képernyőt és a háttérvilágítást visszaállítja a DIMS értékére) a DIMS=0-ra állítod, akkor nem látszik semmi (mert nincs backlight). Aztán mögötte azt csinál, amit akar... Nem tudom, mennyivel fogyaszt többet, ha igazából működik, csak nincs backlight, mint ha igazi sleepbe megy. Talán még azt kipróbálnám, hogy leállítanám a soros kommunikációt, akkor elméletileg csak a soros kommunikáció bekapcsolása parancs után éledne. Bár akkor is veszi a pufferbe az adatokat, tehát igazi sleep lehet, nincs is.

br@y terminálnak mint ha lenne valami script nyelve, no most feltétel vagy várakozás bejött stringre van-e, azt most hirtelen nem tudom. Kár, hogy nem fejlesztik már.

A DIMS parancs elvileg a kontroller EEPROM területére is ment (megjegyzi az adott értéket), sűrű háttérvilágítás állításhoz jobb lehet a DIM használata.

Én valamit összerakok magamnak csak idő kérdése. Ha használhatónak minősül megosztom veletek.Hátha találtok benn javítani valót, vagy lesz ötletetek hasznos funkcióra.

Ja, nem minden alkalommal gondoltam, csak hogy azt beállítani nullára. Így "ébredéskor" is úgy látszana, mint ha aludna, a többi eseménykor/időben persze majd állítgatná a program.
Kicsit más: valamit hallottam, hogy a belső SO8-as flash-t kimadzagolták az SDkártyára és így is működik a dolog? Végül is SPI-SPI... de lehet, hogy rémhír.

Két kérdésem lenne:
- hogy lehet ellenőrizni, hogy egy grafikai elem látható-e, vagy nem (ki/be tudom kapcsolni, de hogy lehet visszaellenőrizni)?
- soros porton ugyanazokat az utasításokat tudom küldeni stringként, mint amit pl. a simulátorban meg tudok adni, csak le kell zárni FF FF FF-el?

A 2. kérdésedre igen a válasz. Az első még nem merült fel eddig bennem..

Ellenőrizd le, hogy kikapcsoltad-e! Ha igen akkor ki van kapcsolva, ha nem akkor nincs!


Esetleg a bkcmd rendszerváltozó megfelelő beállításával, visszaküldi a soros porton kiküldött parancsot sikeres végrehajtás esetén... (vagy valami hasonló, sajnos az angolom még mindig zéró! )
Én még nem próbáltam, de talán ez megoldás lehet!

Én, mint kezdő persze beleszaladtam egy hibába, megírtam nekik, hogy ez most az én bénaságom vagy szokás szerint elsőre rátapintok egy problémára (anno FT800-nál is az első programom szétakasztotta az egészet). Tehát, ha egy slider-t belső változóval mozgatok, akkor vibrál a kijelzés. Elküldtem a HMI file-t, jött is válasz:
I have check your .hmi file,this is command "doevents" weakness.I will feeback to my R&D team. But i think it's not easy to solve this problem,so please be patient.
Tömören: nem lesz egyszerű megoldani a problémát, jelezve a fejlesztőcsapatnak, addig legyek türelemmel. Ilyen az én formám... Most biztos türelmes leszek, mert már nincs kijelzőm, de majd egyszer, újra nekifutok. Addig is, ha jön érdemi válasz vagy megoldás, lehet, élek a kedves fórumtársak segítségével, hogy próbálják ki helyettem.