Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tyhle věcičky miluju. V práci pro některá embedded zařízení používáme 8086 a 80186 od AMD na 40 a 80 MHz. Cold boot DOSu do aplikace z flash čipu trvá 0,7 s.
Nebyl by dnes už lepší třeba Cortex-M? Kolik vlastně dneska stojí taková 186ka?
Někde používáme i ARM SoC s linuxem, ale pracuje se mi s tím mnohem hůř. Celé zařízení na průmyslovém boardu s 186 nestojí ani 5 tisíc, žere 2 W, a z 99% provádí idle/nop cykly. Příště asi stejný nebo podobný SW nasadíme na podobné zařízení s čtvrtinovým výkonem i RAM za poloviční cenu.
Jediná výhoda, která mě u [1]86 napadá, je, že se tím asi líp malosériově bastlí, a že to má relativně jednoduché připojení na externí DRAM, pokud člověku stačí kolem 1M paměti - mikrořadiče (i 32b) mají často mnohem méně, a ARM MPU s DDR čipy jsou zase overkill (plus je nemám jak zapájet...).
Sám marně pátrám po něčem podobném (úplně by stačilo asi několik MB externí RAM), jenže to zatím stejně vypadá, že za malé peníze nic lepšího než třeba RPi Compute Module neseženu, a navíc ten má mnohem lepší parametry (a sám naštěstí nepotřebuji "průmyslové" provedení).
Já jsem měl tou výhodou na mysli spíš rozdíl mezi tím, že zde mi naskočí DOS, inicializuje vektor přerušení pro nějaké základní služby (I/O, fs, socks, wdt, ...) a do sekundy loadne aplikaci, která má všechno pod kontrolou a jen pro sebe. Kompilace a ladění kódu na PC je triviální (jen přehazuju pár parametrů).
Desetkát výše taktovaný ARM s linuxem bootuje půl minuty a do běhu SW kecá dalších několik procesů a "fičur", jmenovitě oom_killer a overcommit. K vývoji si musím rozcházet VM s linuxem v ní GCC crosscompiler, který se kvůli pevným cestám hádá s jinými GCC, a v ideálním případě výrobce poskytuje supermoderní verzi 2.95.3.
Mno, já osobně to chci jako platformu pro (Active?) Oberon, a ten bootuje spíš ve stylu DOSu (bleskově) než ve stylu Linuxu. ;-) Takže takové věci jako embedded Linux a problémy s GCC cross-compilery jdou úplně mimo mě (a nevidím moc důvod, proč klást rovnítko mezi ARM a Linux - koneckonců "domácím" systémem pro ARM je RISC OS, ve stejném smyslu, jako že "domácím" systémem pro 8086 je DOS).
Jinak mi úplně nejde na rozum, proč by OOM killer a overcommit měly vadit v embeddovaných systémech, kde se programuje velice striktně (třeba často i bez dynamické alokace paměti). Když na Linuxu kompletně běží i SpaceX Falcon 9 (+ Dragon), jak je možné, že s tím nemají třeba problémy oni? ;-)
Hlavním důvodem (u mě) je fakt, že málokterý výrobce těchto zařízení poskytuje možnost kernel customizovat, překompilovat a nahrát do zařízení. Pak by bylo vše mnohem snazší. A ovšem, čistě s embedded softwarem klasického typu problém není, a obvykle ani s logikou kterou vykonává (ta vyžaduje konstantní množství paměti, často pár bajtů (v nvram)).
Tkví to v dnes se rozmazávající hranicí mezi embedded, RTU, PLC etc. a v zákazníky vyžadované bižuterii okolo jako je např. webový monitoring (možnost otevřít si v prohlížeči IP zařízení a vidět stav) nebo podporu připojení více master systémů současně. Každé spojení vyžaduje alokovanou paměť. Když dojde, chci aby odešlo FIN, ne kill procesu a wdt restartující hw. Jasně, je-li dynamický prostředek jen jeden, dá se to bez problému řešit bezpečným fixním limitem, je-li jich víc, už to není tak triviální, zvláště když člověk chce dodat zařízení schopné nabídnout co nejvíce.
No tak to ti doporucuji aby jsi se znovu podival na ty Cortexy...
Napr. http://www.nxp.com/documents/data_sheet/LPC11U6X.pdf
V deep-sleep rezimu (na ty tvoje nopky) si bere 350mikroA na 3.3V tj. spotreba 0.001W jestli pocitam spravne :)
CPU stoji 50kc, a vyvojova deska komplet s USB rozhranim kolem 1000,- Kc
Tyhle věci bohužel mají (pro mě) málo paměti. Nevíte o něčem s externí paměťovou sběrnicí a von Neumannovou architekturou (ne Harvard)? (Totiž o něčem, co ze dá koupit v tomhle Zapadákovistánu.)
V práci používáme LPC1788 s externí SDRAM. Kolega na tom po připojení displeje a SD karty rozjel Dooma :-)
Hmm. :-) Poznamenáno, děkuji!
to byl muj umysl, aby jsi nezatracoval cortexy, nevim kolik vykonu potrebujes poslal jsem link na ten nejmensi, to co si poznamenavas je M3 - ponekud vykonejsi model, neni problem to koupit u nas respektive pres web treba na tme.eu nebo farnellu
vice info: http://www.nxp.com/products/microcontrollers/cortex_m3/lpc1700/
dev kity: http://www.tme.eu/en/katalog/nxp-development-kits_112894/
Ehmmm? 8086 na 40 / 80MHz? Opravdu? :-O
Nemá to spise byt 4 / 8 Mhz?:-)
Pokud je mi znamo, tak 8086 se taktoval prave okolo 4MHz (sam jsem s tim mel XTcko na 4,7MHz), pripadne okolo 8 MHz
Jinak 80186 me minulo, mel jsem doma az s 80286 a tam byl maximalni takt okolo 25MHz (pricemz co se tu prodávalo, tak jsem mel v ruce desku s max 20MHz CPU a pretaktovaval jsem ji na 25 :-))
Ano, původně vyráběné čipy měly strop tam někde, ale dnes se tyto stařičké designy sekají menším procesem, takže 80 MHz pro ně není problém. Nebyla by problémem ani větší frekvence, ale pak už by čip neměl 0,3 W a koneckonců poptávka po tom není, protože 80 MHz na veškeré aplikace stačí s obrovskou rezervou.
Dobré zkušenosti které jsem zmínil jsou s těmito moduly:
http://www.icpdas.com/products/PAC/i-7188_7186/upac-7186ex.htm
A není nutné používat stařičké Turbo C. U mě tam běží moderní C++ kompilované novějším Digital Mars. Plus je bezpečné používat instrukční sadu 286, protože ta se od 186 liší jen v extra instrukcích pro prvotní "chráněný" mód, které samozřejmě user-módový kompilátor neemituje.
V práci používám DSTni-EX což je 80186 běžící až na 115MHz s 256kB RAM s integrovaným Ethernet PHY. Prodáváme 10ky tisíc přístrojů s tímto MCU. Používám buď BCC nebo Paradigm kompilátor.
To vypadá na hafo aplikací výborně, mohl bych tě poprosit o objednávací kód těch procesorů ? Nezajímají mne hotová zařízení, ale ten princip je my velice sympatický (o: Jinak jsme na tom podobně, také radši používáme malé systémy, dokdu není vyloženě nutné tam nacpat velký "linux". Každý ušetřený milion rádek se počítá :)
Díky :)
R.
Objednací kódy samotných procesorů neznám, ale pokusím se zjistit.
Čím méně tam toho je, tím méně se toho může pokazit (méně latentních bugů etc.).
Přesně tak... Pokud by to šlo sehnat v nějakém rozumném množsví a dostupnosti, byla by to naprostá paráda. Pokud by se podařilo, tak poprosím ray [] unreal64.net ;)
Děkujemeš
R.
Hmm. Opravdu je to založené na P54C? Já měl dojem, že to je spíš takový kočkopes založený na 80486 s přidaným debuggingem, performance counters, instrukcemi pro kompatibilitu s i586 ISA, řízením spotřeby apod.
Jinak taky nemá 512 kB L2 cache, ale 512 kB eSRAM.
Nekolik let pouzivam jako router/stahovac staricke AMD Geode GX@400MHz s deklarovanou spotrebou cca 1W. Bezi mi na tom Windows XP. Vykon nic moc, ale na torrent/downloader/FTP dostacuje. Nejvetsi spotrebu pak ma samozrejme stary IDE HDD. Limitace systemu je jen 512MB RAM. Asi vymenim za neco modernejsiho a Geode pujde na rizeni kotelny :)
Dublin Bay bol nedavno zruseny a nepojde do vyroby.
Nahradi ho az dalsia generacia Liffy Island.
No ten první Quark na demo-boardu Galileo je spíš pro smích - nic moc to neumí, např. GPIO jenom přes I2C, dost to topí (co do výsledné teploty) a celé je to dost drahé - cena samotného CPU není zřejmě úplně směrodatná. Hlavně že to má ACPI - proboha k čemu? A tuším někdo tvrdil, že Linux co na tom běží hlásí, že to má v rámci P54C i F00F bug :-) Uvidíme, s čím se Intel vytasí v dalších generacích. Já zatím doporučuji na hraní / vestavbu / automatizaci spíš Vortex86 (hlavně DX, případně SX, DX2, EX). Nejblíž u pramene SoCů je výrobce desek ICOP = další firma z rodiny DMP. Jede na tom samozřejmě DOS a samozřejmě Linux (bez úprav vanilkový Debian Squeeze, nevím jak Wheezy, chce to kernel i user space pro i486/i586). Nějaké mouchy by se jistě našly, třeba nulová dokumentace nových integrovaných periferií (motion controller ve Vortex86EX) ale standardní věci třeba včetně PWM GPIO jsou dokumentované dostatečně, a běžné PC periferie (třeba IDE) jsou v posledních generacích Vortexu už taky rozumně použitelné.
"A tuším někdo tvrdil, že Linux co na tom běží hlásí, že to má v rámci P54C i F00F bug"
Cože? Jak by to mohlo mít F00F bug, když to s P54C nemá pranic společného?
Má to F00F bug - nakolik s tím má nebo nemá něco společného zrovna P54C, to nejsem schopen posoudit :-) Ale řekl bych, že Quark, P54C a F00F bug cosi společného mají...
http://softwaretopreviews.blogspot.cz/2014/03/intel-galileo.html
http://www.linuxuser.co.uk/reviews/intel-galileo-review
http://en.wikipedia.org/wiki/P5_%28microarchitecture%29
Quark nemá mikroarchitekturu P5, takže třetí odkaz je irelevantní. Odkaz první a druhý spekulují, že Quark dotyčný bug obsahuje, čistě na základě toho, co kernel detekuje a zobrazuje při startu. Ale když se podíváte do příslušného zdrojáku, tak zjistíte, že kernel používá v tomto případě logiku "výrobce je 'Intel' a 'CPU family' je '5' => f00f bug přítomen" (viz třeba http://lxr.free-electrons.com/source/arch/x86/kernel/cpu/intel.c#L197). Jenže to doposud platilo jen proto, že jediné procesory od Intelu s touto CPU family byla Pentia s tímto bugem. To ale nutně neznamená, že jím trpí Quark, který má sice totožnou úroveň ISA, ale novou syntetizovatelnou mikroarchitekturu. Vy jen *předpokládáte*, že ji má, protože recenzenti *předpokládají*, že ji má, protože kernel *předpokládá*, že ji má. To mi přijde jako docela chabé. Vám ne?
Konečně se někdo podíval do zdrojáků :-) Já se na to vy$#al. Díky :-)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.