Valami erre alkalmas programmal meg kellene nézni a processzorhasználatot és a memóriafoglalást a gépeken, miközben megy a fordítás. Akár szálanként. Elég részletes debug, "magyarul". Ilyet én más szoftvereknél akkor tapasztaltam, amikor valami nagyon beakadt a memóriában (pl. forszírozta a fizikai memóriát a virtuálissal szemben, más szoftver vagy vezérlő meg simán szembe ment vele).
Van egy nagy projekt (100-as nagyságrendű forrásfájl). A forrásban felhasználjuk az Arduino könyvtárakat, a fordításhoz a keretrendszerhez mellékelt avr tools-t használjuk.
A Makefile saját.
Az Arduino verziója: 1.0.6
Néhány teljes fordítási idő:
mindegyik Windows 7 pro sp1. Lenovo laptop: i7, 4 mag, 12 GB RAM: 301 sec
Eh, ebbe nem megyek bele, hogy kína versus egy magyar viszonteladó árai hogyan viszonyulnak egymáshoz, mert látom (impörtőrként más területen), hogy mi kell az éhhalál elkerüléséhez.
Azt furcsállom, hogy az Arduino kinti árazása is ilyen. Brit viszonylatban: Nano rev. 3: 35,29 font (http://www.technobotsonline.com). Rpi b+: 25,98 font (Amazon.co.uk, brit szállítótól). Ez vicc, de komolyan.
És az a helyzet, hogy a raspberry egy összehasonlíthatatlanul erősebb cucc, mint általában az arduinok, és különösen a Nano.
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.
