Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Na erre (is) kell egy git tároló, aztán csak nyomnál egy diff-et, és máris látnád, hogy korábban mit b***tál el. Baromi tanulságos tud lenni
Szia.
Én azt sajnos nem tudom, hogy hogyan kell, de ha gondolod megmutathatnád, itt a teljes program. köszönöm.
Jo az Arduino IDE-ben a Ctrl+Z azzal vissza lehet lépkedni amig nem indul el ujra a kod.
Az mi az a git tárolo? Ilyemivel még nem volt dolgom. Én text editorokban szoktam a különbségeket keresni (ASM-ben még bonyolultabb  ), ahhoz persze kell egy müködö jo kod...... A hozzászólás módosítva: Márc 7, 2020
Igy már értem, gondoltam, hogy ez lesz..
Szia. Egy elvetemült ötlet csak. Miért nem a két végállást kapcsolóval oldottad meg?
Ami a forgás irányát kapcsolgatja,tudom nem elegáns és a cséve testek hosszától is függ a lépések hossza ,de azt a végélés kapcsolót nem kell fixre tenni.
Szép napot mindenkinek!
Abszolút kezdőtől érkezik a kérdés. Futtattam egy programot egy nano-n ami rendben megy is. Most képernyőt cseréltem Keyestudio KS0454-re DfRobot könyvtárakkal. A lábakat átvariáltam, működik, kijelez, de..... a képernyő frissítés katasztrófális. Leegyszerűsítettem a programot, hogy csak a minimális maradjon benne és még így is villog. Gondolom más lezhet a baj, de mi? Lehet, hogy annyira lassú ez a TFT, hogy még egy hőmérőt sem lehet vele normálisan megépíteni? Köszönöm a segítséget!
A git egy verziókezelő, ami alkalmas arra, hogy egy folder változásait nyomonkövethetővé teszi, tárlolja megjeleníti.
(Plusz nagyon jó elosztott csoportmukára, de itt most nem ezek a finkciói vannak előtérben.) A git szabad szoftver nyílt forráskóddal. Önmagában csak a saját gépeden is használhatod. A github egy szolgáltatás, hogy git-es repókat (verziókezelt könyvtárakat) megoszthass, illetve megosztottan használhass. Nyílt projektekhez ingyenes, csak regisztrálni kell és lehet tolni felfelé a verziókat. Ha ide feltetted volna ezt, akkor egyből mindenki láthatta volna az egész programot. Csak beírod a linket - akár konkrét sorra is linkelhetsz egy konkrét változaton belül - és mindenki tudja miről beszélsz. Hasonló a gitlab is, amit saját szerverre is lehet telepíteni. Ez ráadásul szabad szoftverrel valósítja meg lényegében a github funkcionalitását. Ezt azoknak írom, akik idegenkednek a multiktól. Saját gépen használva két változat között például a "git difftool -d ." parancs segítségével meg tudjuk jeleníteni, hogy mi változott az előző változat óta. A különbségeket úgy jeleníti meg, hogy egy összehasonlító programot nyit. Nekem a kedvencem a meld, nálam ez van bekonfigurálva: http://meldmerge.org/ A weboldalt nézd meg, hogy milyen, milyen frankó megjelenítést csinálna neked! Mindezt ingyen szabad szoftverekkel. Magyarítása is van.
Kijelzőnél villogás attól keletkezik, hogy a két képkocka közötti állapotot látja a felhasználó. Mikor betűket rajzolunk, akkor például először letöröljük a betűk hátterét (hogy az előző betűk ne legyenek ott), majd rárajzoljuk az újat. Ha a letörlés állapota véletlenül megjelenik a képernyőn, abból van a villogás.
Ez ellen a tipikus megoldás a double buffering: két képkocka van a memóriában egyszerre, és csak akkor váltunk az újra át, amikor az már teljesen készen van. Ezt a jobb vasak tudják támogatni. Ez sajnos nem tud ilyet ahogy láttam - kicsit ránézegettem az adatlapjára. Double buffering nélkül lehetőség még, ha szinkronizálod a rajzolást a megjelenítéssel: mindig akkor rajzolsz, amikor a kijelzés éppen nem frissül, és a következő frissítési periódusig be is fejezed a rajzot. Szerintem ez sem működhet itt, mert nincs visszacsatolásod, hogy mikor történik a pixelek frissítése az eszköz memóriájából. (Double buffering mellett is szinkronizálni kell a képkockák közötti váltást a megjelenítéssel, ez az úgynevezett VSYNC. Ha ez nincs, akkor lehet úgynevezett tearing. De ez itt lényegtelen, ha csak ennyi baj lenne, nem lenne baj.) Harmadik megoldás, ha a rajzolást úgy írod át, hogy egyből a jó pixeleket írod ki, nincsen köztes rossz kép. (Triviális megoldás lenne, ha a mikrokontrolleren lenne tárolva egy képkockád. Lényegében a double buffering egyik buffere az MCU-n, a másik a LCD vezérlőben van. De ehhez nincs elegendő memória. (64*128*2bájt=16kB vs 2kB SRAM) Ilyet már csináltam OLED kijelzőhöz, de az bináris, pixelenként 1 bit volt, és az épp befért a memóriába. 128*64/8=1024 bájt.) Ezt úgy lehet megcsinálni, hogy a betűkiírást úgy írod át, hogy a betűknek szánt téglalapot végigscanneled például függőleges csíkonként és minden csíkot egyből jóra rajzolsz. Így ha éppen a folyamat közepén frissít a képernyő, akkor is félig átírt számokat látsz, nem félkész kockát. Másik megoldás lehet, ha mégis SRAM-ban rajzolsz, de csak 1 biten, és onnan frissíted a képernyőt. Az SRAM-ba kétértékű pixeleket teszel és a színeket csak a kifrissítéskor teszed hozzá valami logika alapján. A lényeg, hogy ezekhez a betűkiírást lényegében újra kell programoznod. Esetleg megoldás lehet a frissítési periódus lelassítása: hőmérsékletet nem kell túl gyakran frissíteni. És ha ritka esemény, akkor egy villanás nem is zavarja a usert. A hozzászólás módosítva: Márc 7, 2020
Köszönöm
Arra jutottam, hogy ez így nem ér annyit A lényeget értem a megvalósítás mint a TFT, kínai.
Egyébként számold ki a teljes képernyő újrarajzolásához szükséges adatmennyiséget, és így egy adott FPS-hez tartozó adatsebességeket. Aztán nézd meg a felhasznált adatbusz órajelét, stb: szerintem nem lehet ezzel 50FPS körüli frissítést csinálni. Ha jól emlékszem a 128X64X1bit kijelzőt tudtam I2C-n kb 20 FPS-sel hajtani. Annak mondjuk buta volt a protokollja, amiatt sem tudtam feljebb menni.
SPI max frekvencia: 8MHz, az max 1MB/sec. 50 képkockát szeretnénk, tehát 20.000 bájtunk marad egy kockányi időre. Végülis akár bírhatná is az 50 FPS-t, de ehhez az kellene, hogy a programod kb 16 órajelenként előállítson 1 bájtot a képből. Ez reménytelen vállalkozás ezen a csippen. Egy agyonoptimalizált betűkiíró algoritmus is többet fog ennél fogyasztani. Tehát nem csak a képernyő lassú, hanem a processzor is.
Nem fog teljesen megszűnni ugyan a villogás, de javulni fog a helyzet, ha kevesebbszer írod a kijelzőt. Ha a fenti programod a cél mindössze akkor a loop elejére vagy a végére mondjuk beleraksz 50msec várakozást. Ha más feladat is van, akkor célszerű a rendszeridőt kiolvasva eldönteni mikor frissíted a kijelzőt.
A monokróm bufferbe rajzoló libem egyébként itt van: https://github.com/rizsi/Arduino-IR-decoder/tree/master/libraries/r...AW/src
Villódzás nélkül kb 20FPS-t tudok a 128X64-es OLED képernyőn, teljesen vállalható. Ez az OLED vezérlő libem: https://github.com/rizsi/Arduino-IR-decoder/tree/master/libraries/r...ED/src .Az OLED-et teljesen interruptban állapotgéppel vezérli, így nem blokkolja a főprogramot. Ezzel az I2C-s OLED-del működik: https://www.hestore.hu/prod_10035540.html A következő kütyümmel az SPI-s változatra átállok.
Hát ez szerintem felejtős lesz. A fenti kódból már mindent kivettem és kicsik a karakterek is. Ha megnövelem a karakter méretét akkorára amekkorára szeretném és kap még egy szenzort plusz szenzoronként.
tft.setTextSize(6); kapott 3000 delayt a végére Kb ecsettel hamarabb átrajzolnám a kijelzőt Refresh majdnem 2 másodperc! Érdekes: találtam hozzá egy kész .ino (gyári clock) kódot, az is szépen vibrál. Szerintem ez a kijelző statikus "valami" kijelzésére lehet alkalmas, utána meghal
Sziasztok! Ezt a kódot csak azért teszem ide, hogy ne a hibás maradjon meg a fórumon.
HC SR04-es ultrahangos távolságmérőt NEM SZABAD az Echo láb "L"-be kényszerítésével resetelni. Kapcsolási rajz + szkópos vizsgálattal erre jutottam. A modul tápját kell minimum 200ms időre elvenni, amikor nem volt viszhang, így a modul automatikusan resetel.
Én megnézném a karakter kirajzoló függvényét, mert ha ennyire lassú akkor ott valami nagyon nincs optimalizálva.
Koszi!
Jatszani, probalni, tanulni egy ilyen szett jo lehet?https://a.aliexpress.com/_d6mL2NF" target="_blank" rel="nofollow" >Bővebben: Link
Tudnál gyorsítani a programodon.
Pl. ha a betűméret nem változik, miért küldöd el a parancsot az LCD-nek minden egyes loop futásnál? "tft.setTextSize(6);" . Ez úgyszintén: "tft.setTextColor(DISPLAY_WHITE);". Egyszer elég lefutnia. A hőmérséklet kiírásnál, ha pl. a 23.5°C formátumot használod, és szeretnéd 23.7°C-ra frissíteni, akkor csak annyi a dolgod, hogy az 5-ös betűt kiírod ismét a háttér színével, majd kiírod a helyére a 7-est. A teljes LCD törlést pedig el kell felejteni! Ha a kódod pazarló, ne csodálkozz, hogy lassan fut. Nem kell az egész kijelzőt tárolnod, csak elég a tartalmát, tehát hogy 23.5°C. Ez nem kerül 1Kb-ba, csak 3-ba  A hozzászólás módosítva: Márc 7, 2020
Sziasztok! Az Atmega328P PU típus tartalmaz működő Uno bootloadert, vagy csak alkalmas rá, hogy feltöltsem?
Csak alkalmas. Az Atmel és az Arduino két külön istálló, csak van közöttük átjárás. Feltöltöd rá magad, aztán használhatod. Ebayen láttam már előre flashelt példányokat is, ott külön jelzik ezt (pl. így).
A hozzászólás módosítva: Márc 7, 2020
Vehetsz Arduino mini pro-t, ez a legolcsóbb Arduino, és felhasználhatod az AVR-t róla, a bootloader már benne van. Esetleg vehetsz olyan AVR-t, amibe már fel van töltve a bootloader (ez drágább, mint az üres). De egy programozó port sem foglal annyira sok helyet szerintem.
Sziasztok, a linkelt kóddal sikerült beüzemelnem egy Philips ECO6-os tuner modult. Minden működik,a kérdésem illetve amiben segítséget kérnék az a következő lenne:
1. hogyan tudnám kiegészíteni a kódot úgy, hogy 5db befogott csatornát tároljon? 2. bekapcsoláskor mindig az első eltárolt csatornával induljon? Ha jól gondolom a kapcsolást ki kell egészítenem egy nyomógombbal, ami a tárolás lenne és további 5db-al ami a tárolt csatornákhoz kell. A kód jelenleg egy Arduino Nano-n fut, ennyi szabad láb még akad. Ha valakinek ötlete és tudna segíteni azt nagyon megköszönném!
Helló!
Az attól függ hogy szeretnéd hogy működjön a rendszer. Ha azt szeretnéd, hogy minden bekapcsolás után is megmaradjanak az állomások, akkor EEPROM-ba kell égetni az adatokat. Ezt megoldhatod az arduino -ban lévővel is, mert ha jól emlékszem van neki ilyen, de nem javasolnám. Inkább szerezz be egy i2c EEPROM-ot. (Kis hiba és minden loop-ban ír egyet s akkor hamar tönkremegy, mert csak 10 000 írást bír ki ugyanarra a területre. Erre találsz sok példát. Ha így jársz el, akkor a setup-ban egy tömbbe mented az ottani állomások adatait. A gombokkal meg egy változót növelsz 1-5 ig, az épp aktuális állomás adatokat akkor a tömb [valtozó] -val kinyerheted. Írni is hasonlóképpen tudsz. Ugyanez a tömbös megoldás kell akkor is, ha nem mented eeprom-ba őket, csak addig tárolja az adatokat, míg be van kapcsolva az Arduino. Setupban egy 5 elemű tömböt definiálsz, plusz egy gomb ami a tömb indexeinek megfeleltethető lesz. Setup int allomasok[5] '5 elemű tömb, ha két érték tartozik egy állomáshoz akkor két elemű tömb kell loop ha megvan a keresett állomás frekije: allomasok[index]=freki az index 0-4 ig mehet, ami a nyomógombbal beállított érték lesz. 0-az első mentett állomás, 1 a második és így tovább. Induláskor: setupban: Aktualis freki=tomb[0] Ekkor az elsővel indul de nem biztos, hogy abban van állomás. Inkább pluszban el kell menteni a start állomást is egy változóban és azt kiolvasni a tömbökkel együtt. Vagy az éppen hallgatott állomás tömbindexét kell még elmenteni pluszban, így mindig a legutolsónak hallgatott adóval indul. DE!!! Ekkor az EEPROM-ba el kell menteni az aktuális rádió tömb indexét DE CSAK akkor ha az változik!!! Ha nem így jársz el, akkor az eeprom hamar meghal! A hozzászólás módosítva: Márc 8, 2020
Szia, köszi, én is eepromban gondolkodtam, de a Nano belső eepromját használnám, ha már van és nem utolsó sorban spórolnék a lábakkal további terveim is vannak vele, ez az első lépés.
Induláskor a Lastallomas-al kezdene, ez jó ötlet, utána 5db nyomómb segítségével (vagy csak egy ami léptet a tárolt állomások között, ezt még átgondolom) lehetne váltani a csatornák között. Induláskor azonban meg kellene vizsgálni, hogy a Lastallomas üres-e vagy sem, ha igen akkor a 88.5mHz-el kellene indulnia. A scanup parancsra elkezd keresni a modul, ha talál adót megáll, ekkor kellene egy nyomógomb, ha tetszik a talált adó megynomom és letárolja a frekvenciát az eepromba (eeprom írás csak a gomb megnyomására lenne).
Ez sem gond!
Ha el lehet dönteni működés közben, hogy a lastallomas üres-e vagy sem akkor nyert ügy. Mikor az adó hangolt akkor egy plusz változó (byte) 1 ha azon van állomás, nulla különben. A mentéskor ezt is mellé mentheted. Setup-ban kiolvas és ha 1 akkor ok, ha nulla indul a keresés. A lényeg, hogy plusz változók mentésével ezeket simán meg lehet oldani, csak a setup-ban ki kell olvasni ezeket. Sőt! Ha kételemű tömböt mentesz el, akkor minden tömb eleme mellé el lehet menteni ezt a plusz értéket is.
Van olyan eeprom API, ami először kiolvas és csak akkor írja felül, ha változott az érték. Ezzel akár periodikusan is mentheted az állapotot, a változások száma számít csak. A garantáltnál általában többet bír az eeprom, ha nem múlik élet rajta, akkor nyugodtan lehet építeni rá.
Sajnos azért nem ennyire egyszerű, loopban fut az egész jelenlegi program, az egészet át kellene variálni hozzá, ez meghaladja a jelenlegi képességeimet, de azért nem adom fel!
Poweron eseten az eeprom tartalma kiolvas egy tombe.
A tömböt futas ido alatt irogatni modositani. Tobb elemu tomb mert nem csak a frekit beirni hanem masik jelzo bit valtozott vagy nem. Kikapcsolaskor egy port lab "megszakitasra kepes legyen" hivja meg a leallito fuggvenyt. Ami nem csinal mast, hogy a tomb elemeit vissza irja az eepromba. De csak azokat amikben a valtozas tortent. A tobbit nem bantja . Pl a tomb 0. helyere a mindenkori aktualis frekit irni be. Amint a tomb tartalma mentve lett a uC elkuldi mély alvásba ... es lekapcsolja a tápot.mindenről. Power on esetén is ez a port ébreszthetné fel a uC-t.
Sziasztok!
Ha kifagy az Arduino, azt hogyan tudjuk megfogni, hogy miért? A Serial.print kb szívás. Milyen lehetőségeim vannak még? Szeretném tudni, miért állt meg a program...
Serial print eseten hasznald line feed hexa 12 szekvenciat ... nem fog porogni a sok sok sor.
Mas lehetoseg ha van 1 2 szabad port akkor azokkal 1 1 ledet be bebillenteni akkor ha adott program reszletet eler a program. A hozzászólás módosítva: Márc 8, 2020
|
Bejelentkezés
Hirdetés |
