Sziasztok!
Intelligent kijelzőnél a twfile parancsot használva szeretnék file-t küldeni SD kártyára, a kijelző létrehoz egy ideiglenes file-t az SD kártyán .tm kiterjesztéssel, át is lép Transparent data mode-ba (FE FF FF FF), viszont itt megakad a dolog, hiába megy a soros adat, semmi nem történik. Másnál is így van? Valami ötlet esetleg? Köszönet!

Megkapja a paraméterben megadott mennyiségű adatot?
Grafikonoknál jártam úgy, hogy egyel kevesebb bájtot küldtem a kijelzőnek, az meg az idők végezetéig várta az utolsó adatot, és addig nem csinált semmit.

Üdvözletem eme kihalt topik néhai látogatóinak!

Adott egy projekt, ahol a Nextion, mint önálló számítógép dolgozik szoros összhangban egy PIC-el megépített géppel. 50 msec-enként kommunikálnak egymással és míg a PIC hardveres UART-al fogadja az adatokat, addig szoftveresen küldi a válaszokat.
Ez többek között azért van így, mert a PIC nem ér rá
Nos, a lényeg, hogy a Nextion 9.600-as Baud-al küld és 250.000-es Baud-al fogad, ami azt jelenti, hogy 50 msec-enként 2x változtat bitrátát, 9.600 és 250.000 között. A tesztek kiválóan működnek, a logikai analizátor ezt szépen mutatja is, probléma nincsen.

Mégis elfogott némi aggodalom, ami végett kérdezek. A Nextion hardveres UART modulját hosszú távon vajon nem bántja az ilyen gyakori váltogatás?

Kicsi a valószínűsége, hogy problémát okozzon. A kijelzőn lévő mikrokontrollerben sincsenek mechanikus kapcsolók, amelyek kopnának. Az, hogy az abban lévő UART modul órajele milyen útvonalon érkezik, kb. mindegy.

Idézet:
„a PIC hardveres UART-al fogadja az adatokat, addig szoftveresen küldi a válaszokat.
Ez többek között azért van így, mert a PIC nem ér rá”

Ez hogy jön ki? Szoftveresen több idő UART-ot kezelni, mint a TX regiszterbe írni egy értéket.

Valóban több idő.
Hogy érthető legyen, miért ezt a megoldást választottuk D Wye-vel.
Mivel a PIC-nek elég sokfelé kell kommunikálnia nagy sebességgel, plussz még adatokat feldolgozni, kimeneteket kapcsolgatni, bemeneteket figyelni, csomó matematikai műveletet végezni, ezért csak mester-szolga viszonyban kommunikálhat. Az uart pedig nem így működik. Mivel a Nextion kifelé print paranccsal ki tud küldeni 32 bites változókat, ezért mindeféle matematikai bűvészkedések segítségével mindössze 12 byteban kiküldhető egy azonosító, egy parancs, 4db 16 bites változó, és egy 16 bites összeadáson alapuló ugyancsak 16 bites ellenörzőkód. Ha ezt elég lassú módon teszi, akkor a PIC az időkritikus részekre letilthatja a megszakítást, és lesz elég ideje kivenni a pufferból az adatot, mielőtt újabb jönne.
A Nextion vétele már más tészta, mivel csak ASCII kódokat fogad, Ezért a 4x16 bites változó 4x15 byte elküldését jelenti. Ezt a PIC hardveresen nem tudja kellő gyorsasággal. Ezért zavarja ki szoftveresen 250000 bit/secundummal, amikor épp van rá ideje.

Ha kontroller ennyire elfoglalt akkor tényleg nem értem, miért jobb, ha a több időt igénylő megoldást választottátok. A téma szerint maga az UART modul tudja a sebességet (nem teszteltem): Bővebben: Link.

Az, hogy mester - szolga viszony van a két végen, elvileg lényegtelen, csak SW kérdése. Az UART Full duplex kapcsolatot biztosít (HW réteg), hogy erre mit ültetsz rá, egyéni fantázia kérdése.

Olvaslak Benneteket, én is gondoltam rá, hogy vásárolok egy ilyen kütyüt, de egyre inkább arra megállapításra jutok, hogy ez egy mélyebb víz annál, mint amiben én tudnék úszni...

Ne gondolj valamilyen egetverő tudományra. A kijelzőre raksz egy "kép" objektumot és a memóriájába feltöltesz három képet. Ha azt akarod, hogy a második kép legyen látható az objektumban, elküldöd a kijelzőnek ezt a parancsot:

p0.pic=0

p0: az objektum neve
pic: az objektum paramétere (jelen esetben: p0 nevű objektum képe)
0: az áhított kép sorszáma

Ennyi, nem több.

Na akkor ültessük át konyhanyelvre ezt az uart kérdést.
Van neked egy sürgős feladatod. Mondjuk ki kell reszelj egy hegedűtokot tölgyfából.
A tervrajzok egy része már nálad van, tehát el tudsz kezdeni dolgozni. A további terveket laponként hozza a postás fél óránként. Ilyenkor egy percre abbahagyod a munkát, átveszed a cetlit, majd ha mind összegyült átnézed. Erre jó az 1 bájtot fogadni képes uart.
Csakhogy a forgácsot el kell tüntesd. Aprócska adagokban tudod csak a ledobóba önteni. Kidobsz egy adagot, mész tovább dolgozni, de már csönget is a ledobó, hogy küld a folytatást.
Vagy félbehagyod a munkát, odaviszed az egészet a ledobóhoz és lecsurgatod.
Lehet, hogy összességében tovább tart, de nem rohangászol közben.
Persze megteheted, hogy csomagonként dobod le, és addig ott állsz, mig mind lemegy, de annak meg mi értelme?
Ami pedig a Nextiont illeti, az nem egy szimpla kijelző. Ennél a projektnél csak az automata szintentartást végzi teljes egészében a PIC. A manuális üzemet, az adatok letárolását és visszakeresését táblázatból, az eltérések maximalizálását manuális üzemnél, mind a Nextion végzi. A manuális vezérléshez nincs is más eszköz, mint az érintőképernyő. Természetesen a szelepeket már a PIC működteti a Nextiontól kapott utasítások alapján. Közben pedig küldi az encoderek adatait.

Nem értem a logikát.

Ha már egyszer összeállt a küldendő adatcsomag, egyszerűbb párszor írni a TX regisztert, mint szoftverből UART-ot hajtani. Ha két bájt között szünet van, akkor is egyszerűbb az UART modult használni. Amíg az UART modul dolgozik, van idő másra, a sebességkapcsolgatást is ki lehetne hagyni.

Olvastam minden cikkedet a témával kapcsolatban, letöltöttem és megnéztem a programjaidat is. Az tisztán látszik, hogy amit itt az idézetben leírtál, az számodra valóban így van, mert ténylegesen csak kijelzőként használod a HMI-t.
Azonban, ha megnézed akár azt az egyetlen, itt cikként megjelent projektemet, akkor látható, hogy én sosem használom "csak" HMI-ként. Sőt! Vagyok annyira elszánt, mint kevesen és konkrétan eddig több játékprogramot írtam meg Nextionra. Csináltam olyan több-játékos megoldást is, ahol több Nextion van összekötve egymással, kommunikálnak és a játékosok mindegyike saját HMI-n csinálja a műveleteket. Egyetlen ilyen projekthez sem használtam külső segédeszközt, sem PIC, sem Arduino, sem bármi más formában.

Volt pár évvel ezelőtt egy belinkelt videóm egy WS2812B típusú RGB LED meghajtásról. Ott volt ugyan segéd-PIC a rendszerben, de nem csinált mást, mint fogadta UART-on az adatokat a Nextiontól és változtatás nélkül kiküldte 1-Wire kommunikáción. Ha hardveresen a Nextion képes lenne erre, nem kellett volna itt sem külső eszközt használni. De mind a megjelenítés, mind az adatok összerakása / kiszámítása a Nextion feladata volt.

Tehát röviden és tömören: Nem, ez nem csak egy kijelző, ez annál lényegesen több, csak nem használják ki azok, akik mindössze megjelenítőként tekintenek rá. A te összes itt bemutatott projektedet meg lehetett volna csinálni akár GLCD kijelzőkkel is, mert az általad prezentált felhasználás tulajdonképpen legtöbb esetben még egy érintőképernyőt sem kívánt volna, nem hogy egy Nextion elpazarlását.

Félre ne érts: Nem degradálni akarom a munkáidat vagy leszólni bármely aspektusát. Mindössze tisztázni azt, hogy az általam itt beidézett soraidat nem kellő átgondoltsággal fogalmaztad meg.

Semmi gáz.
Elfelejtettem, hotgy te C-ben programozol.
Számomra egyszerűbb megírni asm.-ben egy néhány soros rutint, amit csak egyszerűen meghívok a program bármely részéből, ami automatikusan elküldi amit épp akarok, és annyi byteot, amennyit akarok.
C-ben írva gyanítom ezt a sebességet szoftveresen 16MHz-n el sem lehet érni. Asm.-ben pedig még nincs is a maximumon.

Értem én, hogy ASM, csak azt nem, miért egyszerűbb ASM-ben a szoftveres UART a hardveres helyett. Előbbiben is elég csak a TX regisztert írni, azt is meg lehet tenni kb. bárhonnan. Nem jól tudom?

Onna is lehet nézni, de ha nem számoljuk, hogy egy GLCD-nek vagy több láb kell és/vagy vagy csak fekete-fehér színű, akkor igen. Plusz a "buta" (de olcsóbb) változatok nem renlkeznek csak egy UART kapcsolattal, a másik oldalra mindenképpen kell valami. Egy szabad mikrokontrollerben azért vannak egyéb perifériák is, amik nincsenek meg a kijelzőkben.Fordítva, átgondoltam. Tiszteletem mindekinek, aki jobban tud programozni mint én. Tudom, nem egy nagy szám, de. Nem tudtok szabadulni attól a gondolattól, hogy a kezdőnek is úgy kell programoznia, mintha a kontrollert is ő tervezte volna. Kb olyan, mintha azt mondanátok, csak az vezessen autót, aki minden részét meg tudja javítani, fejből ismeri minden alkatrész funkcióját, méretét, pozícióját stb.

Miért akartok mindenkiből vérprofi ASM betyárokat faragni? Hobbielektronika, hobbi szint. Akinek ingere, úgy is tovább lép.

Nem arról van szó, hogy úgy kéne programozni. Sem pedig arról, hogy hobbi szinten IS ismerni kellene mindent. Hanem pont arról, hogy a fogalmazásodban ledegradálod a Nextoin-t egy mezei, UART képes megjelenítőre, holott nem az.
Lehet egy okostelefont csak telefonálásra használni. De attól az még többet fog tudni annál.

Részben igazad van, részben nincs.

Ez így van. De!

Ez a mondatod már egy kissé kifacsart. Miért is?
Példának okáért én ismerem a tranzisztor, az elektroncső a fet működési elvét, de mégsem tudok erősítőt tervezni, építeni. Mert ahoz több tudás kell. Az autóvezetéshez is szükségeltetne mindenki számára bizonyos szintű műszaki tudás, de nem éppen az, amit te felhoztál. Sajnos ez az ami nincs meg a legtöbb embernek, és ezért nem tudják felmérni, mikor milyen manőverrel lehet egy balesetet elkerülni. Vagy adott járművel adott útviszonyok között mekkora sebességgel lehet kanyarodni, és még sorolhatnám.
A mikrokontroller működésének, működési elvének, az assembly ismeretének hiánya, az egyből a magas szintű programnyelv, esetleg az arduino és az előre megírt programrészekkel való programozás pont olyan, mint az autóvezetés megfelelő műszaki tudás nélkül. A kreszt megtanulta, valahogy le is vizsgázott, aztán kiszabadul a közutakra. Nem a tudásra, hanem a szerencsére bízva magát.
Na ez az, ami ellen én folyamatosan ágálok.

Éppen ezt írtam.

Ahhoz, hogy jó sofőr legyen valaki, nem kell ismernie pl. az adagoló, automata sebváltó stb. pontos működését.

szerk.:
Egyébként nem egyedi jelenség amit írsz, mert minden ASM-ben programozó lenézi azt, aki magasabb szintű programnyelvet használ, tisztelet a kivételnek. Egyébként nem magyar sajátosság, külföldi fórumokon is ez megy csak ott még durvábban. Mondom ezt úgy, hogy nem sértésenk szánom, ezt kérném figyelembe venni.

Na jó, ezt befejeztem.
Te valami teljesen mást olvasol az helyett amit írtam.
Pedig még idézed is.
Amikor egy sofőr " Nem a tudásra, hanem a szerencsére bízva magát.” vezet, az sosem lesz jó sofőr. Csak vezet.
Mint ahogy a nemtudással megírt program sem lesz soha JÓ program, csak valahogy működni fog.

Ha egy program a külső szemlélő számára azt csinálja, amit kell, akkor nem mindegy, hogy miben íródott?

Ha nem tudsz vezetni, akkor nem vagy jó sofőr. Az is lehet jó sofőr, aki nem ismeri az ECU teljes működését, miközben ennek ellenkezőjét állítják azok (visszavetítve mikrokontollerre), akik csak ASM-ben hajlnadóak programozni. Erre írtam, hogy ez megy a külföldi oldalakon is, nem szokatlan a dolog.

Azt írtad, azért nem értem, miért gyorsabb a szoftveres UART, mert én C-ben programozok. Igazábol tényel érdekel, hogyan jött ez ki, de erre választ még nem kaptam. Egyszerűen furcsállom, hogy CPU időben jobban kijössz, mintha egy regiszterbe írnál egy értéket.

Te most direkt húzod az agyam, vagy rohadtul nem megy neked az értő olvasás?
Hol írtam én olyat gyorsabb? Én azt írtam, hogyha igazából nem tudsz mit csinálni az idő alatt, amíg az uart elküldi azt az 1 byteot, akkor már jobb megoldás a szoftveres, mert az legalább folyamatos. Azt hittem konyhanyelven megérted.

Nem te írtad, csak válaszoltál egy kérdésre. Ez volt az eredeti felvetés:

Most azt írod, hogy azért használtok szoftveres megoldást, mert azon időszak alatt egyébként sem tud mit csinálni a kontroller.

Amíg a hardveres uart ekkora sebességgel elküld 1 byteot, és máris rántja a PIC-et megszakításba,
mi mindent tud addig a PIC csinálni?
Akkor már inkább akkor küldöm az adatokat, amikor erre van elég idő.
Azon kívül, ha egy időkritikus részt megszakítok emiatt, esetleg más gubanc történik.
Mivel a vétel ideje nem kritikus, ezért veszem hardveresen, alacsony bitrátával, mert az időkritikus részek idejére (két másik PIC-el is kommunikál) letiltom a megszakítást.
Tehát használom a hardverest is! De van olyan helyzet, amikor jobb megoldás a szoftveres.
Miért nem tudod ezt elfogadni?
És még én vagyok erőszakos téritő

Miért rántaná megszakításba ha nincs bekapcsolva az a megszakítás? Akkor küldöd az adatokat, amikor van rá idő, ugyanezt meg lehet tenni a TX regiszter írásával is.

Egy tök egyszerű kérdést tettem fel egy ellentmondásnak tűnő dolog feloldásához, hátha tanulok (tanulunk) valamit, de csak ködösítést kaptam.

Mi a PIC típusa? Nincs abba egy DMA kontroller is? Ha van, akkor az hardveresen elintézi az összes adat vételét és adását pár paraméter megadása után megszakítások nélkül.

Erről még nem hallottam. Ha ilyen lenne benne, az jó lenne. De gyanítom nincs, mert Bakman akkor már az orrom alá dörgölte volna.
A PIC típusa 18F14K22.

A köd az nálad alapból megvan.
Többszörösen megválaszoltam a kérdésedet, (még konyhanyelven is) hogy miért így csinálom.
Nem fogom másként csinálni, mert nekem ez így jó. Az alapkérdés nem az volt, hogy Bakman uraság miként csinálná.

Ebben valóban nincs.

Sziasztok!
Egy DOS textfile-ból jönnek a szövegek, persze ékezetesek nem stimmelnek.
TEXTboxba kézzel beírva megjelenik (ÉÁéá), a file-ból malackafarka karakterek lesznek.
Keresek 8, 16, 24 magas jól olvasható (320x200-as 2.8" TFT) ékezetes ZI-filet. (pl. ArielBold)
Vagy marad a kézzel átírogatás, csak az 1 hónap pötyögés
Előre is köszönöm!

A karaktertábla 0x20 -tól (szóköz) 0x7E -ig (~) úgy-ahogy egységes minden táblában, azon kívül a karakterkódolás az irányadó, abból meg annyi van, mint csillag az égen. Egyszerűbb a DOS fájlokat más karakterkódolással menteni vagy a Nextion karakterkódolását átállítani arra, ami fekszik a meglévő szövegek kódolásának.

Arial Bold. Arel Bold = molett hableány.

Igen, úgy látom, marad egy kis kézikódolás hexeditorban (talán Contexttel írhatták, van vagy 50 eltolódás az ékezeteseknél), aztán jön a német/svéd/francia is (amikből nagyfokú információhiánnyal rendelkezem, magyarul sülthal vagyok hozzá). Azért fura, mert pl. FAR manager más karaktereket mutat, mint egy hexeditor...
Köszönöm!!!