Pemrograman Fungsional dengan MCU

12

Bahasa fungsional seperti Haskell, LISP, atau Skema memungkinkan seorang programmer untuk bekerja dengan cepat menggunakan paradigma pemrograman fungsional . Mereka memang memiliki inefisiensi , tetapi aplikasi saya lebih menekankan efisiensi pemrogram daripada efisiensi program itu sendiri.

Saya ingin menggunakan pemrograman fungsional pada mikrokontroler untuk melakukan kontrol mesin, dll.

Keterbatasan apa yang ada, seperti sumber daya sistem minimum?
Contoh implementasi apa dari bahasa-bahasa ini yang tersedia?

microcontroller  programming 
— J. Polfer
sumber
1
Jika pertanyaan Anda adalah "Bukankah layak untuk memprogram mesin apa pun dengan bahasa pemrograman paling kuat yang bisa Anda dapatkan," pertanyaan C ++ dan Java disarankan untuk dibaca (tentang OOP daripada pemrograman fungsional).
— Kevin Vermeer
1
Paragraf pertama Anda dianggap argumentatif, yang telah memberi Anda sedikit suara. Pertimbangkan menulis ulang untuk sesuatu yang lebih pasif ("Saya tertarik menggunakan pemrograman fungsional untuk kontrol mesin, contoh apa saja yang ada dari implementasi Haskell / LISP / Skema untuk sistem embedded") atau menghapus seluruhnya.
— Kevin Vermeer
2
Saya tidak membeli pernyataan "tidak efisien" Anda. Anda tampaknya menunjukkan bias ekstrim terhadap sisi hobi / prototipe - volume rendah (alias: 1). C / C ++ / asm menghasilkan kode yang lebih kecil, lebih cepat yang diperbesar ribuan atau jutaan kali ketika Anda dapat menggunakan prosesor dengan kecepatan dan ruang yang cukup. Tertanam tertanam. Anda tidak pemrograman pada OS tujuan umum.
— Nick T
4
@Nick T - "C / C ++ / asm menghasilkan kode yang lebih kecil, lebih cepat yang diperbesar ribuan atau jutaan kali ketika Anda dapat menggunakan prosesor dengan kecepatan dan ruang yang cukup" - bagaimana dengan pemeliharaan? Bahasa fungsional sering dapat dilakukan dalam satu baris apa yang dibutuhkan program C 10s, yang berarti lebih sedikit ruang untuk bug. Selain itu, mereka dapat dipatuhi (yaitu Haskell), dan dibuat untuk berjalan pada target, yang lebih cepat daripada penerjemah. Saya ingin menjelajahi topik ini sedikit karena Haskell yang dikompilasi mungkin sama cepatnya, tetapi lebih cepat untuk dikembangkan daripada mengatakan aplikasi C. Ingin sedikit mempertanyakan status quo.
— J. Polfer
1
@ Sheepimulator Sayangnya, komentar seperti yang terakhir Anda ajukan pertanyaan seperti ini argumentatif.
— Kellenjb

Jawaban:

11

SKEMA ARMPIT adalah penerjemah untuk bahasa Skema (dialek leksikal Lisp) yang berjalan pada mikrokontroler RISC dengan inti ARM. Ini didasarkan pada uraian dalam Laporan Revisi Skema Bahasa Algoritmik (r5rs), dengan beberapa ekstensi (untuk I / O) dan beberapa kelalaian (agar sesuai dengan memori MCU). Lebih lanjut dirancang untuk mendukung multitasking dan multiprocessing. Skema ketiak diharapkan cocok untuk pengaturan pendidikan, termasuk proyek siswa dalam kursus tentang kontrol dan instrumentasi, atau kursus desain batu penjuru di mana mikrokontroler diperlukan. Ini dimaksudkan untuk memperkaya spektrum bahasa yang ditafsirkan yang tersedia untuk MCU (mis. BASIC dan FORTH) dan dapat menjadi alternatif bagi penerjemah bytecode berbasis MCU (misalnya untuk Skema atau Jawa) dan ke bahasa yang dikompilasi (misalnya C).

http://armpit.sourceforge.net/

Kamu bilang:

Menggunakan C, C ++, assembly, dll. Cukup tidak efisien dibandingkan dengan bahasa seperti Haskell, LISP, atau Scheme

Menggunakan bahasa tingkat tinggi adalah penggunaan waktu programmer yang lebih efisien, tetapi seringkali bisa menjadi penggunaan sumber daya komputasi yang kurang efisien. Untuk sistem tertanam yang diproduksi dalam volume, biaya dan kinerja sering kali lebih diprioritaskan daripada upaya pengembangan.

— Toby Jaffey
sumber
5

C, C ++, dan Assembly semuanya sangat dekat dengan bahasa mesin. Dengan menggunakan bahasa tingkat yang lebih tinggi, Anda menambahkan overhead tambahan sebagai imbalan untuk pengembangan yang lebih cepat / mudah / dll.

— pfyon
sumber
3
-1: Saya tidak setuju dengan jawaban ini. Meskipun hak Anda tentang Assembly dekat dengan bahasa mesin, C dan C ++ adalah bahasa tingkat tinggi yang sangat berbeda.
— BG100
1
@ BG100, saya benar-benar menggambar garis "tingkat tinggi / rendah" di suatu tempat di dalam C daripada hanya menyebutnya bahasa tingkat tinggi. Saat melakukan operasi aritmatika, penunjuk (string), dan tugas dasar umum lainnya, instruksi yang biasanya dihasilkan oleh kompiler membuat CPU secara langsung memanipulasi data tanpa lapisan abstraksi.
— Nick T
@Nick T: Saya mengerti maksud Anda, tetapi pertimbangkan ini: jika Anda menulis rutin interupsi yang umumnya perlu dijalankan secepat mungkin, di C Anda tidak akan tahu berapa lama untuk berjalan, tetapi dalam assembler Anda dapat hitung saja instruksinya. Saya pikir level rendah mengetahui bahwa PERSIS sedang terjadi di program Anda, Anda tidak tahu pasti apakah Anda menggunakan C.
— BG100
@ BG100: instruksi assembler yang sama dapat mengambil jumlah siklus yang berbeda untuk dieksekusi berdasarkan operan dan mode pengalamatannya. Padahal di C, setelah Anda kompilasi Anda mendapatkan kode statis yang tidak (tidak bisa) berubah. Benar, ini adalah argumen yang agak lemah, tetapi jika kita akan berdebat hal-hal kecil untuk mencoba menggambar garis merah besar ...
— Nick T
3

Saya telah memprogram papan ARM dengan Python baru-baru ini, dan saya pikir itu hebat. Ini tidak baik untuk kontrol waktu nyata, tetapi saya melakukan lebih banyak hal yang berhubungan dengan web, yang jauh lebih menyenangkan dalam bahasa tingkat tinggi daripada dalam C.

— pingswept
sumber
3

Mayoritas mikrokontroler masih perangkat 8 dan 16-bit (meskipun ini perlahan-lahan berubah). Dua contoh bahasa tingkat tinggi (Skema dan Python) yang disebutkan dalam jawaban lain sejauh ini keduanya berjalan pada core ARM 32-bit. Perangkat 8 dan 16-bit yang lebih kecil (yang mungkin hanya berharga beberapa dolar) tidak memiliki cukup RAM untuk mendukung bahasa yang disebutkan - biasanya mereka hanya memiliki beberapa KB RAM.

Juga, bahasa tingkat tinggi ini tidak dirancang untuk menulis penangan interupsi latensi rendah dan sejenisnya. Bukan hal yang aneh bagi pengendali interrupt mikrokontroler untuk dipanggil ratusan atau ribuan kali per detik, dan setiap kali diperlukan untuk melakukan tugasnya dalam puluhan mikrodetik atau kurang.

— tcrosley
sumber
1
Skema dikembangkan pada pertengahan '70 -an dan sangat awal '80 -an. Tidak berarti apakah Skema memerlukan prosesor 32-bit atau megabita memori. Skema tersedia untuk PC kelas AT pada pertengahan tahun 80-an. Implementasi terbaru mungkin dioptimalkan untuk lingkungan yang lebih kaya sumber daya, tetapi ada contoh yang jelas dari Skema yang berjalan pada apa yang sekarang platform komputasi "sangat kecil".
— The Photon
@ThePhoton aku berdiri terkoreksi. Meskipun saya mengetahui proyek BIT, yang menargetkan prosesor dengan puluhan KB memori (lebih dari apa yang tersedia pada kebanyakan mikrokontroler kecil), saya baru saja menemukan PICBIT , yang dirancang oleh beberapa siswa di Université de Montréal dan Université Laval, yang memungkinkan program Skema nyata untuk berjalan pada prosesor PIC dengan hanya 2K RAM. Luar biasa.
— tcrosley
3

Dimungkinkan untuk melakukan beberapa pemrograman fungsional dengan bahasa Lua. Sungguh, Lua adalah bahasa paradigma mutli; Wikipedia mengklaim bahwa itu adalah bahasa 'scripting, imperatif, fungsional, berorientasi objek, berbasis prototipe'. Bahasa tidak menegakkan paradigma tunggal, tetapi sebaliknya cukup fleksibel untuk memungkinkan programmer untuk menerapkan paradigma apa pun yang berlaku untuk situasi tersebut. Sudah dipengaruhi oleh Skema.

Fitur-fitur Lua meliputi fungsi-fungsi kelas satu , pelingkupan leksikal dan penutupan dan coroutine , yang berguna untuk pemrograman fungsional. Anda dapat melihat bagaimana fitur-fitur ini digunakan pada wiki pengguna Lua, yang memiliki halaman yang didedikasikan untuk pemrograman fungsional . Saya juga menemukan proyek Google Code ini , tetapi saya belum menggunakannya (ia mengklaim dipengaruhi oleh Haskell, bahasa lain yang Anda sebutkan).

eLua adalah implementasi yang tersedia dikonfigurasi untuk sejumlah papan pengembangan untuk arsitektur ARM7TMDI, Cortex-M3, ARM966E-S dan AVR32, dan merupakan open-source sehingga Anda dapat mengkonfigurasinya untuk platform Anda sendiri. Lua diimplementasikan dalam ANSI C dan seluruh sumber berbobot di bawah 200kB, sehingga Anda harus dapat membangunnya untuk sebagian besar platform dengan kompiler C. Direkomendasikan setidaknya 128k Flash dan 32k RAM. Saya sedang mengerjakan port PIC32 untuk itu (masih dalam tahap 'Get the PIC32 board') saat ini.

Hal yang hebat tentang Lua adalah bahwa ia dirancang sebagai bahasa lem, jadi sangat mudah untuk menulis ekstensi C untuk hal-hal yang perlu cepat (seperti interupsi dll), dan menggunakan fitur dinamis, yang ditafsirkan bahasa untuk melakukan cepat pengembangan dalam logika program.

Lua bukan bahasa yang sepenuhnya fungsional, tetapi Anda dapat melakukan banyak pemrograman fungsional di dalamnya, cepat dan kecil ( dibandingkan dengan bahasa skrip lain ), dan Anda tidak perlu merombak perangkat Anda untuk mencoba suatu program. Bahkan ada penerjemah interaktif!

— Kevin Vermeer
sumber
1

"Apakah ada cara untuk melakukan pemrograman fungsional dengan bahasa fungsional pada MCU untuk memecahkan masalah yang sulit?"

Ya, ada beberapa cara. Namun kekurangannya adalah Anda membutuhkan prosesor 32-bit, MMU, 128MB RAM, SSD, RTOS, dan $$$.

Mikrokontroler berbeda dari mikroprosesor. Mikrokontroler mungkin hanya CPU 8-bit, RAM 1K, ROM 8K, tetapi memiliki built in UART, PWM, ADC, dll. Dan itu hanya berharga $ 1,30.

Jadi Anda bisa menjalankan semua bahasa tingkat tinggi, tetapi membutuhkan lebih banyak biaya untuk membuatnya.

— Robert
sumber
2
Saya pikir Anda perlu meninjau kembali definisi Anda tentang mikrokontroler. Banyak mikrokontroler sekarang memiliki 128kB atau lebih dari Flash, dan 64kB atau lebih dari RAM, banyak ruang untuk menjalankan juru bahasa untuk beberapa bahasa yang lebih kecil. Sepertinya Anda memberikan spesifikasi untuk perangkat Linux yang disematkan; Saya pikir OP meminta pelabuhan khusus.
— Kevin Vermeer
1
Jika Anda membayar $ 1,30 untuk MCU 8-bit, maka ada beberapa MCU 32-bit yang lebih murah. Juga, perhatikan bahwa sebagian besar MCU 8-bit di pasaran adalah arsitektur kode-tidak efektif, dengan desain yang diwarisi dari awal 80-an.
— Lundin
0

Buku ini menyediakan beberapa cara untuk melakukan pemrograman dengan nuansa FP yang ringan. http://www.state-machine.com/psicc2/

Tetapi FP nyata harus memiliki kemampuan untuk membangun fungsi dalam runtime dan meneruskannya di seluruh program Anda. Di sini kita memiliki masalah: bagaimana kita dapat mewakili fungsi yang dibangun ini? dan bagaimana kita dapat menjalankan fungsi ini secara efektif? Pada sistem yang besar, kita dapat menggunakan kompilasi dinamis yang menghasilkan kode mesin nyata pada aplikasi fungsi pertama. Pada MCU kami hanya memiliki RAM untuk mengimplementasikan kompiler yang sangat primitif seperti Forth language core.

Satu-satunya cara Anda dapat menggunakan FP atau OOP jika Anda menginginkannya adalah metaprogramming : tulis program fungsional / OOP kompleks yang menghasilkan program untuk MCU (misalnya kode sumber C, atau LLVM IL). Dalam varian ini, Anda tidak dibatasi oleh kompleksitas paradigma atau metode pemrograman.

— Dmitry Ponyatov
sumber
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.