> -- javaslom valami alap szerkesztő használatát (Notepad ++) az Arduino IDE mellett
Javaslom az Atmel Studio-t. Ingyenes, Visual Studio alapú. Támogatja az összes Atmel hardvert. Van hozzá Arduino plugin, aminek a segítségével a sketch-ekből project-et lehet készíteni. A sketch-ek továbbra is használhatóak maradnak az eredeti Arduino IDE-vel is. Van benne rendes kódkiegészítés, debugger, átnevezés, stb.
Szóval egy komplett IDE, nem olyan herélt, mint az Arduino.
A termosztát adók kiváltása nem annyira egyszerű. Egy zárt, működő rendszerbe kívülről beavatkozni, adatokat vagy jelet kiszedni vagy berakni nem magától értetődő, ehhez a zárt rendszer architektúrájának ismerete (gyakorlatilag kapcsolási rajz szintjén) kell. És még így sem biztos, hogy sikerül. A termosztát egy kő egyszerű eszköz rendszerint, 1 bites szabályzást csinál a legtöbb esetben (magyarul ki/be kapcsol), egyszerűbb tehát kiváltani, mint beállni mellé.
A redőny más tészta, mert ha nincs saját vezérlése, akkor pl. a végállásokat meg kell oldani. Ha van saját vezérlése, akkor a kapcsolófelületre kell rácsatlakozni (kvázi nyomógombokat, kapcsolókat párhuzamosítani), ez viszonylag egyszerűen megoldható (hasonló projekten dolgozom épp csak teljesen más felállásban).7
"Remélem, hogy nem keverem össze több felhasználó igényét. :-)
Ha jól emlékszem, az alábbi követelmények voltak:
-Szenzorok olvasása. IGEN
-Értékek helyi naplózása SD kártyára. NEM AKAROM SD-RE, ELÉG HA A NAS SZERVERRE EGY FILE-BA RAKJA AMI KIÉRTÉKELHETŐ
-(Később beavatkozás a rendszerbe a mért, naplózott adatok alapján.) NEM AKAROK BEAVATKOZNI EGYÁLTALÁN, MAJD KÉSŐBB CSAK AMIT 645-ös hozzászólásomban írtam, hogy termosztát adókat csinálni (rádiós) és távolról vezérelni + ha megoldható szintén távolról redőnyvezérlés mind rádiós
-Lokális felhasználói felület grafikus LCD-vel, menüvel, grafikonokkal. HÁT ELÉG HA CSAK A MÉRT ÉRTÉKEKET KIÍRJA
-Távelérés etherneten. IGEN
-Legyen olcsóbb, mint egy gyári megoldás. MINIMUM :)
-Ne nulláról kelljen kezdeni a programozást. AZ BIZTOS
50 nap eszelősen sok idő, és azzal érdemes számolni, hogy a legtöbb kártya (kivétel a Due, a Leonardo és a speciális kártyák közül egyik-másik) azonnal resetet nyom, amikor -- külső táp ellenére -- USB-re dugod.
Valószínűleg az órajel felével vagy a körül, de nem egyenletesen -- ha egyáltalán. Érdekes kísérlet lenne szkóppal megnézni.
Mega(/Due) + RTC + hálókártya. Esetleg egy Yún, de annál már vannak jobbak.
Én vezéreltem már SSR-t netről, kívülről. Jól konfigurálhato router kell hozzá, erre figyelni kell (az Invitel lakossági modem + cucca pl. alkalmatlan rá teljesen)
Persze egy dolgot csinál egyszerre, úgy értettem, hogy sorban vannak a feladatok, és egymás után. A delay() az ebbe a koncepcióba nem ilik bele, az tipikusan a kezdő kis programocskákhoz jó. Viszont az időzítés az nagyon gyakori igény szinte bármilyen felhasználásnál, nade akkor majd a millis()-sel meg az rtc-vel ügyeskedek.
A belső eeprom írást akkor felejteni kell, meg ha lesz rtc, akkor már úgyis ott a ram rajta.
A delay nélküli példát néztem, és láttam hogy nem törődik a túlcsordulással:
if(currentMillis - previousMillis > interval)
ha a millis átcsordul, és kezdi 0-ról, akkor ez az if 50 napig nem lesz igaz, vagyis egy most bekapcsolt Arduino 50 napig szépen fogja villogtatni a ledet, majd 50 napig nem villog. Szóval ezt le kell kezelni, ha túlcsordult, akkor külön módon kell eljárni, és az értéket átírni a previousMillis-be.
Ha már említetted a sebességet, kb. mire lehet számítani? Mondjuk egy ledvillogtató delay nélkül mekkora frekivel villogna?
Ha csak egy parancsot lehetne örökre kiszedni az Arduino parancsok közül, az sok ember szerint a delay() lenne. Én inkább csak a paramétert limitálnám nagyjából 100-ra.
A meglátásod nem rossz, de van benne egy gixer. Itt nincs olyan hogy a board csinál mást IS. Egy dolgot csinál, nagyjából mindig. Ehhez képest egy érdemi kivétel van, az interrupt, mert az az architektúra másik szintjén figyel folyamatosan, vagyis akkor is bele tud szólni a programfutásba, ha épp nem történik vizsgálat. Jó játék soros kiolvasással megnézni pár kódrész futási idejét. Meg fogsz lepődni...
1. kérdés: a meglátás jó. Túlcsordulhat, erre figyelni kell, ha olyan a szoftverkörnyezet. A millis() alapból unsigned long, vagyis az a változó, amivel vizsgálsz, szintén unsigned long kell legyen, a kezdeti változódeklarációknál erre figyelni kell (a váltásnál így is előfordulhat nehézség, de ez ugye 50 nap nagyjából). Lásd: blink without delay.
2. kérdés: elvileg igen, gyakorlatilag olcsóbb és egyszerűbb egy külső eeprommal megoldani. Két okból: egyrészt a belső eeprom (ami konkrétan az IC-n belül van) csak limitált írási-olvasási műveletet képes elviselni (ez néhány ezer az I2C eeprom milliós értékével szemben). Az EEPROM-hoz sem kell elem, kb. 100-200 év az adatvesztésig eltelő idő. Van breakout is, de kb. 40 forint egy darab, plusz a két előtétellenállás.
3. kérdés: nincs rajta idő. A millis() elvileg alkalmas időmérésre, ha csinálsz egy változót, amit szinkronizálni tudsz. De...
Egyrészt az Arduinokon (pláne a klónokon) lévő kristály nem éppen atomi pontosságáról híres, nekem 10 percen belül másodperces járateltérést produkált, ami ugye pár perces időmérésnél irreleváns (nem fogod látni, hogy a blink without delay 1 másodperc vagy 1,001 másodperc), de a másodperces jel akár pár perc alatt el tud "mászni" egy referencia jeltől (pl. egy óra kattogásától).
Helyette: RTC, de ne az olcsójános kínai (DS1307, rettenetesek, 1 percet is meghaladó napi járateltérésük bír lenni), hanem a a DS3231 például.
Telefonon tényleg érdekes lehet programot diktálni, soronként egy elírás, nehezen fog működni.
Nulláról kezdem az ismerkedést az Arduinoval, de máris van kérdésem. A loop() ugye pörög állandóan, és a ledvillogtató példa a delay(1000)-rel lassítja láthatóra.
Ha két dolgot végez a board és az egyik a villogtatás, a másik meg egy olyan, amit maximális sebességgel kell futtatni, akkor a delay nem jó módszer, mert az a másik programrészt is lassítja. A millis()-sel lehet csak operálni? Eltenni az értéket, minden lefutásnál összehasonlítani, és ha már 1000-rel több, akkor váltani a ledet? Működhet ez így, de mi van, ha a millis túlcsordul?
Szabad-e használni az eepromot valami mérési eredmény tárolására? Nade úgy, hogy minden kiolvasást oda tárolok, vagyis lehet akár másodpercenként többezer írás is. Vagy jobb ilyen célra egy elemmel ellátott órapanel, mert a ramot végtelenszer lehet írni és az elem miatt nem felejt? Vagy más megoldás?
Órapanel nélkül van-e dátum és idő a boardon? Mondjuk napi szinkron megoldható pc-ről, reggel 8-kor a pc lehúzza low-ba a 2-es pint 5 másodpercre vagy ilyesmi, és akkor csak egy napig kell szabadon járnia az órának.
Programozásban telefonon nem lehet segíteni. Az összes fórumon az megy, hogy a teljes kód megosztását kérik az esetleges hibaleírással és egy adekvát kérdéssel együtt. Sok kódhoz kell a kapcsolási rajz vagy vázlat is, de legalább egy tájékoztatás, hogy mi hova és hogyan van kötve.
Én a magam részéről azt az elvet vallom, hogy ha valakinek segítség kell, inkább hálót adok neki, mint halat, vagyis nem a megoldást írom meg helyettük, hanem a kulcsot adom oda, ami alapján a megoldásra saját maguk rájönnek.
Amivel készülj:
-- Fritzing (játékos kapcsolási rajz készítő, egyébként ingyenes és elég jó), esetleg 123D Circuits.
-- javaslom valami alap szerkesztő használatát (Notepad ++) az Arduino IDE mellett.
-- rendes táp (12 vagy 5 V stabilizált, legalább 2 A terhelhetőségű, ez függ attól is, hogy az összes alkatrész várható áramfelvétele hogy alakul)
-- legalább egy alap multiméter
-- elektromos szerelési alap szerszámok (páka, csipeszek stb.)
-- prototípus építéshez breadboard (próbapanel), legalább egy, inkább kettő, átkötő kábelek (sok), csipesz.
Erre is rá kell dugdosni valahogy a perifériákat, a különbség annyi, hogy itt az alaplap sokkal komplexebb. Ugyanezt a konfigurációt alap arduino alkatrészekből nem lehet összerakni, még csak részben sem, mert igen gyorsan ki fog ugrani az a tipizált hiba, ami a legtöbb Arduino shield-re igaz (és sajnos a koncepció nagy hátulütője), hogy az egyes emeletek előbb-utóbb ütni fogják egymást lábkiosztásban, vagy ha abban nem, akkor az egyes könyvtárak fogják összekuszálni a rendszert (vagy simán csak nem férnek el a memóriában).
Bár Vargham olvtárs kevés kijelentésébe tudok alapjaiban belekötni (ha egyáltalán van is ilyen), azt azért praktikus figyelembe venni, hogy nem úri hóbortból ajánlgatja ezeket a kártyákat, hanem mert pár specifikációt úgy sikerült a Nagy Kjelző Projekthez összeválogatni, hogy az az Ardiuino alap kártyáinak lehetőségein messze (de nem ennyire messze) túlmutat. Mert teszem azt, ha nem kell az 5 coll (elég mondjuk a 3,2) és nem kell a lan, akkor hopsz, máris elég egy sima (korábban linkelt) 3,2 collos kijelzővel megtámogatott Mega2560 (még sok is). Ad abszurdum, még rá lehet dugni kis szerelgetéssel egy LAN shieldet (nem egyszerű, de nem is kizárt) és lám, működik. 7100 forintból (postával), plusz érzékelők, kábelek satöbbi.
Én is úgy vélem, hogy ez az ár nagyon jó, ha az Arduino shieldek árait összeadogatjuk, ráadásul ezen a kártyán sokkal gyorsabb a processzor és jóval több a memória.
Az meg, hogy stabilabb, megbízhatóbb, mint egy összedugdosott, összeforrasztgatott megoldás, nem is lehet kérdés.
Ezt konkrétan még nem használtam, csak pont ma ajánlgatta nekem a webáruház. :-) Egyébként nagyjából ugyanezeket tudja a legtöbb mbed cucc is, csak éppen 10 ezer forint körül.
Ez egy gyártói fejlesztői kártya. Ez azt jelenti, hogy a chip (mikrokontroller) gyártója gyártja.
Ez általában az alábbiakat jelenti:
- Olcsó. Szinte alkatrész árban adják, hogy rászoktassanak. Cserébe nem lehet végtermékbe belerakni. (Ez egy hobbi projekt esetén irreleváns.)
- Jó alkatrészek, jó összeszerelés, minőségbiztosítás.
- Teljes gyártói támogatás van hozzá.
- A kártyán lévő összes periféria azonnal működik. Mert úgy rakták össze, és mert adnak hozzá szoftvert.
Azért a mbed sem fenékig tejfel... MAX7221 és a TLC5940 dokumentációja gyakorlatilag nem létezik, mintaprogram csak az elsőhöz van, az sem túl bőbeszédű...
dBoxban van revision history, bár körülményes a használata (csak on-line, webes felületről megy). Ennyi nekem elég volt, pláne, hogy a jelentősebb kódváltoztatásokat verziószámozom magamnak. Bitbucketet megnézem.
Nekem az Arduino előtt kb. 25 évre visszamenőleg (egy igen gyenge Visual Basic elméleti próbálkozást és később alap html/xhtml/css játékot leszámítva) csak Basic szinten voltak programozási tapasztalataim (abban mondjuk egész sok). Az első dolgok egyike volt, hogy mindent függvénnyel hívtam, mert igen gyorsan és igen rövid idő alatt bele lehet kutyulódni egy spagettibe. Most van 700 soros kódom (meg van modjuk 2500 soros is, de annak 80%-a PROGMEM), és bár még nincs kész teljesen, 1-2 hónap kihagyás után is simán tudom folytatni, mert úgy van összerakva.
Ugyanez a konfigurâció Arduino klón elemekből összerakva mi lenne árban ill. teljesítményben vajon? Ez az Amtel kártya gyorsabb jóval, gondolom, de 21 ezer Ft jónak tűnik akkor is, ha elkezdem az Ard. shieldek ârait sorban összeadogatni, ugye?
Jól gondolom, hogy egy ilyen integrált megoldás nem csak nagyobb teljesítményű, hanem olcsóbb is?
amit belinkeltem tft-hez összekötő kütyü az arduino-hoz
a programozás na az lesz nagy falat mert nem értek hozzá
azt se tudom merről kell hozzá kezdeni egyáltalán hogyan szólítsam meg?! összedugdosni az egyszerű lesz gondolom olyan mint a LEGO ahogy láttam a képeken.
Egyébként ha beledugom a Lan modult attól még nem fog működni.
Lesz előttem egy rakás összeszerelt alkatrész amit max dobálni tudok :(
kerezsijoc Alább megírtam. Direktben nem megy rá az arduinora, kell elé valami még. Nagy hirtelenjében nem találtam semmi alkalmas eszközt, hacsak nem a korábban linkelt Adafruit cuccot. Szóval az plusz egy költség.
Ami az összeállítást és a programozást illeti... Nem követtem vissza, hogy pontosan mit akarsz, de mindettől függetlenül viszonylag egyszerű. Gyakorlatilag minden fent van hozzá a neten. Magát a szoftvert meg kis kísérletezgetéssel magad is össze tudod rakni. Vagy mondjuk sok kísérletezgetéssel.
Annyit mindenképp javaslok, hogy külön csináld meg az egyes elemeket, vagyis lépésenként, modulárisan haladj, előbb az érzékelő (egy érzékelő), soros portos kiolvasással, aztán több érzékelő, aztán ha ez megy, jöhet a kijelző (egyelőre érzékelők nélkül), aztán kombinálni.
Folyamatosan kell tesztelni, egyszerre csak egy kis kódrészben turkálni és azt lehetőleg hibátlanra megcsinálni, csak utána bővíteni tovább.
Tápellátással lehet gond, forrasztással, programmer firmware-rel, extrém esetben USB ütközéssel, de az nem jellemző annyira. Nekem általános viszonylatban, ICSP csatlakozón ezek ugrottak ki.
Amúgy kijelzőnél még lehet gondolkozni 4x20 karakteres LCD-ben (de ahhoz kell akkor még keypad), vagy 7-szegmenses modulban (TM1638 chip-es, kb. 1,5-2 ezer Ft), 8 digit + 8 gomb + 8 led.
> Egyrészt az off-line/on-line viszonylat nem kőbe vésett, off-line rendszerrel is simán kiszolgálható, ha felkészült vagy rá (mbed).
Igen, a projekt és az SDK is letölthető.
> ha nem egy gépen dolgozol (kódolsz), hanem több helyről, akár telefonról (oké, extrém, de én csináltam),
> akkor meg vagy lőve, kivéve, ha mondjuk dropboxban tartod a kódrészleteket (ahogy én).
Dropbox nem a legjobb. Erre találták ki a verziókezelő rendszereket. Tudom ajánlani a git alapú ingyenes Bitbucket szolgáltatást, amihez tök jó (ingyenes) kliensprogram is létezik SourceTree néven. Én az összes gépemen ezzel szinkronizálom az Arduino projekteket és könyvtárakat is.
> Nagyobb baj viszont, hogy például a beépülő modulok (könyvtárak) kezelése az Arduino (Processing 2) IDE keretrendszerben
> -- bocsánat az erős kifejezésért -- egy rettentő nagy tócsa híg fos.
Egyetértek.
> (bár sok oldalról félrevisz, lásd pl. függvények kezelése kódon belül)
Nagyon félrevisz. Átláthatatlan, spagetti kód írására ösztönöz.
