!!! "problémy s použitím ARMu tedy nejsou na aplikační úrovni, ale na úrovni obsluhy periferních zařízení" !!!
To je žel věta velmi pravdivá a je to velká škoda. Na PDA je nutné, aby bez problémů fungovaly záležitosti jako je obrazovka (dotyková část i zobrazovací), bezproblémové usínání a buzení, dále všechny ty saka co se na PDA dají připínat a tak dále. Žel PDA na Windows CE a jim podobných funguje halda, ale stav ovladačů pro periferie těchto PDA na Linuxu je žalostný.
Dnes si třeba linuxová jádra řady 2.6 na strojích H3800 nepustíte.
Stav je zřejmě dán zejména nezájmem výrobců se ovladači pro Linux zabývat a síla dobrovolníků a specialistů na zpětné inženýrství zde zatím selhává.
Nemám ani úplně nejlepší zkušenosti s plně linuxovým PDA Sharp Zaurus SL-6000L. Systém na něm je dost dobrý, ale člověk je tam nějak svázaný tím co v Sharpu dali dohromady. Pokud si pak řekne, že chce něco méně svazaného a založeného ne na QT, ale na GTK a šáhne po OpenZauru (obrazu založenéme na prostředí GPE), tak zjistí, že zde jsou ještě velké rezervy a to opět zejména v ovladačích jádra. Situace se sice stále zlepšuje, ale...
V tech ruznych hXXXX se moc nevyznam. Muzete nadhodit proc na h3800 nejde Linuxovy kernel 2.6? Na jinych hXXXX bezi?
Jinak s vami souhlasim, horsi to je o to, ze se zda ze i posledni pramen informaci z HP - tedy CRL (vyvojove laboratore) - vysycha a vsechno to "zpetne inzenyrstvi" je tak casove narocne, ze se jen obtizne da udrzet krok s vyvojem.
Pokud se nepletu, tak jde zkompilovat kernel řady 2.6 jen pro h3600.
Ve větvi jádra, kterou spravuje Russell King je již delší dobu (21.7.2005) k dispozici sada patchu od Jamey Hickse se základní podporou pro h3900. Ty ovšem Russell nepřijal - pochopil jsem, že se mu nelíbí nějak jejich struktura - tedy jejich způsob zařazení do jádra jako celku. Jamey Hickse mi psal právě v tom červnu, že až se mu podaří protlačit patche pro h3900, že se mrkne na h3800, které má mnoho periferií s h3900 společných. To vše bylo ještě před oznámením, že laboratoře CRL končí (což je asi zaměstnavatel Jamey Hickse). Žel Jamey Hickse zatím ani nereagoval na připomínky Russell Kinga, takže nevím zda se podpory jader 2.6 na strojích h3900 a h3800 ještě dočkáme.
Ofic. kernel se pro moc iPaqu prelozit neda, ale docela funkcni je kernel v CVS od handhelds.org. Rada 2.4 je skoro plne funkcni (pro mne uplne, ale neznam stav u vsech modelu) a na 2.6-ce se bourlive pracuje. Obecne doporucuji handhelds.org (hlavne wiki). BTW, mam H5450.
Jadro 2.4:
wifi - jede krasne
bluetooth - taktez
fs - existuje modul i userland sw, ale neni upstream (hh.org) - sw ale jen cte obrazky, neni implementovana autentizace (treba do pam nebo jinam)
Jadro 2.6 (zatim neni stable):
wifi - asi jede
bluetooth - jede, ale obcas to vypadne
fs - port toho z 2.4 (nezkousel jsem)
jinak 2.6 neni jeste pro h5xxx pripraveno, nejede mmc, display apod... 2.4-ka je ale stabilni a funkcni...
Uz asi 4 roky delam s embedded zarizenimi a s Linuxem. Zacinal jsem s i386 a letos jsem cele reseni prekopil na ARM. Nadchla me cena, nizka spotrebe snadnost a elegance programovani. Pokud pouzijete uClibc toolchain nacpete si super system tak do 4M. Jediny problem je s HW. Tady vcechach jsem toho moc nesehnal. Ale ve svete je nabidka siroka. Ted jsem dovezl moc pekne borady ARM200Mhz,32MRam,32Nand Flash,USB,ETH,COM,RS485,DIO,ADC,PC104. Pokud nekdo bude mit zajem ozvete se jeste nejake mam.
Programuje se to jednoduse. Napiste si soft na x86 odladite na pecku a pak crosscompilatorem prelozite. Je to hracka. Ja to pouzivam tak, ze mam root na NFS jsem na sshcknuty na borad na seriaku mam konzoli na pak pres remote gdb muzete debugovat. Program si prelozite na pecku kopnete do adresare co ma ten arm pripojeny na NFS a je to. Me to vyhovuje.
Nebo kdyz uz jsme u toho tak treba Asus router WL500g deluxe je dobra volba, za cca 3000Kc mate rozumny arm procesor s 32MB ram nejakou tou flash, ethernetem, wifi a usb2.0 v male krabicce. Hezky maly fileserver pro domaci sit nebo cokoliv jineho maleho. A bezi v tom linux uz od vyrobce s docela aktivni komunitou na wl500g.info Pro setrilky je ne-deluxe model s usb 1.1 a paralelnim portem, pomalejsim cpu a 16MB ram za cca 2600Kc. No nekupte to.
Ten deluxe si koupim jen co si ospravedlnim ze hracka za 3000Kc neni zas tak draha.
To sem zrovna nemyslel jak se programuje v C, ale jak se da nahrat obsah flashky. Predpokladam ze ten board dostanete panensky cisty a nejaky image se tam musi aspon jako prvni nahrat. Jde o to zda je moznost tu flash kompletne menit a co pouzivate jako bootloader.
Hmm, wiggler jsem zkousel, ale neuspel jsem. Jakej na to pouzivas soft? Ja jsem zkousel ocdemon od Macraigor (http://www.macraigor.com/full_gnu.htm). Ten bohuzel bezel na Windowsech, protoze linuxova verze Wiggler nepodporuje a k tomu jsem se pripojoval pres tcp/ip z GDB na Linuxu.
Jednou se mi povedlo se uspesne pripojit k targetu a pracovat s nim ale pak uz nikdy. A to jsme zkouseli vyrobit jeste jeden Wiggler, jestli to neni nejakym studenakem.
Kolega skousel i jiny softy, ale taky to nepomohlo. Existuje nejakej funkcni open source JTAG na ARMa?
No ja mel jednou pujceny board s ARMem od voipac no a povedlo se mi mu zborit flash a kilnout loader. Tak jsem zbastlil JTAG schma bych nasel pak jsem nasel soft pod Linux a nahral tam loader znova slo to clekem v poho. Jedine co bylo zajimave, ze to neslo pres muj Thinkpad, ale musel jsem to pripojit na LPT pecka. Asi nejake slabe budice na LPT u NN.
Popravde receno sice mam par ARMu v supliku, ale zatim jsem se do nich este nepustil, protoze mam rozdelanejch spoutu jinejch projektu.
Jak pravi kolega, zkus jinej pocitac. Mel jsem problemy s jednim programovacim adapterem (tusim ISP na AVR) a na notebooku fungoval pouze pokud jsem predtim pustil soft na programovani Xilinxu :-) Na PC ale funguje normalne.
Jasne chapu. NAND je rozdelen na 3 MTD partition v jedne je BOOT ROM, pak redboot monitor,a pak partisna na Linux. Pouziva se YAFFS2 vse se dodava s boardem vcetne zdrojaku.
Nabootuju s ROOT na NFS pak mount /dev/mtdblock2 /mnt pak do mnt kopnu system. Reboot a v redbootu si zvolis kde je root a hotovo.Jinak JTAG to bohuzel nema. To je mi trochu lito, ale nekde jsem nasel, ze se da priletovat primo na CPU.
Dobry den, o to bych mel zajem, mate nejaky datasheet? Poslete mi ho prosim na muj spam-mail cB0@seznam.cz (s nejakym rozumnym subj., abych ho neprehledl). Kolik energie to chce a jak je na tom s power savings mody? Diky.
Jo hned jsem volal, ale je k tomu potreba development kit :-( a to nemam rad dost to prodrazuje vyvoj a za druhe je to jen CPU modul a ten musis nekam strcit.
stejny kod lze zapsat (tedy jen o jednu instrukciu delsi, ale urcite BEZ skoku) i na x86 pomoci instrukce MOVcc, kde cc je stejna podminka jako u u skoku(pravda, tusim ze cca od pentia vyse, ale to neni uz dnes takovy problem). Vyhoda te instrukce je, ze bez skoku se nenarusi proud prefetchnutych instr (a dekodovanych mikroinstrukci)
(intel syntax)
call podprogram ; spust podprogram
cmp eax, 0
movb eax, -1 ; pokud selhal nastav do eax -1 (mov below)
movge eax, 0 ; jinak nastav R0 do 0
pokud jsem to pochopil blbe, a 'jinak nastav R0 do 0' znamenalo ze '0' je nejaky parametr, KAM se to ma z eax prenest, pak to lze vyse uvedenou instrukci take (jen prohodit operandy)
Jako nejvetsi nevyhodu intelu (x86) vidim hlavne maly (extremne) pocet registru, sileny FPU a to, ze nektere instrukce maji pevne dane sve vstupni/vystupni registry. Osobne bych se velmi primlouval, aby tato architektuar brzy zmizela a byla nahrazena nejakou lepsi (vetsina), ale to je asi jen sen...ach jo :(
Add movge etc.. je problem, ze to existuje az od pentia - a prinos je prilis maly na to, aby se vyplatilo si tim zaneradit kod....
Co se tyce x86 architektury, myslim ze u AMD64 vase stiznosti uz neplati. 16 registru 64-bitovych integerovych, 16 128-bitovych FPU/SIMD, to je vice nez rozumne... Cili radujte se, vas sen se splnil, x86-64 je realita.
Add MOVcc:
No, je to sice az od pentia, ale na druhou stranu by to mely prekladace delat samy (tedy pokud kompiluji sam s -march=...). Vim ze to je trochu z uplne jineho pohledu a nei to tedy tak vhodny argument, ale neco na tom je...
Add pocet registru:
MIPS - 32 general, 32 float...
IA64 - ted z hlavy nevim, ale taky podstatne lepsi
Nejde jen o pocet registru, ale take o to, ze dost instrukci (MUL, ...) maji pevne dany vstup a vystup, takze je jich jeste min... Nejvetsi problem asi IMHO je to, ze to bylo blbe navrzene uz v pocatku, ted je to zpetne kompatibilni a uz na tom jede moc SW, aby se to zrusilo (zejmena windows :(( )
AMD 64 sice moznosti rozsiruje, ale uz jen kvuli kompatibilite to moc zlepsit nemuze (zejmena to vazani registru k instrukcim,...) ale o AMD64 moc nevim, tak abych nekecal..
jednak MOVcc je az od pentia pro myslim (to pentium se mi nezda, tam to myslim nebylo), jednak pokud vim, tak jeste porad nema x86 treba CALLcc jak to mel jiz stary Z80, a jednak u ARMu jdou podminit vsechny instrukce (mozna existuji nejake vynimky, ted si nevzpominam), protoze to "cc" je napevno uvedeno v par bitech kodu instrukce.
Je to proste jina architektura, ma jine vlastnosti a jine prinosy. Nema vyznam ukazovat ze x686+ jiz ma MOVcc, protoze funguje uvnitr zcela jinak jako ARM a nemuze se mu v nekterych ohledech vyrovnat, prave tak jako ARM zase v necem nema sanci proti x86.
jj pokud se nepletu tak prvni ctyri bity v slove koduji podminku u VSECH instrukci.
Srovnavat ARM s xx86 je jako srovnavat hrusky s jabkama, nebo brambory s klobaskama.
napr ARM ma FIRQ, a tim padem muzete v vlastni aplikaci(HW/SW) delat veci ktere by byly jinak obtizne.
Na verzi ARMu tusim XScale jsem videl takovy maly super stroj. Velike jak obyc bigtower a az 96CPU. Jen ta cena. Ale ted to nemozu najit.
Daji se nekde sehnat jiz postavene moduly, ktere by se daly vyuzit pro prumysl? Momentalne napr. obcas pouzii mini-ITX s linuxem. Neco takoveho s ARMem bych privital.
Jak tady pise David Smolik, da, bohuzel u nas tezko. Jinak si troufam tvrdit ze modulu s ARMem je velmi mnoho, casto i s peknymi vyvojovymi nastroji. Staci chvili browsit.
No prave, ze moc neda. Podivej se na MITE, ty delaji DIMM moduly, ale je to dost drahe.
A hlavne mam z DIMM konektorem spatne zkusenosti. Pokud mas zajem napis na marvin at mydatex dot cz
Neni to spatne, ale je zajimave ze kdyz jsem hledal tak jsem nenasel. Ale jdou stejnou cestou jako MITE tj. CPU moduly a to me moc nevyhovuje. Ale to zalezi na co to chcere pouzit. 90% problemu co jsem kdy mel byl vyskoceny CPU modul z patice. Ted davam jednoznacne prednost vecem co jsou zaletovane.
Kromě CPU modulů mají v Tecu i celé řídicí systémy postavené na ARMu - jmenuje se to Tempo: http://www.tecomat.com/cz/produkty/hw/TEMPO/Index.html
Na stránkách to sice nemají, ale dělají i variantu bez displeje.
K Tempu už není potřeba žádný development kit, pro vývoj stačí obyčejné PC a pak už jen šoupnout do technologie a jet :-)
Ne nemyslel jsem soft jako kit, ale je to CPU modul a musis to nekam strcit. Tj musis mit desku co je na ni seriak a ethernet. Bez toho je ti to k nicemu. A to mi prave nevyhovuje. Ale nic proti tomu. Prave soupnout do technologie :-) ale tu musis mit. Ja mam board co uz ma vse na sobe zaletovane nic nevyskoci nic neupadne :-)
No jasne, dodaj jen jeden kus pres www.elatec.cz , to jsou teda totalni vocasove, ale mam to do prace, a tak neni nic problem. Pred vic jak rokem jsem od nich neco objednaval soukromne, a po vic jak mesicnim zpozdeni, kdy se furt vymlouvali, jsem mel dost neprijemny rozhovor s majitelem firmy. Pokud by nekdo z vas mel tenhle problem napiste mi, ja jim to pri tom, kdyz nam neco zase budou vnucovat pripomenu.
Hm takze klasika abych rekl pravdu takovehle zkusenosti mam po cechach vsude. Ted jsem zkusil amiky a jsem prijemne prekvapen. A hlavne k takovehle veci potrebujes podporu ne, ze se na tebe vykaslou.
Upresnim, ze ARM se pouzival na desktopech, a to celkem uspesne. Legendarnim se stal treba Acorn Archimedes, de facto standard v britskem skolstvi, ktery s prehledem drtil PC tehdejsi doby. Cetl jsem kdesi, ze interpretovanej BASIC na tomhle stroji byl srovnatelne rychlej jako kompilovany C na 286 s koprocesorem na dvojnasobnym kmitoctu. http://www.old-computers.com/museum/computer.asp?st=1&c=75
Dodal bych, že Gentoo embedded není zdaleka pouze pro ARM či jiné "malé" procesory, ale dá se používat všude, kde je potřeba spáchat maximálně osekaný systém, ať už z důvodu malé RAM nebo malého úložného prostoru (flash disk). Já ho použil na vytvoření systému pro starý 486 notebook se 4MB RAM. Princip je geniálně jednoduchý. Stáhnete si stage3 kompilované proti uclibc, uděláte klasické kroky, jako u normálního gentoo (chroot, nastavení make.conf..), syncnete portage a jste připravení generovat balíky pro embedded systém. Pak už stačí vytvořit si prázdný adresář pro nově vytvořený / , nastavit na něj proměnnou "ROOT" a naemergovat všechno, co tam člověk chce (a nezapomenout na základní věci, jako baselayout-lite a uclibc), přičemž k dispozici jsou samozřejmě všechny balíky co v portage jsou. Pak stačí přidat jádro a je vymalováno.
Zajimave, ja pouzivam uClibc toolchain. Stahnete z CVS pustite make config vyberete si programy co chcete a pak date make. Ono to zacne stahovat z netu veci kompiluje je to pro cilovou platformu. Taky myslim docela elegantni.
Pokud bych se jako vývojář měl chovat zodpovědně, nebude mě zajímat nějaké gentoo, emdebian a pod, ale buildsystém kde v několika krocích přeložím toolchains a sestavím base system. Z tohoto pohledu existují mnohem vhodnější věci, třeba buildroot nebo PTXdist (moje oblíbená ;-)) http://www.pengutronix.de/software/ptxdist_en.html
V této oblasti je totiž velmi důležité, aby se mi neměnily balíky pod rukama.
Tak zrovna s buildroot mám zkušenosti velmi špatné. Ze začátku jsem byl nadšený, že něco takového vůbec existuje, ale když mi to vzápětí na defaultní konfiguraci vyhazovalo jeden error za druhým a mnohé klíčové věci se tahají jako nějaké noční CVS snapshoty (co jste to říkal o těch balících, které se nesmí měnit pod rukama?) , co jednou chodí a podruhé ne, zanevřel jsem na to. Navíc mi to umožňuje opravdu jenom naprosté základy toho base systému a cokoliv nad rámec bych si musel dobastlit ručně.
V Gentoo si nastavím optimalizace a USE falgy pro cílový systém a pak už jenom dělám ROOT=systemek emerge <seznam všeho, co tam chci> a portage to vyřeší za mě včetně závislostí.
Abyste jste se z toho ze muzete kompilovat pro ARM nezblaznili linuxari ;) - ja si s klidem pustim sve eMbedded Visual C++ a zkompiluju si pro ARM nejakou tu windowsi aplikaci, pak si zapnu Platform Builder a jeste si extra pro svoji verzi ARMu kompilnu Windows CE 5.0 a nevidim v tom zadny rozdil ;) - a kdyz se mi zrovna nechce drbat s C++ tak si proste zapnu VS.NET a pisu si pro ARM primo v .NETu - resp. pisu si pro libovolnej procesor na kterym je .NET (CF) Framework ;)
Jo proc ne, at si kazdy uziva co chce. Jen by me zajimalo jak se ladi na veci u ktere neni monitor ani zadny jiny display jak si tam s temi Win CE povidas ?
neni problem si takovych 90% kodu odladit v x86 emulatoru no a zbytek si lze treba i tak napojit na virtualni monitor primo na monitoru pocitace - ale jinak se priznam ze zarizeni primo bez videokarty jsem jeste neladil - ale nekde uz jsem tu poslal link do MSDN takze tam by melo neco byt
mno, rozdíl je nejméně v tom, že když si teda "kompilnu" Windows CE 5.0 a objeví se nějaký záser třeba s rychlostí odezvy na událost, tak nesedím jak trubka a nenadávám na MS, ale problém najdu a odstraním, že? A ještě byste nám, mistře, mohl prozradit kolik těch libovolných procesorů je ;-). Ono totiž uchodit core s MMU jaksi není až tak težké, ale použitelný systém to nedělá.
Ale jinak souhlas. Nakonec je to jenom o tom, k čemu má zařízení sloužit a čemu rozumí programátor a je-li levnější nějakou vlastnost implementovat vlastními silami nebo implementaci koupit.
>mno, rozdíl je nejméně v tom, že když si teda "kompilnu"
>Windows CE 5.0 a objeví se nějaký záser třeba s rychlostí
>odezvy na událost, tak nesedím jak trubka a nenadávám na MS,
>ale problém najdu a odstraním, že?
V pripade ze jste registrovany partner MS tak mate k dispozici komplet zdrojove kody CE 5.0 a samozrejme si je muzete dle libovule upravovat aby sedeli prave tomu zarizeni pro ktere ted pisete no a pak si buildnete instalacni image v Platform Builderu.
No nevim, ale pokud jsem se zajimal o moznosti, tak mi do embeded M$ Sw moc nejede, zbytecne zvysuje cenu, tech $5 radsi necham jako zisk, nez platit, navic si muzu Linux nahodit tak jak potrebuju, jen to zakladni minimum.
S podporou od M$ mam osobne dost spatny zkusenosti, i kdyz jsme meli plny MSDN
pristup, vetsinu problemu jsem resil pres diskuzni skupiny.
Ted se zrovna chystam v praci neco zkusit, neco takoveho: http://www.elatecworld.com/eng_linux_sbc.htm, M$ Win jsou nepouzitelny, potrebuju upravit i linuxi kernel, jde o RT. Vim, ze na RT jsou specialni sytemy, ale Linux znam, a tak to zkusim na nem, nez se prat s http://freertos.com/.
Vzhledem k oblasti, ve ktere se podle sveho pohybujete, me zcela vazne napada jedna otazka. Uz nekdo napsal driver pro windows mobile 2003, ktery by umel vytvorit tcp/ip spojeni pres usbnet (videl jsem mass-storage driver, takze tohle by melo jit taky)?
Ono totiz ten zatracene pomaly emulovany seriovy port s ActiveSyncem me uz moc nebavi ;)
Popripade neco jineho na navazani spojeni pda+cradle <-> pppd nez je AS?