Rikam si jestli by to bylo vhodne na stavbu nejakeho 1-diskoveho NASU. Koupil jsem si ted Ds-115 od Synology, ale docela me zklamal ten jejich system. Je sice fajn ze se da vsechno strasne jednoduse nastavit a zvladne to kazdy, ale zaroven to prinasi omezeni a clovek musi delat veci zpusobem ktery mu nuti Synology. Priznam se ze mi to nevyhovuje a krabici vracim v ramci 14ti denni lhuty.
Premyslim o tom koupit Minnowboard MAX - je na tom velmi usporny dvoujadrovy Atom s podporou AES-NI, 2GB pameti a Sata port (byt jen verze Sata 2) a USB 3.0 . Jako vyhodu take vidim pouziti X86 Architektury.
Docela by me ale zajimalo jak by tahle bananova deska zvladala sifrovani slozek s AES.
Mam desku s procesorem A10 a pres sambu se dostavam na 7MB/s prenosu se sifrovanim. Prestoze i AllWinner procesory maji hw crypt, sifrovani disku bohuzel stale pracuje s 512B bloky, ktere maji obri overhead a hw crypto neprinasi zadne zrychleni. Proto vrele doporucuji jit do Intelu i kdyby to melo byt jen jedno jadro viz http://kronus9.sblo.jp/article/110278662.html
Taky me dost prekvapil zdvih 2core oproti RPi a ignorovani RPi2, tak si to doplnime :)
BananaPiR1 RaspberryPi2B Rozdil 2 core 4 core +2 (RPi2B) 1 GB 1 GB 2 USB 4 USB +2 (RPi2B)
Po shlédnutí výkonnostních testů Raspberry Pi B2 a Banana Pi je vidět, že výkon procesoru Banana Pi je na tom výrazně hůře. Velkou nevýhodou jsou pouze dvě jádra procesoru a nejen u aplikací s paralelním zpracováním ;)
Samozrejme nepopiram ostatni vyhody BPiR1 4xGLAN mimo USB, Wifi, Sata, Rclock, atd... ;)
No, v téhle tabulde je taky pár nepřesností.
USB: Banán 2, RPi1 + hub
CPU: Víc jader je nanic, pokud to nepodporuje zbytek systému. Můžu mít 16jader, každý s výkonem 1000MIPS, ale když neprojdou z paměti data i program pro všechny čtyři a chache nestíhá, tak jsem v háji.
Banán R1: má 5x 100MBit, ne 4x 1GBit!!!!
Každopádně, pokud potřebuju děcku pouštět pohádky na starší telce s HDMI tak je to na banán. Pokud potřebuju domácí server na tisk a ukládání max. 2TB filmů, je zajímavý banán... Na cokoliv výkonnějšího je stejně potřeba odpovídající železo.
xbmc/kodi na tom zatial moc nebeha, lemaker stale len slubuje, ze uz-uz to bude, samotni vyvojari kodi sa banane obracaju chrbtom - je mozne, ze hlavne kvoli tomu velmi slabo podporovanemu allwinnerovi. btw http://www.phoronix.com/scan.php?page=news_item&px=Allwinner-GPL-Violate-Proof
inak je banan (mam 2jadrovu verziu) celkom fajn. vykon oproti raspi2 som neporovnaval, ale kto hlada, najde.
Presne tak. Puvodne jsem koupil neco s A10 na XBMC. Bylo to v dobe, kdy se pred temi x lety obe platformy objevily. Dokonce jsem mel i RPi a prodal jsem ho, protoze jsem ocekaval, ze nakonec bude A10 rychlejsi. Jak jsem se mylil. Na RPi vse ji davno bezi, oficialni podpora a cinani jen slibuji. I kdyby preci jen neco dokazali po letech splachtit, tak jim na to kaslu. Bude to odflaknuty sunt, ktery se nevyrovna odladenosti RPi. A s prichodem RPi2 uz vlastne neni o cem premyslet.
Som na tom podobne.
Mám MELE s a10, a nakoniec na tom ostal Android. Linuxové ovládače Lima mali perspektívu, ale zapadli prachom. OSS verzia pre viacjadrové GPU v banánovi podporuje len jedno jadro. A XBMC/KODI ? Tí sa na to vyflákli už pradávno, keď viacjadrá utiahli SW prehrávanie. Bežím na tom buď vstavanú appku od číňana alebo BS player. Nenašiel som nič iné čo by zvládlo prehrávať filmy s HW akceleráciou, a po sieti. Aj samotné VLC na to kašle.
A inak, plynulo mi to a10 prehráva HD Ready filmy (mkv s h264). Takže to neľutujem až tak ako keď som kúpil dvojjadrový telefón v naivnej nádeji že Ubuntu zverejní ten PnP desktop pre telefóny, tam bol rozdiel v cene pri nádeji na lepší SW trochu vyšší.
PS: doteraz neviem čo majú ľudia s tým XBMC/KODI. Mám vzhľadovo podobný launcher, titulky si nájde BS Player sám. A doplnky ako počasie a podobne? Appky sú.
no je fajn rozepsat hardwarovou specifikaci do clanku, ale osobne by me mnohem vic zajimalo, jestli pro banana pi existuje nejaka bezproblemova distribuce, jako existuje pro rpi.
jestli fungujou graficke ovladace.
jestli muzu na te rychlejsi grafice skutecne spoustet opencl programy, popripade s jakym vykonem.
a podobne.
Jojo, čtyřjádro je PAPÍROVĚ lepší, Ale je v tom háček.
- Díky pipeline je to sakra blízko k výkonu 1MIPS/MHz pro každý jádro.
- Má jenom DDR2 paměť ani ne na polovině frekvence jednoho jádra (http://www.micron.com/parts/dram/mobile-ddr2-sdram/edb8132b4pb-8d-f).
- Toto v praxi znamená, že v plné plabě při burstu 8 slov a latenci 4-4-4 pokryje nekešovaně tok programu pro jedno jádroa ještě ne celý (CPU 800MHz pro THUMB, 400MHz pro ARM, taktují to na 900MHz)
- CACHE pomůže, pokud všechny jádra vykonávají nějakou rychlou a krátkou smyčku, která se vleze do I cache. Jinak je to furt výkonově jednojádro a víc se z toho vymáčknout nedá. Protože není RAM.
- Přínos čtyř jader vidím jenom v tom, že jsou tam čtyři sady registrů pro jádro a zjednoduší to trochu context switching v systému. Víc za tím nehledejte.
- Nárůst výkonu systému se, až na krátký cykly v programu, nekoná a prostupnost pro data bude naprosto zoufalá.O bus matrix se porve hned 11 zařízení a hádám, že všechny zoufale potřebují RAMku (4x instrukce jádro, 4x data jádro, USB, video, DMA).
Kdyby mísho čtyřjádra dali dvoujádro a pořádnou, rychlou RAM s 32b sběrnicí, tak udělají líp. Jinak stejně v průměru jedno jádro počítá na půl plynu a tři čekají na instrukce, protože zrovna sosá data video adaptér... :Q
Článek přinesl informace pro ty, kdo tuhle oblast nesledují. Uvítám i seriál se zkušenostmi z instalace, což mi ušetří čas, kterým bych ztratil vymetáním slepých uliček. Tenhle stroj plánuji nasadit jako schopný router (na to má rpi málo síťových rozhraní), do kterého možná strčím i disk. Měl by ale určitě umět vyslat wake-on-lan, a být součástí možná až dvou různých vpn.
Takže se nenechte znechutit remcáním místních haterů a sem s tím seriálem.
Zmíněný HW doma mám. A právě SW je to, co mě zklamalo. Chci to používat jako router. Nejdál je zatím OpenWRT, ale i tak, WifiAP je nestabilní. Video akceleraci ani nechci, vím že nechodí (chodí teoreticky, prakticky Raspberry). Ale ty gigabitové ethernety, wifi a sata by chodit mohli, k mé úplné spokojenosti. A i s těmi ethernety jsem četl, že když se to zahřeje, tak rychlost záhadně padne apod.
Takže se těším na další díly :)
Proč srovnáváte R1 banán s malinou? To je jako porovnávat router s tiskárnou... Do obojího vedou dráty, obojí má procesor a paměť, ale jaksi každé má jiné určení. Pokud chcete něco srovnávat, tak porovnávejte M1 banán s malinou, to jsou zařízení se srovnatelným určením.
Jinak k debatám o výkonu banánu oproti malině: tak jak vyšla nedávno nová verze maliny, tak už je ve fázi návrhu i nový banán M2, takže stačí chvíli počkat a máme tu zase rovnocennější souboj. Tedy v tom smyslu, že banán zase vyhraje nad tou nahnilou closed-source mediálně-fanatickou malinou :-P.
skoda ze rozmisteni konektoru M2 navrhoval nejakej slepec, asi budou dodavat radeji pilku na zariznuti ;) ale jo rovnocenejsi to bude, M2 uz take nema SATA :-)
neni ta medialni malina nahodou lepe podporovana ? drivers, sw, komunita ? ses si jistej ze jde o fanatismus ze stra RPi a ne zavist ze strany BPi ? ;)
Jo, no taky mě štve, že si líp nepohráli s rozmístěním konektorů a volba procesoru bez podpory SATA je taky imho nešťastná, byť mám dojem, že benchmarky ukazovaly, že ten SATA port na M1 byl stejně propustný jako USB...
Jinak ano, malina je na tom softwarově a komunitně lépe, Uptonovi ji velmi šikovně medializují a tlačí i do projektů (resp. takové projekty prezentují jako velké objevy), kde to postrádá smysl a tváří se, že kromě maliny jiné alternativy neexistují.
Komunita kolem maliny mi přijde z velké části dost nevzdělaná až neschopná (stáhnu NOOBS, naklikám "nějaký systém", co jsem si zapamatoval z časopisu, stáhnu balíčky a hurá koukat na filmy na "studené" destičce, plné proprietárního blobu). Na druhou stranu je pravda, že nejspíš cena, dostupnost a medializace láká i velmi schopné lidi, takže na malině je postavená i řada velice zajímavých projektů.
Já osobně jsem velkým příznivcem Arduina, které ale pochopitelně je určené na jiné typy projektů (byť se Uptonovi snaží tvářit, že RPi je vhodnou náhradou za Arduino).
Jinak ten fanatismus je můj osobní dojem a spíš než nějaká závist banánů je to má osobní averze k Uptonovi a jeho znamenitým marketingovým dovednostem.
Tak tak, na domásí NAS je SATA neabytná.
A pokud jde o banán, číňan vyrobit, ale číňman nedělat promo akce ve školách... :( Jinak je ta deska velice zajímavá a v mnoha ohledech lpší než malina.
Co bych vytknul malině, tak to, že od začátku nepoužívalui spínaný zdroje a to, že USB nejdou používat plnohodnotně (napájení).
Co bych vytknul Arduinu je volba procesoru, AVR není pro začátečníky zrovna ideální volba, zbytečně to komplikuje návrh...
Co bych vytknul Arduinu je volba procesoru, AVR není pro začátečníky zrovna ideální volba, zbytečně to komplikuje návrh...
No a co jiného na úvod do mikroprocesorů? Procesor, který má interní hodiny a programuje se naprosto triviálně přes ISP, cena se pohybuje podle typu mezi 50 a 150 Kč, destička z číny za 200, to je imho super. Na blikačku stačí procesor, 4,5V baterka nebo starý počítačový zdroj a led dioda (ideálně s rezistorem, ale na 5V při blikání neshoří). Má to interní pullupy, pro reakci na tlačítko stačí připojit jen to tlačítko. Má to UART, SPI... Co je na tom komplikovaného (krom chybějících studijních materiálů)?
Co jiného, PIC?
No a další mega výhody následují:
- Harvardská architektura - je naprosto super, kdy je potřeba nedej bože spustit kosuek testovacího kódu v RAMce apod. Je to někdy celkem svazující třeba při psaní testů nebo bootloaderu (i když to už je tak trochu vyšší dívčí).
- Pokud nějaké funkce potřebuje jako parametr blok dat v RAM i ve FLASH (řekněme třeba výpis na displej), tak kompilátor data z FLASH musí kopírovat do RAMky (které je u jednočipu celkem málo), nebo člověk musí řešit dvě stejný funkce s jiným typem pointeru. Začátečník má plno jiných problémů, který by měl řešit.
- 8b data jsou tak akorát na aritmetiku, do které sype data 10b A/D převodník
- Atmel jako firma obecně má na čipech tolik chyb, že bez jejich seznamu si člověk ani neuleví na WC
- Instrukční sběrnice má 16b, datová 8b. Už jsem viděl tolik začátečníků, kteří nebyli štond to pochopit a divili se, že po inkrementu pointeru na byte nedostanou z FLASH korektní výsledek... Kdybych měl někoho učit práci s jednočipama, tak se snažím ho od takových nepodstatných implementačních detailů odstínit, aby řešil vlastní program a ne to, jak funguje železo.
- Používání SPI pro programování zrovna moc triviální není. A neumožňuje on-chip debug.
Prostě Arduino je hračka pro nemyslící blázny, kteří věří ve výkon úměrný počtu jader a gigovou LAN na desce s pamětí, taktovanou na 400MHz. A nekoukají na princip toho zvolenýho řešení.
A co jako náhradu? STM32 Discovery kit http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF259724 (Cortex, von Neumann, hafo FLASH i RAM, možnost krokování, ISP, je to od cca $11. A všetně polopatickýho návodu od Marda na mcu.cz :)),
A co třeba LaunchPad MSP430? http://www.ti.com/ww/en/launchpad/launchpads-msp430.html#tabs, taky od cca $10 s full debugem včetně krokování, breakpointů, A je to 16tibit, některý verze i s FRAM místo FLASH a RAM... A super low power...
> Používání SPI pro programování zrovna moc triviální není.
Myslíš z hlediska uživatelského nebo z hlediska toho kdo programuje programátor?
Jsem začátečník a mám za sebou pár bastlů na AVR. Chtěl bych v budoucnu přejít na něco lepšího, ale ještě jsem se tomu moc nevěnoval. Co jsem si zatím odnesl:
- neexistence stránky pro debily jako je toto (severity: blocker)
- neexistence kitu za $4, i když Arduino stojí $4 a STM32 je levnější než atmega (severity: nepříjemné, v nejhorším si nechám vyprdnout várku v Pragoboardu a po nocích to připájím)
- launchpady a podobné vývojové desky často dodávané jako hardware i software jen s podpisem smlouvy, že z toho nebudu stavět lítací věci, zbraně a jaderné reaktory (severity: low, dá se řešit použitím ChibiOSu)
SPI se hodí na vypálení programu. Připojíš kablík, vybereš soubor, klikneš, odpojíš, restartuješ. Musíš koupit neo postavit převodník USB-SPI, to rozhodně není ani levný, ani triviální.
USB programování (např. u AT91SAM) je z pohledu uživatele stejný, akorát stačí přímo připojit USB kablík k procesoru a nepotřebuješ programátor - vlastně je to za cenu USB konektoru a dvou rezistorů a jumperu ERASE na desce.
Na jiný rozhraná (A-UDI, H-UDI, SBW, IEEE1149.1, IEEE1149.7, PDI, ...) taky potřebuješ adaptér, Obvodově i výrobně zhruba na úrovníi toho SPI, ale můžeš si s tím v připojenám procesoru spouštět a zastravovat program, vyčítat a nastavovat registry, koukat do paměti a editovat ji, vidíš na PC registry jádra,... To SPI neumí a je fajn ukázat začátečníkovi, že když v tomhle registru změní tohle číslo, tak se ta ledka rozsvítí.
Takže nechápu, proč někdo při dnešních možnostech používá SPI, když má proti jiným metodám omezený použití a proti USB bootloaderu v ROM vysokou cenu. Je to si jako šlapací auto.Pomalý a nadřeš se víc, jak na kole.
> Musíš koupit neo postavit převodník USB-SPI, to rozhodně není ani levný, ani triviální.
Trivialita: AtMega + krystal + 2 kondíky.
> Takže nechápu, proč někdo při dnešních možnostech používá SPI když má proti jiným metodám omezený použití a proti USB bootloaderu v ROM vysokou cenu.
Protože se ta AVRka nedodávají s USB bootloaderem a žádné jiné rozhraní to nemá.
"Protože se ta AVRka nedodávají s USB bootloaderem a žádné jiné rozhraní to nemá."
A jsme zase u toho. Proč používají proprietální jádro na čipech někoho, kdo neumí pořádně vyrobit procesor* a nechají se omezovat jeho možnostma?
Odpověď: Je to nemyslící stádo, který skočí po první nabízené možnosti a ani se nepodívá, jaký jsou dnešní reálný možnosti...
*Aby to nevypadalo, že jsem na Atmel nějak vysazený, tak tři příklady z praxe:
- ATXMEGA64D3, low power zařízení, požadavek na život z CR2032 po dobu jednoho měsíce. Atmel slíbil, že odběr procesoru ve spánku bude pod 3uA, při probuzení, změření data a zpracování jednou za 2s to vycházelo na 4,6uA. Realita? Nějakej debil u nich nastavil časvač na náběh RC oscilátoru na 500ms místo na 0,5us, průměrný odběr 47,5uA. Přišlo se na to v den, kdy shodou okolností deska prošla na EMC a den před tím dorazily do fabriky brouci na prototypovou výrobu... Nakonec se Atmel přiznal, že tohle netestovali (a byla to key feature, kvůli které si zákazník ten procák vybral).
- Řada AT91SAM7, periferka SPI. Na papíře vypadá nádherně. Rychlá, s vlastníma DMA kanálama pro čtení i zápis, 4x chip select, buďto s binárním ovládáním (15 obvodů na sběrnici), nebo každý extra (4 obvody na sběrnici). Jásal jsem, že zápis do velké SPI FLASH půjde s pomocí DMA po blocích přes dva buffery a bude tam krásná datová prostupnost. Realita: nějakej debil to udělal tak, že pokud DMA přeplo buffery, shodil se chip select. Takže nakonec to dopadlo tak, že navíc musel modul SPI sahat i na piny... Nadšení se změnilo v nasrání, naštěstí jsem to podchytil během tří hodin.
-AT91SAM9260, pin JTAGSEL. V dokumentaci pulldown, přepni připojením na tvrdých +3,3V. Tak jsme to udělali a ono to bylo vztažený proti napájení jádra. Měli jsme pět desek, než jsme na to přišli, tři byly v křemíkovým nebi. Takže objednání dalších procáků a přepájení, tři týdny zpožděný projekt... No tak se prostě ta další splátka hypošky zaplatí o tři týdny pozděj, no. Kvůli debilům z Atmelu...
A mohl bych pokračovat ještě dlouho. Takže asi tak...
> A jsme zase u toho. Proč používají proprietální jádro na čipech někoho, kdo neumí pořádně vyrobit procesor* a nechají se omezovat jeho možnostma?
Vždyť o tom tady v diskuzi píšu: Nenašel jsem nic jiného pro co by byl snadno použitelný otevřený software s dobrou dokumentací.
> Odpověď: Je to nemyslící stádo, který skočí po první nabízené možnosti a ani se nepodívá, jaký jsou dnešní reálný možnosti...
Můžeš nějakou takovou možnost uvést? Myslím, že bych to já i mnozí ostatní ocenili.
[cynismus]Spíš kyty za 50Kč u mamuta, ne?[/cynismus]
Když bude drahý kit, budete si stěžovat, že je moc drahý.
Když bude levný kit, budete si stěžovat, že ho nemají v GM/GES a poštovný je dražší, než ten kit.
Tak si konečně ujasněte, co chcete. Pokud s chcete něco naučit, tak je to investice do budoucna. Nevím, proč by za to 10% jednoho měsíčního platu nestálo za koupení kvalitního kitu.
Pokud jde jenom o hobby, tak na jednu stranu není člověku líto vyhodit třeba 20 litrů za telku a jenom u ní večer pasivně slintat, pětku za tablet, aby si mohl večer číst v betli,... A když si pak najde koníčka, který rozšíří jeho obzory a procvičí mysl, tak je mu zatěžko si koupit literaturu a nádobíčko? To nechápu.
By the way, tipněte si, na kolik manželku vyšel dvouletý kurs kresby na VŠ nebo poslední sada 200ks profi pastelek...
> Když bude drahý kit, budete si stěžovat, že je moc drahý.
Trochu. Výše jsem psal, že si nemám problém je vyrobit.
> Když bude levný kit, budete si stěžovat, že ho nemají v GM/GES a poštovný je dražší, než ten kit.
Nic o GME jsem nepsal a kity v GME nekupuji. Poštovné z eBay bývá většinou zadarmo. Arduina (klony) jdou koupit i u českých distributorů za pár korun.
> Tak si konečně ujasněte, co chcete.
Něco jako Arduino, ale s ARMem místo AVRka :). Píšu to v této diskuzi pořád.
> Pokud s chcete něco naučit, tak je to investice do budoucna. Nevím, proč by za to 10% jednoho měsíčního platu nestálo za koupení kvalitního kitu.
Protože občas něco ubastlím a nechám to tam. Tak nechci aby ten kit byl moc drahý.
> Pokud jde jenom o hobby, tak na jednu stranu není člověku líto vyhodit třeba 20 litrů za telku a jenom u ní večer pasivně slintat, pětku za tablet, aby si mohl večer číst v betli,...
Nemám televizi ani tablet. Mám kolo a to i součásti na něj vybírám z těch levnějších.
Neco jako Arduino ale s ARM?
ST ma radu "Nucleo", rada vyvojovych desk s ruznymy STM32 procesory, format Arduina, je to "levne", nektere podporuji MBED.
Freescale ma radu FRDM desek; jsou drazsi nez Nucleo, ale zase mate na desce nejake senzory se kterymi si muzete hrat a nemusite bastlit shield. Nektere take podporuji MBED.
TI ma radu desek LaunchPad, format neni kompatibilni s Arduino. Maji i verze s ARM procesory, treba Tiva. Tyto desky se pouzivaly take pro edX kurz - "Embedded Systems - Shape The World".
Pripadne take ChipKit s PIC32; neni to ARM, ale 32 bit to je. Desky jsou ve formatu Arduino a pry maji nejlepsi kompatibiltu co se tyka funkcnich pinu na Arduino konektorech (ADC, PWM, SPI, atd). Nektere PIC32 procesory se vyrabeji i v DIL pouzdru, treba PIC32MX150.
Víc než 10 let se živím vývojem na jednočipech. A za tu dobu vím, že šmrdlání pinama je 5% mé práce, posuzování vhodnosti / nevhodnosti konkrétních brouků a periferek asi 15%. Bastlíř to asi vidí jinak...
Je to asi osm let, co jsem byl zapůjčen za nemalý peníz do firmy, kde dělal x let na jednom produktu člověk, co neznal nic než Atmely a pojímal projekt stejně, jako tady nějaký Jenda. Tzn. vzal to, k čemu bylo nejvíc dokumentace a hrál si bez abstrakce a v ASM, aby viděl, co se děje na HW úrovni. Výsledný produkt vypadal OK, ale jenom do chvíle, než přišel zákazník a řekl řediteli, že by měl zájem o modifikaci jejich produktu, ale s jiným jádrem procesoru, pro který oni mají koupenou nějakou knihovnu. A chtěl to za 3/4 roku...
Panu "programátorovi" to řekli po podpisu smlouvy. V té chvíli pochopil, co je to relativita času... Překlopit 60kB kódu v ASM na jinou platformu, když ani neměl HAL (Hardware Abstraction Layer) a byl pod permanentním časovým tlakem, ho dostalo do nemocnice. Takže pokud to myslíte vážně, neinspirujte se na "dokumentaci" v podobě příkladů od hobby nadšenců, kteř jsou v knížce tři stránky před váma. Učte se spíš best practices od profesionálů. Ona totiž kvantita neznamená kvalitu ani v dokumentaci.
Na jiných platformách tyhle příklady těžko najdete, to je fakt. Tam se předpokládá, že člověk má nějakou představu o tom, jak funguje počítač, jak funguje HW, co je to registr, jak udělat multitasking, jak implementovat stavový automat,... Metoda učení, kdy stáhnu příklad na blikámí LEDkou na portu a zkusím změnit pin nebo port bez toho, abych pochopil souvislosti kolem, je celkem k ničemu. K učení je potřeba Aha efekt, bez něj se to nikdy nenaučíte.
Souvisí to tak, že vynechá HAL a pak to nerozjede na ničem jiným bez kompletního přepsání. Protože mu nedochází při psaní na jedné architektuře, že dělá něco blbě a že by měl nějak oddělit problém od železa.
Architektur musí člověk poznat několik, aby odhadl, kde hodit dělísí čáru mezi řízením HW a mezi vlastním řešením problému.
A pokud chce těch architektur poznat několik, proč začít zrovna jendou z nejhorších a nejkomplikovanějších?
- Harvard: nic z toho děcko nebude dělat, je otázka, kolik lidí se s tím setká na VŠ. Naopak je dobré, že program je extra od dat a nehrozí vzájemné ovlivňování, navíc je malá RAM super na pochopení problematiky paměťové efektivity i u malých projektů a na reálné příklady na zásobník, frontu apod.
- Ano, to s RAM a flash je nepěkné. Kolik začátečníků se k tomu problému dostane? A když už, tak aspoň pochopí význam ukazatele a nevýhody harvardu oproti von Neumannovi...
- S wiringem jsem nikdy nezaznamenal jediný problém s šířkou datové sběrnice. Když už nebudu používat Arduinovský Wiring, tak bych už měl být dostatečně pokročilý, abych dokázal pracovat s wordy a byty a uvědomoval si rozsah proměnné, což spousta lidí vesele ignoruje, viz nedávné přetečení rozsahu počítadla na YT.
- "obecné chyby" kvůli kterým bych si neulevil neznám a přesto má peristaltika funguje bezproblémově, když na problém narazím, tak ho začnu řešit a vyřeším, tak jako v běžném životě...
- Hmmm, tak nechat člověka dělat hardware, pracovat s mikroprocesory a snažit se ho to naučit a pak pronés "aby nemusel řešit, jak funguje železo" mi přijde jako úsměvný protimluv. Tak buď ty lidi chci naučit hardware a nízkoúrovňové programování, pak musí tom "fungování železa rozumět" a nebo je chci naučit jen software ve vyšších jazycích, pak neřeším HW a neprogramuju na mikroprocesoru. Pak můžeme řešit Python, C++, Javu a RPi... Ale vybrat si mikroprocesory a nechtít řešit HW je fakt dobrý vtip.
- Na SPI jsou v Arduinu knihovny v úrovni obecného protokolu i protokolů konkrétních zařízení. S debuggingem je to v mikroprocesorech vždy náročnější, ale u začátečnických projektů si imho s UARTem a výpisy člověk vystačí, většinou ani není potřeba JTAG a AVRStudio...
Prostě Arduino je hračka pro nemyslící blázny, kteří věří ve výkon úměrný počtu jader a gigovou LAN na desce s pamětí, taktovanou na 400MHz. A nekoukají na princip toho zvolenýho řešení.
Tohle je blábol už proto, že Arduino a nějaká jádra a gigová LAN na desce tam prostě není. To je mýlka s RPi.
STM32: LQFP64 je skvělý package pro začátečníka. Jsou na to parádní patice a skvěle se to pájí... A "komunita" v podobě "polopatického návodu od Marda" je pro začátečniky taky jistě postačující zdroj...
LaunchPad vypadá velmi zajímavě, ale má jeden drobný nedostatek. Ani GME, ani GES neprodává vůbec nic z rodiny MSP a objednávat to s poštovným v dvojnásobné ceně není asi úplně ideální...
Pokud je chci naučit pracovat s MCU na úrovni hardware, udělám jednu smyčku s přímým řízením registru. Pochopí to, ale jak se dostanou ke složitějšímu projektu, tak se v tom ztratí. Rozdělit problém podle úrovně abstrakce a metoda "rozděl a panuj" je u většího projektu nutná.
U AVR konkrétně je problém i naprogramovat výraz y=5x+3 v assembleru.
Obecné chyby ne, ale už jsem zažil 3x situaci, kdy jsme na AVR tři týdny hledali problém a nakonec se ukázalo, že je to v křemíku a že o tom Atmel vůbec neví. Zašlo to tak daleko, že jsme v bývalé práci měli zákaz používat Atmelácký brouky, který jsou na trhu míň jak dva roky. Některý periferky jsme, pokud záazník trval na AVR, realizovali externě. Tolik k tomu jejich skvělýmu provedení.
Práce s jednočipem není o nízkoúrovňovýnm programování periferek. Je to o stylu myšlení a abstrakce problému. To, že je tam potřeba "šmrdlat pinama" je v praxi jenom nepodstatný detail, který pokryje BSP a zbytek aplikace musí být platform independent. V opačným případě by firma měla problémy.
S debuggingem to neí o nic náročnější, než na PC. Pod Linuxem používám vždycky GDB, ať jde o desktop, nebo o jednočip. Jenom v případě jednočipu je GDB server schovaný na PC a připojený přes localhost, komunikuje s driverem adaptéru a z pohledu ladění není rozdíl.
AVR Studio je dávno out. Teď máme Atmel Studio, který je založený na M$ Visual Studiu, je 3x pomalejší než Eclipse a funguje mnohem hůř než dřív. Rozhodně nebrat.
Co se LQFP/TQFP týká, tak to je snad normální pouzdro. Ručně se pájí líp než SOIC nebo DIP, navrhnout desku není problém,... A jsou i horší pouzdra, fpBGA, CSP, QFN, DFN,... A i s tím se dá pěkně bastlit v domácích podmínkách.
GES a GM nejsou argument. To bych nesměl používat třeba BQ24070 pro zálohování napájení a řešit to tranzistorama a operákama...To, že v sámošce nemají kondomy ještě neznamená, že člověk rezignuje na plánování rodiny a množí se jak katolík.
Ke grafice asi nepomůžou, tam je malina lepší volba. Banánu kulhá grafika.
Pokud je potřeba zpřístupnit HDD přes Sambu, nebo vyrobit domácí GIT server s podporou CI, tak je zase lepší banán a správa po SSH místo klávesnice a displeje. Malina vyžaduje navíc něajaký udělátko pro připojení disku na USB a má malou prostupnost dat (chabrus RAM, pomalej Ethernet, všehno na jednom chabým USB2,0).
Reagoval jsem na podporu obecně. U maliny se stačí zeptat na fóru a najde se někdo, kdo už to řešil a je ochotný poradit. U banánu platí "pomoz si a bude ti pomoženo".
Právě že pomoz si sám je u Banánu v míře větší než malé. Však donedávna (na R1) se řešilo, proč vypadává hard disk, až teprve nedávno někdo vyhackoval, že se musí aktivovat jedno nezdokumentované GPIO, aby to běželo dobře. Wifi dodneška nechodí atd. atd. Tohle je mi opravdu težké uznat jako výhodu.
A že Raspberry chodí na první dobrou z něj dělá desku pro nezdatné? Já to beru jako nutný základ, znalosti neznalosti.
Přeci jen, člověk si tu desku pořídí, aby s ní něco dělal. A tím něco myslím právě ten GIT server, Sambu apod.
A ne hledal "co číňan nedomyslel/neřešil".
Ale přiznávám, jsem jedovatý. Právě že R1 jsem si pořídil na router se Sambou a diskem. A bohužel mi k tomu ta deska doted neslouží. Vkládám naděje v tento seriál. Do té doby (čekám na novou verzi OpenWRT, to mi chodí nejlíp zatím), mi leží investice do Banánu bez jakéhokoli užitku. Proto jsem jemně nevrlý na argument "ale papírově je to lepší a je fajn, že to neběží na první dobrou, člověk se něco naučí".
> AVR není pro začátečníky zrovna ideální volba, zbytečně to komplikuje návrh...
To mi není jasné, jako věčnému začátečníkovi :) mi přijde oživit AVRko mnohem jednodušší než oživit nějaký ten ARM (u AVR si stačí přečíst jednu stránku na wiki, připojit na SPI Arduino nebo nastrkat drátky do paralelního portu a spustit avrdude). Jestli jsi myslel návrh plošňáku, tak taky -- s interním oscilátorem to nemá žádnou součástku :), s externím krystal a dva kondíky.
by me zajimalo, jak dite presvedcis, aby si do arduina zkompilovalo a nahralo program.
prave ze ve vyuce to musi fungovat stylem stahnout NOOBS, naklikat "nejaky system" a pripojit predpripravenou desticku s ledkou a hele ono to sviti. kliknu na jinou ikonku a ono to bzuci. a teprve az je dite zaujate, tak do neho muzes zkusit drtit nejaky programovaci jazyk. arduino mi proste pro uplneho zacatecnika prijde prilis slozite.
a pro info - komunita plne zacatecniku je z principu nevzdelana :)
by me zajimalo, jak dite presvedcis, aby si do arduina zkompilovalo a nahralo program.
Celkem jednoduše. Učím na gymplu a momentálně mám pár terciánů (13 let), kteří si sami podle návodů na internetu udělali zatím jednohlasý "synťák" z disketovky a přehráli na něm PWMkovou modulací pohybu motorku ruskou hymnu (jo, jsou trochu extravagantní :-)).
Jeden sekundán (12 let) momentálně řeší úkol napojit robotickou ruku s DC motorkama přes h-můstek na ethernetový shield a ovládat ruku přes http protokol. Zcela samostatně zvládal ovládat robotickou ruku pomocí motorového shieldu řízeného přes seriovou linku. S http serverem v ethernet shieldu jsem mu sice musel pomáhat, ale problém nebyl hardwarový, ale softwarový (parsovat v céčku korektně http protokol není triviální). Princip h-můstku pochopil celkem rychle, nakonec jsme ale stejně využili L293D, zapojil si to podle datasheetu už sám.
Ve výuce to rozhodně stylem "kliknu a ono to bzučí" fungovat nemůže. Záleží děsně na věku těch děcek, já jsem zvyklý už na "starší", čili dejme tomu od těch 12 let. To jsou děcka už dostatečně inteligentní a zvídavá, abych jejich mozečky zatěžoval přemýšlením a netvrdil jim, že programování a návrh obvodů je nezodpovědné klikání metodou pokus omyl. To pak vznikají "programátoři", kteří jsou zvyklí tímhle způsobem řešit firemní zakázky a to je špatně. Krom toho, instalovat cizí projekty ty děcka nezaujme. Že rozběhnou linux na malé destičce pár z nich pro jednou uspokojí, ale s tím se dlouhodobě nevydrží.
Arduino je oproti RPi pro začátečníka naopak o dost lepší v tom, že výsledkem je hmatatelná konkrétní věc, ne "simulace" ve Scratchi na monitoru osekaného pcčka. Na to stačí PC nebo tablet, proč kupovat RPi? No a ovládání periferií je ve Wiringu opět mnohem jednodušší, než učení se pythonu, který komunita RPi tlačí, nebo ovládání přes BASH. Žádné jaderné moduly, žádná neatraktivní příkazová řádka, ale příjemné IDE s pár jednoduchými příkazy a jedním talčítkem pro upload.
cti co pisu. nebo snad ten tercian co ovlada robotickou ruku, zacal rovnou timhle? ne, nejprv se naucil aspon nejake zaklady, vedel co to vubec je programovani, co je to cip, sbernice atd., pak mohl delat pomerne komplikovany projekt s roborukou. desktopove pocitace znal urcite dobre.
Právě že čtu... Když si přečteš ještě jednou mopu reakci pochopíš, že mi jde o nesmyslnost tvrzení, že Arduino je pro ty děcka příliš komplikované a RPi jednoduché natolik, že to přináší výhodu.
Ten sekundán (ne tercián) RPi nikdy v rukou nedržel (teda asi ho viděl v provozu na dni otevřených dveří, kde bylo jen nabootované do Raspbianu a nic nedělalo) a nijak ho to nepoznamenalo. To RPi je na určité typy úloh šikovné -- obecně na síťové aplikace, taky budu chtít aby pokračoval ovládáním té robotické ruky s RPi, mimojiné i díky možnosti webkamery.
Ale je nesmysl, že ovládání GPIO přes RPi je jednodušší než Cčkovým kódem ve Wiringu na Arduinu. Na Arduinu to děcko pracuje přímo na hardwarové úrovni a dokáže pochopit přímou vazbu mezi kódem vykonávaným jako instrukce z flash paměti spínáním IO portů. Na RPi je velkou barierou činnost operačního systému, celá struktura /dev a jaderných modulů, kterým nerozumí a nechápou jejich význam a činnost. Je to mnohem víc černá magie a experimentování pokus-omyl, než vzdělání, chápání a cílená intelektuální činnost mající myšlenku a její očekávaný a případně opravitelný důsledek.
Nechci tě podceňovat, ale já jsem se ještě nedostal k naprogramování jaderného modulu a opravdu nemohu zodpovědně říct, že přesně rozumím vazbě mezi OS a jeho moduly a stavem GPIO pinů procesoru. Natož aby tomu rozumělo děcko.
Btw. v čem je ten projekt s roborukou komplikovanější na Arduinu než na RPi? Vnější hardware (h-můstek) bude vyjma ethernetového shieldu stejný! Jen se přidá komplikované ovládání složitějším jazykem a vypořádávání se s vlivem OS.
ale ty jsi porad o uroven znalosti ditet dal. predstav si male dite, co do te doby pouzivalo pocitac jako BFU, o elektronice nic nevi, a chces ho zacit ucit nejakou elektroniku. dve moznosti:
1, das mu do ruky arduino, kompilator na desktopu a zacnes vysvetlovat princip mikrokontroleru, nahrani programu dovnitr, registry, cecko...
2, mu das do ruky RPi, coz je vlastne pocitac (to uz zna), a pustis scratch, kterym rozsviti ledku?
ja nepochybuju ze lecktere dite POSLEZE zvladne sestavit robota, a bude se jim to na AVRku delat lepe, nebude jim do toho prudit nerealtimovy OS, ale zacinat stavet robota, aniz by vedel co to je program a rizeni, to asi tezko.
na rozsviceni ledky na RPi neni potreba znat OS, moduly, /dev, jaderne moduly.
Ale tady přece nejde o to, aby děcko rozumělo systému.
Programuje se vždycky na nejvyšší dosažitelné úrovni abstrakce
Podívej se na ISO/OSI model. Když dáš dva stacky vedle sebe, tak zjistíš, že co tam pošleš na aplikační úrovni, to ti vypadne ve druhým na aplikační úrovni. Nevíš, co je mezi tím a ani to nepotřebuješ vědět.
Když bude k dispozici funkce RozsvitZelenouLED(), tak je to názornější, než nějaký PORTA.OUT &= 0xf7. Navíc to funguje bz ohledu na HW a na platformu - nezajímá tě, jestli se to pošle do jinýho procesoru po sériovce, nebo je LED na pinu procesoru, nebo je na SAA1064 s připojením na I2C. A o názornost, čitelnost a úroveň abstrakce jde především.
Jenže to pak končí tím, že děcka přijdou na inovaci, jak místo zelené LED použít červenou. Stačí vyměnit zelenou led za červenou, připsat novou metodu RozsvitCervenouLED, zkompilovat, odladit chyby a pochlubit se. A pak ještě vymyslet jak odbít všetečné dotazy, zda bývalo nestačilo místo zelené připojit červenou.
Zkrátka se bavíme o tom, zda používání black boxů je vhodné pro výuku nebo ne. Někdo black boxy miluje (nemusí se starat o to, jak to vlastně funguje). Jiní je nenávidí (třeba proto, že chtějí vědět, jak to funguje). Každopádně dříve nebo později se z black boxu stane problém. To pak máte krabičku, ke které je připojeno 8 LED diod. A vy je můžete ovládat. Ale jen všechny najednou. Takže zablikat jen tou první znamená nejprve zjistit, v jakém stavu jsou ty ostatní. A jediný důvod je blackboxová funkce, která bere 8bitů dat a nastaví podle nich diody. To je případ, který jsem zažil. Děcka byla dost překvapená, když zjistili, že tu funkci vůbec nemusí používat a můžou blikat diodami nezávisle na sobě. A nakonec přišly s otázkou, proč vůbec ta divná funkce existuje, když je k ničemu. Zkrátka autorovi knihovny to přišlo jako dobrý nápad. A naštěstí šlo knihovnu obejít.
Kde je problém? Přepájí LED, dají refactor na jméno funkce a vysvětlí se jim, že je nutný jména a kometáře udržovat konzistentní. To až tak složitý není (a kdyby jim to připadlo složitý, donuťte je používat Doxygen :D)
Stejně tak s dá namítnout, že si děcko vzpomene a hodí LEDku na jiý pin. Pokud ji ovládá z 10 míst, musí měnit program na deseti místech a hlídat si všechny výskyty, při abstrakci od HW stačí předefinovat makro s odkazem na port a makro s maskou pinu. A ví, že to změnil všude.
to tu hernajs nikdo netvrdi. prece nechceme, aby dite treba stavelo ss zdroj od nuly vcetne usmernovace z diod, kdyz ho bavi rizeni po sbernici a stourat se v protokolech...
zkusit priklad, a pote ho rozvest, doplnit, upravit, pripadne vymyslet novy priklad je prece bezna metoda uceni.
Upřímně Arduino sdílí některé neduhy o kterých mluvíš - hardwarově je ta AtMega úplně tragický procesor (za poloviční cenu koupíš ARM, který se s 8bit AVR nemůže srovnávat), alespoň pro mě ho drží jenom dobře zdokumentovaný software…
A který ARM v DIL pouzdru, aby měl aspoň tolik vývodů jako třeba ubohá ATmega8, máte na mysli? ( Myslím procesor, ne nějaký kit ) Aby ho dotyčný začátečník píchl do propojovacího pole a za chvíli mu blikala ledka, hrál reprák nebo se hýbalo servo? A co mu pro výuku dá, když musí zjišťovat, jak vlastně ta GPIO knihovna funguje, místo toho, aby se učil jak se konfigurují jednotlivé registry? Nebo vy na těch vašich ARMech konfigurujete periferie "ručně" pomocí editace kopy registrů a nebo používáte právě ony knihovny? A v asembleru by ten ARM byl opravdu jednodušší než ta příšerná architektura u AVR? Oba typy mají své opodstatnění, ale pro poznání a ošahání si té nejnižší HW úrovně je pro začátečníka asi opravdu vhodnější AVRko.
> A který ARM v DIL pouzdru, aby měl aspoň tolik vývodů jako třeba ubohá ATmega8, máte na mysli?
Žádný, přiznám se, že DIL neřeším.
> A co mu pro výuku dá, když musí zjišťovat, jak vlastně ta GPIO knihovna funguje, místo toho, aby se učil jak se konfigurují jednotlivé registry?
Měl jsem napsat že nejen dobře zdokumentovaný, ale i jednoduchý software.
Dil pouzdro? Co třeba http://cz.farnell.com/texas-instruments/msp430f2003tn/mcu-16bit-msp430-16mhz-dip-14/dp/1753249?ost=MSP430F2003&categoryId=700000004186? Když tlačíte na DIL pouzdro a cenu... A je to šestnáctibit. AVR není jediná architektura na trhu.
Jinak jsou pouzdra DIL na smetišti dějin společně s 5V logikou, TTL obvody, reléovou logikou a elektronkama.
A ono je jedno, jestli hledá informace o GPIO knihovně, nabo o registrech. U obojího se totiž musí myslet a to většinu lidí odradí.
A na ARMech je nejlepší způsob kašlat na knihovny. Napsat si vlastní BSP na mítu a je to. Assembler jsem zatím na ARMu potřeboval jenom jednou (úrava crt.s) a přišlo mě to mnohem jednodušší, než na AVR.
A AVR je horší, jak už jsem psal. Jiná šířka instrukční a datové sběrnice, složitější segmentace paměti, adresní rozsah pro program je 128kB a už používají větší FLASH, takže tam jsou další občůrávky. Zrcadlení konstant do RAM, která je už tak nedostatková a při prvním stack overflow se to začne chovat nepředvídatelně,.. ARMy jsou proti tomu s jednou rukou v poklopci.
Takovýhle komentář mohl napsat jenom ten, kdo neměl ARM nikdy v ruce.
> Dil pouzdro? Co třeba http://cz.farnell.com/texas-instruments/msp430f2003tn/mcu-16bit-msp430-16mhz-dip-14/dp/1753249?ost=MSP430F2003&categoryId=700000004186? Když tlačíte na DIL pouzdro a cenu... A je to šestnáctibit.
Psal "aby měl aspoň tolik vývodů jako třeba ubohá ATmega8". A tohle má neuvěřitelných 128 bajtů RAM.
> Jiná šířka instrukční a datové sběrnice, složitější segmentace paměti
Řeší můj kompilátor.
> adresní rozsah pro program je 128kB a už používají větší FLASH
Bavíme se o low-endových typech, které mají mnohem méně flashky.
ARM v DIL pouzdru? treba tenhle http://www.seeedstudio.com/depot/LPC1114FN28-ARM-CortexM0-based-32bit-MCU-DIP-p-1700.html
jinak je tu taky moznost vzit nejakou hotovou desku mensich rozmeru ktera se vejde i na breadboard, treba hledej na ebay "leaflabs maple arm"