Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Én fájlokra szoktam szétszedni a programom, pl. külön fájl a kijelző kezelésnek, a hardware-es résznek, a setup-ban lefutó, egyszeri beállítások, az általános fv-ek, a menürendszer, a fix szövegek, a rengeteg változó, ez is szétszortírozva, felhasználó által változtatható és csak a programozás előtt változtathatóra (finomhangolás), interruptok, ha vannak, stb. Így átlátható marad a projekt. Arra kell figyelni, hogy ne includold be a fájlt, mert minden .ino fájl, ami egy könyvtárban van a fő programoddal, automatikusan a programodhoz fűződik (utána, a végétől kezdődően!). Tehát azok a dolgok, amiknek a program elején kell lenniük, trükkösen kell megoldani: a .ino fájlt egy mappával feljebb kell elhelyezni, mint a főprogram, és azt már inclidolni kell! Tehát a definíciók, a változók mind ide kerülnek. Idegesítő egy rendszer, de ez van... Ja, és a füleknek rövid nevet kell adni, mert kb. 10 fül fölött az utolsókat már nehézkes elérni (legördülő menüből kell kiválasztani).
Mert normális arduino projectben csak egy *.ino kiterjesztésű fájl van.
A többi *.h, *.c, *.cpp lehetne. Most hirtelen azt sem lehet tudni, hogy melyik *.ino-dat kel elindítani? Legalább a könyvtárad neve azonos lenne a főprogramodéval! És ahogyan fejlesztik az arduino IDEt, lehet, hogy a következő verzióban ezeket visszafogja dobálni, hibajelzésekkel. Mivel teljesen szabálytalanok! A hozzászólás módosítva: Ápr 27, 2019
Idézet: „trükkösen kell megoldani: a .ino fájlt egy mappával feljebb kell elhelyezni, mint a főprogram, és azt már inclidolni kell!” Ezzel megint gondok fognak adódni, ha kétszer fogja meghívni az *.ino-ját! Inkább tanuljon meg rögtön szabványos header állományt készíteni! Hiszen állítólag a tanulás a célja? A hozzászólás módosítva: Ápr 27, 2019
Nálam azonos nevű a könyvtárral, csak a gitre tettem recycledbe, mert csak itt akartam megmutatni. Az ino fájlokat nem tudtam, hogy át kellene neveznem, legközelebb úgy lesz. Ezt, hogy mit érdemes külön tenni még nem tudom csak a funktions is jóval nagyobb lett, mint az első verzió, ahol azért szedtem szét, mert sokat kellett görgetni. No majd átszervezem
Ezzel megint az a bajom, hogy a gyakorlatlanságom miatt még nem tudom, hogy mit érdemes headerbe írni és miért pont azt? Sajnos ilyen nyakatekert vagyok, sokat teszem fel azt a kérdést, hogy: Miért? Néha észreveszem magam, olyankor hallgatok, de okosabb nem leszek ha nem értem a miértjét! Nézd el nekem ha sokat kérdezek! Olvasok németül/angolul, de ezt (a logikáját és nem azt, hogy hogyan) nem találtam még sehol. Kéne valami for dummies könyvet néznem, hátha benne van
Hirtelen a mindig kéznél levő könyvem: Bővebben: Link
Bár ez inkább PCs alkalmazásokról szól! De minden lényeges dolgot megtalálsz benne, ami a C-ben szabvány. A hozzászólás módosítva: Ápr 27, 2019
Én is ezt csinálom. Ha nem lenne "szabályos", nem adna rá lehetőséget az IDE. Maximum nem megszokott. Sokkal áttekinthetőbb a kód.
A hozzászólás módosítva: Ápr 27, 2019
Rengeteg szabadság volt az 1.5xx IDE-k előtt, Amikre az 1.8xx IDE-k már hibát dobnak.
És volt is rengeteg értetlenkedés, hogy miért nincsen visszafelé kompatibilitás? Pedig csak a fejlődés hozta magával a jobb hiba ellenőrzést.
Elöző link:
Idézet: „4.11.1. Állományok beépítése Az állománybeépítés egyszerű lehetőséget kínál a #define utasítással létrehozott definíciókból, deklarációkból és más elemekből összeállított részek kezelésére. A programban bárhol előforduló #include "állománynév" vagy #include <állománynév> alakú programsor a fordítás során kicserélődik a megadott nevű állomány tartalmával. Ha az állománynév idézőjelek között volt, akkor az adott állomány keresése ott kezdődik, ahol a rendszer a forrásprogramot megtalálta. Ha a keresett állomány ott nem található vagy a nevét csúcsos zárójelek között adtuk meg, akkor a keresés egy géptől és rendszertől függő szabály szerint állományról állományra folytatódik. Az így beépített állomány maga is tartalmazhat #include sorokat. Gyakran több #include sor van a forrásállomány elején, amely az egész program számára közös #define utasításokat és a külső változók extern deklarációit tartalmazó állományokat vagy a könyvtári függvények prototípus-deklarációihoz való hozzáférést lehetővé tevő header állományokat (mint pl. az <stdio.h>) építi be a programba. (Szigorúan véve a headerek nem szükségképpen állományok, a kezelésük módja géptől és rendszertől függ.) Az #include nagy programok deklarációinak összefogására használható előnyösen. Alkalmazásával garantálható, hogy minden forrásállomány azonos definíciókat és változódeklarációkat használ, amivel kizárható néhány nagyon csúnya hiba. Természetesen, ha egy beépített állományt megváltoztatunk, akkor az összes azt felhasználó állományt újra kell fordítani.”
Ezt még átrágom párszor
Még nem látom, hogy a jelen projektben mit lenne érdemes kiszervezni xy.h-ba... Lehet, hogy ehhez több tapasztalat kell... A többi dologra meg odafigyelek legközelebb (ezt is megpróbálom rendbe tenni)!
Inkább kapjanak sorszámozás a könyvtáraid pl.:
Spotwelder.001, Spotwelder.002 A bennük levő tartalom rögtön fordítható, és jól látod a fejlődési sorrendet is. A hozzászólás módosítva: Ápr 27, 2019
A baj, hogy nem mentettem külön-külön, hanem ugyan abban a könyvtárban dolgoztam végig, így nincs korábbi visszalépésre lehetőség a Ctrl-Z-n kívül. Jó lett volna lépésről lépésre dokumentálni, hogy mit miért csináltam, itt is megígértem, hogy majd feltöltöm, de elkapott a gépszíj és most már késő, mert be is zártam már egyszer amikor a háttérben az új kernel frissült a rendszeren és úgy gondoltam, hogy itt az idő újra indítani a gépem
 Mindegy már. Szerettem volna magyarázatokat olyanoktól akik tényleg értenek hozzá, de már a konkrét kérdéseket sem tudom amióta működik
Igazad van. de az Arduinonál nem a szabvány headerrel van gond, hanem alapból az include el van rontva. Próbáld ki, ha gondolod. Készíts egy main.ino-t, legyen ez a fájl mellett, mappán belül a header fájlod, meg egy másik, amit majd használni akarsz. Includold be, ahogy kell, a főprogram elején mindkettőt. Nem fog menni, mert hibát jelez: a fájlok kétszer vannak include-olva, mert az Arduino automatikusan, a főprogram mappájában levő összes fájlt a főprogram után (!!!) fűzi! Akkor van gond, ha a fájl tartalmának a főprogram elején kellene lennie (mint pl. egy nagy tömb, amivel később dolgozni fogsz).
Ha a szabványos header fájlod olyan, hogy megvizsgálja, be lett-e már töltve, akkor nem fog hibát dobni. Viszont most elgondolkodtam. Lehetséges, hogy az Arduino a fájlok kiterjesztése szerint kiválogatja, hogy mit tölt be a program legelején és mit a legvégén? Abban biztos vagyok, hogy a lapfüleken levő fájlokat, .ino kiterjesztéssel a főprogram vége után fűzi, erre találtam is utalást. De minden egyéb titok, nem szerepel sehol, nincs dokumentálva, de szinte biztos, hogy bonyodalmakat okoz, mire rájön az ember, mit hogyan. A hozzászólás módosítva: Ápr 27, 2019
Első teszt:
megnyitottam a blink-et, elmentettem az asztalra main.ino néven. Total commanderrel készítettem mellé egy prog.c-t, és egy prog.h-t (a fájlok üresek). Bezártam az Arduinot, majd megnyitottam az asztalról a main.ino-t, és mi történt? Megjelent két új lapfül a main mellett: prog.c, prog.h. Mikor én nem is változtattam a main-on, tehát az alap blink-et tartalmazza! Ha lefordítom a main-t, belefordítódik mindkét prog fájl, kérdés nélkül (a prog.c-be beírtam ezt: volatile long tomb[100][30];, és azonnal panaszkodott az Arduino, hogy kevés memória marad). Ha beírom a main.h elejébe, hogy #include "prog.c", akkor nem dob hibaüzenetet! Ha ugyanezt eljátszom egy prog.ino fájllal, ez is automatikusan megjelenik lapfülként (újraindítás után), és be is másolódik a főprogramba. Viszont ha beírom a main-be ezt: #include "prog.ino" vagy <>-zel, akkor jön a hibaüzenet: nem találja a fájlt! Viszont ha teljes elérési úttal írom be: #include "C:\Users\david\Desktop\ardu\main\prog.ino" , akkor pedig megkapom a "error: redefinition of 'volatile long int tomb [100][30]'". Tehát sikerült az include-olás, viszont ez már a második! Itt lehet kitérni arra, hogy melyik megoldásnál hova lesz a main-en belül a program bemásolva: ahol inculde-olom, ott abba a sorba, ahol nem pedig nem include-olok, és automatikusan teszi az IDE helyettem, ott pedig a főprogram végétől kezdve. Pl. ha a prog.c-be beírom, hogy char eszek; akkor main-ben, a loopban nem fogom a változót látni, mivel a változó csak a loop után kerül deklarálásra! Ha a program elejére bekerül a #include "prog.c", ami tartalmazza a char eszek;-t, akkor lefut a program, látja a loop az eszek változót, és nem jön semmi hibajelzés sem. Ilyen egy *** rendszert. Hogy lehet ennyire átláthatatlan??? A hozzászólás módosítva: Ápr 27, 2019
Hali!
Hányas verziójó arduinót használsz? Nekem is volt olyan régebben, hogy még a további alkönyvtárakban lévő cuccost is automatikusan befordította, aztán módodsítottak, és már nem fordult le a projektem, meg kellett szüntetnem a további alkönyvtárakat. Mostanában nncs bajom vele, lehet mert "szabályosan" csinálom? A projekt mappában nem tartok semmilyen "nem odavaló" C-val kapcsolatos fáljt, az esetleges régebbi/mentett verziót külön alkönyvtárban tartok, az esetleges átmeneti/próba dolgokat ( a projekt mappában) átnevezem *.ino_ *.cpp_ stb, így nem akarja használni...
1.8.8-at használok. Reméltem, hogy kijavítják ezt valami logikusabbra, ezért frissítettem régebben, de nem hozott változást. Legalább le lenne dokumentálva, de szerintem az IDE készítői sem látják át, mikor mi történik.
h fájlt nem szabad header guard nélkül használni. Ez alapszabály C és C++ nyelveken.
Az Arduino pedig sima C++ nyelven írt könyvtárak gyűjteménye, amik AVR architektúra esetén az AVR libC könyvtárakon keresztül érik el a hardvert. Az egészet a GCC fordító fordítja le.
Header guard nem sokat segít, maximum a dupla include-olást akadályozza meg (elrejti a hibát, mert nem veszed észre, hogy az IDE, önállósodva, már beinclude-olta a fájlt valahol (a megkérdezésem nélkül). Hogy hova, és mi kerül beillesztésre az nem egyértelmű.
Egy saját programban az include-olás a legegyszerűbb, sima hivatkozás. Nem tudom, hol van erre a header guardra szükség. Ismerem, de ha valami kétszer lesz beinclude-olva, akkor ott a program hibás. A hozzászólás módosítva: Ápr 27, 2019
Hello!
Szűrni szeretném json fájl tartalmát pl value de nem sikerül hiába a minta példa soros porton át jön a json teljes tartalma!
Helló!
A payload változóban eltárolódik rendesen minden? Belefér ennyi adat?
Sziasztok!
Van egy 2D plotter aminek már elkészítettem a vázát, tehát mechanikailag, de a programban némi gondom akadt... Az arduinó kód megvan, meg a hozzátartozó GCTRL is, viszont azt nem tudja beolvasni a processing IDE nevű program..valakinek van valami ötlete? Előre is köszönöm!
Hát ennyi konkrétum alapján max. annyit lehet mondani, hogy valami nem OK...
Kérdezem én is mi a gond!
Hány byte az a json amit feldolgoznál?
Mert az arduino memóriája véges, sőt. Bővebben: Link
Ha a kodod jó, akkor érdemes lenne fele ekkora vagy meg kisebb méretű fájlal kipróbálni. Nehogy az legyen a gond hogy nem fér bele. Illetve nézz utána, hogy a String mekkora adatot tud meg egyben kezelni!!! Ha az sem segít akkor megnézni hogy a Jason fájl milyen karakter kódolású. Ha nem ASCII hanem mondjuk utf8 akkor gond lesz. A másik meg hogy a Jason fájlban mik a soremeles karakterek. Próbáld ki sokkal kissebb fájlal, és küld vissza a soros monitorra hogy lásd tényleg azt kapta amit kell. Ha nem akkor ott a gond. Ha igen akkor a korban van valahol de azt nem látom.
A karakter szűrés egyáltalán nem működik pl csak a value értékre 4..5 soros json sem mert átjön soroson a teljes tatalom!
Ezt használom Bővebben: Link
Tedd közzé azt a Jason fájlt amiben van robot value. Én a value-t nem találom a fentiben.
Szerintem ott a gond hogy elküldi a fájlt, azonban nem adod meg neki hogy melyik rekordbol kéred a value-t. Olyan nincs hogy value rekord. Szenzorok az van amiben több szenzor is van amiknek külön van value bejegyzése.
Azaz ki kell szedni a megfelelő helyről mint a példa kódban. Robot senzors. Ok ez azt mondja meg hogy a nagy fajlbol a szenzorokat tartalmazó adatokra van szükséged. Ezután még kell mondani neki hogy ezek közül a humiditi adatai kellenek abból is a value nevezetu. Ezek tömbök amik több dimenziósak.
|
Bejelentkezés
Hirdetés |
