Látom, hogy van billentyűzeted valamilyen formában.
Menü alapelv:
-- gombfigyelés, ha van gombnyomás,
-- gombvizsgálat (melyik gomb lett lenyomva), ennek megfelelően:
-- adott paraméter(ek) átállítása (szintén gombfigyeléssel), majd:
-- visszalépés a főmenübe.
Ez nyilván vizsgálatok sorozatát jelenti, amiből a fő gombvizsgálatnak a fő loop-on belül kell megtörténnie, mégpedig elég sűrűn (pontosabban nagyjából folyamatosan). Mivel az arduino kissé béna megszakításkezelésben, én inkább kezdésre a sima "van-e gombnyomás" vizsgálatot javaslom. Erre van számos példa az arduino fórumon, illetve a tudástárban. A kód jelentős része egyébként megvan az általad küldött mintában, onnan kiszedve (lényegében egy másik függvényt írva) meg lehet csinálni azt, hogy az adott relét válaszd ki. Attól függően, hogy mit és hogyan akarsz állítani, én egy sima fa-struktúrájú menüt csinálnék (főmenü, utána 1-2-3-4 relé kiválasztása, azon belül értékállítás, jóváhagyás, vissza).
Javaslom a switch/case algoritmus beható vizsgálatát. Ilyen esetekben roppant hasznos megoldás.
// ez lesz a változód, aminek adsz valami értéket (ezt fogod átadni a függvénynek):
int valtozo = ertek;
// itt hívod meg a függvényt:
fuggveny(valtozo);
}
void fuggveny(int x)
{
// ez a függvény törzs, amit hívsz, amiben a void loop() valtozo változója x-ként reinkarnálódott
}
Tehát. Van egy függvényed (a példában ez a relaysecBe_settting függvény), amit úgy tudsz meghívni, hogy a fő programrészből csak a nevére és a paramétereire hivatkozol:
relaysecBe_settting(relayNum);. Ha a függvény nem kér vagy nem akarsz paramétert átadni, akkor a zárójel üresen marad, ha paramétert akarsz átadni, akkor azt a zárójelbe írod be. A függvény egy külön szakasz, ami úgyszintén void-dal kezdődik és a függvény neve után jönnek a függvényhez használandó paraméterek változó deklarációi. Az uint_8 a változó típusa, a byte megfelelője. A lényeg, hogy amit átadsz változót (a fenti példában a valtozo) és ami a paraméterlistában van, azonos típusú kell legyen, vagyis bool, int, unsigned int, long, unsigned long, float stb., lásd Arduino.cc fórumok.
uint8_t relayNum;
Ez egy változó deklarálás a változó értékének megadása nélkül. Ha a void loop()-on belül van, akkor csak ott fog élni, ha az egész hóbelevanc elejére, közvetlenül a könyvtárhívások után teszed, akkor globális változó lesz, minden függvény használni fogja (nem kell vesződni a paraméterátadással).
relayNum = 0; //0...3
Ez a változó értékadása. Ezt te választod meg és/vagy maga a szoftver állítja (pl. menüből, véletlenszerűen stb.). A loop-on belül bárhol lehet (illetve ha relayNum globális változóként lett deklarálva, akkor az egész cuccon belül bárhol lehet értékadás).
relaysecBe_settting(relayNum); << ide kerül a relé száma 0 ... 3
Ez maga a függvény hívás. Mindenképp az után legyen, hogy a relayNum-nak értéket adtál (eggyel ezelőtti sor), ellenkező esetben az lesz, hogy egy memóriából véletlenszerűen kapott számot fog hozzárendelni, aminek lehetnek nem várt káros következményei (javaslom, hogy az alapérték már a deklarációkor egy olyan szám legyen, amihez nem tartozik konkrét művelet, tehát ha 4 relé van, 0-tól 3-ig, akkor 4-et hozzárendelni). Szóval, ez a függvényhívás lehet szintén a loop-ban nagyjából bárhol, ahol értelme van (végre akarod hajtani a függvényben található utasításokat -- ahogy elnézem, valamilyen idő beállítását, illetve ellenőrzését szolgálja).
Mivel a void loop()-ot nem láttuk, ennél többet nem tudok tanácsolni.
A régi lakásomban így volt megoldva pár évvel ezelőtt, és működött. Általában :) Annyi plusz volt, hogy egy mini PC volt még az álmennyezet alá berakva, hogy tudjam távolról is vezérelni. Ahol most lakunk nincs álmennyezet, ezért nem tudom egy pontról elhúzni a vezetékeket, így mega helyett - szobánként - egy-egy olcsó nano volt, rs485 kommunikációval. Most ESP és WiFi a nyerő, ami még talán olcsóbb is. Igaz én 10 éve fejlesztgetem már a dolgot és nem csak lámpakapcsolást tud, hanem mozgás- fény- hang- hőmérséklet- érzékelést is. A lámpakapcsolást úgy megprogramozni, ahogy írtad, nem lesz nehéz, inkább a vezetékelésben látok buktatókat, hogyha úgy akarod megoldani, hogy minden lámpát és kapcsolót egy "csillagpontról" vezérelnél.
Így a végén annyit tennék hozzá, hogy én a teljes nagyfeszültségű részt és annak minden elemét (nyilván együtt) külön tápra tenném, továbbá az arduino használatban lévő kimeneteit hidegíteni + diódával védeni. Watchdog elengedhetetlen.
Megfelelő minőségű relével nem lesz baj. Ha nem is az örökkévalóságnak készültek, borzasztó mennyiségű kapcsolást elviselnek. Az SSR-nek ehhez képest csak annyi előnye van, hogy halk, ha olyan, akkor zéró-átmenetnél kapcsol, egészen gyors váltásokat is tud csinálni (a relé ezt annyira nem kedveli), és jóval kisebb az áramfelvétele.
Önmagában sajnos nem stabil, mivel a kapcsoláskor keletkező impulzusok (főleg ledes-neonos világításnál) néha megfagyasztják a kontrollert. Szükséges egy úgynevezett watchdog áramkör, ami ilyenkor újraindítja az arduinot, és a kapcsolók állapotát célszerű letárolni a memóriába, hogy reset után visszatérjen az előző állapotba. Így már egész használható tud lenni. Sok múlik a tápegységen és a vezetékelésen is. Saját tapasztalat, hogy asztalon hetekig működő kapcsolás élesben katasztrofális viselkedést produkált, igaz nálam a lámpák 90%-a ledes, amiben a kapcsolóüzemű táp nagyot tud "visszarúgni" induláskor. Én diakos optoval leválasztott triakot használok ilyenre (szilárdtest relé / SSR), de lehet, hogy sima relével nem lenne ilyen érzékeny, de azt nem tartom hosszú távon megbízhatónak.
Zsenge vagyok még Arduinoban, DE nagyon tetszik! Azt szeretném kérdezni, hogy szerintetek 7/24 stabilan működne-e a szerkezet ha komplett lakás világítást (kb 13-15 kör villany) szeretnék rákötni? Kezdetben egy sima nyomógombos koncepcióval.
Biztos vagyok benne, hogy halott ötlet! Nem véletlen, hogy a hardveres ASIO kártyák jóval drágábbak, mint a szoftveres megoldások. A zenében nagyon kis késés (latency) is zavaró tud lenni, ezért fontos a gyors eszköz. Az arduino önmagában nem lenne lassú, de a sok port bővítő meg D/A kiolvasása több ms késést eredményezne, ami tuti, hogy az élvezhetőség határán túl lenne. Persze ez akkor fontos, ha a VST hang real time szólal meg, ha csak rögzítésre kell, akkor persze jóval nagyobb késés is elfogadható. Nem tudom mire kellene pontosan a szerkezet, de ha zenéléshez, akkor a billentyűzetet egy régi jó minőségű elektromos zongorával oldanám meg, a potikat/kapcsolókat meg virtuálisan valami érintőkijelzőn pl.
Másrészt. Fogalmilag én kettészedném az I/O portsokszorozást (a szimpla I/O portokat kiköltözteted egy adatbusz végén ülő elemre) és a mátrixot (áramköri elemek ki- és bemenetekre való ügyes felfűzésével ki- és bemeneteket spórolunk, 12 gomb beolvasásához így nem 12 port, hanem csak 7 db kell [16-hoz 8, ami fele annyi]).
Azok a multiplex IC-k, amiket posztoltál a két feladatot többé-kevésbé egyszerre oldják meg (van ilyen millió féle, max7221-ből vagy két tucat van itthon, MCP23017-ből is van 2-3 darab legalább). Számomra a multiplexing a mátrix (legalábbis a posztban erre gondoltam), ott pedig tudomásom szerint kevéssé életszerű potmétereket a bemenet forrásaként használni.
Itt már osztott észt más is mbed viszonylatban (annó kb. 1-1,5 évvel ezelőtt a "melyik nagyobb szar, az Arduino vagy az RPi" témakörben). Akkor megírtam a tapasztalataimat az mbedről (Arduinoval összevetve), és ez most, 1,5 év után sem változott érdemben, pedig azóta 10-ből 8 fejlesztési feladatot mbeden csinálok, a maradékot Arduinón.
Annyiban lett szofisztikáltabb a véleményem, hogy HA csak egy megvalósítandó cél van ÉS van hozzá valahol egy teljes, jól dokumentált leírás ÉS inkább kezdő, akkor irreleváns, hogy min csinálja, egyébként elsősorban Arduino. Kivéve, ha programozói tapasztalata van C-ben, mert onnan az Arduino kódra visszatérni egy rémálom. Tekintheted mindezt vitaindítónak is.
A portok száma kis jóindulattal irreleváns, a nagyobb gondot a billentyűleütések időbelisége adja. Illetve most rájöttem, hogy az sem annyira jó, ha van polifónia, mert az egyidejű több billentyű lenyomás multiplexingben annyira nem biztos, hogy nyerő, mert bizonyos billentyűkombinációkat vagy eseményeket félreértelmezhet. Alapvetően nem az a baj, hogy százas nagyságrendben kell bemeneteket lekérdezni, a gond azzal van, hogy ezeknek az ellenőrzése egy kissé körülményes (időigényes). Egy józan paraszti ésszel, szintaktikailag hibátlanul megírt szoftver futása egy alap arduino kártyán akár a tizedmásodperces ciklusidő közelébe is eljuthat (csak tipp, nem mértem, de hasonlóval volt már gondom), ami elfogadhatatlanul sok.
Több Arduinoval előrébb vagy, de az időzítést nem egyszerű megoldani. Két megoldásod van: vagy mindegyik Arduino egy Midi eszköz (a midi fordítást és csomagküldést kell megoldani), vagy az összes arduino össze van kötve adatcserére/gyűjtésre, és egy van, amelyik kvázi masterként továbbít a Midi portra. Egyiket sem magától értetődő megírni, de nyilván nem lehetetlen.
I2C egy másik történet. Alapvetően Master-Slave felállású többpontos perifériahálózatok hozhatók létre. Arduino környezetben se nem kifejezetten gyors, se nem kifejezetten megbízható, egy rosszabbul megírt könyvtárral meg rengeteget lehet szívni. Ugyanakkor vannak olyan áramköri elemek (portsokszorozók, multiplexerek), amelyek i2c protokollon címezhetők, így az Arduino oldalán csak két lábat foglal, és 2-3-4 ilyen elem egymás után kötve elvben rengeteg adat olvasható ki elég gyorsan. Ezzel érdemes lehet kísérletezni, ha nem is úgy, hogy 255 egyedi alkatrész van egymás után kötve.
de ő nem 100+ cuccot akar programozni, hanem egyet. de ahhoz is kezdő. az arduinóban az a poen, hogy mindenre van kész kód, csak meg kell érteni. komplett midi keyboard kód is van, nem is egy. az mbedhez is van sokminden, de messze nem olyan nagy a community.
Abszolút kezdő vagyok ezért, ha blődséget írok akkor elnézést kérek.
Arduino port problémára:
1 Több Arduino lapot is lehet használni.
2 I2C protokoll nem jöhet szóba? Pl nem kell annyi bemenet, mert végigballag igen gyorsan minden rácsatlakoztatott ezközön (max 255), címez/olvas. Van keymatrix illesztő is I2C protokollal, azaz azt a lapot kötöd az Arduinora, a lap többi kimenete meg a billentyűk felé.
A kártya elvileg alkalmas rá, multiplexelve pláne. Bár ez utóbbinak elvben hátránya, hogy viszonylag hosszú "vak" ideje lehet, amíg, bár nyomod a gombot, nem látja, hogy nyomod. (Részben csak feltételezem, az egyetemen nem hallottam.)
Potenciométert (analóg jelforrást) nem fogsz tudni multiplexelni. (A multiplex lényege az, hogy több csatlakozás egyszerre bemenetként és kimenetként is funkcionál, felváltva. Ha az egyik bemenetet aktiválod [magas állapot], akkor ha egy bizonyos gomb be van nyomva, akkor egy bizonyos kimeneten megjelenik úgyszintén egy magas jel, de a többin nem. Hátránya, hogy elvileg két gomb nem lehet egyszerre benyomva [azonos szálon lévők semmiképp]. A megoldással egy 4×3 gombos billentyűzethez nem 12 bemenet kell, hanem csak 7, pontosabban 3 ki- és 4 bemenet. A kiolvasás is egyszerűbb, mert soronként elég csak egy vizsgálat [van-e jel], és ha van jel, akkor kell megnézni, hogy pontosan hol -- szemben a sima 12 bemenetes, körönként 12 vizsgálatot tartalmazó beolvasással.) Ha az idővel nem lesz probléma, megoldható a dolog szerintem, de ezt mérni és számolni kellene elég sokat. Mindenképp modulonként írnám hozzá a szoftvert, és haa egy modul működik, akkor mennék tovább a következőre.
Csak műszaki tekintetben is elég jelentős kihívás. Tegyük most félre, hogy egy szál billentyűnek hány féle paramétert kell rögzítenie a sima "le van nyomva a billentyű" állapoton túl. A következő menet az, hogy ebből alapból ugye 88 darab van, ami oktávonként 13-mal csökken. A legtöbb midi billentyűzet 4 oktávos, ami 52 gombot jelent. Plusz egy analóg bemenet (ha csak egy potmétered van). Ez testvérek között is 53 bemenet, plusz a ki/bemenet a midihez (2 port). Ezt önállóan csak a nagyobb cuccok tudják (Mega, Due stb.).
Ez a hardveres rész. A szoftveres részben az a nehézség, hogy az összes szükséges bemenet állapotát egyszerre kell figyelni, és mivel 54 van belőlük, ez egy felettébb időigényes művelet, amit tovább lassít a midi feldolgozás és illesztés (elég időérzékeny a midi, bár azt most nem vágom, hogy egy nagyságrenden belül vagyunk-e vagy van az Arduinóban tartalék, az a tippem, hogy ha van is, csak minimális).
