Vlákno názorů k článku RISCová architektura PowerPC od AnthonyX - Pěkné počteníčko. Za mne +++ - - - -...
-
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í.
