A kezdők kedvéért összefoglalom, hogy mi nem az Arduino. :-)
Nem mikrokontroller.
Nem programozási nyelv.
Nem professzionális fejlesztőeszköz.
Akkor mi az Arduino?
Egy mikrokontroller kártya. Eredetileg Atmel AVR 8 bites, ma már sokféle mikrokontrollerrel szerelt hobbi fejlesztőeszköz.
Egy nagyon buta IDE. (Integrált fejlesztőeszköz.) A Processing IDE-re épül. Arról is tudnék pár keresetlen szót írni...
Egy függvénykönyvtár. C++ nyelven írt, nem következetes, erőforrás pazarló, hülyéket megvédeni akaró, mégsem hülyebiztos. Példa: Egy kimenet írásakor MINDIG leellenőrzi, hogy nincs-e ott PWM, nem analóg bemenet-e, stb. Ez rengeteg idő.
Egy önsegítő közösség. Ahol a naiv kezdőtől a profiig mindenki osztja az észt. Válogasd ki belőle a használható tanácsokat. ;-)
Egy fejlesztő közösség. Ahol bárki írhat bármilyen elv alapján függvénykönyvtárakat, amiket aztán megoszt. Senki sem ellenőrzi a minőségüket, vagy az interfészük használhatóságát. Te letöltöd, és nem érted, miért nem működik. Rengeteg horror példa van. Például sok I2C eszközkezelő szoftver. A "könyvtár" úgy veszi, hogy rajta kívül senki más nincs a rendszerben. Tehát lefoglalja az I2C buszt, és busy waiting (delay) segítségével időzít... Semmi más nem fog mellette működni.
A különféle mikrokontroller gyártók általában komplett hardver, szoftver, fejlesztőeszköz, debugger megoldásokat dobnak piacra. Ezek jelenleg már olcsóbbak, és jobbak, mint az Arduino. Tíz évvel ezelőtt az Arduino pont a csóró hobbisták miatt hozott egy csomó, profiknak vállalhatatlan kompromisszumot. Aztán akkorára nőtt az egész népszerűsége, hogy a gyártóknak lépniük kellett. Tulajdonképpen jelentős szerepe van az Arduinonak abban, hogy manapság minden gyártónak van kimondottan olcsó, debuggerrel összeépített fejlesztőpanelje.
Példa: Egy eredeti Arduino UNO jelenleg 7-8 ezer forint. Egy ugyanilyen MCU-t használó ATMEGA328P-XMINI 3000 ft, és van rajta beépített debugger chip... Az ingyenes Atmel Studio IDE-vel lehet rá fejleszteni, minden perifériájához van C kód (AVR LibC), és lehet debuggert használni. De ugyanígy 3-4 ezer forint egy debuggerrel egybeépített STM32 Nucleo, ahol 32 MHz és 180 MHz közötti ARM mikrokontrollerből választhatsz. Az IDE és a HAL szintén ingyen van. De elérhető hozzá az Arduino függvénykönyvtár is.
Ha szeretnéd az Arduino szoftveres környezetének előnyeit élvezni, mint gyors fejlesztés, sok előre megírt könyvtár, akkor én ezt tenném:
Választanék mikrokontrollert, és vásárolnék hozzá debuggert. Egy Atmel ICE jelenleg 15 ezer, egy ST Link pedig kb a fele. A legtöbb komoly, debuggert is támogató IDE mostmár képes Arduino projekteket is kezelni.
Vállalkozó szellemű, intelligens Arduino-s személyt keresek aki tartana nekem egy rövid diskurzust. Személyesen vagy telefonon.
6v-8.4v RC szervó működtetésével és programozásával kapcsolatos infók érdekelnek. Hozzáértőnek nem túl bonyolult ám nekem még az, de tudom hogy idő pénz szóval beszéljük meg :) Nagyon köszönöm!
Arduino esetén az van, hogy ha fut egy adatküldés az eszközről a gép felé, akkor foglalt az USB/soros átalakító. Ha az IDE soros monitora figyel, akkor az IDE nem fogja engedni a küldést, hanem szól. Ha más alkalmazás figyeli (bármilyen soros terminál), akkor pedig hibára fog futni, mert nem azt kapja vissza a feltöltés inicializálásakor, amit kellene. Ha nincs figyelés (nem veszi semmi az adatokat a számítógép oldalán), akkor simán elindul a feltöltés.
Nem. Nincs op. rendszere. Van egy betöltője, ami adott szekvenciára elindul, és a soros porton fogadja a byte-okat, majd letárolja, végül egy Reset, és elindul a letöltött kód. Ehhez túl sok közöd nincs, legfeljebb, ha új boot loader-t akarsz írni :)
Értem. Szóval akkor a modul belső op. rendszere az USB portot megosztva használja az futó alkalmazás és az op. rendszer belső dolgai között, mert gondolom, hogy miközben fut az én programom (ami adott esetben használja a soros portot), továbbra is figyel arra, hogy a PC megszólítja-e egy újabb progi letöltése érdekében.
1. Semmi akadálya, de ki kell választanod az IDE-ben a kontroller típusát és az USB virtuális COM portját (minimum), amin megszólítod a kontrollert
2. Majdnem :) Az IDE szólítja meg a modult, mire az letöltés üzemmódba kerül.
3. Felesleges neked az USB porttal külön bajlódni, a Serial kezelő betöltése és inicializálása után a Serial.print(...) utasítással tudsz a PC-n elindított soros vonalat kezelő rutinnak ASC-ben adatot küldeni. Az IDE debug modulja pl. erre alkalmas, de ha bármely soros terminált használod , mind jó lehet.
Olvasgatom a hozzászólásokat, élvezem, hasznosak nekem is. Én még csak most ismerkedem az Arduino-val, bár sok évvel ezelőtt (kb. 20-25) uP-s fejlesztéseket én is csináltam, de ilyen Arduino-szerű rendszerek akkor még nem igazán voltak (max. az i8052AH BASIC környezet), azóta meg másfelé vitt az élet, a témával is felhagytam nagyjából, úgyhogy most egy kicsit elölről kell kezdeni az egészet. Nemrég jártam az egyik bécsi Conrad-ban, és hogy ne jöjjek el szuvenír nélkül, vettem egy Tesco-gazdaságos Arduino Nano-t (helyesebben egy C-Conrol Duino-t). Hogy mire fogom használni, arról még fogalmam sincs, de majd csak kitalálok valami értelmes feladatot a számára (elsősorban ismerkedési szándékkal vettem).
Az első alapvető kérdésem a következő lenne:
1. Rádugom a modult a PC-re, és elindítom az IDE-t
2. A modul folyamatosan figyeli az USB portját, hogy le akarok-e tölteni neki valami kódot?
3, Ezt azért kérdezem, mert ha a kód, amit rá akarok tölteni a modulra, szintén használná az USB portot (pl. a bemenő analóg portok értékeinek visszaküldése a PC-re), akkor az megoldható?
Az Arduino szintjén nem. Ott 99% humán. Jelentős rendszerekben van olyan szintű tesztautomatizálás, ami külső elemmel csinálja ugyanezt, de ott a külső elem is egy beágyazott rendszer (vagy egyedi vagy gyári), de az ellenőrzés alapelve nagy vonalakban ugyanez. Az IDE csak a szintaktikát ellenőrzi, illetve bizonyos fokú előre megírt protokoll alapján optimalizálja a gépi kódot. De ebből kb. semmit sem látsz (és a célnak megfelelően jól van ez így).
Mivel hobbiról van szó, a "házi kód policy" kb. az, amit magadnak kitalálsz. Elképesztően ritka, hogy valaki többedmagával dolgozzon Arduino platformon.
Amit leírtam lépésről lépésre, pont a unit teszt. Mert ez alá nincs értelme menni (sérül a funkcionalitás), feljebb pedig már nagyobb egység van. Alapvetően baromi hülyén van megcsinálva, de ez van, ha a gyári keretrendszert használod, akkor máshogy nem lehet. Illetve lehet, csak az máshogy szopás.
Sziasztok, nem is gondoltam, hogy akkor nalatok is vannak deploy elotti szintaktikai stilus, szemantikai automata ellenorzesek es human codereview a hazi code policy val ? Jol ertettem ?
Unit es funkcionalis etc tesztrendszerek amikben mock frameworkok biztositjak az izolalsagot es a modularitast ?
Tenyleg rosszul gondoltam, en totalisan el vagyok tevedve ...
Nem látom ennek értelmét így. Egy szál 328p-vel megoldható ez a feladat, az idő 99,9%-ában úgyis csak a változásfigyelés pörög. Ha nincs túlhúzva, az i2c és az spi is megy egymással gond nélkül, ha valaki nem akar egyidőben mindent megoldani. De itt a másodperc töredéke alatt futnak le a teljes adatküldések, így nincs jelentősége, ad abszurdum, másodperces frissítést is lehetne csinálni (nem lehet, mert a kijelző lassú). Ha képes lenne rá (keretrendszer hiányosság) én elküldeném deep sleep-be, oszt jónapot. Az einknek úgysem kell felügyelet.
Amit én csinálnék:
-- RTC kezelés. Minden adatot ki, manipulálás mindenféle formában, eredmények soros vonalon ki. Addig, amíg úgy nem fut, ahogy nekünk a legjobb.
-- eink kezelés. Ismert formátumú adatok kiküldése először kötött formátumban, utána változó adatként (léptetés, switch/case stb.), a végső feladat, hogy az rtc-ből kijövő formátum (nem a konkrét adat) menjen ki rá úgy, ahogy azt elképzeltük. -- eink második menet: frissítési gyakoriság változtatása állapotgéppel (gombnyomásra, fényerőre, eltelt időre, stb.).
-- kódoptimalizálás olyaténképpen, hogy az adott modul egy függvényben legyen, ha szükséges, paraméterhívással. Így is teszt.
-- aztán mehet az összegyúrás. A loop csak figyel, mint a korábbi példában is, állapotgépként, a többit csinálják a függvények.
Amíg egy modulteszt nem 100%-os az összes szóba jöhető állapotra, addig kell ütni, amíg nem lesz az. Utána lehet esetleg optimalizálni (de nem muszáj). A "majd megoldjuk a teljesben" NEM megoldás.
És verziótörténet végig, nyilván.
Ami az Arduino-t illeti. Pontosan, nem több, nem kevesebb. Csak ugye mindenki azzal kezd, hogy holdmodult, okosházat és motorszabályozó elektronikát akar építeni belőle. Pedig ezekre így pont teljesen alkalmatlan.
Az Arduino azért felkapott, mert arra, amire kitalálták, parádés. Másra a lehető legrosszabb.
Ahogy én látom, az Arduino egy kiváló terep : kicsit tüskés, így a nagy mellény gyorsan sérülhet :) Azt gondolom, hogy arra teljesen jó, hogy egy-egy részfeladatra deszakmodellt pillanatok alatt össze tudj dobni, a deszkamodell igazolja vagy elvesse a gondolatod megvalósíthatóságát. Pont a rögzítetlen játékszabályok és a perifériák sokfélesége adja az Arduino kiválóságát és egyben csapnivaló tulajdonság halmazát is. A sokféleség mellé igencsak elférne, hogy nem egyszerre sokfélét, hanem jellemzően külön-külön kötögetjük , illetve ha a rákötött perifériák pl. egy 'érzékelő, több relé' értelemben vett közel homogén együttest alkotnak, akkor semmi baj sincs (az esetek jelentős részében). Akkor kezd a derült ég sötétedni, ha több, real-time kezelést igénylő eszköz van egy procira kötve - erre csak nagyon korlátozottan alkalmas.
Visszatérve az eredeti problémára, az utóbbi mondat szerint:
- egy Arduinora kötött RTC (A porc.) , I2C-vel egy másikkal (B proc.) összekötve, amelyen rajta lóg a kijelző
- Az 'A' feladata az RTC kezelése, és időnkénti szinkron átküldése a 'B' felé (pl. 2 percenként). Az indításkor természetesen a pontos időt is átküldi.
- A 'B' feladata az aktuális idő nyilvántartása, és adott időnkénti kijelzőre írása. Az I2C buszon érkező csomagok fogadása, értelmezése.
Így kettétörtük az eddigi bonyolulttá vált feladatot, és két, egyszerűen kezelhető, az Arduino tervezési filozófiájának megfelelő taskot hoztunk létre. Ha ez korrekten megy, meg lehet próbálni konszolidálni, azaz, egy rendszerbe ültetni mindent, kivéve a második Arduino-t.
A web totál más, mint a beágyazott fejlesztés és jobbára más, mint a szoftverfejlesztés (win/iOS/Android). Az, hogy x éve weblapokat raksz össze, egyáltalán nem jelenti azt, hogy alapvető, pláne mély algoritmizálási rutinod lenne, az pedig itt, ha nem is alapelvárás, de nagyon-nagyon nagy segítség. Alapvetően más gondolkodás kell „ide”, mint „oda”. Nem rosszabb az egyik a másiknál, csak más. A fejlesztőeszközök is, a szükséges tudás is.
Az Arduino azért felkapott, mert arra, amire kitalálták, parádés. Másra a lehető legrosszabb.
nyilvan nincs rendes ralatasom a temara, de amennyire felkapott az Arduino en mast vartam.
Ja, vissza kell allni a futo verziora, en is erre jutottam, csak hat mivel refaktorral jutottam odaig, tul sok minden lett a kalapban, hogy mi lehet a gond egy uj teruleten.
Amugy meg webfejleszto vagyok 15 eve, volt minden asp, java most js
front-end back- end, egyikben sem vagyok pro, mert mindig kellett mindenhez erteni vagy eppen valtozott a technologia.
A legtöbb MCU, ami tényleg MCU és nem mikroszámítógép (RPi) alapvetően barebone. Aztán hogy hány és milyen réteget pakolsz rá, az már tényleg (elsősorban) fejlesztői környezet kérdése. Az Arduino az egyik legelbaszottabb ilyen, az utóbbi időben hajlamos vagyok az egyébként eléggé profinak tűnő mbed.org-ot is ide sorolni, mert azon túl, hogy az alapot (RTOS) heti-kétheti rendszerességgel frissítik (rendszerint azért, hogy valamilyen hardveres bizbaszt integráljanak kvázi OS szinten), sok minden nem történik és nagyon kevés gyártó kivételével mindenki pont telibe szarja, hogy a saját eszközeihez megcsinálja-e rendesen a könyvtárakat vagy sem (aztán hogy azok karban vannak-e tartva vagy sem, már egy egészen más történet). Alapvetően minden azon dől el, hogy az adott cuccot milyen fejlesztői környezetben kezded el piszkálni (már felvéte, hogy az adott környezet azt a konkrét fejlesztői eszközt támogatja-e vagy sem).
Ebben a tárgykörben az Arduino a legalja sok szempontból. Mindent készen, de szarul kapsz, gyakorlatilag az egy szál forráskódot írod meg, ami az összes többi könyvtár (mondjuk HAL, de ez sem egészen igaz) paraméterezésével együtt. Borzalom.
Most kíméletlen szöveggel örvendeztetlek meg: ha fejlesztőnek gondolod magad, akkor, ha egy számodra új környezetben kell bármit megvalósítanod, akkor első lépésben azt kell megértened, hogy mi is annak a környezetnek az alapfilozófiája, magyarul, mire is készült. Enélkül a legegyszerűbb, grafikus alakzatok segítségével összepakolt rendszer (pl. Scratch vagy Google Appinventor) is billegni fog - azaz, kicsiny változtatásra is nagyot fog esni :( Alapvetően két szélsőséggel találkozhatsz, ha mikrokontrolleres környezetben dolgozol:
- 'meztelen' processzor, legfeljebb valamiféle hardware - software kombinációjú hibakeresőd van, operációs rendszer jellegű környezetről szó sincs ... Ilyet találsz pl. a MicroChip környezetben
- intelligens monitor, majdnem BIOS szintű, vagy tényleges operációs rendszer alatt fejlesztesz. Ekkor jellemzően elfelejted a perifériák időzítési, I/O port kezelési nyavalyáit, mert készen kapod a drivereket hozzájuk - hacsak nem neked kell épp kifejlesztened :) FreeRtOs - (lehet, hogy rosszul írtam) egy ilyesmi kísérlet, vagy a Raspberry Pi - re applikált Linux, mint komplett operációs rendszer.
Az Arduino fejlesztési környezete egy vegyes felvágott, az egyes perifériák kezelését vagy te magad, assembly szinten készíted el, vagy könyvtárakat vadászol, és boldogan könyveled el, hogy szó sincs semmiféle szabványosnak mondható megszólítási - státusz felületről, vagy épp az I/O portok allokálásának és elengedésének valamiféle közös felületéről. Ezeket a könyvtárakat rendszerint hobbi programozók írják, és fogalmad sem lesz arról, hogy az állapot az 'éppen elindult', vagy kőkeményen tesztelt kategóriába sorolható. Jellemzően a korábbi Dacia autóhoz hasonlítható: megveszed vagy hozzájutsz majd addig szereled, amíg számodra alkalmas üzemi állapotba nem kerül :)
Megnyugtatlak, volt olyan C++ -ban írott rendszerem, amelynek különböző részeit az alábbiakból kellett összerakni:
- Turbo C
- Watcom C
- Zortech C
de lehet, hogy valami kimaradt :) Az egyik itt esett el, a másik ott ... A Watcom C-ben nagyon komoly fejlesztések voltak, pl. a Novell file servereinek operációs rendszerét is ebben írták, a Zortech-ben pl. adatbázis kezelőt, interaktív keretrendszerrel- szóval, nem egy barkács klub játékait említettem.
Kicsit hosszúra nyúlt, bocs, nem akartalak untatni, csak az elvárásokat kell a helyén tudni. Ha bármiben segíthetek, jelezd légyszíves.
Tegyünk rendbe azért egy-két dolgot. Az, amit te az Arduino keretrendszerben művelsz, az a felszín felszínének a legfelső rétegének kapargatása egy tollseprűvel. Az Atmel önmagában egy elég erős jószág, az Arduino keretrendszerbe ágyazva csak annyi történik, hogy a kemény munka jelentős részét szimplán eldugják előled, de attól az még ott van a háttérben. Az a kitételed, hogy „egy dátum kiiratása a 21. században az nem szabadna komplexitásnak lennie” egyértelműen azt jelenti, hogy fogalmad sincs arról, hogy valójában milyen folyamatok zajlanak a háttérben. Ez kezdőként nem baj, csak nem azzal kell kezdeni, amit a Windows világában megszoktál, hogy bekapcsolod, ráböksz és működik. Ez nagyon nem az a liga.
„setup részen ez már működött úgy, hogy a hónapot és a hét napját magyarul írta ki - oké ékezetek nélkül de tényleg működött a kiíratás, csak nem frissült napról - napra.” Ha ez valóban így van, akkor semmi más dolgod nincs, mint a működő verzióra visszamenni és megnézni, hogy a naponkénti/óránkénti/bármilyen frissítést hogyan lehet megcsinálni [u.i.: nem delay()-jel]. Alap fejlesztői koncepció, hogy modulárisan gondolkodunk (lásd LyPapa korábbi válaszát): az egyes elemek működését úgy hardver, mint szoftver oldalról egyenként ellenőrizzük és optimalizáljuk, csak ezt követően kezdjük el őket egymáshoz rakosgatni. Ez a „mindent dugj össze, töltsd fel és működni fog” elv a legritkább esetben jelent tiszta alapot egy saját személyre szabott projektnél.
„utána olvastam és amint Ti is írjátok a Serial.println on kívül nincs debug segítség ... hát ha ez a jó, milyen lehet a használhatatlan” Ez így nem egészen igaz, mert az Arduino keretrendszeren kívül, megfelelő hardverrel az Atmelt is lehet normálisan debugolni. Csak ehhez egy 2 GB-os fejlesztői környezet (IDE) és egy uszkve 50 000 forintos hardver kell. Rengeteg mással egyetemben az Arduino keretrendszer egyik legnagyobb hiányossága, hogy nincs rajta normális debug. Az a megoldás, amit a korábbi válaszomban írtam, az esetek 95%-ában képes a probléma megoldására. Tudjuk, hogy nagyon szar, hogy nincs breakpoint, nagyon szar, hogy csak közvetett módon tudjuk egy változó (vagy változók) állapotát ellenőrizni és az is rengeteg órajelet zabál fel, nagyon szar, hogy csak körülményesen tudunk a folyamatba beavatkozni.
„Így egyből inkább más libekkel próbálkoznék...” Miért? Működött.
Én közel 8 évig fejlesztettem Arduino keretrendszerben. Az utolsó 3 év már nagyon fájt, de egy projektet be kellett fejeznem. Borzalmasan megírt könyvtárak jellemzik az egészet. Elképesztően kotvány egyik-másik, és mivel nincs de facto szabvány arra vonatkozóan, hogy a perifériákat hogyan kell architektúrába rendezni, így ahány gyártó, annyi féle hardveres implementáció és ehhez képest még egy nagyságrenddel több könyvtár, ami a perifériát kezeli. Ezek 75%-ának nagyjából nem lenne szabad léteznie. A maradék 25%-ból is maximum 5% az, ami normális, következetes, rendszeresen karbantartott és viszonylag hibamentes. Ebből párat az Adafriut kalapált össze, de tőlük is láttam már eszelős kotványt.
Ha valami egyszer már működött, akkor nem a könyvtárral van a baj, hanem annak a kezelésével (nagyon kevés kivételtől eltekintve). Csináld végig rendesen a modulteszteket, és ha minden úgy megy, ahogy elképzelted, akkor rakd össze az egészet!
„Mivel egyébként is fejlesztő vagyok van elég egyébb tanulni valóm, csak akkor férne bele más, ha időben is eleget haladnék vele.” Hm. Mit fejlesztesz? Milyen környezetben?
köszi a segítséget, eskü, de egy picit csalódott vagyok, mivel :
- egy dátum kiiratása a 21. században az nem szabadna komplexitásnak lennie.
- setup részen ez már működött úgy, hogy a hónapot és a hét napját magyarul írta ki - oké ékezetek nélkül de tényleg működött a kiíratás, csak nem frissült napról - napra.
- csak annyi történt, hogy a loop ban néztem volna, hogy mikor frissüljön a dátum és ez most buktatja mindent ami kész volt.
- utána olvastam és amint Ti is írjátok a Serial.println on kívül nincs debug segítség ... hát ha ez a jó, milyen lehet a használhatatlan
Azt, hogy bújjam a libeket azt még átgondolom, hogy megér e ennyi időt egy ilyen probléma, én szégyelném magam, ha ilyen használhatatlan interface t adnák akármihez is, ha igen, akkor is csak 50 felkiáltójellel.
Még átolvasom részletesebben a tanácsaitokat és utána meglátom. Így egyből inkább más libekkel próbálkoznék ...
Mivel egyébként is fejlesztő vagyok van elég egyébb tanulni valóm, csak akkor férne bele más, ha időben is eleget haladnék vele.
Én még ennél is sokkal tovább egyszerűsíteném. A kijelző megjelenítését nagyon durván elbaltázott módon implementálták, szóval egy kezdő számára ez nem mélyvíz, hanem barlangi szabadtüdős búvárkodás.
Ennyi alapján senki élő ember nincs, aki megmondja. Helyette a debug eljárás:
1. kiszedsz minden szart belőle. Pl. nem tudom, hogy a 76. sorban az epd epd minek, amikor előzőleg a setupban már inicializáltad és nem úgy tűnik, hogy utóbb bárhol is leállítottad volna.
2. Csinálsz egy tök üres loop-ot, ami eddig a loopban volt, azt felviszed a setup végére delay() nélkül. Kiszeded az if-et, de az updateDateText()-et meghagyod.
3. A void updateDateText() és void drawText() függvényeket a Setup elé teszed mindenestül. Valószínű egyébként is le fog fordulni, de jobb a békesség. 4. A két függvény (mint előbb) minden második sorába írj be egy Serial.println("sorszám"); utasítást, benne a "sorszám" növekvő sorrendben. A Serial Monitor kiírása alapján tudni fogod, hogy hol hasal el a szoftver. Az A) eset alapján elvileg nem szabadna, mert minden lefut, amin az updateDateText()-ben van.
További javaslatok:
Ne a napváltást állítsd be arra, hogy frissítsen, hanem mondjuk ahogy @LyPapa nagyon helyesen megírta, indíts el egy számlálót és annak az értékét frissítsd a kijelzőn.
Ez egy g'ci komplikált program egy kezdőnek, gyakorlatilag a változómanipulálástól kezdve (itoa()) a kettős függvényhíváson át a komplikált, objektumszintű könyvtárkezelésig (now.day()) minden van benne, amit egy kezdő nem ért. Ennél azért számottevően egyszerűbb cuccokkal kellene kezdeni, mert a "gyári", sokszor retek módon megírt példaprogramokkal is folyamatosan el fogsz hasalni és a legkisebb változtatás is szétdobhatja az egészet és onnan felettébb nehéz felállni.
Ennek szellemében, ismét ahogy LyPapa írta nagyon helyesen, előbb meg kellene tanulni sorban:
-- hogyan kezeld az RTC-t, -- hogyan kezeld a soros vonali kiírást,
-- hogyan manipuláld a változókat (formátumváltás),
-- hogyan kezeld a eink kijelzőt.
Mindezt külön, nem egyszerre. Olvasd el és értsd meg az összes használt könyvtár (epd4in1, imagedata, epdpaint, RTClib) readme-jét.
Bocs, hogy belekotyogok, de ha jól látom a kódot, akkor van ott minden, ami egymásba akadhat ... Én azt tenném, hogy
1. Leválasztanám egyenként a komponenseket, és úgy tesztelném. Pl. az RTC helyett a loop-ban inkrementálnék egy számlálót, és másodpercnek tekintve kiírogatnám a kijelzőre. Ha elakad így is, akkor csak a soros vonalon, a monitorra , majd fordítva, azaz, a monitor kimarad, kijelző él.
2. Utána járnék, hogy melyik komponens mit is használ - legalább I/O port, interrupt szinten. Lehet, hogy bizonyos hívások esetén le kell valamelyik periféria működését állítanod, majd újra engedélyezned.
Persze: egyrészt, a 2x5 csatlakozót nem könnyebb összekötni az alaplap 2x3-as ICSP csatlakozójával, mint a kényelmesen hozzáférhető digitális/analóg pinekkel (pl. mert kevés a hely). Azóta egyébként próbáltam azt is, ugyanúgy nem működik, ugyanaz a hibaüzenet, máshol lesz a gond, nem a zsinórozásnál.
Másrészt erre a bizonytalan projektre nem akarok költeni, (nyilván egy 2x5 -> 2x3 átalakító nem a világ, de ez elvi kérdés) amíg nem látom, hogy feltámasztható a dolog, tényleg nincs más baja az alaplapnak azóta, mióta felkerült rá a blinking progi.
Biztos, hogy rossz a kábelezés. Azt eleve nem értem, hogy miért az "élet nem annyira egyszerű" forgatókönyvet tolod. Van rá bármi okod, hogy ne a hardveres soros vonalat használd?
Adott egy olcsó kínai arduino uno klón (Wavgat uno r3). Sajnos az USB csatlakozója tönkrement. Még az USB utolsó lehelletével fel lett telepítve az IDE működéséhez szükséges driver és alaplap . A Blink próbasketch is felment rá, most is az fut, ha bekapcsolom, tehát amúgy működőképes az alaplap.
Van egy USBASP programmerem (ATMEGA8A), jól feltepítve, device manager ismeri - de, hogy az élet ne legyen olyan egyszerű, 2x5 csatlakozóval, szóval nem tudom direkt a klón ICSP-jére kötni, hanem az analóg/digitális interface-ek pinjein keresztül madzagoltam össze, ez alapján: https://www.arduino.cc/en/tutorial/arduinoISP.
Programmer:"USBASP", File menu: "Upload using programmer", alaplapnak kiválasztva a Wavgat.
Próbálok feltölteni rá programot, de állandóan leragad az "Uploading..." státuszban. Nem is tölt föl a program. Hibaüzenet:
java.lang.NullPointerException at cc.arduino.packages.uploaders.SerialUploader.uploadUsingProgrammer(SerialUploader.java:295) at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:90) at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77) at processing.app.SketchController.upload(SketchController.java:732) at processing.app.SketchController.exportApplet(SketchController.java:703) at processing.app.Editor$UploadHandler.run(Editor.java:2075) at java.lang.Thread.run(Thread.java:748)
Bármilyen ötletnek örülnék, mert kidobni nincs szívem, hiszen működne az alaplap - de már kezdem feladni.
udvözlök mindenkit! surgös segitsegre van szuksegem, taviranyito kodjat szeretnem kiolvasni, program van, felvan töltve,a programban atirtam a HEX helyett DEC, viszont a soros monitoron csak kerdöjelek meg negyszögek stb. jelennek meg,mit tegyek? egyeb mas programnal is ez a helyzet
