Můj první počítač typu PC byla legendární 386 od AMD. Intel tehdy vyráběl 386 do maximálního taktu 33MHz a bez cache (nepředstavitelné že). AMD okopírovalo Intelácký design ale vyrábělo 386 na 40 MHz a s 8 kB paměti cache. Zrychlení o 7 MHz nebylo tak znatelné, ale když jste si hráli s vypínámím Cache v BIOSu - to byl rozdíl...
Takže parametry prvního PC, které jsem měl doma - psáno jazykem tehdejších inzerátů byly 386DX 40MHz 4 MB RAM 40MB HDD (ano opravdu 4 MEGA nikoliv GIGA byte RAM a 40 MEGA nikoliv GIGA nebo TERA byte pevného disku).
Z hlediska procesorové architektury je 386 CISC procesor který má většinu instrukcí typu REGISTR - PAMĚŤ takže v assembleru můžete napsat
ADD AX, BX - což je součet hodnot dvou 16 bitových registrů , ale taky můžete napsat
ADD AX, wordPtr [CS:BX] - což znamená, že k registru AX se přičte hodnota z adresy kam ukazuje registr BX - v kódovém segmetu. Z tohoto důvodu má 386 a následníci relativně málo regi strů (intel s každnou generací přidává a přidává) a tudíž musí relativně hodně číst z paměti což v době kdy procesor 8086 jel na 4,77 MHz stejně jako paměť vůbec nevadilo, ale dneska by to bez chache pamětí bylo smrtelné.
Pak jsem programoval grafické knihovny pro PC pod MS DOSem a tam mě strašně otravovalo jak mají PC procesory málo registrů, protože pokud kreslíte úsečku je ideální všechny koeficienty načíst do registrů a v dlóóóúhé smyčce počítat jenom adresy videopaměti, kam se nakreslí pixel, takže jediné přístupy do paměti jsou kreslení těch pixelů - to na 386 šlo ale za cenu drbání se "levou rukou za pravým uchem" kdy jste jisté registry museli uložit do paměti a pak je používat v rozporu s tím jak architekt procesorů 386 zamýšlel.
Pak jsem se vrhl na roboty a když jsem si vybíral procesor kterým je budu řídit hlavní požadavek byl srozumitelný assembler (proto jsem nevybral PIC) a dostatek registrů - proto jsem vybral AVR - což je 8 bitový RISC procesor jako z učebnice procesorové architektury.
Ono v podstatě není důležité, že AVR je RISC ale že je LOAD/STORE - to znamená, že má úplně jinou - mně více vyhovující - filosofii práce. Nemůžete sčítat registr s hodnotou z paměti, protože jediné dvě instrukce, které umí zapisovat do paměti jsou instrukce LD - Load a ST -Store (a pár jejich variant). Takže AVR se programuje, tak jak jsem vždycky chtěl programovat. Načtete hodnoty z RAM do registrů a pak na dlouhou dobu zapomenete, že nějaká RAM existuje, a zpátky zapíšete až úplně úplně definitivní výsledek.
No a dneska máme dobu 32 bitových MCU, kterých se zdá být obrovské množství, ale pokud vyloučíme amatérovi nedostupnou exotiku jako jsou Hitachi SH5 a výše, nebo NEC V850, jsou jenom 2 dostupné procesorové architektury - PIC32 - což je de facto MIPS - což je de facto jedna z nejstarších RISCových arcitektur (starý nečtěte jako špatný, protože MIPS je skvělý). Druhá amatérům dostupná architektura je ARM.
PIC / MIPS - nemá smyslu probírat, protože to je de facto AVR rozšířené na 32 bitů - správněji řečeno AVR je tak silně inspirováno MIPSem že se dá říct, že AVR je MIPS ořezaný na 8 bitů.
Zcela zvláštní architektura je však ARM - ten vznikl v roce 1985 jako 32 bitová náhrada za MOS6502 do školních počítačů BBC mikro. Byl designován malinkým týmem inženýrů, téměř bez peněz a jenom s pár měsíci času k dispozici. Tudíž tito byli nuceni dotáhnout princip KISS - keep it simple for the stupid - k dokonalosti.
Vzali nějakou generic RISC architekturu - podobnou MIPSům a dekodéru instrukcí vynechali jeden level - tím pádem ARM ve své původní podobě používá 32 bitů široké instrukce, které jsou tříregistrové takže mlůžete psát
ADD R1,R2,R3 - což znamená R1 = R2 + R3 navíc ale - díky zjednodušení dekodéru - jsou naopak instrukce komplexní - takže existuje třeba ADDEQ R1,R2,R3 - což znamená - spočti R1 = R2+R3, ale jenom tehdy když výsledek přechozí instrukce byl 0 (je nastaven ZERO FLAG). Mimo to mají ARM instrukce přímo bit jestli mají výsledek někam zapsat, nebo ne, takže každá aritmetická instrukce zárověň funguje jako instrukce porovnání. A aby toho nebylo málo tak ARM má "barrel shifter" - jednotku, která dělá bitové posuny, takže vrchol ARM Assembleru jsou instrukce typu
BICEQ R2, R3, ASR #3 - což je jediná instrukce, kterou pro ilustraci přeložím do 386 assembleru - předpokládejme že R2 = EAX a R3 = EBX
JZ je_nula - přeskoč celou sekvenci pokud je nastaven nulový příznak
SHR EBX, 3 - posuň EBX o 3 bity ( to je to #3 u ARMu )
NOT EBX - neguj Bity v EBX
AND EAX, EBX - udělej logický součin s EAX
:je_nula - toto není instrukce - jen adresa kam se skočí když není nastaven nulový příznak
Takže v extrémním případě 1 instrukce ARM = 4 instrukce 386 - počítáme - li že většina ARM instrukcí se dělá v jendom taktu procesoru, zatímco 386 měla 4 takty na instrukci - je jasné že při maximální optimalizaci může ARM udělat na stejné frekvenci až 16x tolik práce než 386.
Samozřejmě, že dnešní X86 procesory mají několik jader, a každé jádro udělá až 10 instrukcí paralelně v jenom taktu - ale my se tady bavíme o 386 a prvotním ARMu tedy o techologii začátku 90 let. Dodnes je to tak, že v tabletu máte 1GHZ ARM, který spotřebuje 5 Wattů a skoro se vyrovná nějakém CORE procesoru co spotřebuje 100 wattů - což je právě proto, že dědictví CISC prodesorů 70 let prostě nemůže x86 přeskočit.
Když už jsme u těch zajímavostí - tak protože dědictví 8086 nelze přeskočit musí jej x86 procesory obcházet - počínaje Pentiem II jsou vlastně taky RISC, ale před RISC jádrem je něco jako "hardwarový kompilátor", který překládá instrukce 8086 do vnitřního kódu daného procesoru, který je programátorům nepřístupný. Takže když máte na PC program v Javě - tak ten se překládá do bytekódu, bytekód se překládá do instrukcí 8086, ty se pak hardwarově překládají do vnitřních instrukcí daného Intelu, nebo AMD - mazec ne ?
Tudíž se není čemu divit, že když jsem experimetoval s 8 bitovým AVR a měřil jsem jeho ryhclost tak - z hlediska robotů mi vycházelo, že rychlost 16 MHz 8 bitové (!!) ATMega8 ekvivalentní 16-20 MHz 32 bitové 386. Takže už i ten nejjednodušší robot řízený "slušným" procesorem si nese "obnošené PC" na zádech ani o tom neví.
Možná teď už je čas napsat rovnou o co mi jde. Kdysi jsem byl příznivcem elektroniky pro roboty dělané na míru - ale jak stárnu a jsem stále lenivější - přešel jsem na koncepci "dostat do robota maximální výpočetní kapacitu" - což v akademické sféře dodnes znamená notebook přilepený izolepou na záda robota. Hardcore robotici, kterým bylo notebooku líto koupili router, místo firmwaru nahráli do routeru Linux a používali ten. Ani jedna ani druhá možnost samozřejmě není nic, co by se mi dvakrát líbílo, ale mám pocit, že tahle doba pomalu končí, protože lidi si velice zvykli na ARDUINO a tím se naučili používat "malé destičky s procesorem", kterých je dneska spousta a mnoho z nich velice vyspělých.
Když to zase probereme z hlediska uživatele amatéra - tak tady máme
- Rikomagic MK802 - počítač velikosti větší USB flashky - de facto procesor z mobilu bez displeje s androidem - podle mně nepříliš vhodný do robotů - spíše vhodnější pro "home theater" počítač.
- Raspberry Pi - taky "střeva z mobilu" - ale udělaný přímo jako "bastl pro bastlíře" - má svoji distribuci Debianu, a utáhne základní software jako internetový prohlížeč atd. - má všechny porty i volně programovatelné GPIO piny - laciné a skvělé řešení "hlavního procesoru" pro robota.
- vývojové kity od ST s STM32 a to s ARM Cortex 3 nebo s Cortex 4 - z mého hlediska mají jednu skvělou věc a to AD převodník snů - který digitalizuje až s frekvenci až 1 MHz - ideální řešení pro motory a složitá čidla. Navíc ty s Cortexem 4 mají i numerický koprocesor - může si robotik přát více ?
- Vývojové kity od NXP - rychlé ARMy "za hubičku", které sice nemají nějaké extra periferie - AD převodník mají až vysoké řady - dražší než od ST, ale pokud potřebujete 32 bitový výpočetní výkon za 70 kč - proč ne.
Tím jsme došli do bodu kdy musím sebekriticky přiznat - začátečníci - zvažte jestli začnete jako my staří "zespoda" a to assemblerem na nějakém 8 bitovém MCU, nebo tím "zkripleným" C na ARDUINU , nebo jestli půjdete "shora" - naučíte se psát prográmky pro PC v C a pak přeskočit na Raspberry a odtutd na STM32 ? Vzhledem k vývoji polovodičů se druhá cesta jeví skoro jako lepší.
Ode mně však v žádném případě neočekávejte, že vás přestanu otravovat s tranzistory, odpory a kondenzátory, protože můžete mít klidně procesor HCHKRDN na 20 GHz, ale pokud vám nefungují čidla a není čím pohánět motory - jste stejně v .......
Zbývá už jenom oblíbená rada pro blondýny : jsou chlapi, které i "ferrári za 10 mega" začne časem nudit, a pak jsou takoví co si s "destičkou za 600" se třemi čipy vyhrají několik let - jste si vědoma toho rozdílu ?
Petr G. | 25. března 2013 v 17:22
Jen pro doplnění, vývojovka STM32F3 DISCOVERY má AD převodník s max. rychlostí až 5 Msps