Keuntungan mikroprosesor 48-96 Mhz 32-bit (seperti di Arduino Due)


10

Tampaknya Arduino Due (32-bit, 84 Mhz, ARM-Cortex-M3 berbasis SAM3X8E) dirilis hari ini.

Selain itu, jelas ada segudang prosesor dalam kategori ini (32-bit / 48-96 Mhz / ARM) serta papan prototipe yang sesuai:

  • NXP LPC1768 / mBed
  • STM32 / Penemuan
  • PIC32 / ChipKit
  • PIC32 / Parallax Propeller
  • LM4F120 / TI Launchpad
  • dll.

Saya mencoba memahami daya tarik mikroprosesor "di antara" ini, yang bagi saya tampaknya terletak di antara AVR / MSP430 / etc low-end. (pro: murah, daya rendah, tapak kecil) dan ARM7 high-end / etc (pro: mampu instruksi jauh lebih besar per detik).

Dalam situasi atau cara apa mikroprosesor berbasis 32-bit / 48-96 Mhz / ARM merupakan pilihan yang cocok? Lebih khusus, saya bertanya-tanya dalam aplikasi apa atau di mana parameter mereka akan membuat untuk pilihan yang unggul selama desain, baik mikrokontroler 8-bit low-end atau prosesor ARM7 yang sangat high-end.


Nah - hal pertama dalam pikiran saya Anda dapat memproses streaming video langsung - di mana Arduino tidak bisa mengatasinya. Ini juga memungkinkan algoritma enkripsi lanjutan atau hashing (lebih cepat dan lebih mudah daripada di Arduino). Saya terkejut Arduino keluar dengan platform 32bit tetapi hanya menunjukkan Anda - Beberapa orang hanya ingin melakukan lebih dari kontrol relay. Ini hari yang hebat untuk Arduino!
Piotr Kula

Anda tidak akan melakukan lebih dari pemrosesan video langsung yang sepele pada prosesor <100 MHz, kecuali jika Anda melakukannya di inti fungsi khusus terlampir. Dan terutama tidak pada ram on-board yang cukup terbatas pada perangkat ini. Poin yang lebih realistis adalah bahwa biaya chip ini tidak jauh lebih tinggi daripada bagian 8 bit; itu sebenarnya lebih rendah dari ATMEGA dengan flash & ram yang sebanding.
Chris Stratton

3
Sejauh yang saya tahu, Parallax Propeller adalah chip khusus tanpa kaitan dengan PIC32. Adakah sumber untuk koneksi?
AndrejaKo

Jawaban:


12

Ini adalah salah satu mata pelajaran yang bisa menjadi sangat diperdebatkan. Ada begitu banyak sudut pandang yang berbeda, dan berbagai hal penting bagi orang yang berbeda. Saya akan mencoba memberikan jawaban yang komprehensif, tetapi memahami bahwa akan selalu ada seseorang yang tidak setuju. Hanya mengerti bahwa mereka yang tidak setuju dengan saya salah. (Hanya bercanda.)

Ringkasan Cepat:

Jawaban ini akan panjang, jadi izinkan saya merangkumnya di depan. Bagi sebagian besar orang, chip ARM Cortex-M0 / M3 / M4 terbaru menawarkan solusi terbaik, fitur terbaik untuk biaya. Ini bahkan benar ketika membandingkan MCU 32-bit ini dengan leluhur mereka 8 dan 16 bit seperti PIC dan MSP430s. M0 dapat dibeli dengan harga kurang dari US $ 1 / masing-masing dan M4 dengan harga kurang dari US $ 2 / masing-masing kecuali untuk aplikasi yang sangat sensitif terhadap harga solusi ARM sangat bagus. M0 adalah daya yang sangat rendah dan harus cukup baik bagi kebanyakan orang. Bagi mereka yang sangat peka daya, MSP430s mungkin masih menjadi pilihan yang lebih baik, tetapi M0s layak dipertimbangkan bahkan untuk aplikasi ini.

Jika Anda tertarik pada analisis yang lebih mendalam maka bacalah, jika tidak, Anda bisa berhenti membaca sekarang.

Sekarang saya akan melihat setiap area dan membandingkan MCU yang berbeda:

Kecepatan Eksekusi

Tentu saja MCU 32-bit akan lebih cepat. Mereka cenderung memiliki kecepatan clock yang lebih cepat, tetapi juga melakukan lebih banyak pekerjaan untuk masing-masing jam tersebut. MCU seperti ARM Cortex-M4 termasuk instruksi pemrosesan DSP, dan bahkan dapat memiliki dukungan floating point di perangkat keras. 8 dan 16 bit CPU dapat beroperasi pada angka 32-bit, tetapi tidak efisien dalam melakukan hal itu. Melakukannya akan dengan cepat mengkonsumsi register CPU, siklus jam CPU, dan memori flash untuk penyimpanan program.

Kemudahan Pembangunan

Menurut pendapat saya, ini adalah alasan paling berharga untuk menggunakan MCU 32-bit modern - tetapi juga yang paling kurang dihargai. Biarkan saya membandingkan ini dulu dengan PIC 8-bit. Ini adalah perbandingan kasus terburuk, tetapi juga yang terbaik untuk menggambarkan poin saya.

PIC yang lebih kecil pada dasarnya mengharuskan pemrograman dilakukan dalam bahasa assembly. Benar, ada kompiler C yang tersedia bahkan untuk PIC 8-bit tetapi kompiler itu gratis atau bagus. Anda tidak bisa mendapatkan kompiler yang baik dan gratis. Versi gratis dari kompiler lumpuh karena optimasinya tidak sebagus versi "Pro". Versi Pro sekitar US $ 1.000 dan hanya mendukung satu keluarga chip PIC (8, 16, atau 32 bit chip). Jika Anda ingin menggunakan lebih dari satu keluarga maka Anda harus membeli salinan lain seharga US $ 1.000. Versi "Standar" dari kompiler melakukan optimasi tingkat menengah dan biaya sekitar US $ 500 untuk setiap kelompok chip. PIC 8-bit lambat oleh standar modern dan membutuhkan optimasi yang baik.

Sebagai perbandingan, ada banyak kompiler C yang bagus untuk ARM MCU yang gratis. Ketika ada batasan, batasan tersebut biasanya pada ukuran maksimum Memori Flash yang didukung. Pada alat Freescale Codewarrior batas ini adalah 128Kbytes. Ini banyak bagi kebanyakan orang di forum ini.

Keuntungan menggunakan kompiler C adalah Anda tidak perlu repot (sebanyak) dengan detail level rendah dari peta memori CPU. Paging pada PIC sangat menyakitkan dan sebaiknya dihindari jika memungkinkan. Keuntungan lain adalah bahwa Anda tidak perlu repot dengan kekacauan menyerahkan angka 16 dan 32 bit pada MCU 8-bit (atau angka 32 bit pada MCU 16-bit). Meskipun tidak terlalu sulit untuk melakukan ini dalam bahasa assembly, itu adalah rasa sakit di bagian belakang dan rentan kesalahan.

Ada kompiler non-ARM C lain yang bekerja dengan baik. Kompiler MSP430 tampaknya melakukan pekerjaan yang masuk akal. Alat PSoC Cypress (terutama PSoC1) bermasalah.

Model Memori Datar

MCU yang memiliki RAM / register / Flash halaman hanya bodoh. Ya, saya berbicara tentang PIC 8-bit. Bodoh, bodoh, bisu. Itu membuat saya sangat tidak senang dengan PICs sehingga saya bahkan tidak repot-repot melihat barang-barang baru mereka. (Penafian: ini berarti bahwa PIC baru mungkin ditingkatkan dan saya tidak tahu itu.)

Dengan MCU 8-bit sulit (tetapi bukan tidak mungkin) untuk mengakses struktur data yang lebih besar dari 256 byte. Dengan MCU 16-bit yang ditingkatkan menjadi 64 kbytes atau kword. Dengan MCU 32-bit yang mencapai hingga 4 gigabytes.

Kompiler C yang baik dapat menyembunyikan banyak hal ini dari programmer (alias You), tetapi meskipun demikian itu mempengaruhi ukuran program dan kecepatan eksekusi.

Ada banyak aplikasi MCU yang ini tidak akan menjadi masalah, tetapi tentu saja ada banyak aplikasi lain yang akan mengalami masalah dengan ini. Sebagian besar masalah seberapa banyak data yang Anda butuhkan (array dan struktur) dalam RAM atau Flash. Tentu saja, ketika kecepatan CPU meningkat, begitu juga kemungkinan menggunakan struktur data yang lebih besar!

Ukuran paket

Beberapa PIC kecil dan MCU 8-bit lainnya tersedia dalam paket yang sangat kecil. 6 dan 8 pin! Saat ini ARM Cortex-M0 terkecil yang saya tahu adalah dalam QFN-28. Sementara QFN-28 cukup kecil untuk sebagian besar, itu tidak cukup kecil untuk semua.

Biaya

PIC termurah adalah sekitar sepertiga harga ARM Cortex-M0 termurah. Tapi itu benar-benar US $ 0,32 vs US $ 0,85. Ya, perbedaan harga itu penting bagi sebagian orang. Tetapi saya berpendapat bahwa kebanyakan orang di situs web ini tidak peduli dengan perbedaan biaya yang kecil.

Demikian juga, ketika membandingkan MCU yang lebih mampu dengan ARM Cortex-M0 / M3 / M4 biasanya ARM Cortex keluar "kira-kira genap" atau di atas. Ketika memperhitungkan hal-hal lain (kemudahan pengembangan, biaya kompiler, dll. Maka ARM sangat menarik.

Ringkasan Kedua

Saya kira pertanyaan sebenarnya adalah: Mengapa Anda TIDAK menggunakan ARM Cortex-M0 / M3 / M4? Ketika biaya absolut sangat penting. Ketika konsumsi daya super rendah sangat penting. Ketika ukuran paket terkecil diperlukan. Ketika kecepatan tidak penting. Tetapi untuk sebagian besar aplikasi tidak ada yang berlaku dan ARM saat ini merupakan solusi terbaik.

Mengingat biayanya rendah, kecuali ada alasan kuat untuk tidak menggunakan ARM Cortex, maka masuk akal untuk menggunakannya. Ini akan memungkinkan waktu pengembangan lebih cepat dan lebih mudah dengan sakit kepala lebih sedikit dan margin desain lebih besar daripada kebanyakan MCU lainnya.

Ada MCU non-ARM Cortex 32-bit lain yang tersedia, tapi saya juga tidak melihat manfaatnya. Ada banyak keuntungan menggunakan arsitektur CPU standar, termasuk alat pengembangan yang lebih baik, dan inovasi teknologi yang lebih cepat.

Tentu saja, hal-hal dapat dan memang berubah. Apa yang saya katakan valid hari ini, tetapi mungkin tidak valid dalam satu tahun atau bahkan sebulan dari sekarang. Kerjakan pekerjaan rumah Anda sendiri.


1
Untuk mengakses lokasi memori dengan ARM, seseorang harus terlebih dahulu memuat register dengan alamat yang berada dalam 4K; banyak perangkat I / O dialokasikan lebih dari 4K ruang alamat, meskipun banyak yang hanya menggunakan beberapa alamat diskrit. Sebaliknya, PIC 18Fxx dapat langsung beroperasi di sebagian besar lokasi I / O dengan instruksi tunggal, terlepas dari kondisi perbankan. Cara yang digunakan untuk menyimpan sebagian besar RAM agak mengganggu, tetapi untuk jenis bit-banging tertentu (tujuan arsitektur PIC dirancang pada tahun 1970-an) arsitektur PIC bekerja dengan sangat baik.
supercat

1
BTW, saya merasa penasaran bahwa sementara mikroprosesor 8-bit yang populer dari tahun 1970-an dapat secara efisien memproses struktur data 256-byte yang selaras, dan prosesor 16-bit yang populer dapat bekerja dengan baik dengan struktur data 65,536-byte yang selaras pada 16 -batas batas atau struktur data yang diselaraskan secara acak hampir sebesar itu, prosesor 8-bit dan 16-bit yang lebih baru membuatnya sulit untuk menulis kode efisien yang melintasi batas-batas halaman / bank.
supercat

@supercat Kisaran alamat 4K untuk instruksi "LDR / SRT Immediate Offset" benar, tetapi seringkali tidak menjadi masalah. Saya tidak setuju dengan sisa komentar Anda. Melihat pada Freescale M4 docs, setiap perangkat tidak membutuhkan lebih dari 4K rentang alamat sehingga satu "pointer alamat basis" cukup untuk mengakses semua register di perangkat itu. Ada juga 32 register tujuan umum, yang mana dapat digunakan sebagai pointer alamat basis - sehingga mengakses beberapa perangkat dengan cepat di bagian kode yang sama relatif tidak menyakitkan.

1
@supercat Poin kedua Anda menyentuh seluruh perdebatan RISC vs CISC. ARM adalah CPU RISC, yang berarti dioptimalkan untuk melakukan tugas yang paling sering. Tugas yang tidak sering, seperti akses yang tidak selaras, membutuhkan lebih banyak pekerjaan atau membutuhkan waktu lebih lama (tergantung pada Lengkungan CPU). Saya melihat ini sebagai hal yang positif, bukan hal yang negatif. Itu sebabnya kami mendapatkan MCU 32-bit cepat dengan harga 8-bit yang lebih tua. Bahkan dengan kebiasaan ini, saya akan mengambil salah satu dari CPU ini lebih dari PIC setiap hari.

Saya salah bicara; Saya tidak bermaksud mengatakan bahwa satu register dasar tidak dapat menangani seluruh perangkat, tetapi register harus sering kali dimuat untuk setiap perangkat (jadi orang tidak bisa hanya misalkan meninggalkan register dengan IO_BASE_ADDR sepanjang waktu ). Untuk beberapa jenis kode, dapat mengatur bit I / O dalam satu siklus dengan instruksi seperti "bsf LATA, 4", tanpa harus memuatkan register terlebih dahulu, bisa sangat berguna. Saya suka ARM, tetapi pemetaan I / O langsung pada PIC bisa sangat bagus (terlalu buruk akses memori lainnya tidak begitu baik).
supercat

3

David Kessner benar. Saya ingin menambahkan yang berikut ini.

  1. MCU 8-bit adalah satu-satunya MCU yang tersedia dalam paket PDIP yang mudah ditangani dan mudah ditempelkan di papan tempat memotong roti prototipe.
  2. MCU 32-bit sebenarnya dapat menggunakan daya lebih kecil dari MCU 8-bit. Belum tentu benar bahwa MCU <20 MHZ 8-bit akan menggunakan daya lebih kecil dari Cortex M4.
  3. 8-bit MCU sering digunakan oleh penggemar yang biasanya tidak memerlukan banyak dari MCU. Mungkin beberapa ratus baris kode C sederhana.

Saya setuju bahwa hari ini ada sedikit alasan untuk tidak menggunakan MCU 32-bit. Saya hanya akan menggunakannya [MCU 8-bit] karena 2 alasan: Saya suka kemudahan paket PDIP (tidak diperlukan solder); Saya sering tidak membutuhkan lebih banyak kekuatan / kompleksitas daripada apa yang dapat ditawarkan MCU 8-bit.

Pemecah kesepakatan sebenarnya adalah alat yang tersedia.


Untuk prototyping, ada soket untuk LQFP, yang berfungsi cukup baik. Dan tentu saja Anda dapat menyolder LQFP dengan tangan, hanya perlu sedikit latihan. QFN, DFN dan BGA Saya tidak akan menyolder dengan tangan, tapi kemudian setiap MCU 32 bit low-end di pasaran datang dengan LQFP.
Lundin

1

Kami menggunakan Freescale MCF52259 yang relatif tidak modis, sebuah MCU berkemampuan 32-bit ~ 80Mhz.

Alasan / proses berpikir untuk pilihan tersebut adalah:

  • Itu menggantikan perangkat M.Core 32-bit, sehingga porting relatif sederhana
  • Itu juga berarti kita bisa tetap menggunakan IDE yang ada (CodeWarrior)
  • Kami membutuhkan banyak IO: Kontrol untuk langkah / arah pada 3 motor stepper, 4 saluran PWM, 3 UART, dan I2C dan SPI.
  • Ada banyak hal yang terjadi (lihat poin terakhir) dan beberapa di antaranya perlu terjadi tepat waktu, jadi kami perlu memastikan bahwa ada cukup siklus CPU untuk menyelesaikan semuanya.
  • Kode lawas itu menabrak ukuran flash 256 ribu dan RAM 32 core, jadi menggandakan flash & RAM membuat hidup mudah untuk bangkit & berjalan cepat.

Saat ini lebih hemat biaya (dan lebih bijaksana) untuk lebih spesifik / memperluas kemampuan perangkat keras (penyimpanan, kecepatan, IO, dll.) Daripada menghabiskan waktu pengembangan yang berharga untuk mengoptimalkan kode untuk memasuki MCU yang lebih murah / lebih kecil kecuali ruang atau kekuatan adalah masalah besar.

Dalam kasus kami, perangkat itu dua kali lipat dari spesifikasi M.Core untuk setengah harga, pergi ke MCU yang lebih murah hanya akan menghemat uang per papan tetapi menghabiskan banyak waktu pengembangan dan membatasi potensi pengembangan di masa depan tanpa mengubah MCU lagi.

Jika kita membangun satu juta papan, ada baiknya melakukan latihan rekayasa biaya untuk memangkas segalanya, tetapi seperti berdiri, itu tidak sebanding dengan waktu pengembangan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.