Nem úgy, hanem úgy, hogy a Raspberry itthoni ára alacsonyabb, mint a Nano itthoni ára ugyanabban a boltban...
Az, hogy én 3-4(-5) Nano-t vagy egy teljes DIY arduinot veszek azon az áron, mint itthon egyet (vagy egy fél mikrokontroller ic-t), az teljesen megszokott.
Arduinoval videot lejátszani nem fogsz, ez kb. tuti. Élvezhető sebességgel legalábbis biztosan nem. 16 MHz (de még a due 84 MHz-e is) kevés hozzá. Azt viszont megteheted, hogy akár képkockára pontosan, vagyis 1/25 másodpercnyi időzítéssel indítasz vagy állítasz le videót. Aztán az, hogy ez gyakorlatilag milyen eszközzel történik már más kérdés.
Raspberryhez nem értek, az sokkal inkább mikroszámítógép, mint mikrokontroller, azzal együtt, hogy GPIO portokkal azért el van látva (a B+ még jobban is, mint az alap ATMega 328p alapú Arduino). Technikai értelemben alkalmas a feladatra, hogy ezt hogyan lehet megvalósítani, az már egy másik kérdés.
Köszönöm! Jó ötlet a külön lejátszó, csak itt fontos lenne az hogy az arduino egység tudja vezérelni mikor mi jelenjen meg(ill én a távirányítón) . A TFT vél szerelt shield amiben sd olvasó is van az nem jó nekem? Vagy esetleg megoldhaó, a külső lejátszó beágyazott vezérlése? A raspberry tudja e egyidejűleg vezérelni a kijelzőket és a szervókat? Minden eszköz összehangolt működése fontos!
A video nehéz ügy. Az arduino agya (Atmel 328, de még a Mega2560 is) alkalmatlan ilyen nagyságrendű és sebességű jelfeldolgozásra, vagyis ezt egy külső egységgel kell megoldanod.
Raspberry PI elvileg tudja ezt, egyúttal kicsit ágyúval verébre megoldás is (bár kérdés, hogy milyen szintű videoról van szó, illetve mennyire jelentős a többi feladat).
Senki sehol nem mondta/írta, hogy profi cucc. Massimo is mindig ezzel kezd, hogy ugyan fejlődnek, meg erősödnek, meg Intel meg ezaz, de ez attól még egy oktatási (kvázi hobbi) platform elsősorban.
Nem hiszem hogy ay lett volna a cél, hogy jó sok shield-et lehessen használni, függetlenül attól, hogy fizikailag lehetséges csatlakoztatni őket. Ey ay Aurduino ilyen hobbi cucc szerintem, nem profi célokra szánták.
A láb ütközés a legtöbbször átkötéssel megoldható. Ha más nem, akkor a shield nem lesz rádugva, hanem külön összedrótozva. Mondjuk akkor már jobb saját hardvert gyártani. Akár proto nyákon, akár saját maratással.
A szoftver nagyobb probléma. A shieldek könyvtárait 90%-ban úgy írják meg a készítők, hogy nem gondolnak arra, hogy más eszközöket is csatlakoztatsz a mikrokontrollerhez. Vagyis delay-t használ, magára húzza az egész SPI buszt, beleáll az i2c busz olvasásába, fix megszakítást használ, stb.
Mi rendszeresen használunk Arduino-t prototipizáláshoz. Gyorsan, könnyen ki lehet próbálni új ötleteket. De olyan még sosem volt, hogy két, különböző eszközt használó ötletet csak úgy összegyúrjunk. Mindig az volt a vége, hogy saját könyvtárat kellett írni az adott hardver kezeléséhez. Az pedig sok mérnöki munkaóra.
vfp válasza megfelel a valóságnak, legalábbis az alapelveket illetően.
A két kulcskérdés a táp, ez ugyanis több shield esetén problémás lehet, továbbá a lábak használata/kiosztása az egyes shieldek viszonylatában. Tehát lehet, hogy két shield mehetne, mert nem terhelik túl a tápot, de ütköznek, mert ugyanazt a lábat használnák egy adott feladatra. Végül szoftveresen sem mindegy, mert két komplexebb shield, plusz esetleg egy-két további könyvtár simán nehézkessé, adott esetben lehetetlenné teszi a programozást, mert nem lesz elegendő memória a teljes sketch számára.
Nálam a végcél egy ECU lenne egy gázturbinához. Először csak mérnék, környezeti hőmérséklet, nyomás és hőmérséklet a kompresszor után, olajhőmérséklet és nyomás, valamint fordulatszám. Ezeket esetleg naplózni, vagy a PC-re, vagy SD-kártyára.
A végcél akváriumok vezérlése lesz. Sokmindent összeszedtem már különböző fórumokról, de én szeretem tudni, hogy mi mit csinál és miért, meg persze a saját számíze szerint szeretném jól megcsinálni éls tanulni belőle.
A vezérlő terveim szerint a következő folyamatokat vezérli: neon világítás időzítése; led világítás időzítése; led naplemente, napfelkelte; 3 dózispumpa adagbeállítás és időzített adagolás; hűtés, fűtés vezérlés; co2 és levegő pumpa időzített üzemeltetés, szűrők leállítása meghatározott időintervallumra, UV szűrő időzítésés, vízszint figyelés, riasztás alacsony vízszintnél. A különböző elemek vezérlése logikailag összefügg. Jelenleg ezeket OMRON ZEN-el oldom meg (ott egy kicsit egyszerűbb a programozás, cserébe korlátozott a programozható relék száma, sok a korlát, nagy helyet foglal... és már nincs benne kihívás).
A hobbitársaktól ötleteket kapva belevágtam ebbe és tetszik.
int alap = 0; // Kicsit felesleges ezekhez a változókhoz értéket rendelni, mert az első előforduláskor automatikusan kapnak egy releváns értéket. int atlag = 0; int adag = 0; // Itt az első lehetséges galiba, ha a ciklusok számát felemeled mondjuk 100-ra (100-zal oszt átlagot, 100 mintavételből), akkor az int típusú változó 32767-nyi maximális értéke rohadt gyorsan túl fog csordulni. 10 mintavételnél ez nem akkora gond (1023×10=10230), így technikailag 32-ig mehet fel az átlagolás ciklusainak száma. Tesztelni kell, hogy milyen mértékű iterálás kell az elégségesen sima szóráshoz. Javasolt változótípus: unsigned long. (Ennek a maximális értéke uszkve 4,3 milliárd. A kető között csak a sima long [2,15 milliárd] és az unsigned int [65 ezer] van. Előbbi kettő bőven sok, utóbbi elég lehet, az unsigned int 64-szeres mintavételt elbír.) for (int i=1; i <= 10; i++) { alap = analogRead(pot1); constrain(alap, 1, 1023); // Ez ide tökéletesen felesleges, mert az analogRead() eleve nem mehet 0 alá és 1023 fölé (hacsak nincs rosszul deklarálva a változó, pl. byte-ként, mert ugye akkor 255-nél fordul). alap = map(alap, 1, 1023, 1, 60); // Változatlanul nem értem, hogy miért van szükség a map-re ebben a fázisban, tekintetbe véve, hogy a bemeneti analóg érték átlagolása (ezzel a szórásának tekintélyes csökkentése) a célunk, nem az, hogy kiderüljön, pontosan hova "esik" az analóg érték az 1-től 60-ig terjedő értelmezési tartományban. adag += alap; } atlag = adag / 10;
És van benne még egy galiba: az elemhívása elején az adag változó a korábbi értéket tartalmazza (hacsak a sketch más része felül nem írja), azért nem 0-ról, hanem az előző mérés eredményéről indul az összesítés (vagyis minden hívásnál szép lassan mászik fölfelé, amit csak a constrain() kompenzál a felső határnál).
Nálam ez így néz ki (csak az átlagolás rész, amit a beolvas() hív meg és csak globális változókkal dolgozik).
const int pot1 = A3; // 1. potméter A2-n int beolv; // a potméter aktuális értéke unsigned long beolvas; // az átlagoláshoz használt átmeneti változó ("gyűjtő") int atlagolas = 100; // hány lépésben átlagoljon. A magasabb érték lassabb, de stabilabb mintavételt ad. Maximális elvi értéke kb. 4,2 millió
void beolvasas() { beolvas = analogRead(pot1); for (int i = 0; i < (atlagolas-1); i++) { beolv = analogRead(pot1); beolvas = beolvas + beolv; // csak a könnyebb érthetőség kedvéért } beolvas = beolvas/atlagolas; beolvas = constrain(beolvas,0,1023); // a számítási hibából eredő túlcsordulást levágja }
constrain() csak a "tisztításhoz" van benne, map() egyáltalán nincs, mert a feladat nem az, hogy megatározzuk, hogy az 1-től 60-ig terjedő tartományban épp hova esik a potméter aktuális értéke, hanem az, hogy kiderítsük, a korábbi méréshez (referenciához) képest változott-e a potméter helyzete vagy sem. A kimeneti értéke a beolvas változóban van tárolva (ami ugye egy sima int), értéke 0 és 1023 között lehet.
