Aranyáron? Akkor nézz rá egy Riverdi vagy 4D Systems HMI árlistára.

Ebbe ne menjünk bele mert nekem élő példám van

Azokat azért ne vegyük már egy kalap alá a kínaiakkal.
Én most csak a sima többi kínai kijelzőkhöz viszonyítottam, amiketolcsóbban lehet kapni...

Szerintem figyelembe kellene venni azt is, hogy az IDE a 0.52 -es verziónál tart. Nem indítod el a környezetet 2 hétig, és már frissül is. Ez még egy fejlesztés alatt álló dolog, szerintem ettől függetlenül jól használható, csak meg kell ismerni. Ráadásul az sem mindegy, hogy honnan rendeli az ember, ebből is vannak klónok.

Biztos jó, azzal kezdtem. De valószínűleg mindegy. Az én sérült példányom connect parancsra

comok 255,65535,null,79,61489,D264B8204F0E1828,16777216

választ ad de a jó válasz feltehetőleg

comok 1,101,NX4024K032_011R,52,61488,D264B8204F0E1828,16777216

lenne. Az első 3 tétel nagyon nem stimmel, nyilván ezért tagadja meg a feltöltést az editor.
Ennek alapján írtam feltöltőt:
https://github.com/g4klx/MMDVMHost/blob/master/Nextion_G4KLX/nextion.py
Feltöltöttem egy üres design tft fájlját, de sajnos a válasz connectre nem változott. Most olyan oldalt keresek, ahol a "whmi-wri" parancs fel van sorolva, úgy értem esetleges társaival, hátha a konfigurációs adatok vamai más paranccsal írhatók.

Sziasztok!

Az eddigi fórum olvasgatása alapján azok közületek, akik Arduino vagy PIC egységgel párosítjátok a Nextion HMI-t, vagy a C nyelv valamely alágával, vagy az Arduino alap parancsaival teszitek ezt.
Jómagam PIC-el párosítanám, Assembler nyelven, de ezen kommunikáció, miszerint telibe parancsot küldök [Pl.: n0.val=10] nem jöhet szóba. Már csak a lassúsága végett sem, plusz kilométeres sorokat küldhetnék.
Ha az Editor Emulátorával dolgozok, és ott adok meg direkt parancsot, majd rámegyek a HEX fordításra, akkor valójában azt látom, hogy minden egyes leütött karakter ASCII kódját küldi el, HEX-ben, majd a 3 FF lezárást.
Azonban, a Nextion képes UART-on akár 32Bites direkt HEX karakterlánc elküldésére [DEC fordításban]. Akkor erre képes kellene, hogy legyen visszafelé is.

A kérdésem az, hogy ha én PIC-el UART-on elküldök a Nextion felé egy 32Bites HEX kódot, azt be-e teszi valahova és ha igen, hova, vagy hogy tudnám kiolvasni? A Nextin oldalán nem találtam erre vonatkozó leírást, a YouTube-on és a Google találati listán pedig csak a fentebb említett, nálam szóba nem jöhető megoldások vannak.

Biztos vannak benne rejtett parancsok (ha vannak...), de azokat kell használni, amiket specifikálnak. A uC mindenre képes, de ha nincs megírva SW-ből, akkor nem tudja és kész. Ez direkt olvasható, ASCII parancsokra lett kitalálva. Azt, hogy hova kerül a beolvasott adattömb a belső RAM-ba, azt csak az tudja, aki írta (vagy Ő sem). Használj EVE-t, ott binárisan küldheted a dolgokat. (különben nekem sem nagyon tetszik az ASCII bőlére eresztett nyelvezete, de ha van DMA-d a PIC-ben, akkor mindegy, milyen kisregényeket kell kiküldeni)

A Nextion pl. grafikon adatok fogadásakor elfogad 200-300 értéket is egymás után ... ( jó ... lehet csak 254-et, de hogy 200-nál többet az tuti! ).

Márpedig csak így fogsz tudni adatot továbbítani a kijelző felé (n0.val=1 FF FF FF). Más mód nincs.

Miért kell ehhez DMA?
Megszakításból kiküldhetőek az adatok gyakorlatilag karakterenként néhány us alatt (64MHz-en kb. 2us/karakter alatt).

Csak azért írtam, mert nagyon sajnálja az időt "Már csak a lassúsága végett sem, plusz kilométeres sorokat...". Igaz, én nem PIC-cel, de (ha van), akkor DMA-val vittem ki a kijelző felé az adatokat. Végül is mindegy, ha van elég idő rá...biztos van valami oka, hogy Ő nem megszakításból csinálja.

Egy PIC-es vezérléshez kijelzőnek és adatbeviteli és részben kezelő eszköznek szeretném használni a Nextiont.
A bevitellel és a kezeléssel semmi gond. Mivel egy printh utasítás hatására egy 32 Bites számot gyönyörűen elküld, amit a PIC 4 darab 8 Bitesként le is tud kezelni. Így az első Byte-t egy kódnak használom, ami meghatározza, hogy milyen változó tartalmát akarom cserélni [24Bites változókat használok], így a kód utáni 3 Byte szépen átviszi az adatot. Illetve a kód jelenthet nyomógombok, kapcsolók vagy potméterek adatát, így ezzel a 32Bittel rengeteg mindent át lehet vinni.
32Bit létrehozása a Nextionban nem bonyolult, a kódnak használt Byte-ot felszorzom 256*256*256-al, ehhez adom hozzá az átvinni kívánt számértéket. Ha gomb vagy potméter értéket akarok átvinni, akkor azokat is felszorzom. A második byte helyén lévőt felszorzom 256*256-al, a harmadikat 256-al, a negyedik marad. Ezeket összeadom és már át is ment. Ugyanezt szeretném visszafelé is elérni, mert amíg a Nextion ráér számolgatni, a vezérlőnek nincs ideje kilométeres adatsorokat elküldeni.

Talán megoldás lehet - nem teljesértékű, de rövidebb kommunikációt igényelne -, ha a PIC is négybájtos adatokat küldene. Ehhez persze ASCII karaktersorrá kellene alakítani a szám értékét. A fő probléma ugye az, hogy a PIC csak 8 bites adatokkal dolgozik, tehát a szorzás nemigazán jön számításba. Egy- és kétbájtosra már megírtam a makrókat a PIC-hez (egy projekt keretében 4x20 karakteres LCD-kijelzőre kellett kiírni értékeket, köztük kétbájtosat is, ez jó ide is), de a négybájtosnál gondjaim vannak. Nekem most pontosan 8 darab bájtos értéket kellene átvinni a kijelzőre, úgy 120-150 msec-enként (ennyi a ciklusidő a PIC-oldali rendszerben). Ha ezt rendszerváltozóba tudnám tolni [sys1, sys2, a visszatérő érték(ek)et a sys0-ban adná a HMI], akkor egyszer - globális rendszerváltozók lévén - bármelyik lapról el lehetne érni az átadott adatokat, másodszor pedig viszonylag rövid parancssorral meg lehetne oldani, csak az a fránya értékátalakítás ASCII karakterekké...

A szám egyszerűen átalakítható ASCII karakterré: byte-onként tárolj egy-egy egyjegyű számértéket (0-9) és adj hozzá byte-onként 48-at (0x30). És az már az ADCII kód.
Ha megnézel egy ASCII táblázatot, abból megvan, miért

Milyen adat az amit másodpercenként 7-8-szor kell frissíteni a kijelzőn?

Szuper. Ez addig nem gond, ha az egyes értékek 0 és 9 közé esnek. Tuti tipp.

Nekem bejön 8 bájtom az egységbe most is, ezt kellene kiváltani a HMI-vel. A bejövő információk adottak, azon változtatni nem lehet, kompatibilisnek kell maradnom az adatátvitellel. Ezek darabonként 0 és 255 közötti értéket vehetnek fel, ezt kellene egy értékkel átküldeni. Magyarul a PIC-ben kell létrehozni egy 32-bites számértéket (mert a HMI-nek ez kell elküldeni, ráadásul ASCII karakterekkel), annak a számjegyeit már oda tologatom a kódtáblázatban, ahova akarom, nem ez a gond. Hanem az, hogy ha 255-höz hozzáadok 2-t, akkor nem 257 lesz az eredmény. Mert ha annyi lenne, akkor semmi problémát nem jelentene a "2", "5", "7" karakterek küldése. Utána ezt a HMI-ben szét tudnám dobálni bájtokra, maradékosztással meg bit-tologatásokkal.

(Az már csak hab a tortán, hogy ráadásul az összes adatmennyiségből az első három bájtot bitenként kell majd értelmezni, mert azok kontrollámpákat kapcsolnak ki-be.)

Nem magán a kijelzőn. A rendszer adatforgalma adott, egy "főgép" körbekérdezi az egységeket (amik közül ez az egyik), mindenkinek elküldi a neki szánt adathalmazt. Az én készülékem a változott értékeket küldi aztán tovább, jelenleg az LCD kijelzőnek, amit ki szeretnék váltani a HMI-vel (több, itt nem részletezendő okból). Tehát itt már "lenne idő" rengeteg bájt kiküldésére, de a PIC azért eléggé elfoglalt a saját számításaival, és a ciklikus adatátvitellel (megszakítással megy a vétele soros vonalon; RS485 stílusú hardveren, de saját kommunikációs protokoll alapján, és ha iksz időn belül nem válaszolja le a főgép felé, akkor az adatátviteli hibának veszi), ezért viszonylag korlátozott időszeletben tudok csak a PIC másik soros vonalán társalogni. Magyarul: nem célszerű hosszú kisregények átküldése, ezért szeretném a két rendszerváltozót használni erre Így két utasítás lenne az egész kommunikáció: sys1=123456778 és sys2=87614326, aztán a HMI majd ráér ezt a 2x4 bájtot kibontani magának a kijelzendő értékekre és bitekre.

Ok! így már értem ...

És mi lenne ha egy másik PIC-nek küldenéd át valami gyorsabb kommunikációs protokollal, az feldolgozná, és ráérne cseverészni a HMI-vel olyan formátumba ahogy az szereti?

Éppen ez az. Itt a baj. Ha egy 24 bites decimális számot el akarok küldeni, az nem 3 byte + azonosító, esetleg lezáró kód lesz, hanem pl."n2.val=14563498 FF FF FF" azaz 7byte + érték, ami akár 8 byte is lehet, + lezárás. Azaz 18 byte. Miközben ugyanezt a Nextiontól el tudom küldeni 4 byte-ban

Lamprologus!
Pont ezen gondolkozom én is. Ha másként nem megy, marad ez a megoldás. Csak bosszantó, hogy ez így plusz egy PIC és plusz egy program.

A bájtok száma nálam még nem is jelentene problémát. Viszont 32 bites számaim lennének, az pedig önmagában 10 karakter lehet. Nehezíti a dolgot, hogy a Nextion előjelesen kezeli, tehát -2147483648 és 2147483647 közötti értéket kér, ez adott esetben így már (az előjellel) 11 karakter. A rendszerváltozókat használva ("sys1=-2147483648 FF FF FF") ez 19 byte, és ez kétszer. Nem a világ vége. De hogy a bánatba' lesz a négy bájtomból egy darab 10(11) hosszú karaktersor? Itt vagyok elakadva, és nem technikailag, hanem az algoritmust illetően. Mondom, a kétbájtost már megoldottam (a Microchip fórumán leltem rá assemblerben egy nem túl rövid, de működő Int-BCD megoldást), de nem találok sehol LongInt változó átalakítást, az Int-ből meg nem tudom levezetni a folytatást.

Lassan kiderül, hogy a két programot egyszerűbb, gyorsabb lesz megírni mintha csak egyet kéne!

BIN to BCD lesz a barátod, keress rá. Millió egy ilyen rutint fogsz találni.
A byte-tot át lehet alakítani 3értékes BCD-re, amit már egyszerű ASCII-re alakítani és átküldeni a kijelzőnek.
Nem kell a kijelzőnek 32 bites számot küldeni, el lehet egy 1-est is. Feleslegs egy byte átküldéshez 32 bites-ként kezelni a PIC oldalán.
A bit kezelés meg már elég egyszerű lett, mióta berakták a shiftelést, az AND és OR lehetőségeket.

Pedig egy csomó ilyen példa van:
http://www.piclist.com/techref/microchip/math/radix/index.htm

Szerintem ezért tök felesleges csak a kommunikáció miatt még egy PIC-et berakni. Megszakításból igen alacsony költséggel ki lehet küldeni az adatokat.
Amúgy ha sok adatot kell átvenni, akkor érdemes szövegként átvinni az adatokat. PIC oldaláról annyi a különbség, hogy a számok elé és mögé 1-1 idézőjel kell. n0.val=123 > t0.txt="123"
Azaz ha fel kell tölteni pl. 10 változót byte-os értékkel, akkor át kell vinni szövegként a 10x3 karaktert. Ebben az esetben minden byte-tot 3 karakteren kell átvinni, azaz a vezető nullákat is bele kell rakni, pl. 1> 001. A Nextion oldalán pedig substr és cov parancsokkal a txt-ből kiszedhetőek a byte-ok. Ebben az esetben a 10x 13 = 130 karakter helyett 42 karakter kell átvinni, ami kevesebb, mint harmada.
Így az átvitt szövegből (pl. tt.txt az átvitt szöveg, t0.txt egy szöveges változó, sys0 a cél numerikus változó) visszakapható a változó:
substr tt.txt,t0.txt,0,3
cov t0.txt,sys0,0

A Nextion oldalán kicsit macerásabb, de sokkal kevesbb adatot kell átvinni a soros porton.

Ez a szöveges dolog jó ötletnek tűnik, erre még nem gondoltam. Így csak az egyes bájtokat kell "000" és "255" közötti stringgé alakítani, az a szubrutin meg már megvan évek óta makróban (ráadásul a vezető nullák ki- vagy bekapcsolhatóak a meghívás paraméterezése szerint, úgyhogy ez már tényleg kész van). De az előző hozzászólásod is hasznos volt számomra (mennyit kerestem pedig ilyen rutinokat!), nagyon nagy köszönet érte!

Őszintén szólva: nem okozna gondot a nyolc bájt külön-külön átvitele külön-külön változóba, de valahogy irritált, hogy a HMI-változó hosszának 3/4-ed részét csak nullákkal tölti fel, miközben értelmesen is fel lehetne tölteni. Jóvanna, néha elveszek a nüanszokban, mindig is mondták a programozási technikámra, hogy "a szépségbe fogsz belepusztulni egyszer!"

Csak nem Mérleg jegyű vagy?
Nekem is mondta anno a tanárom: "Először legyen meg a kódod váza, és amikor működik, utána csicsázd!"
Azaz először algoritmizáld végig, aztán kódolj és csak utána bitfaragj

Válasz magamnak meg új kérdések.
A feltöltö programos sajnos elszúrtam, valójában a whmi-wri parancsot még visszaigarolja (küld 05-öt) de utána az adatblokkok vételétmár nem, csak ezt nem vettem észre. Ez a dolog most vár. Beszereztem új HMI-t, nem próbáltam soroson uploadolni csak kártyával, működik tetszik.
Szinte röstellem megkérdezni, de sehol sem lelem a leírásokban a kifejezés (expression) szintaktikáját, miket tud számolni, tud-e stringeket összefűzni , értelmez-e logikai változót, tud-e tömböt kezelni, tud-e hexában fogadni (ha már küldeni tud) stb.
Kérlek, adjatok egy linket ahol erről van szó!

Gondolom ezt keresed.

Nem. Ezt tanulom használom, de egy csomó dolgot nem találok benne. Azt sejtem, hogy 32 bites egész aritmetika van benne, bár a linkelt oldalon a 32 bit mint szöveg nem fordul elő és a long integer is csak egy megjegyzésben. Ha pl. ki akarok írni egy számot 3 tizedesjegyre és rendelkezem a szám ezerszeresének értékével, akkor ugye az egészszámból előállított stringbe (cov) be kell toldanom balról a harmadik helyre egy tizedespontot. Semmit sem tudok a lehetséges string műveletekről. A fenti feladatot meg tudnám oldani 2 substr eredményeként előálló string és a tizedespont összefűzésével, de nem tudom van-e iylen művelet, a "concatenation" kifejezeés nem szerepel a lapon. Ezek csak példák és illetlenségnek tartanám ha ilyen részletekkel zavarnám a tisztelt nagyérdeműt, ezért esdeklem egy linkért ahol össze van foglalva a kifejezésekkel kapcsolatos tudnivalók, operandus típusok lehetséges műveletek, precedenciája, zárójelezés lehetősége, ilyesmik.

Amit zoox küldött neked, az a Nextion teljes leírásának egy szelete, az utasítás készlet. De azon az oldalon rengeteg mindent megtalálsz.
Logikai változókat tud kezelni, azonban a hex kérdésedre én is keresem a választ. De eddig semmi. Ha te eredményesebb leszel, kérlek oszd meg velem is.