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.
Átlagolás módszertan (ez nekem is érdekes tapasztalás volt, de self-learning alatt ez belefér).
1. csinálsz egy külön rutint, mondjuk void atlag() {...}
2. ezen belül lesz egy
unsigned long osszeg
változó. Ezt másutt nem kell használni, így nem kell globális változóként deklarálni.
3. for .. ciklus akárhány elemmel (mondjuk 0-tól 39-ig az 40 elem). mérsz, az osszeg változóhoz hozzáadod a mért értéket, majd elölről, amíg a 40 kör le nem fut
4. elosztod az osszeg-et a mérések számával (40-nel), ez lesz a nyers adatod,
5. ezt megvágod constrain-nel (a végállások miatt fontos, 0 alá nem mehet, de tapasztalataim szerint a kerekítési hibák miatt képes 1023 fölé szaladni).
Mérések alapján kb. ezer tételes átlagolásnál kerül 0,5 mp közelébe a ciklus futása (ami egyrészt ésszerűtlen, másrészt még mindig rohadt gyors).
Igen, minden mérést átlagolj! Ha a fenti külön elemet legyártod, akkor azt bármikor hívhatod.
1. Az átlagolás még mindig nem jó. Azóta mondjuk én is rájöttem (ugye a diploma hiánya), hogy a sima "iskolás" módszer az értékek összeadásával, majd az értékek számosságának elosztásával jobb (stabilabb) eredményt ad. Ez sem ördöngősség, és mivel egyébként is át kell írni, ezt is érdemes átvarázsolni. A gond a változók kezelésével van elsősorban.
2. Ez is a tesztelés eredménye, hogy praktikus minden mérést átlagolni.
3. A void loop () nyitása mi? Egyből felülírod valami random számmal az előzőleg jól kiszámolt értéket?
4. if () alá nem kell return ide, mindenképp kiszáll belőle.
Teleírom a fórumot lassan... Egy mérésssel és egy változóval kevesebb! Működik. Egy hibája van mindössze - először minden esetben meghívja a kijelzést (mivel először az átlaghoz hasonlít).
// Carbo const int pot1 = 5; // 1. potenciometer A5-re kotve int alap1; int alap11; int adag1; int atlag1;
Már hogy a rákba ne tudnád? Van egy adagértéked, amely a poti aktuális állapotától függ. Vagyis ha tekerődik a poti, változik az adag, méghozzá pont oda, ahol a poti áll. Ha tudod az adagot, tudod, hogy milyen tartományban kell(ene) állnia a potinak. Ha nem ott áll (ez egy méréssel megoldható), akkor változtatni akarod a mennyiséget...
