Szeretnék kommmunikációt létrehozni 3 arduino között. Mind a három Mega panel, ebből kettő mér és számol, míg a harmadik csak a mért jeleket fogadja, és USB-n keresztül egy PC-re juttatja, ahol egy Labview várja az érkező adatokat. I2C -vel szerettem volna megoldani a kommunikációt, de olvastam, hogy kötött a távolság a két alaplap között (kb 6 m) nekem az egyik adó és fogadó között kb 4m van a másiktól pedig 25m-re. Mit javasoltok, hogy a mért adatok eljussanak?Vezeték nélküli kommunikáció nem játszik, mivel a Megán nincs szabad digitális lábam.
Én egy wifi mérleget építettem ilyen megoldással. Először egy ESP olvasta ki (port bővítővel) a mérleg eredeti kijelzőjét és küldte az adatot a mysql szervernek, majd elaludt. De se LUA, se Arduino nem tudta elaltatni rendesen az ESP-t, így pár nap alatt mindig kimerült. Most egy Nano olvas, majd villanyt ad az ESP-nek, az elkéri az adatot a Nanotól, és ha jelzi, hogy kiment a szerverre, akkor a Nano újra lekapcsolja. Így 2-3 hónapig is elmegy egy 9V-os elemről (vagyis mostmár 2 LiIon celláról).
Szerintem is jó ötlet megosztani a feladatokat több mikrokontroller között, főleg, hogy ma már párszáz forintból meg lehet venni darabját.
Több MC együtt. Amikor csináltam az időjárásállomásom (ESP8266-ra), egy angol srác kommentelt be egy olyant, hogy ő energiatakarékossági okból a szélmérésre egy ATTINY85-öt használ, az esp alszik és csak akkor ébred amikor adatküldés van. Szóval teljesen természetes, hogy a feladatokat szétszórjuk akár több kontroller között. Nálam 230V-ról megy, szóval én ezzel nem tököltem, de akksi/elem üzemidőn nagyon sokat javított. Bővebben
Analóg kérdés. Lehet valamit félreértettem, de lehet a kérdező nem érti, hogy vannak analóg és vannak digitális adat kezelésre alkalmas portok? Rá is van szitázva a board-ra, hogy ANALOG IN, és többnyire A... kezdetű a láb jelölése.
Köszi. Ez alap, épp csak a számok nem stimmeltek (én Mega2560-at néztem, mert az eredeti hozzászólásban az volt, te meg az UNO-t). Erre a témakörre írtam válaszul az eredeti kérdés felvetőjének, hogy bármit is csinál, azt csinálja következetesen, különben előbb-utóbb bajok lesznek.
> Viszont ezt a portmegfeleltetés dolgot, kezdve az Ez egyébként az MCU Port C 4-es lába. nem egészen értem. Vagy más dokumentációt nézünk vagy az én figyelmemet kerülte el valami.
Több hozzászólásodat összefoglalva néhány észrevétel.
1. Egy ilyen bonyolultságú rendszert nem 2-3 hét, hanem alsó hangon 2-3 hónap alatt lehet összerakni, és még akkor is benne van a taposóakna a tekintetben, hogy az Arduino keretrendszer alapvetően prototipizálásra, tanulásra, tanításra való.
2. Feladatmegoldás legalább annyi potenciális problémát rejt, mint amennyit megold és nem vagyok benne biztos, hogy amit a vámon megnyersz, azt a réven nem bukod el.
3. Ami a megvalósíthatóságot illeti. Azzal kezdtél itt kb. 2 hónapja, hogy egy ventilátort és valami kis visszajelzőt szeretnél egyszerű menüvel, órával és két gombbal. A mostani hozzászólásodban írt felsorolás ennek kb. a tízszerese. Ahogy a ventilátorokra és a kijelzőre még sok is a Mikro/Nano, úgy egy ennyire komplex feladatra (pláne a gesztusvezérlés) már nem feltétlenül az Arduino a helyes válasz. Itt egy picit nagyobb, jóval erősebb alternatíva, itt egy másik, ami már számottevően nagyobb, úgyszintén erősebb. Ebbe 4 hetes határidőre napi 16 óra szabadidővel nem kezdenék hozzá.
4. Pár javaslat a tételes listára (amit nem memeltem ki, azt vagy nem értem vagy nem tudok rá érdemi javaslatot tenni):
- 5-6 led csoportot vezérelni PWM-el (fényerő és gesztusok alapján)
- 2 venti csoport vezérlése (pára és hő alapján)
- programozható RGB ledek, melyek gesztusra reagálnak
TLC5940. Komoly támogatása van, kő egyszerű, mindenütt kapni gombokért.
- digitális óra
Bármelyik RTC (DS3231 párti vagyok, ugyan nagyobb, de számottevően pontosabb).
- pára + főfok (több)
Ilyenből számos van. Ha nem kell nagy pontosság, akkor DHT11.
- mágneses hall (jelmez szájának detektálása)
A hall szenzor tudomásomo szerint csak mágneses lehet, viszont bináris (konkrétan impulzust érzékel). Amire te gondolsz és a feladatra jóval alkalmasabb, az egy potméter.
- fényérzékelők (több)
Alap esetben fényérzékelőnként egy analóg bemenet.
Több megoldás van, mindegyiknek van előnye és hátránya. Meg kellene határozni, hogy hol vannak azérzékelők, mekkora látótérrel rendelkezzenek, milyen széles dinamikatartományban kell érdemleges információt szolgáltatniuk.
- mikrókapcsolók (pl. orr megnyomása, orrnyereg simogatásának érzékelésére, stb.)
A mikrokapcsoló nyomást érzékel, határozottan be kell nyomni, hogy működjön (tactile feedback). Nem biztos, hogy jó, ha egy farkasnak nyomásra kattog az orra [az enyém egy sportbaleset miatt 24 éve kattogott, amikor orrot fújtam és nagyon szar volt]. Erre vannak egyéb érzékelők (felületi érintés stb.), nézz körül a kapacitív érintésérzékelők háza táján.
- fej tartása: giroszkóp (bár itt nagyon mozdulatsorokat kéne valahogy felismerni, de még nem tudom hogyan)
MIT vagy Boston Dinamics (ami nagyjából MIT). Magyarul: szerintem ez már kevésbé egy Nano/Mikro kategóriája, sőt, ilyen szintű mikrokontrollerek kategóriája.
Giroszkópra: MPU6050, paraméterezés alapján feldolgozott adatsort küld, vagyis a mikrokontroller kész adatot kap, nem kell számolnia.
Viszont ezt a portmegfeleltetés dolgot, kezdve az „Ez egyébként az MCU Port C 4-es lába.” nem egészen értem. Vagy más dokumentációt nézünk vagy az én figyelmemet kerülte el valami.
Ugyanakkor az praktikus lenne, ha következetességre törekednénk a tanácsok formáját illetően. Mert ezzel a kommenttel most engem is jelentősen megkevertél, ehhez képest egy kezdő a sűrű sötét nagy erdő frusztrációt élheti át.
Annyiban kiegészíteném a dolgot, egyúttal hálás köszönetemet tolmácsolva Vargham felé, hogy a kását nem feltétlen eszik ilyen forrón. Ha szigorúan a keretrendszeren belül gondolkodsz (a leírások, minták zöme erre alapul), akkor jobb egy következetes „nevezéktant” választani, és ennek megfelelően írni meg minden kódot. A legtöbb mikrokontrolleres fejlesztői környezet engedi, hogy a lábakra több módon is hivatkozz (sőt, közvetlen utasítással is lehet kapcsolgatni a lábakat), a lényeg, hogy ne keverd ezeket a megoldásokat egy kódon belül. A #define egy lehetséges mód erre, a const int egy másik. De a kettő nem csereszabatos egymással (gépi kód szinten más a megfeleltetésük.
Egy ábra az Arduino Mega 2560 lábkiosztásának „nevezéktanáról”:
És hogy mindezt miért ilyen hosszan: kódrészlet alapján nem lehet (pontosabban nehéz) hibát keresni.
Akkor érdeme ebben gondolkozni ha előre szeretnék menekülni.
És így látatlanban tetszik az a megoldás amit mondtak, hogy inkább port bővítés helyett kontrollert tegyek, mert akkor annyi plusz haszna is, van, hogy rész feladatokat is tud ellátni esetleg magától.
Nálam az a gond, hogy az elektronikát le kéne zárni SOS-ben, és sajna ha a jelmez le van szőrözve már nem igazán alakítható, mer úgy is megsérül.
Persze most minden egység úgy van kialakítva az alap hordozó worblából (há hatására gyúrható mint a gyurma), hogy minde egység kivehető, cserélhető legyen.
De később pákával nem akar az ember olvaszthatni az alap vázon.
Tehát ezért próbálom úgy megoldani a kis helyen azt, hogy inkább ne legyen minden erőforrás kihasználva mintsem kevés legyen.
Adafruit 128x64-es mini demo. (ami benne van a LIB demok között)
Program memória 75%, és ram is eléggé megzabálva fordítás után.
Azt kaptam másoktól, hogy sok a karakterkészlet, a szükséges buffrer, és stb az ilyen kijelzőnél.. És azért nem az igazi ilyen kis nanon az ilyen kijelző.
128x32-es oled esetén ugyanez 55% körül van.
De mondjatok akkor valamit ha itt félreértés van, és símán bele tudnék férni a nano 32/2Kb-os memóriájába.
> Tehát erre kaptam, ha mindent egybe akarok, akkor lehet meg fogom szívni, és lehet a 16Mhz is kevéske lesz a végén.
A projekt, amin dolgozom (nem hobby, hanem munkahelyi munka), úgy indult három éve, hogy egy ATmega2560 és akkor belefér minden. Most ott tartunk, hogy csak a fő program fut benne, MINDEN periféria saját mikrokontrollert kapott. (Ezek aztán soros porton meg CAN buszon beszélgetnek egymással.) Egész egyszerűen összeakadtak egymással az időzítések, sehogy sem működött minden egyszerre egy MCU-n, hiába lett volna rá képes papíron.
Nem értem teljesen. Minek eszi meg pontosan a 75%-át? Milyen memóriából foglal el 75%-kot? és ezt pontosan hogy nézted meg?
Egy kijelzővezérlés nagyon nem csinál ilyesmit...... Főleg nem egy I2C-n kiküldött adatcsomagos verzió. Vagy maga a program rossz, ami nem mást csinál, mint állandóan a kijelzővel foglalkozik...........
Maga a kijelző az I2C-ne kommunikál, de mondjuk egy alap adafruit demó amivel ellenőriztem hogy nem -e hibás az 75% memóriát megeszik. És akkor hol lesz mag a program?
Vagy hogy érted a másként az I2C-t?
De jó hallani, hogy nem feltétlen elvetendő ötlet a több eszközös.
Itt maga a mega esélytelen lenne, hogy beférjen, mert egy jelmez fejében lenne.
Csak ez a neten pár helyen található tömörített mini (Mega2560 R3 Pro Mini) talán amit nagyon be lehetne erőltetni, de erre kaptam, hogy lenne több port, meg több memória, de a feladat miatt lehetne gondjaim, ha mindent egy egységgel akarok megoldani:
A feladat:
- 5-6 led csoportot vezérelni PWM-el (fényerő és gesztusok alapján)
- 2 venti csoport vezérlése (pára és hő alapján)
- mp3 lejátszó vezérlése gesztusok alapján (soros bezérlésű)
- programozható RGB ledek, melyek gesztusra reagálnak
- digitális óra
- eeprom kiegészítő tárhely
- PC monitor szerű menü a menet közbeni konfiguráláshoz 2 nyomógombbal és 128x64-es oled kijelzővel
- lehet FB rádiót is le lesz.
- később a fület is jó lenne mozgatni, de ott nagy hely a motor, meg hangos is (sajna műizmot meg nem találtam még :( )
A gesztusok és a környezett miatt lesz számos:
- pára
- főfok (több)
- giroszkóp (lehet nem csak a fejben, hanem később a kézben is)
- mágneses hall (jelmez szájának detektálása)
- fényérzékelők (több)
- mikrókapcsolók (pl. orr megnyomása, orrnyereg simogatásának érzékelésére, stb.)
Gesztusok:
- fej tartása: giroszkóp (bár itt nagyon mozdulatsorokat kéne valahogy felismerni, de még nem tudom hogyan)
- száj nyitottsága (analog hall)
- orr megnyomás
- orrnyereg megnyomása
- lehet a kezek vagy máson is lennének nyomógombok, hall vagy giroszkóp.
Tehát erre kaptam, ha mindent egybe akarok, akkor lehet meg fogom szívni, és lehet a 16Mhz is kevéske lesz a végén.
Ha te már ilyesmikkel dolgozol, akkor mi a meglátásod? Valóban nem biztos, hogy egy pl.: Mega2560 R3 Pro Mini a legjobb megoldás? Sajna a HW részt le kell zárni, és ezen minit pl. nem is tudom időre beszerezni. (nem találtam senkit, aki pl. megválna egytől.)
A kommunikációról több arduino vagy más vezérlő kötöttről van valamilyen jó forrásod?
Ha csak a kijelzőt kell vezérelni külön a sok erőforrás miatt, akkor nem megoldás azt rádobni az I2C buszra?
Én most csinálok egy olyan cuccot, amiben van 50 db bemenet, és azt egy külön mega fogja lekezelni, majd az állapotváltozásokat átküldi a masternek. Persze ennél komplikáltabb de a lényeg kb ez.
Több ADUINO-n osztott feladatmegosztást próbált már valaki?
Kaptam olyan tanácsot, hogy egy összetettebb feladatot nem biztos, hogy érdemes egy nagyobb HW-ba (pl.: Mega2560 R3 Pro Mini) egybe tömöríteni (az meg egy másik, hogy nincs is hely, ezért most egy NANO van csak tervezve), mert akadásokba és ütközésekbe futhatok bele.
Inkább több egység között osszam meg a feladatokat.
Erről van valakinek tapasztalata?
A konkrét tanács az volt, hogy I2C-n a nano-hoz kössek egy pro minit. Az kezelje a kijelzőt vagy pár kisebb feladatot. (ugye a 128x64-es oled meghajtás nagyon sok erőforrást vesz ki már önmagában is, és félő a fő feladatra nem marad semmi helye.)
Vagy inkább a Nano helyett egy ESP32 D1 mini-t használjak. (bár nem tudom, hogy az mennyire szerencsés ha a fejemnél egy WI-FI antenna van). Így fő feladatnak ott egy gyors egység, a mellek dolgoknak meg a pro mini (vagy a nano), ami plusz portokat jelent analog és PWM terén. (és több haszna van, mintha csak buta portbővítés lenne)
Az lehet, de esetünkben nem (csak) a végeredmény számít, hanem maga az építés öröme, a tudat, hogy az én két kezem és agyam szülötte a dolog. Az már csak hab a tortán, hogy egy ilyen kütyüt már olcsóbban is össze lehet rakni, persze ha a belefektetett munkát néznénk, akkor tényleg nem érdemes nekiállni. De a példáknál maradva hegyet mászni sem kéne, hisz fel lehet jutni helikopterrel is, nem beszélve a legóról, vagy egy kirakóról.
Ha távolabbra tekintesz, minden óra küzdelem később megtérülhet egy másik projektben, amit már rutinból csinál az ember, ha meg csak hobbiból épít, szerintem akkor is inkább ez, mint a TV-t bámulni esténként. Főleg, amilyen műsorok mennek mostanában...
Például: klíma ON, hűtés üzemmód, setpoint: 23fok, beltéri venti 3-as fokozat, függőleges terelőlapátok swing üzemmód, vízszintes lapátok 4-es pozició, kültéri halk üzemmód, netán távirányítóban mért hőmérséklet, és további ilyenek vannak benne...
Mivel típusfüggő, hackelhet rendesen. Általában 30 vagy 38 byte, 4 bites crc-k...
> A #define poti 4 nem az analóg 4-es lábat fogja hivatkozásként megadni, hanem a digitális 4-es lábat
Nem.
A #define poti 4-nek semmi más hatás nincs, mint hogy a preprocessor a fordítás ELŐTT a poti string MINDEN előfordulását kicseréli 4-re. A #define-ban definiált nevek és értékek NEM részei a programnak. Úgy kell rá tekinteni, mint egy search/replace-re.
Tehát az analogRead(poti); ki lesz cserélve még a fordítás ELŐTT arra, hogy analogRead(4);
Ez egyébként az MCU Port C 4-es lába.
A háttérben az Arduino keret alapértelmezetten analóg bemenetként inicializálja ezeket a lábakat, ezért nem kell a setup()-ban ezt megtenni.
Azonban ezeket a lábakat is lehet normál GPIO-ként kezelni. Elég betenni a setup()-ba: pinMode(18, INPUT); Innentől kezdve az A4 sima digitális bemenetként működik. Ugyanígy megy a pinMode(18, OUTPUT); is.
Az Arduino UNO-nál például 14-et kell hozzáadni. De ahogy látom az újabb IDE-ben már a pinMode(A4, OUTPUT); is működik.
Honnan tudod, hogy nem olvassa az egész kódot? A legtöbb utasítás maximum 3-4 hexa-csomag, illetve ezeknek az ismétlődése, ha folyamatosan nyomod a gombot.
A #define poti 4 nem az analóg 4-es lábat fogja hivatkozásként megadni, hanem a digitális 4-es lábat (és praktikusabb D4-két hivatkozni rá). A jó(bb) megoldás a #define poti A4. Számos módja van, hogy a lábakat címezd, de a 4-es lábból soha nem lesz analóg (bemenet).
A ki/bemenet deklarálás úgy, ahogy az olvtárs megírta.
