32 bit 48-96 Mhz mikroişlemcilerin avantajları (Arduino Due gibi)


10

Görünüşe göre Arduino Due (32 bit, 84 Mhz, ARM-Cortex-M3 tabanlı SAM3X8E) piyasaya sürüldü.

Ayrıca, bu kategoride çok sayıda işlemci (32 bit / 48-96 Mhz / ARM) ve karşılık gelen prototip panoları var:

  • NXP LPC1768 / mBed
  • STM32 / Keşif
  • PIC32 / ChipKit
  • PIC32 / Paralaks Pervanesi
  • LM4F120 / TI Başlatma Paneli
  • vb.

Ben bana düşük uç AVR / MSP430 / vb arasında yalan gibi görünen bu "arasında" mikroişlemciler cazibesini anlamaya çalışıyorum. (artıları: ucuz, düşük güçlü, az yer kaplayan) ve üst düzey ARM7 / etc (pro: saniyede çok daha fazla talimat verebilir).

Hangi durumlarda veya yollarla 32 bit / 48-96 Mhz / ARM tabanlı mikroişlemciler uygun bir seçimdir? Daha spesifik olarak, hem düşük uçlu 8 bitlik mikro denetleyiciler hem de çok yüksek seviye ARM7 işlemciler üzerinde tasarım sırasında hangi uygulamaların veya hangi parametrelerin üstün bir seçim için yapacaklarını merak ediyorum.


Aklımdaki ilk şey, Arduino'nun bunu başaramadığı canlı video akışlarını işleyebilirsiniz. Ayrıca gelişmiş şifreleme algoritmaları veya karma (Arduino'da olduğundan daha hızlı ve daha kolay) sağlar Arduino 32bit platform ile çıktı şaşırdım ama sadece size gösteriyor - Bazı insanlar sadece bir röleyi kontrol etmekten daha fazlasını yapmak istiyor. Arduino için harika bir gün!
Piotr Kula

Ekli bir özel işlev çekirdeğinde yapmadığınız sürece, <100 MHz işlemcide önemsiz canlı video işlemeden fazlasını yapmayacaksınız. Ve özellikle bu cihazlardaki oldukça sınırlı yerleşik koçta değil. Daha gerçekçi bir nokta, bu yongaların maliyetinin 8 bitlik parçalardan çok daha yüksek olmamasıdır; gerçekte karşılaştırılabilir flaş ve koçlu bir ATMEGA'dan daha düşük olabilir.
Chris Stratton

3
Bildiğim kadarıyla, Parallax Pervane PIC32 ile hiçbir ilişkisi olmayan özel bir çiptir. Bağlantı için herhangi bir kaynak var mı?
AndrejaKo

Yanıtlar:


12

Bu, oldukça tartışmalı olabilecek konulardan biridir. Çok farklı bakış açıları var ve farklı şeyler farklı insanlar için önemlidir. Kapsamlı bir cevap vermeye çalışacağım, ancak her zaman aynı fikirde olmayan biri olacağını anlayacağım. Sadece benimle aynı fikirde olmayanların yanlış olduğunu anlayın. (Şaka yapıyorum.)

Hızlı özet:

Bu cevap uzun bir cevap olacak, bu yüzden bunu özet olarak açıklayayım. İnsanların büyük çoğunluğu için en son ARM Cortex-M0 / M3 / M4 yongaları, en iyi çözümü, maliyet için en iyi özellikleri sunar. Bu 32 bit MCU'ları PIC ve MSP430'lar gibi 8 ve 16 bit atalarıyla karşılaştırırken bile bu doğrudur. M0'lar her biri 1 ABD dolarından daha az ve M4'ler her biri 2 ABD dolarından daha az bir fiyata satın alınabilir. M0'lar çok düşük güçtür ve çoğu insan için yeterince iyi olmalıdır. Çok güce duyarlı olanlar için MSP430'lar daha iyi bir seçim olabilir, ancak M0'ler bu uygulamalar için bile dikkate değer.

Daha ayrıntılı bir analizle ilgileniyorsanız, o zaman okumaya devam edin, aksi takdirde şimdi okumayı durdurabilirsiniz.

Şimdi her bölgeye bakacağım ve farklı MCU'ları karşılaştıracağım:

Uygulama Hızı

Tabii ki 32 bit MCU'lar daha hızlı olacak. Daha hızlı bir saat hızına sahip olma eğilimindedirler, ancak bu saatlerin her biri için daha fazla iş yaparlar. ARM Cortex-M4 gibi MCU'lar DSP işleme talimatları içerir ve hatta donanımda kayan nokta desteğine sahip olabilir. 8 ve 16 bit CPU'lar 32 bit sayılarla çalışabilir, ancak bunu yapmak etkili değildir. Bunu yapmak, program depolamak için CPU kayıtlarını, CPU saat döngülerini ve flash belleği hızla tüketecektir.

Kalkınma Kolaylığı

Kanımca, modern 32 bit MCU'ları kullanmanın en değerli nedeni - ama aynı zamanda en az takdir edilen. Öncelikle bunu 8 bitlik PIC'lerle karşılaştıralım. Bu en kötü durum karşılaştırması, ama aynı zamanda puanlarımı göstermek için en iyisi.

Daha küçük PIC'ler temel olarak programlamanın montaj dilinde yapılmasını gerektirir. Doğru, 8 bit PIC'ler için bile C derleyicileri var, ancak bu derleyiciler ya ücretsiz ya da iyi. Hem iyi hem de ücretsiz bir derleyici alamazsınız. Derleyicinin ücretsiz sürümü, optimizasyonunun "Pro" sürümü kadar iyi olmaması nedeniyle sakat. Pro sürümü yaklaşık 1.000 ABD Dolarıdır ve yalnızca bir PIC yonga ailesini (8, 16 veya 32 bit yongalar) destekler. Birden fazla aile kullanmak istiyorsanız, 1000 ABD doları karşılığında başka bir kopya satın almanız gerekir. Derleyicinin "Standart" sürümü orta düzeyde bir optimizasyon yapar ve her yonga ailesi için yaklaşık 500 ABD dolarıdır. 8 bitlik PIC'ler modern standartlara göre yavaştır ve iyi bir optimizasyon gerektirir.

Buna karşılık, ARM MCU'lar için ücretsiz olan birçok iyi C derleyicisi vardır. Sınırlamalar olduğunda, bu sınırlar genellikle desteklenen maksimum Flash Bellek boyutundadır. Freescale Codewarrior araçlarında bu sınır 128Kbayt'tır. Bu forumdaki çoğu insan için bol miktarda var.

C derleyicisi kullanmanın avantajı, CPU'nun bellek haritasının düşük düzeyli ayrıntılarıyla uğraşmak zorunda kalmamanızdır. PIC üzerinde sayfalama özellikle ağrılıdır ve mümkünse en iyi şekilde önlenir. Başka bir avantaj, 8 bit MCU'da (veya 16 bit MCU'da 32 bit sayılar) 16 ve 32 bit sayıları dağıtmanın zorluğuyla uğraşmak zorunda kalmamanızdır. Montaj dilinde bunu yapmak çok zor olmasa da, arkada bir acıdır ve hataya yatkındır.

İyi çalışan başka ARM C olmayan derleyiciler de var. MSP430 derleyicisi makul bir iş çıkarmış gibi görünüyor. Cypress PSoC araçları (özellikle PSoC1) hatalıdır.

Düz Bellek Modeli

RAM / register / Flash disk belleği olan bir MCU sadece aptalca. Evet, 8 bitlik PIC'lerden bahsediyorum. Aptal, aptal, aptal. Bu beni PIC'lerden o kadar çok rahatsız etti ki, daha yeni şeylerine bakmak için bile uğraşmadım. (Feragatname: Bu, yeni PIC'lerin iyileştirilebileceği ve bunu bilmediğim anlamına gelir.)

8 bit MCU ile 256 bayttan büyük veri yapılarına erişmek zordur (ancak imkansız değildir). 64 kbyte veya kwords'a yükseltilen 16 bit MCU ile. 4 gigabayta kadar çıkabilen 32 bit MCU'larla.

İyi bir C derleyicisi, programcıdan (You olarak da bilinir) birçok şeyi gizleyebilir, ancak o zaman bile program boyutunu ve yürütme hızını etkiler.

Bunun bir problem olmayacağı birçok MCU uygulaması var, ancak elbette bununla ilgili problemleri olacak birçok başka uygulama var. Çoğunlukla RAM veya Flash'ta ne kadar veriye (diziler ve yapılar) ihtiyacınız olduğuna dair bir konudur. Tabii ki, CPU hızı arttıkça daha büyük veri yapıları kullanma olasılığı da artar!

Paket Boyutu

Bazı küçük PIC'ler ve diğer 8 bitlik MCU'lar gerçekten küçük paketlerde bulunur. 6 ve 8 iğneli! Şu anda tanıdığım en küçük ARM Cortex-M0 bir QFN-28'de. Bir QFN-28 çoğu için yeterince küçük olsa da, herkes için yeterince küçük değildir.

Maliyet

En ucuz PIC, en ucuz ARM Cortex-M0'ın yaklaşık üçte biri. Ancak bu 0,35 ABD doları ve 0,85 ABD dolarıdır. Evet, bu fiyat farkı bazıları için önemli. Ancak, bu web sitesindeki çoğu insanın bu küçük maliyet farkını umursamadığını düşünüyorum.

Benzer şekilde, daha yetenekli MCU'ları ARM Cortex-M0 / M3 / M4 ile karşılaştırırken genellikle ARM Cortex "kabaca eşit" veya üstte çıkar. Diğer şeyleri çarpanlara ayırırken (geliştirme kolaylığı, derleyici maliyetleri vb.) ARM'ler çok caziptir.

İkinci Özet

Asıl soru şu: Neden ARM Cortex-M0 / M3 / M4 KULLANMAYIN ? Mutlak maliyet çok önemli olduğunda. Süper düşük güç tüketimi kritik olduğunda. En küçük paket boyutu gerektiğinde. Hız önemli olmadığında. Ancak uygulamaların büyük çoğunluğu için bunların hiçbiri geçerli değildir ve ARM şu anda en iyi çözümdür.

Düşük maliyet göz önüne alındığında, bir ARM Cortex kullanmamak için iyi bir neden yoksa, bir tane kullanmak mantıklıdır. Diğer MCU'lardan daha az baş ağrısı ve daha büyük tasarım marjları ile daha hızlı ve daha kolay geliştirme süresi sağlayacaktır.

Başka ARM Cortex 32 bit MCU'lar da mevcut, ancak ben de onlara bir avantaj görmüyorum. Daha iyi geliştirme araçları ve teknolojinin daha hızlı yeniliği de dahil olmak üzere standart bir CPU mimarisiyle devam etmenin birçok avantajı vardır.

Tabii ki, işler değişebilir ve değişebilir. Söylediklerim bugün geçerli, ancak bir yıl hatta bir ay sonra geçerli olmayabilir. Kendi ödevinizi yapın.


1
ARM ile herhangi bir bellek konumuna erişmek için, önce 4K adresinde bir adres içeren bir kayıt yüklemeniz gerekir; birçoğu yalnızca birkaç ayrı adres kullansa da, birçok G / Ç aygıtına 4K'dan daha fazla adres alanı ayrılmıştır. Buna karşılık, 18Fxx PIC'ler çoğu I / O lokasyonunda doğrudan bankacılık durumundan bağımsız olarak tek bir talimatla çalışabilir. RAM'in çoğunun bankalanma yöntemi oldukça can sıkıcıdır, ancak bazı bit vurma türleri için (PIC mimarisinin 1970'lerde tasarlanma amacı) PIC mimarisi çok iyi çalışır.
supercat

1
BTW, 1970'lerden kalma popüler bir 8 bit mikroişlemcinin keyfi olarak hizalanmış 256 baytlık veri yapılarını verimli bir şekilde işleyebildiğini ve 16 bitlik popüler bir işlemcinin 16'ya hizalanmış 65.536 baytlık veri yapılarıyla iyi çalışabileceğini merak ediyorum. - bayt sınırları veya keyfi olarak hizalanmış veri yapıları neredeyse bu büyük, daha yeni 8 bit ve 16 bit işlemciler, sayfa / banka sınırlarını birleştiren verimli kod yazmayı zorlaştırır.
supercat

@supercat "LDR / SRT Anında Ofset" komutu için 4K adres aralığı doğrudur, ancak genellikle bir sorun değildir. Yorumunuzun geri kalanına katılmıyorum. Freescale M4 belgelerine bakıldığında, her bir çevre birimi adres aralığının 4K'dan fazlasını almaz, bu nedenle söz konusu çevre birimindeki tüm kayıtlara erişmek için tek bir "temel adres işaretçisi" yeterlidir. Ayrıca, herhangi bir temel adres işaretçisi olarak kullanılabilen 32 genel amaçlı kayıt vardır - bu nedenle, aynı kod bölümünde birden çok çevre birimine hızlı bir şekilde erişmek nispeten ağrısızdır.

1
@supercat İkinci noktanız RISC ve CISC tartışmasının tamamını ele alıyor. ARM bir RISC CPU'dur, yani en sık yapılan işleri yapmak için optimize edilmiştir. Hizalanmamış erişim gibi sık olmayan görevler daha fazla çalışma gerektirir veya daha fazla zaman alır (CPU Kemerine bağlı olarak). Bunu olumsuz bir şey değil, olumlu bir şey olarak görüyorum. Bu yüzden eski bir 8 bit fiyatı için hızlı 32 bit MCU'lar alıyoruz. Bu tuhaflıklarda bile, bu CPU'lardan birini her gün bir PIC üzerinden alırdım.

Yanlış yazdım; Bir taban kaydının tüm bir çevre birimini işleyemeyeceğini ima etmek istemedim, ancak daha çok her bir çevre birimi için bir kayıt genellikle yüklenmelidir (bu yüzden bir örnek, IO_BASE_ADDR ile her zaman bir kayıt bırakamazdı) ). Bazı kod türleri için, "bsf LATA, 4" gibi bir komutla tek bir döngüde bir G / Ç biti ayarlayabilmek, önce herhangi bir kaydı önceden yüklemeye gerek kalmadan, çok kullanışlı olabilir. ARM'yi seviyorum, ancak PIC'deki doğrudan I / O eşlemesi oldukça güzel olabilir (çok kötü diğer bellek erişimi çok hoş değil).
supercat

3

David Kessner doğru. Aşağıdakileri eklemek istiyorum.

  1. 8 bitlik MCU'lar, PDIP paketlerinde kolayca kullanılabilen ve prototip bir breadboard'a yapışması kolay olan tek MCU'lardır.
  2. 32 bit MCU'lar aslında 8 bit MCU'lardan daha az güç kullanabilir. <20 MHZ 8-bit MCU'nun bir Cortex M4'ten daha az güç kullanacağı doğru değildir.
  3. 8-bit MCU'lar genellikle MCU'dan çok şey gerektirmeyen hobiler tarafından kullanılır. Belki birkaç yüz satır basit C kodu.

Bu günlerde 32 bit MCU'ları kullanmamanın çok az nedeni olduğunu kabul ediyorum. Onları sadece [8-bit MCU'lar] 2 nedenden dolayı kullanırım: PDIP paketinin kolaylığını seviyorum (lehimleme gerekmez); Genellikle 8-bit MCU'nun sunabileceğinden daha fazla güce / karmaşıklığa ihtiyacım yok.

Anlaşma kırıcı gerçekten mevcut araçlardır.


Prototipleme için, LQFP için oldukça iyi çalışan soketler vardır. Ve tabii ki olabilir sadece uygulama biraz alır, elle LQFP lehim. QFN, DFN ve BGA Elle lehimlemem, ancak daha sonra piyasadaki her düşük uç 32 bit MCU LQFP ile birlikte gelir.
Lundin

1

32 bit ~ 80Mhz özellikli bir MCU olan nispeten modaya uygun bir Freescale MCF52259 kullanıyoruz.

Seçim için nedenler / düşünce süreci:

  • 32 bitlik bir M.Core cihazının yerini alıyordu, bu yüzden taşıma nispeten basitti
  • Ayrıca, mevcut IDE'ye (CodeWarrior) bağlı kalabileceğimiz anlamına da geliyordu
  • Çok sayıda IO'ya ihtiyacımız vardı: 3 kademeli motor, 4 kanal PWM, 3 UART ve I2C ve SPI üzerinde adım / yön kontrolü.
  • Çok şey vardı (son noktaya bakın) ve bir kısmının zamanında gerçekleşmesi gerekiyordu, bu yüzden her şeyi yapmak için yeterli CPU döngüsü olduğundan emin olmamız gerekiyordu.
  • Eski kod, M.Core'un 256k flaş boyutuna ve 32k RAM'e çarpıyordu, bu yüzden flaşın ve RAM'in iki katına çıkarılması, çabucak kalkmak ve çalıştırmak için hayatı kolaylaştırdı.

Günümüzde, donanımın kapasitesini (depolama, hız, IO, vb.) Fazla spesifikasyona / genişletmeye, yer veya ortam yoksa marjinal olarak daha ucuz / daha küçük bir MCU'ya sıkıştırmak için kodu optimize etmek için değerli geliştirme süresi harcamaktan daha uygun maliyetlidir (ve amaca uygundur). güç büyük sorunlardır.

Bizim durumumuzda, cihaz yarı fiyatına M.Core'un iki katı özelliğiydi, daha ucuz bir MCU'ya gitmek, kart başına sadece kuruşları kurtaracaktı, ancak çok fazla geliştirme süresine mal olacak ve MCU'ları tekrar değiştirmeden gelecekteki gelişme potansiyelini sınırlandıracaktı.

Milyonlarca pano inşa ediyor olsaydık, işleri parçalamak için maliyet-mühendislik egzersizi yapmaya değer olurdu, ancak durduğu için geliştirme zamanına değmez.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.