Nem is értem hogy miért is használ még bárki is ArduinoIDE-t. Zseniális, ahogy a mesterséges intelligencia fel tudja gyorsítani fejlesztési feladatokat VSCode alatt.

Ez nagyon jó módszer ... lenne, csak a legtöbb esetben ott szokott megbukni a dolog, hogy nincs elég RAM-ja az adott mikrovezérlőnek. Jelen esetben a 16kB RAM-ban pl. ezt biztosan nem fogja tudni megcsinálni.

Biztosan nem "szokott", mert az eljárás keskeny, akár 1 képpont széles szeletekben is kiválóan megvalósítható... Máshol sincs mindig elég memória. Görbéket is és betűket is ki lehet így rajzolni, bár az utóbbinál kényelmesebb legalább egy betűnyi szélességgel dolgozni. És azzal sincs gond, ha betűket és görbét is rá kell írni a háttérre a memóriában. Mindenesetre nem iktatunk be üres háttereket. Mekkora a kijelző, 240 képpont magas? Akkor is kisebb hely kell 1,5-2 kB-nál.

Másfelől rakni lehet a procira egy SPI RAM-ot is. Ma már ugyanolyan kitaposott út, mint pl. egy szenzor használata. Előtte persze kalkulálni kell sebességet, mire elég.

Azt nem tudom, hogy az említett MicroBasic-ben milyen library-k állnak rendelkezésre, de felteszem, arra is írnak mindenfélét. A válaszokból valóban úgy tűnik, hogy túl nagy feladat lenne minden komolyabb eltérés a jelenlegitől, de ezért van a fórum.

Még egy fontos dolog: a memória, vagyis a képdarabkák (csíkok vagy más formák) szervezését egyeztetni kell azzal, hogy pontosan milyen módon lehet az LCD-t kitölteni, a képpontokat elküldeni. Ettől sok fog függni, mivel ha nem sorrendben lapátoljuk ki a képpontokat, akkor a címzések is időbe kerülnek, jobb, ha minél kevesebb van belőlük.

Elárulom neked a nagy titkot! Mellőzni kell mindenhol a törlést! Ez egyébként is baromi lassú(nagy felület), felesleges vele terhelni az erőforrást. Helyette felülrajzolást kell használni. A görbéknél is! Így nem fog villogni kicsit sem....

Igen, ez így működik...ha van hozzá RAM-od?!! Még kis kijelző esetén is meglehetősen sok memória kell hozzá, nagyobbnál többnyire külső RAM-ot kellene ehhez használni...

Éppen most írtam le, hogy hogyan lehet kicsi RAM-mal is megoldani, még konkrét számot is írtam. Nem nekem kell egy igen régi eljárást megvédenem.

A felülrajzolás egyébként nem annyira egyszerű.

És hogyan menedzseled, hogy az akár 1 képpont széles csíkokba, miket kell éppen kirajzolni??! Háttér, koordináta vonalak, szöveg részek, görbék, stb... ezek mind különböző objektumok, amik metszhetik egymást egy csíkon belül is...
Az SPI RAM nemigen elegendő sebességben. Max a QSPI, legalább 10-20MB/s vagy még gyorsabb memória kell ahhoz, hogy egy kis kijelzőt is kiszolgáljon....

Néhány görbe rajzolásáig teljesen karbantartható, és kis memóriával megvalósítható feladat.

Ehhez kell a programozó és egy kis fantázia.

Tehát most vízszintes haladásról van szó, mert szkóp. Ha van egy betűd, például egy A betű, akkor annak nyugodtan meg tudod találni a pixeleket tartalmazó fontdefinícióban (remélem, vektorfontok használatát most nem várod tőlem) az első oszlopát és fel tudod használni, ráírni a háttérre. A következő csíkban a másodikat stb.

Valamint egy görbének is veszed az adott csíkhoz, időpillanathoz tartozó pontját, aztán a következőben a következőt stb.

De nemcsak csíkról lehet szó: általában ami pixelenként generálható, ott néhány egymásba ágyazott ciklussal és szorozgatásokkal-összeadásokkal olyan interleave-eket csinálsz, amilyet akarsz, vagyis egyfajta szervezésű adatokból (pl. tömbökből) egy másikfajta szervezést.

Amikor pedig a memóriában "összeadod" pl. a szöveget és a háttered, aztán ezt az állapotot és egy görbét, vagyis két átfedő rajzolás történik, ott meg kell adni azt, hogy a már meglevő képponttal mi történjen (mint egy rajzolóprogramban): felülírás, xor, összeadás stb.

Az, hogy hány kiírandó objektum van, teljesen mindegy, a fenti eljárást kell ismételgetni.

---
Megjegyzem, ilyen célokra legalább nem ennyire kicsi mikrokontrollereket érdemes használni; pl. egy ESP32-t tartalmazó lapkán ma már eleve ott van az 1-2-4-8 MB-os Flash és RAM, és meglepően olcsók. Ja, és az tényleg gyors is - azzal az órajellel és busszal.

Igazából csak a lényegen siklottál át elegánsan Tehát hogyan is menedzseled egy függőleges oszlop képpontjaihoz tartozó objektumok aktuális metsző adatait?? Értem én, hogy elméletben ez megoldható, le is programozható..., de na...akinek két anyja van, kb annak )) Bár, az MI lehet legenerálja hozzá a forráskódot ma már
Ezzel szemben a felülírásos módszer jól kézben tartható, könnyen megvalósítható, átlátható, minimális háttér memóriával megvalósítható...cserébe kétszer annyi vonalat kell rajzolni! De ez még mindig sokkal gyorsabb, mint egy képernyő törlés....

Kétdimenziós tömbből egy másik kétdimenziós tömbbe átírni az adatokat egy más szervezésben nem egy ritka vagy különösebben nehéz feladat, gyakorlatról beszélek, de időnként lehet fejtörős, az tény.

Egyáltalán nem siklottam át, hogy mi történjen az egymást metsző objektumokkal, de lehet, hogy az elnevezés megtévesztő: nem olyan objektumokról van szó, mint a rajzolóprogramokban, csakis bitenként végezzük a műveleteket (lásd lejjebb). Nem fogjuk pl. két kör metszetét röptében átszínezni vagy bonyolult prioritásokat definiálni szövegek és görbék közt. Viszont így is van jó néhány eszközünk az értelmes rajzolásra. Tehát pl.:

- van három "objektumod": két szöveg meg egy görbe (plusz a kívánt háttér),
- haladsz valamilyen módon sorban a képpontjain,
- és van egy függvényed, ami egy objektumnak ismeri azokat a képpontjait, amiket éppen ki akarsz rajzolni,
- ez a függvény mindig éppen egy képpontnál tart (persze nagyobb egységeket is lehet használni a proc. szóhosszától függően, de most egyszerűsítünk),
- ezt a képpontot kell a már meglevővel (először a háttér képpontjával, aztán az esetlegesen már ott levő képponttal összekombinálni), persze még mindig a memóriában,
- ez a kombináció maga is egy függvény (egyetlen paraméterrel, a rajzolásban pl. egy switch-case fog függni tőle), ami, ahogy írtam, lehet egyszerű felülírás, hogy az utoljára kirajzolt maradjon ott, de tartozhat egy objektumhoz olyan tulajdonság is, hogy az ő képpontjai majd növelik a már ottlevő intenzitását stb., rengeteg ilyen lehetséges.

Ebből mindent le lehet vezetni, amire itt szükség van, de nyilván akadnak korlátok, kis mikrokontrollertől indultunk: ha a görbének szeretnénk intenzitást, mert többször kirajzolod, azért azt ne keresztezze felirat stb. A "felülírás"-nak legalább annyi korlátja van. Tőlem komplex megoldást vársz, te pedig elintézed annyival, hogy hát felülírjuk az előző görbét (amihez tényleg nem kell sok memória). És ha már szöveg is van és metszi a görbét? : -)

Mint mondtam nem néztem bele komolyabban a MikroBasic utasítások assembly hátterébe. Az biztos hogy a basic forrásban nem használok törlést. Olvasom a hozzászólásaitokat és tanulok belőle.

Akkor feltehetően a könyvtár van úgy megírva, hogy új kiírás előtt egyszerűen törli az érintett területet... Mindenképpen meg kellene nézned, hogy van realizálva, és ha kell, akkor módosítod, vagy átírod... Én ezt úgy szoktam megoldani, hogy felülírással megy ki a szöveg(ez eddig minden képpontot érint), és ha az aktuálisan rövidebb, mint a max szöveghosszúság, a különbséget egy kis megfelelő méretű, háttérszínű négyszöggel törlöm.... Így soha nem fog villogni...

Csak annyiban "vártam" komplex megoldást, amennyiben lazán és könnyedén lépsz át olyan ponton, ami pont a legkritikusabbja ennek az eljárásnak!
A dolog nehézsége és bonyolultsága épp az, hogy valahol nyilván kellene tartani, vagy kiszámolni, hogy az aktuális függőleges csík épp miket metsz és azokat konkrétan milyen pontokban?! Feleslegesen térsz el bőre eresztve a bitműveletekre, mert az itt most senkit sem érdekel..., ellenben a fenti probléma alapjaiban határozza meg az egésznek a működését!
Ahogy mondtam feljebb, elméletben leprogramozható, de szerintem nagyon bonyolult, nehezen nyomon követhető kódot eredményezne, főleg sok objektumot tartalmazó képernyőnél....
Én biztosan nem vállalkoznék rá

A szövegrajzoló függvénynemnek van átlátszósági lehetősége. Ekkor hátteret nem rajzol...illetve de(pont a folytonos memória írás miatt), de előzőleg kiolvassa a képernyő memóriából az ott lévő pixeleket. Ennek a hátránya, hogy ilyenkor lassúbb a szöveg rajzolása(lassúbb az olvasási utasítás). Szerencsére átlátszó hátterű szövegre elég ritkán van szükség...

Függőlegesen is működik? Ha nagybetű vagy szám után kisbetűt írsz ki, eltakarja a maradékot? : -) És az előző görbe + egy szöveg az oszcilloszkópon, ha átfedés van? Te írtad. Változó feltételek...

Utolsó megjegyzés: éppen a múlt héten javítottam egy hasonló eszköz (nem szkóp) hasonló problémáját (segítségnyújtás volt, villogott) - én is ezt csináltam volna, hogy ráírom az új szöveget a régire megfelelő szélességben (a háttér újrarajzolását kellett kiszednem) - csak az volt a galádság, hogy valaki (kis mikrokontrolleres műszaki eszközbe) proporcionális (ráadásul serif) fonttal írt ki mindent, a library meg nem tartalmazott ilyet, hogy egy szöveg szélessége képpontokban... : -) Az egy új tárháza a rémségeknek.

"A dolog nehézsége és bonyolultsága épp az, hogy valahol nyilván kellene tartani, vagy kiszámolni, hogy az aktuális függőleges csík épp miket metsz és azokat konkrétan milyen pontokban?!"

Szép is lenne, ha a kijelző memóriájában akarnánk a képpontok alapján számolni a metszéseket és nem az eltárolt (sokkal-sokkal kevesebb) adat alapján, hogy pl. hol áll egy kurzor, ill. mi az utolsó (akár több kör) mért adat. Végül is miről beszélünk?

Az előző görbe vagy vonal felülírása mennyiben oldja ezt meg? Mert ilyesmiről beszéltünk. Azért írtam részletesen, mert nem volt világos, hogy mire célzol.

Ezt nyugodtabban, úgy értem, lassabban kellene-kellett volna megbeszélni, tisztázva a feltételeket, hogy melyik megoldással éppen mit szeretnénk elérni. Egy általános megoldástól indultam, ami a legkevesebb ügyeskedést tartalmazza, nem azért mondtam, mert nem tudok mást elképzelni - ahogy az előző hozzászólásomban láthattad is. De befejezem, mert másoknak ez nem lehet élmény.

Eddig még nem volt igényem függőleges szöveg kiírására kisképernyős környezetben..., de nem látok semmi különbséget....
Kirajzolod az előző görbét, háttérszínnel, majd az aktuálisat. Ezek egyszerre futnak, ahogy törli az előző pixelt(vagy pixeleket), rajzolja is az újakat. Villogás kizárva! Erre rajzolhatsz szöveget, átlátszó háttérrel, vagy anélkül, ahogy tetszik... Ez bevált, évek óta működő módszer...


Nekem ehhez van olyan függvény készletem, ami direkt változó szélességű fontokhoz készült. A rajzoló függvény mindig visszaadja az aktuálisan kiírt szöveg vég koordinátáját, így onnan lehet folytatni, ha nem egyszerre van minden kiírva. De van olyan függvény, ami egy tetszőleges szöveg hosszát adja vissza képpontokban. Ezekre építve gond nélkül tudom paraméterekkel pozicionálni jobbra, balra, vagy középre igazítva is a szöveget, változó karakterszélességnél is....

Utoljára vagy 2 hete foglalkoztam ezzel a projekttel. Hát nem is olyan gyors a kirajzoltatás, mint amilyenre emlékeztem. A villogást a kép kirajzoltatás okozhatja. A csatolt videón 1s késleltetés van beiktatva a képek közé, így nem annyira zavaró a villogás. Az LCD egy 16bites párhuzamos portos 320x240 felbontás. Mögötte van egy adapter és a PIC32MX320F064H modul. Az előtérben egy PIC18F452 van ami soros porton keresztül adja át a 686B adatot 115200bit/s sebességgel. Az adatátvitel ideje úgy emlékszem 35ms. Becsatolom a teljes MikroBasic32 forrást tömörítve. Talán érdekel valakit. Tele van megjegyzésekben lévő nem használt utasításokkal is! Még takarításra vár! Ez a fő modul:


Egy videó működés közben. Video itt

A DrawLines(), DrawText() eljárások a source modulban találhatóak.

"Eddig még nem volt igényem függőleges szöveg kiírására kisképernyős környezetben..., de nem látok semmi különbséget...."

Úgy értem, vízszintes szöveg kiírásánál, mikor nagybetű vagy számok után törlés vagy más trükk nélkül kisbetűket írtál ki... Persze ha te írod a library-det, akkor nyilván nincs gond ezzel, ill. a szélességgel sem.

Ugyanaz az elv..., újra rajzolod a görbét, majd az új karakter rajzolása közben törlöd az összes pixelt, ami betű színű volt, és rajzolod az új pixeleket...

Igazából egy kis összekacsintásnak szántam, de amúgy pont erről beszélek: van rálátásom, hogy mi hogyan szokott működni, és egyedi megoldásokat, egyedi optimalizációkat használsz, a te szükségleteid szerint korlátozott képességekre mondod, hogy "működik". Ez teljesen jogos és célszerű, csak nem érv más bevált és alapvető megoldások ellen, ill. megtévesztő lehet. Lásd:

egy UI függvény, ami pl. egy kis "a" betűt kirajzol, csak az annak megfelelő függőleges helyet szokta elfoglalni, csak oda ír, míg a nagy "A" betű többet (Qt, Windows GDI stb.). Beállítástól függően törli is az előző pixeleket, ahogy nálad is - az adott karakter magasságában. Így ha ezt az "a"-t kiíratod-rárajzoltatod a nagy "A"-ra egy memóriában, akár egyből a kijelző memóriájában, akkor a nagy "A" teteje ott fog maradni. Méghozzá monospaced és proporcionális font esetén is (kivéve a fix mátrixokat, pl. 5x7-es), csak az utóbbinak még a szélessége is különbözik.

A leírásodból és abból, hogy nálad jól működik, aminek az ellenkezője évek alatt csak kibukott volna, arra következtetek, hogy a te fontrajzoló kódod egyforma magasságú karaktereket használ (az üres képpontokat is beleértve, pl. minden 7 pixel magas téglalapban van), csak vízszintesen térnek el a szélességek (és felteszem, a kódod megoldja az alávágásokat is, ahogy illik). Ha ez így van, akkor ahogy írtam, ez egy teljesen jó rövidebb út az erdőn keresztül. Ha nem, akkor van egy hibánk. : -) És hát itt sincs szó az objektumok kifinomult kezeléséről.

Én nem meggyőzni akarlak arról, hogy egy bevált, sok ideje használt viszonylag egyszerű elméleteken alapuló kód miért jobb, vagy célszerűbb, egy nehezen használható, inkább csak elméletben létező algoritmusnál..., alapvetően gondolatébresztőnek szántam, leginkább a kérdező problémájára! Valamiért nem akarod belátni, hogy az általad javasolt algoritmus lényegesen bonyolultabb és nehezebben megvalósítható, még akkor is, ha az elvét le tudod írni 3 mondatban Arra kíváncsi lennék, ezt legalább egyszer már meg is valósítottad valamilyen projectben, vagy csak értetlen ábrándozás kategóriája az egész?!

Kezdenek az igények kicsit elszaladni. Lassan a windows GUI-t lepipáló, mindenre IS kiterjedő fontkezelést vársz el egy mikorvezérlős környezetbe szánt könyvtártól! Nem az a cél, hogy mindent is lekezeljen és megvalósítson, hanem hogy a gyakorlati igényeket kielégítse, amire eddig tökéletes volt.

Részemről ez a téma ebben az irányban lezárva. Nem látom értelmét tovább csámcsogni ezen...

Inkább csak semmilyen információt sem akarsz befogadni, így a mit mire és mivel mindig változik, csak hogy el lehessen mondani, hogy én milyen lehetetlen dolgokat akarok. És persze amiket mondok, az mind csak elméletben létezik és értetlenség, követni, reagálni rá felesleges... : -) Nekem ezeket nem kell bizonyítanom. Egyébként a "mikrovezérlő" soha nem volt olyan tág fogalom, mint ma, már jó ideje az.

Mert azzal kezdte az ESP-ket programozni? Ahhoz talált forráskódokat?

Na arról mesélhetnél, hogyan gyorsítja... még csak barátkozom a PlatformIO-val, de már találtam pár szimpatikus lehetőséget benne ...

Az ArduinoIDE forráskódok nagyrészt lefordíthatóak VSCode+PlatformIO környezetben. Ugyan azok a libek használhatóak, sőt még ezek verziókezelése is megvan. Módosítani a kódodban nagyjából annyit szükséges, hogy a saját függvényeidet a setup() és loop() elé kell tenni a kódban (vagy mielőtt meghívnád őket). Ha ArduinoIDE alatt tudsz programozni, akkor nem kell megtanulni csak az VSCode sajátosságait.

- IntelliSense (automatikus kódkiegészítés és valós idejű hibajelzés), ami jóval fejlettebb, mint az Arduino IDE alap kódszínezése.
- Ha valahol elakadsz a kódolásban vagy hibakeresésben, az integrált mesterséges intelligencia segít mindkettőben.
- Refactoring eszközök (pl. változók átnevezése, függvények gyors átrendezése) sokkal hatékonyabbak.
- Könnyű navigáció fájlok és függvények között (ugrás definícióra, szimbólumkeresés stb.).
- Git vagy más verziókezelő integrációja VSCode-ban natív és kényelmes.
- PlatformIO saját build-rendszert használ, ami gyorsabb, megbízhatóbb és jobban konfigurálható, mint az Arduino IDE alap make-rendszere.
- Automatikus függőségkezelés (pl. platformio.ini fájlban egyszerűen deklarálható, melyik library kell).
- VSCode rengeteg bővítménnyel tuningolható

Van néhány hátrányos tulajdonság is, amit nem szabad elhalgatni:
- Elsőre bonyolultabb lehet, főleg ha csak "pár sornyi kódot" írsz.
- A PlatformIO konfigurációs fájl (pl. platformio.ini) némi tanulást igényel, de persze jól dokumentált.
- Több erőforrást igényel (VSCode és PlatformIO is "nehéz" egy sima Arduino IDE-hez képest).

Most ennyi jutott eszembe...

Figyelmeztetés

Olykor szoktam vírusellenőrzést csinálni és szinte soha semmi nincs a gépemen de most trójait talált az avast , méghozzá 5-öt, mind az arduino15/staging-ba volt ami az esp-s könyvtárhoz kapcsolódik. Ajánlatos átnézetni a gépet olyan módszerral ami még a rendszertőltés előtt ellenőríz, azoknak akiknek nem mindegy a gépük állapota, akinek mindegy annak semmi dolga nincs.

Az ellenőrzéssel egyet értek, de ez false pozitiv. A -gen végű trojaiak valami heurisztikus keresés eredményei. Olyan dolgokat csinál a futtatható ami jellemző lehet egy trójaira, de nem azonosított konkrét trojait. A build tooloknál ez nem is csoda. Érdemes ilyenkor a virustotal oldalán ellenőrizni. Az objcopy és strip-re nem jelzett semmit a virustotal, csak a c++filt-re, ott is szinte csak az Avast:
Bővebben: Link

Az internetes források szerint ez Avast probléma, nem szerepel minden alkalmzás az adatbázisukban.

Egy dolog viszont holt biztos! Ez a valami nélkül (is) tökéletesen műkődik a gépem (meg vele sem volt semmi gyanús jele a fertőzésnek de köszönöm szépen jól megvagyok nélküle).