Prestanda är en fördel. Att vara en 32-bitars processor överträffar (nästan) alla 8-bitars styrenheter DMIPS-klokt. Kärnan har också gått igenom flera generationer, läst optimeringar.
Dessa optimeringar visas inte bara i prestandanummer utan även i energiförbrukning . Den senaste kärnan har fördubblat sitt DMIPS / mW-förhållande jämfört med föregående generation (se även detta svar).
ARM finns tillgängligt från många många tillverkare , mer än någon annan mikrokontroller, och alla har ett antal versioner att välja mellan, med olika kombinationer av kringutrustning och minne på chipet och paket. Exempel: NXP erbjuder inte mindre än 35 styrenheter med on-chip Ethernet.
ARM är billiga . ARM var förmodligen den första 32-bitars styrenheten som bröt USD 1-barriären.

Denna kombination av prestanda , brett erbjudande och låg kostnad gör det så att du helt enkelt inte kan ignorera ARM:

År 2005 använder ungefär 98 procent av alla mobiltelefoner åtminstone en ARM-designad kärna på sina moderkort, enligt forskning från analysföretaget Linley Group. ( källa)

Mobilmarknaden har också en annan effekt. Mobiltelefoner är mycket begränsade och kräver små paket. NXP: s LPC1102 kommer i ett WLP-16-paket bara 5 mm \ $ ^ 2 \ $, en skala som tidigare endast använts av 8-bitars mikrokontroller med lågt stiftantal.

En punkt som ännu inte nämnts: År 1908 kallade en kille som heter P.L. Robertson uppfann ett nytt förbättrat skruvhuvud och skruvmejsel. Han ville vara den enda personen som tillverkade skruvar och skruvdragare för sin design. Årtionden senare kom någon annan vid namn Mr. Henry F. Phillips med en alternativ design. Till skillnad från Robert Robertson var Phillips mer intresserad av att licensiera sin design än att producera skruvar och drivrutiner.

På 1970-talet kom Sony med en teknik som heter Betamax; JVC kom med en som heter VHS. Sony var intresserad av att producera videobandspelare; JVC var mer intresserad av licensiering.

Det verkar finnas ett mönster här. (Obs: Intel licensierade en stund sin 80x86 -teknik, men har under årtionden varit mer fokuserad på att utveckla tekniker för internt bruk.)

1. Samma hårdvara / mjukvara att utveckla för ARM: s av alla leverantörer. Du köper JLINK / ULINK och lite Keil IDE en gång och kan använda det för att utveckla, emulera och felsöka nästan vilken ARM som helst på en planet.

2. Du behöver inte lära dig ny arkitektur när du flyttar till ny chip-leverantör => mindre leverantör lockin => mer konkurrens => lägre priser

3. I moderna tekniska processer (0,18um och lägre) är ARM-kärnan så liten att den offrar det för 8bit kärna skulle inte spara någon synlig del av ett pris. Därför anledningen till att gå till standard högpresterande men ändå billig arkitektur.

4. Prestanda - bara med ARM kan du ha en enda klocka 32 * 32-> 32 multiplikation och hårdvarustöd för 32 * 32-> 64 och delning för sub-1dollar-enheter (nämligen till exempel nedre STM32: er)

5. ARM är inte alltför girig och tar inte ut orimliga avgifter för licenser , så tillverkare kan producera billiga mikroer.

Jag fokuserar på mellanliggande ARM -processorer av följande skäl:

1. Fullständigt Linux-stöd

   Detta betyder enhet förare nästan gratis. Jag har gjort tillräckligt med USB-värd och enhetskod, jag vill inte göra DET längre. Jag är inte heller så glad över att försöka lägga till TCP / IP till en slumpmässig processorplattform (även om LwIP / uIP inte är så illa). Jag har aldrig ens försökt göra Wi-Fi, en riktig Bluetooth-stack, webbkameror osv. Att använda Linux innebär att ett mycket brett utbud av enheter blir mycket lättare att prata med.

   Jag blev också riktigt förvånad över hur rationellt och enkelt att skriva Linux-drivrutiner. Efter att ha gjort några Windows-enhetsdrivrutiner är Linux en dröm. (För att vara rättvis har Windows-drivrutinsramverket förbättrats mycket sedan jag gjorde det.)

   Programvaruplattformen är också fantastisk. Jag får SSL-kryptering, filsystem, fjärrhantering, enkla applikationsuppdateringar (kopiera en fil över istället för en komplex bootloader) osv. Åh, och massor av befintliga verktyg om du behöver göra något.

   Det är också royalty gratis och mycket lättare att böja sig efter din vilja än säga att en sluten källa WinCE plattform skulle vara. (Inte för att jag verkligen är en öppen källkodsidealist ... det är allt väldigt praktiskt resonemang för mig.)

   Jag pratar om ARM-kärnor med faktiska MMU: er, så detta är för mellan- och avancerade marker (även om du kan använda μClinux antar jag).

2. Strömförbrukning

   Detta är i grunden en upprepning av andras kommentarer, men det är en stor faktor för mig. Min nuvarande 454 MHz ARM-plattform drar 1/2 a watt, 1 watt vid max CPU. Du kan inte ens komma nära det med x86.

Det är ganska mycket mitt resonemang. Jag ser inte ekvationen förändras snart.

ARM har gått igenom en progression:

1. En 32-bitars instruktionsarkitektur, som hade större kod än många andra arkitekturer, men som kunde avkodas snabbt och kunde göra många operationer med färre instruktioner än konkurrerande arkitekturer
2. En arkitektur med dubbla instruktionsformat, som kan växla mellan den snygga och kraftfulla (men tyvärr något uppblåsta) ARM-instruktionsuppsättningen och en mindre kraftfull (men mycket mer kompakt) 16-bitars "Thumb" instruktionsuppsättning. Varje tuminstruktion hade en motsvarande ARM-instruktion, vilket minimerade behovet för programmerare att lära sig två instruktionsuppsättningar. koden skulle innehålla en blandning av instruktioner som bara fanns tillgängliga i ARM och instruktioner som skulle ha varit tillgängliga i Thumb men som i alla fall måste representeras som 32 bitar; i Thumb2 får sådan kod platsfördelarna med att ersätta några av 32-bitarsinstruktionerna med 16-bitars.
3. En enda-tumarkitektur, som är mer begränsande än jag skulle ta hand om, men som är mindre och billigare än någon av de andra.

ARM-arkitekturen gör det möjligt att utföra ganska sofistikerade operationer mycket snabbt - mycket snabbare än på något annat chip. Till exempel (med ARM7-TDMI):

 ldrh r0, [r10, # ADDR_BUS_OFS]; Läs målsystemets adressbuss (13 bitar) ldrb r1, [r9, r0, lsr # 8]; Använd övre bitar för att leta upp adressen i en tabell över hanterare lägg till pc, r9, r1 lsl # 2; Gå till lämplig hanterare 

Varje hanterare lagras som en byte, vilket ger 1/4 av adressförskjutningen från början av tabellen. Nettoeffekten är att när innehållet i adressbussen har hämtats tar det bara sex cykler (två instruktioner) att hoppa till en hanterare baserat på de övre fem bitarna i den hämtade, med hjälp av en 32-byte hopptabell.

Motsvarande THUMB-kod skulle vara mer som:

; Förutsatt att vi inte behöver r6 / r7 för något annat, tilldelas de om från r9 / r10 ldrh r0, [r7, # ADDR_BUS_OFS] mov r1, r0 lsr r1, r1, # 8; TUMM kräver att källa och destination ska vara samma ldrb r1, [r6, r1] lsl r1, r1, # 1; Skulle kunna använda skift-vänster-två, om måladresserna var helt ordinriktade lägg till pc, r1 

Det är bra ur en koddensitetssynpunkt, med tanke på att instruktionerna bara är hälften så stora som originalen, men skulle ta nio cykler efter hämtningen snarare än sex. I en applikation där bussen som bevakas kommer att köra i sin egen hastighet oavsett om ARM har lyckats hantera den, desto snabbare ARM-instruktioner är ett stort plus.

För övrigt är Thumb2 binärkompatibel med Tummen, som underlättar användningen av tidigare verktyg, men betyder att det finns några saker som den inte kan göra lika bra som den ursprungliga ARM. I ARM kan man till exempel "rotera" en 8x8 bitmapp som hålls i fyra register med cirka 3 instruktioner per två bitar:

 movs r0, r4, lsl # 25; Sätt översta biten av LSB i C och nästa bit i N orrcs r6, # 0x00000001 orrmi r6, # 0x00000100 

I Thumb2 skulle det vara nödvändigt att lägga till uttryckliga villkorliga instruktioner:

 movs r0, r4, lsl # 25; Lägg LSB: s översta bit i C och nästa bit i N itcs orrcs r6, # 0x00000001 itmi orrmi r6, # 0x00000100 

Netto 33% minskning av tids- och rymdeffektivitet jämfört med ARM; det handlar förmodligen om ett värsta exempel på att tumkod är mindre effektiv än ARM, och även det är inte riktigt hemskt.

En annan liten nackdel med Thumb2 jämfört med ARM: i ARM-kod börjar alla instruktioner fullt ut -ordgränser, vilket underlättar statisk analys. I Thumb2 kan instruktioner godtyckligt börja vid halvordsgränser och sträcka sig över hela ordgränser. Statisk analys kan således bli mycket svårare.

Lite är historia, Acorn ville ha en anpassad CPU (t.ex. med inbyggda minneskontroller osv.) för en ny dator på 1980-talet (8 bit 6502 begränsade vad de kunde göra). De pratade med Intel, men Intel skulle inte licensiera en CPU till dem.

Så Acorn designade en mycket enkel RISC-processor, men eftersom de inte var en CPU-tillverkare var de villiga att licensiera den till vem som helst (och behövde alla snabba pengar de kunde få!). (Jag tror att CPU: n fungerade första gången, delvis för att den var så enkel och designern har skapat en hel del forsknings-processorer medan han var vid Cambridge University.)

Med åren har CPU-designen blivit enklare och enklare att inkludera inom kundchipdesign.

Chiptillverkaren kände sig säker licensiering från Acorn eftersom de inte var en konkurrent. Ingen trodde också att de skulle åka till en tävlings hemstad för att få en licens, eftersom Acorn var i Cambridge (den riktiga!) . (Gjorde chansen att en "fakta" resa till Cambridge för att besöka Acorn påverkar kortslutning av alternativ när som helst ...)

Många av de mönster som inkluderar Acorn Risc Machine CPU var för inbäddningssystem var energianvändning viktigt. Billiga och bra utvecklingsverktyg skapades också för Acorn Risc Machine CPU.

Så när mobiltelefoner började behöva anpassade marker med en inbäddad CPU döptes Acorn om till ARM och resten är historia. (Kanske var det också lite att de andra processorerna mestadels kontrollerades av USA, men mobiler blev först normala i Europa)

(Påminner något om detta om Microsoft och Dos med ett litet okänt team från IBM?)

Det faktum att ARM var en av de bästa processorerna vid den tiden (och fortfarande är) för många uppgifter hjälpte också - men att bara ha den "bästa" CPU-designen är inte nog.

Bortsett från tekniska problem finns det många icke-tekniska skäl för ARM. Men det snabba svaret är detta: Det är inte Intel (eller x86).

Om du tittade på var CPU R&D dollar investeras just nu faller de i princip i två läger: ARM och Intel. (Jag ignorerar små MCU-enheter och slår AMD in med Intel.) Det finns väldigt lite pengar som går till PowerPC, MIPS, SPARC och andra stora processorer. ARM och Intel är de enda som fortfarande står.

Med Intel och andra x86-processorer får du en enorm mängd äldre bagage. Du behöver till exempel en chipset, ett BIOS och andra saker. Även om processorn var supereffektiv, tenderar de andra enheterna att väga ner ditt system och göra det större, mer energikrävande och dyrare. Att bara utveckla ett kretskort med en Intel-processor är en enorm fråga, och sedan måste du förhandla med en BIOS-leverantör etc. För att göra saken värre vill många av leverantörerna för chipsets, BIOS, videochips etc. att göra affärer med små människor som inte säljer mindre än en miljon enheter om året.

Med ARM har du inte det bagaget. Det finns många källor till marker från saker med mikrocontroller-linje upp till monster med flera kärnor. Du behöver inte hantera licensiering av ett BIOS (vilket är ungefär som att gå till en begagnad bilförsäljare). Och tillverkare och leverantörer är i allmänhet trevliga för dig.

Jämför ARM7 / ARM9 med MIPS IV och det finns liten fördel förutom licensfrågor som redan nämnts. Internt i MIPS instruktionsuppsättning och intern buss gör den överlägsen (prestanda per kostnad) för vissa typer av mönster; varför många Wi-Fi-routrar använder MIPS-kärnor snarare än ARM-kärnor.

Eftersom ARM-kärnor applicerades mestadels på handhållna enheter lade ASIC till fler funktioner för effektkontroll medan MIPS fokuserar mer på prestanda per cykel snarare än lägre kraft. Fördelen med RISC jämfört med Intel x86 är en annan diskussion.

Det finns inga verkliga fördelar. Bifogade DSP och andra styrenheter, som GSM, är det som gör dem så populära.