Názory k článku RISCová architektura PowerPC
-
Pavel TišnovskýZlatý podporovatelDíky :-)
Jen ještě dodám (do článku se to příliš nehodilo) odkaz na Tiobe, ze které vyplývá, že assembler ještě zdaleka neumřel (i když je pravda, že způsob dělání statistiky na Tiobe je kritizován):
-
Ja bych TIOBE a assembler taky bral s rezervou. V tom assembleru mohou být Arduina a jiné jednočipy.
Když už jsem u toho Arduina, ty Atmely jsou prý taky dost výkonné RISCové procesory. Samozřejmě, blbě se to srovnává, protože jednočipy jedou tak na cca 16Mhz, kdežto PC na mnohem víc. Tajně čekám, až někdo provede srovnání. Poměry výkon/cena, poměr výkon/frekvence, výkon/spotřeba, atd.. -
Pavel TišnovskýZlatý podporovatel
Jojo oni v tom článku spekulují, jestli ten vzestup je dán IoT, kde se používají různé krabky s Arduinem. A pravda ... ani nevím, proč jsem zatím Atmely odbyl jen miničlánkem, no uvidíme dále, co s tím :-)
-
Dobře.
Bylo, nebylo, před sedmi lety jsem v nové práci nastoupil na projekt, který měl předělat jeden produkt z end-of-life mikrokontroléru na ATXMEGA64D3. Na první pohled pohodový projekt, s novým procákem na 32MHz, ale jedno překvapení střídalo druhý. Takže pár úžasných dobrodružství:
Absolutně bezkonkurenčním králem je u téhle řady A/D převodník, který se nabízel pro sběr dat z čidel, na potvoru nelineárních. Slibovaných 12 bitů vypadalo luxusně, ale jenom do zjištění, že má dva režimy, bipolární a unipolární. V unipolárním nula není na nule, prý schválně, kvůli kapacitním senzorům. Takže šup do bipolárního režimu proti nule, rozlišení 11 bitů. Nepochopíš.
Reference ještě zábavnější. Čidlo mělo výstup rail-to-rail a přepočítávat kalibrace na 8b procesoru je kravina. Proč taky, když se dá u normálního MCU zapojit napájení čidel jako reference... Ne tak u AtXMEGA, kde bylo napájení 3.3V (a nešlo snížit), ale maximální napájení reference nějaký nedokrvený pyj navrhl na 2.4V. Takže srazit napájení pro čidla, šum na úrovni 3 LSB...
No a když je tam A/D převodník, proč ho nepoužít pro rezervní analogový vstup? Interní bandgap reference 1V, tolerance... moment, žádná není, v datasheetu jenom typická hodnota bez limitů a tolerance. No schválně, kolik tipuješ, že budce mít toleranci reference u 12b ADC? Podle toho, co napsali tři týdny od dotazu, mám počítat s 10% na obě strany. Takže zase poměrně trapná situace na úrovni sundávání push-upky, že.
Fajn byla i komunikace po UARTu, teda do okamžiku, kdy měla sestupná hrana na RxD probudit procesor pomocí přerušení. Ono na nožičce přerušení byl, ale synchronní. A jelo, jenom když byl port taktovaný. Ale požadavky na napájení jsme splňovali jenom s vypnutým oscilátorem. Jenomže pak se ten dacan při komunikaci neprobudil. Neberu si práci osobně, tak jsem mluvil o tom vývojáři jako "j" o Laelovi jenom asi tři hodiny.
Jo, a mají perfektně řešený brownout. Žral jim 128uA, ale deklarovali, že je to "MCU s nejnižší spotřebou na trhu". A co s tím? Brownout měl tři režimy. Vypnuto, zapnuto a vzorkování. V režimu vzorkování si čuchnul k napájení po 1us na 1/128us. Atmeláci mají buďto vytříbený smlysl pro humor, nebo nikdy nečetli o ESD. Každopádně je to na kopanec do jednoho varlete.
A když jsme u brownoutu, režim se volí pomocí fuses. A rozhodli se, že jde nastavit nezávisle pro spánek a aktivitu. Jenomže zase byli zdechlí testovat a pokud někdo nešťastnou náhodou nastavil systém tak, že spal, probudil se, něco udělal a usnul, jak to Atmeláci popisovali v whitepaperu, chtěl je kopnout i do druhýho varlete. Oni totiž svázali vzorkování brownoutu s časovačem, který připojil hodiny k jádru po startu oscilátoru a nikdo to ani nezkontroloval, ani neotestoval. Časovač expiroval asi po 0.5s a pokud bylo potřeba probouzení víc než 2x za sekundu, už to nějak nešlo...
NVM, to byl počin, který zařadil Atmel po bok legendárního prznitele technologií, M$. Jedná se o "Non-volatile Memory Controller" a sdružuje to paměť FLASH s programem a FLASH, používanou jako EEPROM, aby ušetřili místo na čipu, fuses atd. Samozřejmě se zabývali i bezpečností, takže před zápisem do NVM je potřeba zapsat klíč do speciálního registru a během pěti instrukcí (nebo několika málo, už se přesně nepamatuju) muselo dojít k zápisu. Další bezpečnostní featura je, že pokud dojde k přístupu do NVMM během zápisu, zápis selže. Ale nějak nepochopili, že instruction fetch je taky přístup do NVM. Takže pokud běží program, nejde zapisovat do NVM. Řešením je uspat jádro a probudit přerušením. Přerušení musí být povoleno instrukci před uspáním, protože flag je v době povolení aktivní. Navíc se musí přesně stihnout odemčení, povolení přerušení a uspání v přesné sekvenci a omezeným počtem instrukcí. Ale pozor, pokud přijde přerušení z jiné periferky, zápis se nepovede, protože jádro začne číst přerušovací rutinu. Záchranou bylo to, že mají tři úrovně přerušení. Tohle jsem dal a nejvyšší a nižší při zápisu zakazoval. Jinak by modul, simulující EEPROM, musel být nejenom v assembleru, ale porušit zapouzdření všech ovladačů periferek a kecat jim do povolování přerušení...
Jenomže zmršený brouk je jejich standard a měli snahu překonat sami sebe. Jak? Pomocí tajné zbraně, revize čipu. To takhle z výroby jednoho dne začali hlásit, že yield sletěl na 5%. Změnili revizi čipu. Změnu ADC zadali nejmenované stavební firmě, protože převodní charakteristika ADC se vlnila jak D1 u Ostravy, samozřejmě pro každý kus jinak, a vyhodili v rámci úspor jeden kalibrační registr. Tímto mistrovským tahem se z povinně zapisované adresy stala zakázaná adresa a po zápisu na ni se převodník zbláznil. Mimo to tam bylo asi jenom pět stránek nepodstatných změn, jako jsou posuny prahových napětí brownoutu, nějaký úlety v časování,... Dle technické podpory byla možnost objednat starší verze čipu, než to vyřešíme, ale nákupčí byli s objednávkou 10k kousků starší revize posláni tam, kde bych raděj viděl tým Atmelu. Dva měsíce jsme to řešili, než se produkce s novýma mrzáčkama dostala s yieldem nad 85%. Brrr.
A tak se dá pokračovat třeba o I2C, kde je workaround "nepoužívat", protože SDA zapomněl nějaký ostrostřelec vytáhnout na nožičku a tesťák zrovna asi vyplňoval formuláře, který jsou důležitější než jeho práce. A markeťák nechal v dokumentaci původní počet rozhraní, protože to líp vypadalo. Nebo o všech dalších periferkách, mimo event systém. Na ten jsem neměl odvahu, takže nemůžu soudit.
Jo, a tenhle znáš? Když XMEGu osolíš na 32MHz, vezme zi cca 0.8mA. Když je v RESETu, papá 1.3mA. Takže boot z měkkýho litiovýho zdroje ani náhodou, ani omylem. Brownout ho udrží v RESETu, dokud neodepíše baterku. Taky dobrej.
Naštěstí jsem objevil na problémy s Atmelem skvělý workaround. Změnu zaměstnavatele. Teď dělám s STM32 a mám (relativně) klid.
-
mhi (neregistrovaný)
Budte v klidu, treba Microchip ma tech bugu take pozehnane. Do dnesniho dne treba neopravili dva bugy - v CAN controlleru a v JTAGu. O obou vi uz nekolik let, dokonce mi jednou kvuli tomu volal nekdo z Indie na stedry den ... na support jsem jim po pul roce napsal, proc to alespon neni v errata, ani se neobtezovali odpovedet. Slo pritom o naprosto zasadni chyby, CAN controller se dal probudit zpet k zivotu po trivialni chybe jen resetem procesoru a ten JTAG zcela ignoroval nejakou cast standardu (nesly spravne chainovat dalsi soucastky).
Atmel nam taky driv daval vzorky nejakeho noveho ARM7 MCU, dostali jsme asi 10 vyvojovych verzi, ty posledni fungovaly podle ocekavani. Udelali jsme tedy objednavku, jenze ejhle, byla jeste jedna revize, pry na chlup stejna jako ta posledni co mame ... jenze v errata se najednou objevilo, ze asi 3 features toho MCU nechodi a odstranili je ... cipy nam najednou byly nanic. Jedna z tech features bylo, ze odstranili ochranu kodu pred vyctenim (neoficialni oduvodneni: stavalo se, ze se jim procesor nejak zamknul a nebylo jak jej preprogramovat).
-
Pavel (neregistrovaný)
trosku mi unika proc by nemely byt osmibity vyrobene stejnou (soudobou) technologii, jako Cortexy-M?
To jako porovnavame puvodni 30 let stare MCU s dnesnimi Cortexy? :)
schvalne se divam data sheet 8bitu a vidim: standby 1nA pro 2V, operating 8.5uA na 2V na 32kHz a 100uA na 1MHz - jasne ty frekvence muzou byt smesne, ale na nejake ty klavesnicky, casovani osvetleni, zavirani garaze, termostaty atd. je to vlastne az moc, to klidne muze jet na tech 32kHz
-
Miyuki (neregistrovaný)
Jo XMEGA krásnej koncept na papíře, škoda že to takhle zeslonili, mohla to bejt zajmavá alternativa, ale v dnešní konkurenci a s tim jak má Atmel nastavený ceny ... uplně stačí kolik chtěj za větší ATMEGA v porovnání s dnešníma cenama ARMů od konkurence
Víte někdo jak jsou na tom vlastně kvalitou ty ARM řady od Atmelu ? Jen tak ze zvědavosti, protože vzhledem k ceně je stejně zkoušet nebudu. Kupuje to vlastně od nich někdo ? -
No měl jsem čest s něčím takovým.
S ARM7TDMI (řada AT91SAM7) jsem měl čtyři projekty. Nebyly to špatní brouci, ale smysl pro Atmelácký humor se nezapře. Třeba u AT91SAM7X*, když RTC jede na RC oscilátoru s tolerancí tuším 1.5%. Běžně za hodinu ustřelí o minutu a hodinový krystal se připojit nedá.
Lepší byl ten vtípek se signálem JTAGSEL u AT91SAM9260 (ARM9EJ-S @ 200MHz). Tím signálem se přepíná JTAG mezi boundary scanem a laděním jádra. Má pull down, podle datasheetu se má přepnout připojením na +3.3V natvrdo. Tak jsme to udělali a brouk po smrti. No nedali tam pitomci ochrannou diodu na VCORE? Takže do jádra na 1.2V nebo 1.5V (už přesně nevím, jaká je to varianta, to druhý napájení je u 9261) šlo 3.3V. Takže odeslání desky na výměnu BGA...
Dál jsem to nesledoval, na Cortexy jsem se díval jenom v reklamních mailech, ale nějak už nemám chuť to koupit, zapnout a naštvat se. Šancí dostali víc než dost.
-
Je celkem možné, že se do assembleru počítají optimalizace kódu pro infrastrukturu kolem GPU. Je dost možné, že různě ručně optimalizovaných výpočetních jader něco existuje. Pak existuje mnoho podpůrných CPU/MCU na velkých čipech (různé management procesory) a real time "stavové automaty" realizované jako CPU AM3/4xxx PRU, TMS570 N2HET atd. Pokud se to nějak do statistik dostane, tak bych se nedivil, že nakonec množství roste.
-
No ono spíš jde o to, že do různých potvor pro RFID, USB interface a podobně, i dneska výrobci rvou zastaralou 8051 :( , která se nedá v ničem jiným rozumně naprogramovat :(
Třeba http://www.ftdichip.com/Products/ICs/FT51.html, u kterýho je "NEW"... :Q,
http://ww1.microchip.com/downloads/en/devicedoc/5617db.pdf, https://www.nordicsemi.com/eng/Products/Sub-1-GHz-RF/nRF9E5/(language)/eng-GB, ...A pokud mám věřit tomu, že 8051 je podle https://www.silabs.com/SiteDocs/selector-guide/mcu/efm8-selector-guide.pdf 25% současnýho trhu MCU, tak je ten ASM jasný :Q
-
Protože Microchip umí analogařinu, ale číslicovka jim jde jak Atmelu analogařina. No a po tom, co byl Atmel schramstnut Microchipem, jim podle známýho pravidla nepůjde ani jedno...
PICky jsou spíš takový hračky a nasadit je, nebo AVRka, na něco seriózního, bych měl strach.
Navíc AVR, PIC, H8, R8C, STM8,... jsou pod patentovou ochranou, to už u 8051 skončilo. Člověk ví, co od toho nečekat a stará škola na to slyší. Takže sázka na jistotu.
Já se spíš divím, že se někam narve 10+ bitový ADC s 8+ vstupovým MUXem a nechají tam 8b jádro na zpracování.
A pokud chceš rozumnýho brouka s málo nožiřkama, tak zase není důvod pro osmibity. Můžeš začít třeba na MSP430G1xxx od TI (RISC, 16b, 16MHz, od tuším 14 nožiček), ale jsou i Cortex-M0/M0+ v tak malých pouzdrech...
-
+1.
V dnešní době je nesmysl pracovat s architekturou, která má ALU užší něž je šířka adresy (hodně jednoduše podané kritérium). Dále je nesmysl lámat C na architekturu, kde void * nemůže být použitý pro předání dat z rodata (Flash) stejně jako z data (RAM). Pokud je nutné mít dva různé způsoby předání, tak se buď plýtvá pamětí, nebo kóde a pro složitější funkce s více parametry se jedná o kartézský součin. Pokud se něco nezměnilo, tak toto je na klasickém AVR zcela nedostupné. Existují různé způsoby obcházení tohoto problému. Na těch slavných 8051 to končí tak, že procesor lze považovat za architekturu s 8-bit slovem, ale obecný ukazatel je 24-bitů (to je tři slova). Z hlediska uměleckého a procvičení mozkových závitů je zajímavé se i po letech k této architektuře vrátit jako k puzzle. Nakonec pár oprav jsem i do SDCC poslal. Zkouším na něm přenositelnost některých mých divočejších C kontrakcí. Ale do jakéhokoliv reálného projektu je to zásadní ztráta času. Tedy pokud se nejedná o 100k+ kusů a obětování pár člověkoroků času na psaní z dnešního pohledu nesmyslného, nepřenositelného kódu neumožní vybrat sice špatný čip ale s takovou cenou, ročně úspory přinesou alespoň několik milionů.
Ale i takovou hrůzu, podle mě, lépe napíše člověk, který se naučil myslet koncepčně v C na soudných architekturách než ten, kdo se nikdy neposunul nad assembler jedné hodně omezené architektury nebo psaní v C pokřiveném "překladačem" sketchů.
S 8051 jsem bohužel pracoval hodně. S AVR nikdy. Ale třeba AVR32 mi již návrhem připadlo dobré.
-
Pavel (neregistrovaný)
Tak on je PIC (dnes i podle výrobce) spíš "programovatelná součástka", prostě náhrada za takové ty bastl zapojení s 555, posuvnými registry, demultiplexory, UARTy atd. - dneska se tam všude vrazí PIC a ušetří se za součástky okolo (tím se zvedne spolehlivost, to ostatně znáš...).
A právě proto, že se to používá všude (stmívače, domácí zvonky, asi i jednodušší termostaty) bych čekal, že budou mít větší čísla prodeje... ovšem víme, jak je to se statistikami.
ARMy a to i ty nejnižší Cortexy jsou naprosto jiná liga.
-
Jenže v dnešní době implementovat tu relativně hodně složitě kódovanou instrukční sadu 8051 s nutností řešit podle opcode dočítat jeden nebo dva byte a různě složitě adresovat paměť je nakonec mnohem víc práce než navrhnout nějaký jednoduchý i třeba jen 16-bit RISC, který i jen jako jedno-cyklový tu 8051 předběhne. Když se pak přidá pipeline tak na 8051 to bude noční můra. Na tom RISCu se to často ani moc nezvětší. Takže nakonec to 8051 neimplementujete jako 16 až 20-bit RISC s tím, že bude původní 8051 kód interpretovat s využitím fixního mikrokódu a to je již lepší dát uživatelům rovnou programovat v tom kódu toho RISCu. No možná trochu přeháním, ale jednoduchý 32-bit i 16-bit RISC jsme si v FPGA vyzkoušeli a myslím, že dokáži tu složitost 8051 vidět.
-
mhi (neregistrovaný)
Nevim, zda to byla reakce na mne, ale ve sporu asi nejsme, jasne, urcite bych uvital nejaky pekny 16bit RISC misto 8051. To by se ale mohlo prosadit jedine kdyz by na to byly vyvojove nastroje. Kdyz by to mohl kazdy vyrobce prsknout snadno do sveho obvodu. Oboji najednou se nikdy nestane, na to ma 8051 moc silnou pozici.
Cinan neumi ve Verilogu navrhnout procesor, oni jen vezmou to co existuje, neco k tomu dobastli a procesor je na svete. Podle me vetsina prodanych 8051 jsou prave ruzne specificke procesory z Asie. Statistiky pro to zadne nemam, vychazim z toho co vidim okolo sebe. Staci se jen mrknout na popularitu http://www.stcmicro.com/ ...
PS: Zajimave jsou udelane dsPIC ...
-
Kdo říká, že to není a nejsou? Měl jsem pár projektů na MSP430 a s 8051 je to nebe a dudy...
Je libo low power? https://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/overview.page
Nebo novější s vyšším výkonem? https://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/MSP432/overview.page
Hraješ si s rádiem? https://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/wireless_mcus/rf430/overview.page, https://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/wireless_mcus/cc430/overview.page
Potřebuješ 16bit s nízkým příkonem, co udrží bez zálohy data po vypnutí a rozhodneš si, kolik paměti bude RAM a kolik FLASH? https://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/ultra-low_power/msp430frxx_fram/overview.pageA vývoj? MSP430 GCC, není problém ani pod Linuxem. Na osahání ti stačí http://cz.farnell.com/texas-instruments/msp-exp430g2/g2xx-launchpad-dev-kit/dp/1853793. První programátor jsem měl ještě JTAG na LPT, teď mám vyvedený kablíky z LaunchPADu. A jak vidíš na obrázku, i pouzdro DIP se dá koupit... :D
-
MSP430 je pěkně navržený 16-bit a 20-bit CPU. Pro větší adresní prostor se nepoužívají banky/segmenty, ale ALU rozšířili na 20 bitů. Že ne na 32 plně chápu, protože CLA ve sčítačce narůstá s počtem bitů možná dokonce exponenciálně a určitě je 20 a 32 velký rozdíl. Na implementaci se trochu komplikuje to, že to není čistý RISC, instrukce mají proměnnou délku (n x 16bit). Jinak je ale kódování velmi hezké a s využitím některých kombinací prvních dvou registrů jako generátorů konstant i velmi úsporné.
Nástroje jsou již pěkné, dokonce existuje na OpenCores i OpemMSP430, který jsme před lety na Xilinxu používali a běhal velmi pěkně.
Tady ale může být (bude) problém, že se Ti bude klonům nejspíš bránit a má v záloze nějaké patenty nebo jiný mechanizmus, jak je potlačovat.
Jinak o MSP430 říkám, že je to to, co se mělo narodit když vznikala 8051, bohužel se to tenkrát nepovedlo. Myslím, že nebude ani na tranzistory moc složitější.
-
No tu snad vidí každý a smysl má jenom jako reuse pro 20 let starý kód v ASM.
Pro mě je 8051 nepoužitelná, protože:
- RAM maximálně 128B (u 8052 128B + 128B indirect, direct adresování vede na SFR)
- To vede k nepoužitenosti nativního C, protože se nedají vyměňovat argumenty funkcí skrz zásobník (zoufalá kapacita)
- Maximum 128 SFR registrů. Pro větší spektrum periferek je to nic, nebo se musí vymýšlet fligny jako rozdělení jednoho 8b registru na třeba 128x1b nebo 16x4b, takže zase roste velikost kódu.
- Jiný styl práce s periferkama. Zvykl jsem si mít periferku pěkně popsanou ve struktuře registrů, instanci periferky rozlišit adresou a je to. Tam je to díku booleovskýmu procesoru mišmaš všehochuť... Není to zásadní problém, je to nepříjemný.
- Externí paměti. Ne vždycky jdou použít, třeba u menších brouků (AT89C?051,...). Když už jde použít, dolní byte adresy, který se mění, se musí chytat do latche a horní, který se mění podstatně míň, je vyvedený na port (naopak by o bylo rychlejší). Navíc s adresováním pomocí registrů, ne nativně. U originál jádra je samotná instrukce dlouhá ne 12, ale 24 taktů.
- Zoufalý výkon. Originál 8051 jela na 12MHz, 12 taktů/instrukci. Různý firmy přišly s různýma zrychleníma (Temic 6 taktů, nějak zrychlovali i Silabs, Cypress,....), ale pravděpodobně nekompatibilně.
- Zákazník běžně chce field update. U 8051 se nedá spustit bootloader z RAM, dokonce ani z XRAM. Je potřeba udělat XRAM banku přístupnou jako XCODE, tím se sníží rychlost, zkomplikuje hardware,...
- Jakákoliv změna (zrychlení, přerovnání SFR, prohození bytů externí adresy, ...) vede k vendor lock-inu jako volba jiné 8b platformy - R8C, PIC, AVR, STM8,... při (často brutálně) nižším výkonu a složitějším návrhu. Když si porovnám 32MHz AVR s 32 MIPS a 30MHz 8051 upravenou na 6 taktů s 5 MIPS, je ten rozdíl poměrně dobře vidět.
-Furt je potřeba hlídat, s kterým paměťovým prostorem člověk pracuje. RAM, IRAM, XRAM, SFR, CODE, XCODE, BOOL, vlastní rozdělení XRAM a XROM,...V dnešní době je to fakt zbytečný masochismus.
-
mhi (neregistrovaný)
Rozhodne nejsem obhajce 8051, ale podivejte se kde se dneska pouziva ... implementovat do nejake historicke verze typu 89S51 novy kod muze jen masochista. Ovsem je tu milion ruznych jednoucelovych obvodu, kde ta 8051 je pritomna: Bluetooth cipy, NAND flash controllery, USB device controllery, ruzne RF veci, atd atd atd. Vyrobce vezme neco chytreho a k tomu na rizeni pripoji tu 8051. Tyto obvody bezne maji vic RAM, ruzne mapovane flashky/maskromky, 1-cycle instruction, nejake treba i 32bit instrukce navic, apod.
Jmena tech obvodu mnohdy nejsou ani dohledatelna, datasheety jsou-li nejake jsou v cinstine. Toto dela podle meho nazoru ten obrovsky trh s 8051, proto mame levne "china-made" vyrobky.
-
8051 je pevně daný standard - 128B RAM, 2x timer, 1x UART, nějaká ta ROMka, 12 clk/instr. Cokoliv jinýho už není čistá 8051, ale "8051 compatible". Anebo taky ne, pokud výrobce něco vypustí nebo změní. Takže čistou 8051 člověk dneska nepotká. Ale furt se na té architektuře dělají všelijaký ptákoviny, i když to je ve finále komplikovanější, než použít něco normálního. Takový Nordic si přidal SPI FLASH pro program do romless verze, no jak to splní (mimo ASM) standard pro jádro je ve hvězdách. USB periferku by taky člověk na 8051 pohledal... A i zastaralá USB 2.0 s 480Mbps, zpracovávaná na 8051, zní komicky...
BT je naštěstí už na Cortexech, jako https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822 - a to ještě nedávno Nordic stavěl na 8051. A v nových obvodech to už to neštěstí naštěstí mizí, objeví se jenom, pokud
- tomu markeťák nerozumí a podlehne pláči nějakých zoufalců, co zamrzli ve středověku
- projekť manager vývoje novýho čipu je ze staré školy a odmítá lepší alternativy, protože zamrzl v půlce minulýho století.
- výrobce se snaží zavděčit těm, c nikdy na nic novějšího nepřejdouA třeba http://www.ftdichip.com/Products/ICs/FT51.html je zajímavý. U x51 je počet SFR omezen na 128 (horní půlka RAM) a tohle má registrů 300. Takže zase nějaký rovnák na ohybák a nekompatibilní vydrbávky. Myslím, že s lepším jádrem by si hodně práce ušetřili a prostě to flákli do adresního prostoru.
-
atarist (neregistrovaný)
"8051 je pevně daný standard - 128B RAM, 2x timer, 1x UART, nějaká ta ROMka, 12 clk/instr"
Ne přesně, však už Intel měl od začátku v té řadě víc procesorů, od ROM-less (tuším 8031?) až po 8052 (dvojnásobek paměti RAM i ROM, další čítač). To, že se to označuje řada 8051 neznamená, že tyto malé odchylky nejsou ve stejné řadě.Jinak podle mě se každý z vás baví o jiném úhlu pohledu - 51 je pro programátora opruz, to souhlas, ale pokud potřebuješ nasekat milión ovládání schodišťových světel, tak už se sakra vyplatí si najmout programátora, co to zmastí v 51 nebo PICu (a bude u toho nadávat, to je život), než tam rvát například Cortexy. Pokud je to dražší zařízení, kde se cena čipu ztratí, tak se s 51 ne...at, to je jasný.
-
Lael Ophir (neregistrovaný)
Ono už to tu padlo, ale klidně ještě jednou: pokud jde třeba o klávesnici k alarmu, centrálu alarmu, USB klávesnici, ovladač barevných LED a podobná zařízení, může být 8051-compatible cenově výhodnou alternativou. I to USB se dá řešit (třeba AT89C5131A), a vzhledem k aplikaci rychlost nikoho nemrzí.
-
Chci MCU s 20 piny, SMD pouzdro, minimálně 2kB FLASH, 100ks. Kandidáti:
Tvrdíš, že je řešení 8051, takže pro srovnání:
AT89C2051 (8051, 128B RAM, 2kB FLASH, 8b, 24MHz, 2MIPS, 2x 16b timer, UART) 41.90Kč
http://www.tme.eu/cz/details/at89c2051-24su/mikroprocesory-atmel-8051-smd/atmel/A pro porovnání, STM32 Value Line, nejnižší model:
STM32F030F4P6 (M0, 4kB RAM, 16kB FLASH, 32b, 48MHz, 48MIPS, I2C, SPI, UART, 5x 16b timer) 18,7859Kč
http://www.tme.eu/cz/details/stm32f030f4p6/mikroprocesory-st/st-microelectronics/Nejvyšší model s 20 piny té samé řady:
STM32F042F6P6 (M0, 6kB RAM, 32kB FLASH, 32b, 48MHz, 48MIPS, I2C, SPI, 2x UART, CAN, USB Device, 5x timer 16b, 1x timer 32b) 39.7341Kč
http://www.tme.eu/cz/details/stm32f042f6p6/mikroprocesory-st/st-microelectronics/Srovnání:
Za cca 2/5 ceny 8051 můžu mít 32x víc RAM, 8x víc FLASH, 4x širší sběrnici, 24x víc instrukcí za sekundujako bonus I2C, SPI a tři časovače. Nebo za o chlup menší cenu 48x víc RAM, 16x víc FLASH, 24x vyšší výkon na 4x širší sběrnici, I2S, SPI, jeden UART, USB, a čtyři časovače (z toho jeden 32b).
A to není všechno. Kdo koupí STM32, dostane jako bonus:
- Možnost programovat v desce - odpadne skladování různých MCU s různou aplikací a jejich kontrola před osazením
- Možnost ladit v desce bez vyletování brouka pomocí SWD
- Možnost použít FreeRTOS a multitasking zdarma
- Vygenerování ovladačů a jádra systému za pár minut pomocí STMCube
- Portovatelnost kódu na vyšší řady, nebo obvody jiných výrobců
- Rezervy do budoucnaTakže se vrať z planety, kde M$ dělá použitelný věci a osmibity výhodnější, než Cortexy.
-
atarist (neregistrovaný)
A teď si vem zadání, kde máš například řídit světla na chodbě - je tam pět vstupů, dva digitální (tlačítka a detektor pohybu), tři analogové (fototranzistor měřící, zda se už setmělo, potenciometr pro dobu svícení, potenciometr pro citlivost na okolní světlo). To je vše se dá buď PICem (PIC10F320) za 0.36$, takže řekněme při odběru 100 kusů se vlezeš do 10 korun. 8051 imho nemá cenu řešit, to je fakt asi jen pro ty, co mají starou codebase a není čas/peníze na to to přepsat do C :-)
[jinak ty ceny STM s Cortexem jsou pro mě úžasně nízko, na to, jak výkonné to jádro je. V oblasti 32bit MCU se už asi rozhodlo]
-
8051 je v tomto případě s trochou komplikací navíc, třeba A/D převodník integrační s časovačem a komparátorem. A přepočet (včetně dělení 16b/16b) napsat v ASM. Tam to nemá cenu řešit.
PICku bych tam taky nedával, mají problémy s EMC. Dokonce i jejich vývojový kit zabloudil, když vedle něho začal zvonit mobil.
Ve sterým baráku jsem měl tři profi výrobky od firmy, která PICy používá. Jeden časovač na světla při odchodu a dva časovače u větrání. Všechny tři do roka a dne odešly. Teď mám PIC-free barák a všechno funguje...
Takže co je je platný levný matroš, když produkt nepřežije záruční dobu a zákazník si nejenom nic dalšího od firmy nekoupí, ale podělí se o zkušenost s ostatníma?
-
Z80 je škoda, byl to svýho času nejlepší procák, kterýmu Intel nesahal po kotníky. Ale když se podívám, co začali u Zilogů dělat v roce 2013 a letos v květnu to furt mělo status Preliminary, a je to jejich vlajková loď, tak je to celkem pochopitelný podíl na trhu. Osmibit, 24MHz, 64kB FLASH a 3.75kB RAM u nejvyššího modelu je v době, kdy je standard 50MHz 32b Cortex s 256MB FLASH a 64kB RAM, zoufalství, pokud nechtějí oni platit zákazníkům, že to od nich berou. Jo před deseti, patnácti rokama, to by ještě byli konkurenceschopní.
-
Díky, zajímavý článek jako vždycky od Pavla. Jenom bych doplnil dvě věci. Jsou dvě velké rodiny RISCových procesorů: jedna používá posuvná registrová okna (AMD29000, SPARC apod.), ta druhá ne (MIPS, ARM...). Co PowerPC? Z článku tak nějak vyplývá, že registry jsou pevné, neboli že PPC patři do té druhé skupiny, ale možná se pletu. No a k té instrukční sadě: PowerPC je odvozené z POWER, což byla vždycky nesmírně rozsáhlá architektura. RISC tedy v tomto případě nesmíme chápat jako "malou" instručkní sadu, ale jako sadu, ve které je každá jednotlivá instrukce jednoduchá, tj. jednoduché binární formáty, omezené adresovací režimy atd.
-
Pavel TišnovskýZlatý podporovatel
Díky :)
V mnoha instrukcích se pro indexaci registrů používá pět bitů, takže jsou přístupné všechny GPR najednou, ne například jen osm v daný okamžik.
Je to tak, POWER má instrukční sadu hodně rozsáhlou, je to například dobře vidět na případu skoků, ale i na instrukcích, které vezmou dva vybrané bity z CR a provedou s nimi jednu z operací AND, OR, NAND, NOR, XOR nebo negaci XOR (fakt jsou tam zastoupeny všechny tyto operace). Jestli to skutečně používají překladače, těžko říct :)
-
atarist (neregistrovaný)
myslel jsem to napriklad v porovnani s MIPSy nebo RISV-5. U POWER jsem mel pocit, ze tam proste nacpali vsechno, co slo "zadratovat" bez mikroradice, aniz by nejak premysleli, k cemu to bude. U MIPSu naopak vsechno nepotrebne odrezali az na uplny zaklad (bez flagu, jen skok pri nulovem/nenulovem registru, nasobicka schvalne udelana "navic" atd.)
Ale je fakt ze "člověk vlastně minimalismus architektury nechce" muze byt pravdivy, viz prave PPC, ARMy s Thumb-2, aarch64 apod. nebo z druhe strany x86-64, kterej se k riscu blizi nenapadne.
-
No právě. Minimální architektury jako MIPS byly atraktivní v době, kdy se za každý tranzistor platilo zlatem. Skutečně bylo v mnoha ohledech lepší mít co nejjednodušší procesor, u kterého zbylo na slušný cache a šlo zvyšovat hodiny bez obav, aby se to uchladilo. Dneska naopak skutečně válí složitější (ARM) nebo velmi složité (POWER, x86-64) architektury, protože tam kde to jde je hardware vždycky rychlejší, než software. Pokud jde o ten x86-64, na něm nevidím nic RISCového. To, že má víc registrů a "vyčištěnou" instrukční sadu z něj nedělá RISC.
-
No ono to je s x86-64 složitější. Architektura je to jasně CISCová, ale její implementace od AMD i Intelu jsou vnitřně RISCové a těmto RISCovým jádrům je předřazen dekodér instrukcí, který x86-64 kód převádí pro to RISCové CPU uvnitř. U AMD by to mělo být už od K5 procesor AMD 29000 pokud mě paměť neklame. U Intelu to je tuším od Pentium Pro, ale nevím co to je uvnitř zač a ani nevím, jestli se to dá někde dočíst.
-
atarist (neregistrovaný)
Záleží na úhlu pohledu. Já bych si možná i troufl říct, že x86-64 je RISCová architektura s dekodérem složitější instrukční sady. Něco jako ARM Thumb-2 - uvnitř skoro čistý RISC, nad tím taková směska RISCových a CISCových instrukcí (LDM, STM) s proměnnou délkou a prefixovými instrukcemi (IT*).
-
A to já bych zase nepřikládal takovou váhu tomu, jestli jde o RISC nebo CISC, protože to se ve finále na designu projeví jenom velikostí programu a rychlostí, mimo ASM to člověk nevidí av C to většinou schová kompilátor.
Zásadnější dělení vidím mezi von Neumannem a Harvardem. A to proto, že:
1. Harvard má často jinou šířku datové a instrukční sběrnice a je potřeba v SW zohlednit alignment. Prosákne to celou aplikací i Cčkem (PIC, AVR,...).
2. Harvard většinou nedokáže běžet z RAMky, to je potřeba vědět třeba při návrhu bootloaderu, dynamicky natahovaných rutin z vnější paměti (nutnost interpreteru) apod.
3. U harvardu je třeba explicitně volit, jestli konstanty budou ve FLASH s programem, nebo někde v datové oblasti. V prvním případě se můžou objevit dvě verze jedné rutiny s jinou třídou pointeru v argumentu, ale nachlup stejný, v to druhým... Zkusili jste takto zobrazovat na displeji hlášky celkové velikosti 8kB jednočipu s 4kB RAM?Takže tyhle rozdíly jsou z pohledu aplikace o hodně zásadnější a dotýkají se architektury celýho systému podstatně víc, než RISC/CISC.
-
Když je řeč o instrukční sadě neboli externí architektuře, tak mám za to, že amd64 je jednoznačně CISC, MIPS je čirý RISC, moderní ARM tak něco mezi a POWER je... prostě IBM :) Z hlediska aplikací (tj. hustota kódu, LOAD/STORE nebo operace rovnou z/do paměti atd...) se tyhle procesory prostě tak jeví, celkem bez ohledu na to, co je uvnitř.
Jinak je pravda, že K5 byl ve skutečnosti AMD29K schovaný za dekodérem instrukcí. U Intelu je to tak od PPro, ale cosi podobného, byť v mnohem primitivnější prodobě, bylo už u 486. Vzpomínám si, že v manuálu ho vychvalovali jako "RISC Processor" (RISC byl tehdy buzzword).
Ale zdaleka to není specifika Intel/AMD. Stejný princip už drahnou dobu používá POWER a dneska i Cortexy od ARM, takže na otázce RISC/CISC se tím nic nemění (tedy pokud na tom vůbec záleží). Absolutně netuším, jak ta jádra vypadají, je to ostatně dost zajímavé téma, ale u ARM bych čekal pravděpodobně nějaký hodně jednoduchý RISC a u procesorů z hyperthreadingem, tj. Intel, AMD a POWER, bych to viděl spíš na něco typu VLIW. Představuju si, že dekodér/překladač instrukcí čte instrukce paralelně ze dvou nebo osmi vláken a přeložené je pak láduje do odpovídajících instrukčních slotů VLIW kódu... ale možná se pletu a ve skutečnosti to třeba funguje úplně jinak.
Když se to tak vezme, nebylo by vlastně vůbec nelogické, aby Xeon a Itanic měli uvnitř stejné nebo velmi podobné jádro.
-
Spider (neregistrovaný)
Tim Intelem myslis i960?
Mam dva na dvou procesorovych kartach do Compaq serveru s CPU 133MHz: http://images.esellerpro.com/2131/I/246/85/Picture%20230.jpg
-
ventYl (neregistrovaný)
o VLIW v pripade implementacie podkladovej architektury velmi silne zasadne pochybujem. prax ukazala, ze VLIW vyzaduje velmi silne optimalizujuci prekladac a vhodny kod na to, aby tato architektura bezala optimalnym vykonom. hyperthreadingu sa dosahuje "jednoducho" tym, ze u superskalarnych procesorov byva casto napr. viacero ALU na jednu instrukcnu frontu, aby bolo mozne v kratkom slede po sebe spustit viacero instrukcii vykonavajucich sa na ALU bez toho aby sa museli vkladat delay sloty do pipeline. Namatkovo PowerPC 970 malo takto 3 Vector unity na jadro, PPC 7450 malo dve / jadro. Ak sa takyto paralelizmus znacne nafukne stane sa to, ze pri bezne hustom kode bude velka cast procesora pomerne casto zahalat, pretoze proste instrukcie na duplikovane jednotky nejdu tak zhusta. Preto sa potom spravi to, ze sa da do jadra napr. 5 ALU a potiahnu sa 2 instrukcne pipeline, ktore sa budu o tieto ALU delit. Takze sa da povedat, ze pri dostatocne bohate dimenzovanom superskalarnom procesore sa hyperthreading dostane "zadarmo". Staci pridat dalsiu instrukcnu pipeline a vyriesit vzniknute problemy :)
Ak sa nahodou stane, ze su vsetky ALU zamestnane a dojde dalsia instrukcia, ktora by rada ALU pouzila, vlozi sa do pipeline delay krok tak, ako by sa vlozil, keby vsetky dostupne zdroje vycucala jedna instrukcna pipeline. Toto sa zjavne dost casto stavalo u prvych HTckovych Pentii 4, ktore mali volnych jednotiek pomerne dost malo (a instrukcie trvali strasne vela krokov, takze ak bolo nieco busy, bolo viac menej iste, ze ten delay krok nebude jediny), co malo za nasledok, ze vykon pri pouziti HT mohol byt v sucte nizsi ako pri single-thread behu, pretoze sa dost vkladali delay kroky a ak sa k tomu pripocitala rezia synchronizacie SMP systemu, hruby vypoctovy vykon bol nizsi ako keby sa bezalo na jednom vlakne.
Tomuto napr. stale veri planovac vo Windows, ktory sa snazi zamestnavat vzdy najprv jednu instrukcnu pipeline v ramci jadra a az ked mu dojdu volne timesloty na primarnych pipeline, zacne obsadzovat aj sekundarne pipeline. U novsich procesorov rodiny Core i* by s tym ale uz nemal byt taky problem, pretoze jednak rollbackli ku kratsej 15-17 krokovej pipeline z ery Pentium 3 a za druhe asi prehodnotili mieru nasobnosti funkcnych blokov procesora.
-
VLIW se ukázalo jako neprůchozí tam, kde je nutné generovat kód staticky (tj. překladačem), protože ani ten nejlepší kompiler nemůže provádět optimalizace, které by se v důsledku rovnaly problému zastavení Turingova stroje. Něco jiného je ale, pokud se má kód generovat dynamicky z několika nezávislých paralelních instrukčních toků a s průběžnými informacemi o stavu jednotlivých pipelinů. Tady nevidím důvod, proč by to v zásadě nešlo. Tím nechci říct, že to tak nutně je v případě existujícího hyperthreadingu, ale jako princip mi to připadá rozumné.
-
atarist (neregistrovaný)
No a není už potom lepší se skutečně na VLIW (skládání x operací do jednoho slova) vykašlat a mít prostě řekněme pět paralelně běžících modulů, do kterých se instrukce vkládají tak, jak přijdou? Příkladem: 2x ALU, 1x FP, 1x skoky, 1xLOAD/STORE. VLIW začal kdysi dávno, aby se ty moduly "krmily" ze staticky generovaného kódu (jasně, CPU bylo mnohem jednodušší), ukázalo se to být ne zcela optimální, takže kromě nějakých DSP to snad (?) už nikdo nepoužívá...
-
Vícero elementárních jednotek má každý superskalární procesor. Mě by zajímalo, jestli je v případě hyperthreadingu dekodér dokáže současně krmit instrukcemi z různých paralelních vláken.
Jinak VLIW byl propadák u staticky generovaného kódu (až se divím, že to někomu připadalo jako dobrý nápad) ale u dynamického výstupu z dekodéru, což je v podstatě zadrátovaný JIT, se to tak zle nejeví. Aby bylo jasno: netvrdím, že to tak funguje, ani, že by to tak bylo nutně dobře. Jenom mi to přišlo jako jeden možný přístup.
Kromě DSP VLIW ještě používá pár mikrokontrolérů a GPU. Tuším, že některé radeony jsou nebo byly VLIW. No a samozřejmě tu pořád ještě máme Itanium. Dlouho jsem si myslel, že není nic horšího, než staré x86 v reálném režimu, až jsem jednou měl tu "čest" psát pár rutin v assembleru IA64...
-
atarist (neregistrovaný)
Pravda, Itanium (melo se to puvodne jmenovat Itanic :) tady mame, ale uz treba enterprise linuxy od jeho podpory ustupuji a asi to je to cele v zombie fazi...
Jestli tomu dobre rozumim - idea je takova, ze na vstupu je RISC kod z vice threadu a dekoder z toho vytvori VLIW? Tak proc ne, ted tam asi maji nejaky crossswitch, ktery proste instrukce prohazuje do volnych modulu a navic si musi hrat s prejmenovanim registru.
-
Což o to, Itanic se potápí už hezkou dobu. Pokud si pamatuji, tahle přezdívka se objevila sotva pár dní poté, co HP a Intel slavnostně oznámili značku Itanium - což mimochodem mluví samo za sebe... Enterprise distra ho už opustili (RHEL od verze 6, Ubuntu server už před tím, jinak nevím), ale nejsou samy, MS zařízl podporu ve Windows Server 2012 a i Oracle před lety oznámil, že se s ním už nebude zdržovat, za čež pak musel Intelu zaplatit odškodné... Jinak na něm fungovalo ještě OpenVMS (to pro změnu zase nefungovalo na ničem jiném), ale i tomu už je odzvoněno.
Ta idea je přesně tak, RISC nebo CISC kód v několika threadech, konkrétně dvou (Intel) nebo osmi (POWER). Dekodér ho přeloží a odešle do front, odkud se pak jednotlivé instrukce nacpou do příslušných slotů VLIW kódu, např. 2xALU + 1xMEM, podle toho, v kterých pipelinech je volno a jaké instrukce jsou zrovna připravené k běhu. Přejmenování registrů se v každém případě děje tak jako tak pokud má CPU umět spekulativní exekuci nebo exekuci mimo pořadí. Např. Intel ho používá už od Pentium Pro (ten má konkrétně 128 fyzických registrů, různě namapovaných na osm logických registrů architektury x86, u každé instrukce jinak).
-
mhi (neregistrovaný)
Nemam uplne zkusenost primo z oboru navrhovani procesoru, ale co jsem v podobnem oboru ziskal sve pidizkusenosti a co jsem konzultoval s lidmi co delaji obdobne veci a jsou autoritami (napr. "chief architect" JITu v Jave), tak je potreba udelat vzorky nejakeho kodu (typicky spustenim OS, aplikace, apod. & merenim), a na tech vzorcich stavet vypocty "co by se stalo kdyby". A za kdyby dosazovat WLIV, ruzne predikujici JITy, multithreading, apod. Je to celkem dost prace a myslim, ze to je pole hodne neorane, protoze jsem se vetsinou dostal k odpovedi "meli jsme to v planu udelat, ale nedodelali jsme to, protoze management ...." (=byl hotovy prodejny produkt a trh to nevyzadoval).
Myslim, ze i neco podobneho vypadlo z jednoho ze zakladatelu VMware, ale nechci mu to primo vkladat do ust.
Mozna to trosku zkresluju, ale z odpovedi jsem to vycitil.
-
danny (neregistrovaný)
"Některé instrukce skoku obsahují dva bity nazývané „at“ (resp. přesněji „a“ a „t“, kde „t“ pravděpodobně značí „(branch) taken“). Tyto bity ovlivňují prediktor skoků a lze je považovat za statickou predikci nastavovanou překladačem či programátorem v assembleru. "
možná nejen v assembleru: fungují tady makra "likely" a "unlikely" z C?
-
Pavel TišnovskýZlatý podporovatel
To z hlavy nevim, ale podivam se na to. Selsky rozum rika, ze by to mohlo probublat az do assembleru, ale neni to jen GCC-specific? (ja to nikdy nepouzil :)
-
Podporujou to všechny "velké" compilery kromě MS, tedy GCC, C-Lang, Intel. Ve skutečnosti tedy podporují __builtin_expect, v Linux kernelu jsou nad tím ještě zmíněné likely() a unlikely().
Jestli to využije tyhle bity, nevím, předpokládám, že nejspíš jo. V ostatních architekturách obvykle přeskládá pořadí if-else, aby se pravděpodobně neskákalo dopředu.
-
Vyvinuli to u Hitachi, (Super Hitachi) a po spojení s Mitsubishi do firmy Renesas to značení nechali.
Kdysi jsem měl projekt na SH-2, ale moc si toho už nepamatuju. Dělali jsme i hardware s SH-3 a SH-4 (tam jsem dělal jenom s HW a jádro/instrukční sadu jsem nezkoumal, kolega na to rovnou hodil tučňáka, takže moc nemůžu sloužit). Existuje hodně variant, v rukách jsem měl jenom SH-2, SH-3, SH-4 a SH-4A.
