Satu mikrokontroler besar, atau banyak mikrokontroler kecil?


24

Saya terbiasa melakukan hal-hal dasar dan langsung dengan mikrokontroler, relatif berbicara. Hal-hal seperti mengemudi LED, menjalankan motor, rutinitas dasar, GUI pada LCD karakter, dan sebagainya, tetapi selalu hanya satu tugas utama dengan paling sedikit beberapa tugas sampingan. Ini telah menurunkan saya ke produk-produk kelas bawah karena itu benar-benar yang diperlukan dalam kasus-kasus itu.

Saya ingin mulai merancang hal-hal yang lebih kompleks tetapi sisi atas dari kontinum mikrokontroler bukanlah sesuatu yang saya telah terpapar dengan baik. Jadi, saya sudah memiliki waktu yang sangat menantang mencoba untuk memilih mikrokontroler di mana saya akan melakukan banyak tugas secara bersamaan - saya tidak bisa mengatakan hanya dengan nomor MIPS dan pinout yang memuaskan jika memiliki tenaga kuda yang cukup untuk melakukan apa yang saya inginkan melakukan.

Sebagai contoh, saya ingin mengendalikan 2 motor BLDC dengan rutinitas PI, di samping beberapa serial dan USB comms, GUI, dan banyak tugas lainnya. Saya tergoda untuk hanya memiliki mikrokontroler untuk setiap motor dan kemudian satu untuk tugas lain-lain sehingga saya dapat menjamin bahwa overhead dari hal-hal lain tidak akan merusak fungsi motor yang kritis. Tapi saya tidak tahu apakah itu ide yang bagus atau cara naif untuk melakukan sesuatu.

Saya kira pertanyaan saya benar-benar berlipat dua:

  1. Apakah pendekatan all-in-one adalah ide yang bagus ketika harus melakukan banyak tugas multitasking, atau apakah lebih baik melakukan segmentasi dan mengisolasi, dan

  2. Bagaimana saya bisa mengetahui secara intuitif jika mikrokontroler yang saya lihat memiliki daya komputasi yang cukup untuk melakukan apa yang saya butuhkan berdasarkan daftar tugas saya?

Saya sedang melihat dsPIC33 moderat sampai ke ARM SoC yang menjalankan RTOS. Cara sistematis untuk mengasah apa yang saya butuhkan akan banyak membantu saya.




4
Sudah terlalu banyak jawaban, tetapi kadang-kadang mendapatkan banyak micros yang dapat diprogram di papan yang sama semua berbicara dengan bahasa yang sama jauh lebih berhasil daripada hanya menggunakan mikro tunggal, mungkin dengan beberapa perangkat cerdas.
Erik Friesen

Jawaban:


10

Jawaban atas pertanyaan Anda berbeda tergantung pada apa tujuan akhir Anda. Jika Anda membutuhkan sedikit atau kurang dari perangkat ini, Anda harus membuat pengembangan lebih mudah, dan tidak perlu khawatir tentang biaya komponen. Jika Anda akan membuat seribu atau lebih dari ini, ada baiknya menganalisis persyaratan Anda dan mengurangi biaya perangkat keras perangkat.

Jumlah kecil

Jika Anda menjalankan perangkat ini satu kali atau sedikit, maka upaya pengembangan Anda akan membanjiri biaya per-item Anda, dan Anda harus fokus pada apa yang akan termudah / tercepat untuk Anda kembangkan, daripada biaya / ukuran mikroelektronik.

Secara umum enkapsulasi dapat mengurangi kompleksitas, meningkatkan produktivitas Anda. Jika Anda memiliki beberapa persyaratan real-time yang sulit, seperti kontrol BLDC, loop PID, dll, maka Anda mungkin menemukan lebih cepat untuk menggunakan pengontrol terpisah khusus untuk tugas-tugas yang berkomunikasi dengan pengontrol di mana Anda menjaga antarmuka pengguna dan non-real lainnya tugas waktu.

Jadi dalam hal ini, jawaban atas pertanyaan Anda adalah:

Apakah pendekatan all-in-one adalah ide yang bagus ketika harus melakukan banyak tugas multitasking, atau apakah lebih baik melakukan segmentasi dan mengisolasi, dan

Skala tips sedikit menuju segmentasi dan isolasi. Alasan utama adalah bahwa debugging sistem waktu nyata bisa sangat memakan waktu, dan menjaga tugas-tugas seperti itu pada prosesor mereka sendiri membatasi variabel yang harus Anda ukur atau kontrol ketika mencoba menemukan mengapa sesuatu tidak berfungsi dengan benar.

Bagaimana saya bisa mengetahui secara intuitif jika mikrokontroler yang saya lihat memiliki daya komputasi yang cukup untuk melakukan apa yang saya butuhkan berdasarkan daftar tugas saya?

Dalam hal ini perbedaan biaya antara prosesor 32 bit dengan banyak sumber daya dan prosesor 8 bit dengan sumber daya terbatas relatif kecil dibandingkan dengan jumlah waktu yang Anda habiskan untuk pengembangan. Ada sedikit alasan untuk mencoba dan mencari tahu berapa banyak daya yang Anda butuhkan - dapatkan saja prosesor terbesar yang menurut Anda dapat Anda kembangkan dan gunakan itu. Jika pada suatu saat nanti Anda perlu mengoptimalkan desain biaya, itu relatif mudah untuk mengukur penggunaan sumber daya prosesor yang sebenarnya, kemudian pilih prosesor lessor yang dapat menangani beban aktual. Sampai saat itu, gunakan yang terbesar dan jangan khawatir tentang menemukan "paling cocok".

Produksi massal

Jika Anda berencana untuk membuat banyak perangkat ini, maka analisis yang cermat akan menghasilkan penghematan biaya yang signifikan. Secara umum, mikrokontroler yang lebih besar akan menelan biaya kurang dari dua mikrokontroler yang mampu menggantikan mikrokontroler tunggal, meskipun tentu ada pengecualian tergantung pada tugas-tugas khusus yang diperlukan. Pada jumlah ini, biaya perangkat keras kemungkinan akan jauh lebih besar daripada biaya pengembangan, jadi Anda harus berharap untuk menghabiskan lebih banyak waktu menganalisis persyaratan Anda dan melakukan pengembangan daripada yang akan Anda lakukan jika Anda hanya menghasilkan sedikit.

Apakah pendekatan all-in-one adalah ide yang baik ketika harus melakukan banyak tugas multitasking, atau lebih baik melakukan segmentasi dan mengisolasi?

Pendekatan all-in-one umumnya akan lebih murah sepanjang umur seluruh proyek daripada beberapa prosesor. Ini akan membutuhkan lebih banyak pengembangan dan waktu debug untuk memastikan berbagai tugas tidak bertentangan, tetapi desain perangkat lunak yang ketat akan membatasi hampir sebanyak memiliki perangkat keras terpisah.

Bagaimana saya bisa mengetahui secara intuitif jika mikrokontroler yang saya lihat memiliki daya komputasi yang cukup untuk melakukan apa yang saya butuhkan berdasarkan daftar tugas saya?

Anda perlu memahami tugas yang ingin Anda lakukan dan berapa banyak sumber daya yang mereka ambil. Misalkan yang berikut ini benar:

Rutinitas BLDC PI Anda akan mengkonsumsi X siklus waktu prosesor 100 kali per detik, dan masing-masing membutuhkan sekitar 50 byte RAM untuk operasi, 16 byte EEPROM untuk penyetelan, dan 1k flash untuk kode. Mereka masing-masing membutuhkan 3 periferal 16 bit PWM dalam mikrokontroler. Anda mungkin perlu menentukan jitter, yang akan memiliki persyaratan latensi interupsi tertentu.

USB dan rutinitas serial Anda akan mengkonsumsi siklus Y dari waktu prosesor sesuai kebutuhan, 2k RAM, 64 byte EEPROM, dan 8k flash. Ini akan membutuhkan USB dan periferal serial.

GUI Anda akan mengkonsumsi daya siklus Z 30 kali per detik, dan akan membutuhkan 2k RAM, 128 byte EEPROM, dan 10k flash. Ini akan menggunakan 19 I / O untuk komunikasi dengan LCD, tombol, kenop, dll.

Ketika Anda baru mulai, mungkin sulit untuk memahami apa itu X, Y, Z sebenarnya, dan ini akan berubah sedikit tergantung pada arsitektur prosesor. Namun Anda harus dapat memahami, dalam perkiraan rata-rata, berapa banyak ram, eeprom, dan flash yang akan dibutuhkan desain Anda, dan periferal apa yang Anda butuhkan. Anda dapat memilih rangkaian prosesor yang memenuhi memori dan persyaratan periferal dan memiliki beragam opsi kinerja dalam keluarga itu. Pada titik itu, untuk pengembangan, Anda cukup menggunakan prosesor paling kuat di keluarga. Setelah Anda menerapkan desain Anda, Anda dapat dengan mudah memindahkan keluarga dalam hal daya ke opsi biaya yang lebih rendah tanpa mengubah desain atau lingkungan pengembangan Anda.

Setelah cukup banyak melakukan desain ini, Anda dapat memperkirakan X, Y, dan Z dengan lebih baik. Anda akan tahu bahwa rutinitas BLDC PI, meskipun sering dijalankan, cukup kecil dan membutuhkan siklus yang sangat sedikit. USB dan serial rutin membutuhkan banyak siklus, tetapi jarang terjadi. Antarmuka pengguna memerlukan beberapa siklus sering untuk menemukan perubahan, tetapi akan membutuhkan banyak siklus jarang memperbarui tampilan, misalnya.


11

Saya akan memisahkan kontrol motor, dan memiliki mikrokontroler terpisah yang mencakup PWM (mungkin PIC18) untuk masing-masing dari dua motor BLDC, karena kontrol PI adalah tugas yang terisolasi setelah dijalankan, dan setelah Anda menulis kode Anda bisa menggunakannya di kedua micros. Anda dapat menghubungkannya kembali ke mikrokontroler utama melalui antarmuka seperti I²C, dan unduh parameter untuk kontrol PI dari sana jika diinginkan. Itu akan memungkinkan Anda untuk memodifikasinya di GUI Anda.

Saya kemudian akan menjalankan semua yang lain di mikrokontroler utama, seperti PIC24 (PIC32 mungkin berlebihan, berdasarkan pada tugas yang Anda daftarkan). Plus, PIC24E tercepat dapat berjalan hampir secepat PIC32.

Ketika memilih mikrokontroler, saya pertama-tama memperkirakan jumlah flash dan RAM yang saya butuhkan, dan kemudian melihat panjang kata dan kecepatan prosesor. Untuk nanti, seringkali persyaratan yang paling sulit untuk dipenuhi adalah interupsi tercepat yang Anda harapkan untuk ditangani. Jika Anda mengeluarkan suara 16 KHz, misalnya, dan memiliki interupsi setiap 62,5 μs, maka Anda lebih baik memiliki mikrokontroler dengan waktu instruksi turun dalam puluhan nanoseconds, atau Anda tidak akan dapat melayani dan mendapatkan yang lain kerja selesai.


7

Ada pendekatan semi formal yang dapat Anda gunakan untuk membantu Anda menghasilkan jawaban. Saya sangat merekomendasikan membaca bab 2 dari "Merancang Sistem Tertanam" White, yang sebagian besar tersedia di Google Buku .

Bab ini membahas tentang merancang arsitektur sistem, dan menawarkan pendekatan semi formal untuk cara terbaik merangkum tugas-tugas. Sementara bab ini sebagian besar tentang satu sistem pengontrol, ia dengan mudah meluas ke beberapa pengontrol. Ini akan membantu Anda membayangkan sumber daya mana yang perlu dibagikan, dan membantu Anda memilih tingkat enkapsulasi Anda untuk setiap tugas.

Dia menawarkan berbagai pandangan untuk dipertimbangkan, salah satunya saya tunjukkan di bawah ini, tetapi ada banyak manipulasi yang berguna. Ini, tentu saja, tidak masuk akal sendiri, tetapi saya harap ini mendorong Anda untuk membaca bab ini.

dari White, Making Embedded Systems, Bab 2

Mengenai "bagaimana saya tahu jika saya memiliki cukup pengontrol", preferensi saya sendiri adalah memasukkan daya sebanyak mungkin ke dalam kotak pasir perancangan saya sebanyak yang saya bisa, dan kemudian mencari tahu berapa banyak sumber daya yang dapat saya kurangi begitu desainnya berjalan dengan baik. cara. Perbedaan harga antara $ 10 mikrokontroler dan $ 3 mikrokontroler untuk keperluan prototyping mungkin hanya beberapa minggu untuk memperlengkapi kembali dan memutar-mutar ibu jari Anda menunggu suku cadang baru, sementara desain selalu dapat terus bergerak jika Anda memiliki daya yang cukup.


5

Saya bekerja pada sistem yang secara luas menggambarkan apa yang Anda gambarkan - motor, IO, display, 3x UARTs + SPI + I2C berjalan pada Coldfire 52259 (mid-range 32-bit ~ 80MHz micro) dan itu tidak terlalu sulit, meskipun mendapatkan arsitektur perangkat lunak yang tepat adalah penting - kami memiliki banyak hal yang berjalan pada perangkat keras & interupsi (apa pun yang dapat ditangani sendiri oleh perangkat keras, kami menjalankan perangkat keras & layanan dengan interupsi) meninggalkan loop () utama untuk melakukan semua pembersihan.

Secara pribadi saya tidak suka kebanyakan RTOS yang pernah saya lihat, pada akhirnya mereka membengkak proyek, menambahkan hal lain untuk dipelajari, dan Anda akan mendapatkan kinerja yang lebih baik dari perangkat keras dengan melakukan sesuatu secara langsung (menggunakan fungsi perangkat keras yang tersedia + interupsi) daripada berpura-pura dengan perangkat lunak.

Pada akhirnya, akhir-akhir ini nampaknya ada sedikit perbedaan antara MCU yang rumit & cukup kuat untuk benar - benar diuntungkan oleh RTOS dan sesuatu (SoC) yang baru saja menjalankan Linux tertanam.

Namun, dalam contoh itu saya akan mengatakan ada beberapa nilai dalam menggunakan micros murah kecil untuk menangani fungsi-fungsi kritis (kontrol motor EG di mana waktu atau berhenti pada batas sangat penting) di bawah perintah CPU "otak" utama sehingga Anda tidak mengandalkan pada "non-realtime" OS untuk melakukan sesuatu tepat waktu.


3

Semua orang menjawab lebih baik tetapi saya harus menambahkan sedikit yang mungkin berguna. Ini mungkin agak melenceng dan saya ingin menambahkannya sebagai komentar tetapi ada aturan 50 rep :(

Jawaban singkatnya tergantung, lihat di atas tetapi mengapa tidak berpikir tentang manfaat prosesor juga.

Mengapa tidak memikirkan manfaat prosesor yang lebih kecil. Bagaimanapun, ini adalah pertanyaan tentang prosesor. Untuk tugas-tugas matematika dan non-iteratif tertentu, beberapa prosesor dapat menghasilkan dorongan logaritmik. Aturan Amdahl menyatakan bahwa dorongan dapat dicapai1((1-hal)+hals)tapi ini datang. P adalah persentase perhitungan yang dapat dibagi dan s adalah percepatan (tergantung pada jumlah operasi, perangkat keras; dll.).

Tentu saja, biaya, kemudahan implementasi; dll. penting dan bahkan lebih penting untuk dipertimbangkan juga.


1

Jawabannya dapat bergantung pada detail implementasi. Beberapa tugas lebih mudah diimplementasikan dengan cara yang bersih dan kuat pada mikrokontroler yang terpisah. Konsumsi daya juga dapat menjadi pertimbangan - secara umum satu mikro menangani beberapa tugas akan membutuhkan daya lebih sedikit daripada beberapa mikro menangani tugas tunggal.


1

"Horsepower" adalah nomor dua apakah Anda dapat memenuhi batasan waktu nyata Anda.

Jika Anda memiliki dua output PWM, dan keduanya perlu beralih pada waktu yang sama, maka Anda perlu memiliki paralelisme yang diperlukan untuk dapat melakukan itu. Jika Anda memiliki pengontrol PWM khusus yang menangani waktu yang tepat, itu akan bekerja, bahkan dengan mikrokontroler yang agak kecil, sedangkan solusi berbasis GPIO akan sangat kompleks bahkan jika banyak daya komputasi tersedia.

Untuk sebagian besar protokol, MCU modern telah menanamkan implementasi dari bagian-bagian protokol yang memiliki kendala waktu nyata, jadi jika Anda dapat menemukan MCU yang memiliki periferal yang diperlukan dan memiliki kecepatan CPU yang diperlukan untuk menangani aliran data (yaitu persyaratan realtime yang keras mengalami degenerasi ke dalam persyaratan waktu nyata yang lunak dari formulir "akan dapat membaca dari FIFO sebelum penuh, dan lebih cepat daripada mengisi"), itu akan menjadi pilihan yang optimal.

Jika tidak ada solusi seperti itu, opsi Anda adalah memindahkan fungsi ke controller yang terpisah, menggunakan solusi CPU + FPGA (mis. FPGA dengan inti ARM keras), atau solusi FPGA murni (opsional dengan CPU lunak, tergantung pada persyaratan kerumitan).

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.