Az ESP-WROOM-32-n nincs is LED. Mit szeretnél villogtatni? Vagy valamilyen ESP32 fejlesztőpanelod van? A működés ellenőrzésére lehetne valamilyen serial-on adatot küldő programot feltölteni próbaképpen.

Ez egy ESP32-WROOM-32D, 38 lábú panel. Van benne LED, a 2-es porton. ESPEasy-vel működik.
A példák közül a Blink-et szeretném futtatni.
De futás helyett még resetre vár. EN, Boot hatástalan.

EZ AZ ?
Mert ha igen ezen csak 1 power led van, annak a jelentése , hogy áram alatt van. Még olyan lehetséges , hogy mikor feltöltöd a progrmot akkor villog.

Ha a fent említett modelled van akkor a kódod így néz ki

és a 4 pinre kötöd a ledet a megfelelő előtét ellenállással . IO4-led anod, előtét ellenállás, led katod-GND. Piros lednél kb 180-220 Ω

Köszönöm a segítséget!
Ezen valóban nincs LED.

Köszönöm a segítséget! Ezen valóban nincs LED. Egy másikon próbáltam az ESPeasy-t.
Most már működik.

Nem hagyott nyugodni az LGT328 sikertelensége, rendeltem egy nano stílusú lapot. Ez hibátlanul működteti az ST7735 alapú lcd-t. Viszont felmerült egy újabb probléma. A kijelző szemet bántóan villog. Pedig csak akkor frissítem, ha az indokolt, pl. ha változik a mért érték. Na de az ADC billegése miatt szinte folyamatos a frissítés. Van erre valami ötlet, hogyan lehet ezt megoldani?

Felülírod a képernyő tartalmat, vagy előbb törlöd, és írod?

ADC adatait atlagold, 5 10 ertekbol szamoljal atlagot, es utana irasd csak ki.
Kevesbe fog billegni.

Tölöm az egészet, utána újra írom. Ha csak felülírom, az előző értékek ott maradnak, és egy értelmezhetetlen zagyvaság, majd egy telibe írt terület lesz a karakterek/számok helyén.

Átlagolom. Már 100 mérést is próbáltam átlagolni, valamit javul, de nem sokat.
Máshol azt olvasom, hogy az ST chip lassú nagyon, ez is okozhatja a villogást. Arra gondoltam, hogy csak egy átlagolási ciklust írok ki. De lesznek olyan részek, ahol potival állítok egy feszültséget, közben tudnom kell annak az értékét.

Módosítsd úgy az st7735 library betűrajzoló függvényét, hogy ne csak az aktív pixelt rajzolja ki, hanem a nem aktív pixeleket is az aktuálisan beállított háttérszínnel. Ezzel a módszerrel mellékesen sokkal gyorsabbra is meg lehet csinálni, mert nem kell a kijelző kirajzolási területét pixelenként címezgetni, hanem elegendő egy alkalommal a teljes betűt befoglaló terület rajzablakának a címzését elküldeni. Ebben az esetben az új szöveg teljesen felülírja a régit, ha ugyanoda pozicionálod.

Nem Arduino és nem ST chip, de szintén villogással küzdök. Egy oszcilloszkóp kijelző így mindig törölni kell a hátteret, jelző vonalakat és a kijelzett értékeket. Én már gondoltam arra is hogy a lefordított utasítások a lassúak. Hatékonyabb eljárásokat kellene keresni. Egyébként amit használok (MikrobasicPIC32, PIC32MX320F064 40MHz-en futtatva). Próbáltam 80MHz-en is hajtani, de nem jelent meg a képernyőn. Maga a kirajzolás nagyon gyors, de ennek ellenére látszik a villogás.

ESP32-nél én is belefutottam abba, hogy lassan fordít az Arduino IDE...
Egy SD kártyáról, mp3 lejátszás, webes felületen progit több mint fél óra alatt fordít le ...

Platform IO ugyan ezt a porgit 1 percen belül lefordítja ...

Sajnos nem látok bele a Mikrobasic32 utasítás hátterébe, elég kusza a generált assembly kódja. Talán képet képes kezelni, úgy rémlik. Kösz a tanácsot.

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.

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...

É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.

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....

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...

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.

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...

É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...

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 ...