Proyek
Embox telah berusia 9 tahun, tetapi banyak yang tidak mengerti apa itu dan
apa yang dimakannya dan mengapa itu diperlukan. Beberapa dari mereka yang telah mendengar tentang proyek dan tahu bahwa ini adalah sistem operasi, percaya bahwa Embox adalah "OS domestik". Memang, Embox dikandung sebagai upaya untuk membuat OS "mereka" dengan "blackjack dan kapal", tetapi yang utama adalah "blackjack dan kapal". Artinya, karakteristik tertentu atau kombinasinya, yang kurang dalam proyek lain, ditempatkan di garis depan.
Tentu saja, tidak ada yang akan menulis OS universal bahkan dengan beberapa chip. Tagline Embox - "Kotak alat penting untuk pengembangan tersemat" - menyiratkan bahwa proyek ini ditujukan untuk sistem tertanam. Namun, konsep ini sangat luas, termasuk: Internet of things (IoT) dan robot, berbagai raspberry (RaPi) dan sistem on-board, arduinki dan ASU-TP, ... Daftarnya, seperti yang Anda tahu, dapat berlangsung untuk waktu yang sangat lama, ada tempat-tempat di mana Linux hidup hebat, dan ada tempat-tempat di mana Linux berlebihan dan berbagai RTOS kecil digunakan. Dalam artikel ini, saya ingin berbicara tentang dunia yang tertanam dalam semua keanekaragamannya, dan juga tentang tempat Embox di dalamnya.
Komputer Papan Tunggal
Komputer industri
Mari kita mulai dengan komputer papan tunggal. Banyak dari mereka dibuat dalam desain industri. Sebagian besar dibangun di atas prosesor dengan arsitektur ARM dan x86. Banyak orang berpikir bahwa prosesor x86 tidak digunakan di segmen ini, dan semuanya terbatas pada
raspberry ,
beagleboards ,
pisang , dan sebagainya. Tetapi jauh sebelum RaPi, ada mesin papan tunggal lainnya yang ditujukan untuk segmen PC industri, yang disebut
PC / 104 form factor. Mereka lebih rendah kinerjanya dibandingkan dengan desktop konvensional, karena mereka ditujukan untuk tugas-tugas di mana keandalan berlaku atas fungsionalitas. Untuk alasan yang sama, Linux tidak sering digunakan sebagai OS untuk platform perangkat keras ini, ada berbagai OS berpemilik dengan properti real-time (
VxWorks ,
QNX ,
LynxOS, dan sebagainya ). Saya tidak menulis "RTOS" (yang saya sertakan ketiga OS ini) untuk alasan yang cukup sering
Windows CE dan pengembangan
Windows Embedded terletak pada platform perangkat keras ini. Dan saya tidak mengubah lidah saya untuk menghubungkan seluruh kebun binatang ini ke RTOS.
Pembayar Tunggal Konsumen
Malinki menetapkan tren yang sama sekali berbeda. Mereka, pada kenyataannya, ditujukan bukan pada sistem industri waktu nyata, tetapi pada segmen konsumen, di mana rasio harga / fungsi dinilai, dan raspberry (dan analog) secara signifikan di depan pesaing mereka dalam parameter ini. Lagi pula, ketika Anda membeli dengan syarat $ 30-50, Anda mendapatkan unit sistem lengkap, yang dengannya Anda dapat dengan mudah membuat perangkat dengan fungsionalitas yang agak rumit menggunakan alat Linux. Ini sangat berguna untuk membuat prototipe atau DIY. Plus, tentu saja, raspberry dapat digunakan sebagai PC atau server kecil. Oleh karena itu, distribusi Linux siap pakai sering digunakan sebagai OS, pertama-tama, tentu saja,
Raspbian - Debian untuk Raspberry Pi, atau distribusi dengan nama lucu untuk penutur bahasa Rusia
Pidora - Fedora untuk RaspberryPi. Untuk platform serupa lainnya, ada juga distribusi siap pakai yang disediakan oleh produsen peralatan dan komunitas OS (produsen). Setuju, ketika Anda perlu membuat prototipe, cara termudah adalah dengan mengambil paket yang sudah jadi, menginstruksikan, menulis fungsionalitas dengan python. Hasilnya, cepat dapatkan prototipe yang berfungsi.
Contohnya adalah robot yang mengenali garis menggunakan OpenCV .
Linux dalam perangkat yang disematkan
Tetapi dunia yang tertanam jauh lebih luas dari kartu ARM papan-tunggal standar. Selain itu, mereka merupakan bagian yang relatif kecil dari perangkat, dan kontribusi utama mereka adalah mempopulerkan dan menyederhanakan entri ke dalam pengembangan perangkat kelas ini. Perangkat serial dibuat berdasarkan prosesor yang sama (sistem pada chip) atau serupa, tetapi papan dirancang untuk tugas (proyek, perangkat). Akibatnya, distribusi standar setidaknya berlebihan, karena mereka sering menggunakan semacam manajer paket, dan Anda dapat dengan mudah memberikan banyak hal menarik (tetapi tidak perlu untuk menyelesaikan tugas tertentu). Perangkat yang disematkan biasanya datang dengan fungsionalitas lengkap, dan bahkan disebut firmware. Ada kelas distribusi Linux lain untuk membuat firmware. Distribusi semacam itu memungkinkan Anda untuk "menginstal" paket yang diperlukan secara statis - dengan merakitnya dalam sistem file root, dan tidak secara dinamis - menggunakan manajer paket dari repositori. Biasanya, distribusi ini dapat dibangun tidak hanya aplikasi aplikasi dan perpustakaan, tetapi juga kernel dalam konfigurasi yang diberikan. Dan seringkali juga merupakan cross-compiler, karena kompilasi pada perangkat itu sendiri setidaknya tidak efektif.
Proyek Yocto
Hingga saat ini,
proyek Yocto adalah distribusi yang paling terkenal (proyek untuk membuat distribusi). Pada gilirannya, ini didasarkan pada proyek
OpenEmbedded terkenal
lainnya , yang merupakan semacam sistem pembangunan untuk distribusi Linux. Jika Anda ingin menggunakan Raspberry Pi bukan sebagai sistem kecil yang sudah jadi, tetapi sebagai perangkat khusus dengan Linux, maka
Yocto atau analognya akan menjadi pilihan yang bagus. Secara pribadi, saya tidak melihat keuntungan kuat dalam menggunakan distribusi Linux non-standar dengan besi standar, tetapi jika Anda berencana untuk mengembangkan perangkat serupa atau memiliki keinginan untuk mempelajari teknologinya sendiri, maka pendekatan ini terlihat paling menjanjikan. Setelah semua, ketika perangkat keras khusus sedang dikembangkan, programmer dapat mengembangkan dan men-debug bagian-bagian mereka dari sistem (algoritma, driver, perpustakaan, ...). Yang sangat mengurangi waktu pengembangan, dan karena itu TTM terkenal (waktu ke pasar).
Openwrt
Proyek firmware berbasis Linux yang terkenal lainnya adalah
OpenWRT . Saya yakin bahwa mereka yang bersenang-senang dengan router kustom telah mendengar tentang dia. Berdasarkan proyek ini, firmware dibuat untuk berbagai router, yang merupakan satu biner, termasuk kernel dan sistem file root. Menggunakan firmware (daripada distribusi universal) dalam sistem tertanam dihubungkan dengan gagasan bahwa fungsionalitas sistem akhir diketahui pada saat pengembangannya, yaitu, bahkan jika versi router diperbarui, firmware berubah sepenuhnya dengan semua fungsionalitas (atau bagian dari firmware ini diganti dengan cara khusus ) Instal, misalnya, office suites, biasanya tidak perlu, dan sering secara umum dilarang, karena ini dapat menimbulkan ketidakpastiannya sendiri. Pendekatan ini memungkinkan, antara lain, secara signifikan menghemat perangkat keras. Router yang sama, misalnya, memiliki prosesor yang jauh lebih kuat dan lebih sedikit memori daripada kelenjar universal.
Sistem waktu nyata
Kembali ke topik kalkulator industri, perlu untuk membahas istilah "sistem waktu nyata". Banyak orang berpikir bahwa sistem waktu nyata lebih cepat. Ini adalah kekeliruan. Mungkin, itu terhubung dengan bangunan bersejarah. Bagaimanapun, istilah itu sendiri muncul ketika mobil melambat. Dan pengguna memperhatikan bahwa reaksi sistem mungkin tertinggal dari tindakannya. Istilah "waktu nyata" berarti bahwa sistem harus responsif terhadap pengaruh apa pun, termasuk tindakan operator. Tetapi pada komputer modern, pengguna (operator) tidak mungkin melihat adanya hambatan. Dalam sebagian besar kasus, ketika Anda mengklik menu, ikon, tombol, kami akan segera melihat redraw layar, kecuali tentu saja semuanya sudah beres (Internet ada di sana, prosesnya tidak hang, dll.). Tetapi jika sesuatu yang tidak terduga terjadi, misalnya, koneksi terputus, kita akan melihat bagaimana sistem waktu nyata berbeda (harus berbeda). Kami hanya akan restart smartphone biasa. Tetapi jika sistem ini mengontrol pembangkit listrik, maka Anda sendiri mengerti, ini tidak selalu mungkin. Dari sini kami menyimpulkan bahwa sistem waktu-nyata harus dapat diprediksi, dan tidak dengan cepat, merespons setiap peristiwa atau rangkaian peristiwa, terlepas dari keadaan dan lingkungannya.
Linux dalam sistem waktu nyata
Secara alami, telah ada (akan dan akan) upaya untuk membuat sistem real-time dari Linux. Yang paling terkenal adalah
RTLinux , yang awalnya merupakan tambalan untuk Linux, menggantikan "
scheduler sepenuhnya jujur " yang asli, lebih tepatnya, memasukkan sendiri, yang merupakan salah satu tugas yang diatur oleh penjadwal Linux. Penjadwal ini bekerja pada prioritas tugas statis, sehingga bekerja jauh lebih dapat diprediksi. Tapi itu bukan lagi Linux, atau lebih tepatnya, fungsi Linux tidak secara real time.
ARINC-653
Pendekatan lain untuk menyediakan waktu nyata, agak mirip dengan patch RT untuk Linux, adalah pendekatan yang diperlukan oleh standar
ARINC653 atau yang disebut pendekatan
MILS . Pendekatan ini menyiratkan bahwa sistem dirancang berlapis-lapis, lapisan bawah menyiratkan hypervisor yang sangat ringan, berdasarkan tugas-tugas dari berbagai tingkat kekritisan yang dilakukan dalam bagian yang ditentukan secara statis. Saya menyebut hypervisor sangat ringan karena menyiratkan bahwa ia memiliki kekritisan tertinggi dan oleh karena itu kodenya (algoritma) harus diperiksa selengkap mungkin (idealnya, tidak adanya situasi yang tidak diproses harus dibuktikan secara matematis). Karena itu, kode harus sekecil mungkin. Yah, dan Linux, seperti yang mungkin Anda pahami, terletak di bagiannya sendiri.
uCLinux
Upaya untuk menggunakan Linux dalam sistem embedded dimulai sejak lama. Salah satu yang pertama adalah upaya untuk menggunakan Linux dalam sistem di mana tidak ada dukungan perangkat keras untuk memori virtual (MMU). Proyek ini disebut
uCLinux dan kontribusinya terhadap kernel Linux adalah
mode NOMMU atau MMU-less.
Linux dalam sistem waktu nyata
Untuk meringkas upaya untuk menggunakan Linux dalam sistem waktu nyata, Anda perlu menjawab pertanyaan mengapa ini terjadi. Yaitu, di satu sisi, Linux tidak secara khusus (saat ini, dan dalam bentuk murni) diadaptasi untuk sistem waktu nyata, dan di sisi lain, upaya terus dilakukan untuk melakukan hal ini. Dan ini terjadi karena pengenalan pembatasan (mengganti penjadwal, memperkenalkan hypervisor, pembatasan penggunaan memori virtual, dan sebagainya). Jawabannya, menurut saya, terletak di hadapan Linux basis kode raksasa. Ini adalah driver, ini adalah aplikasi fungsional dan perpustakaan. Jelas, jika Anda ingin membuat sistem yang andal, Anda harus menggunakan bagian-bagian yang sudah jadi sebanyak mungkin, karena pengembangan yang baru, apakah itu logika fungsional atau driver, selalu mengandung kemungkinan memperkenalkan kesalahan. Dan karena sistem real-time modern memiliki persyaratan fungsional yang agak tinggi, menggunakan kembali fungsionalitas siap pakai dari Linux menjadi semakin menggoda. Dengan kata lain, memutakhirkan Linux ke sistem waktu-nyata tampaknya tidak begitu mahal dibandingkan dengan mengembangkan fungsionalitas, walaupun didasarkan pada sistem operasi waktu-nyata, karena keandalan seluruh sistem, dan bukan hanya bagiannya dalam bentuk kernel dari sistem operasi, harus dapat diandalkan.
Windows di perangkat yang disematkan
Saya ingin kembali ke Windows untuk sementara waktu. Di awal karir saya, saya berdiskusi dengan pengembang yang lebih berpengalaman bahwa Windows tidak dapat digunakan dalam sistem yang andal. Yang dia keberatan, jika Anda menguji sistem yang sudah selesai dengan perangkat lunak fungsional yang diperlukan dan melarang perubahan apa pun: pembaruan, instalasi perangkat lunak, dll., Sistem akan cukup andal untuk banyak tugas, termasuk yang kami diputuskan. Sekarang saya tidak ragu bahwa lawan saya benar, bukan saya. Selain itu, bahkan MS-DOS kuno telah digunakan dalam sistem industri untuk waktu yang sangat lama. Faktanya adalah multitasking, yang tampaknya sangat diperlukan, menimbulkan ketidakpastian. Dan jika Anda menjalankan perangkat lunak yang sepenuhnya mengendalikan seluruh sistem, Anda dapat mencapai perilaku yang jauh lebih deterministik. Dengan kata lain, jika jumlah tugas yang tidak terbatas berputar dalam sistem, maka tidak mungkin bahwa akan mungkin untuk mencapai kepastian dalam pekerjaan semua fungsi sistem. Oleh karena itu, cara termudah untuk meningkatkan prediktabilitas sistem adalah dengan membatasi fungsinya, dan karena itu penolakan universalitas saat runtime. Kenyataannya, yang kami amati dalam contoh penggunaan Linux dalam sistem waktu nyata yang disebutkan di atas.
Mikrokontroler
Contoh MS-DOS sebagai OS dasar untuk sistem waktu-nyata industri membawa kita pada gagasan bahwa jika Anda hanya menggunakan perangkat lunak Anda sendiri, Anda dapat mencapai perilaku yang dapat diprediksi dari seluruh sistem. Dan memang benar! Benar, Anda perlu membuat reservasi bahwa ini hanya mungkin jika fungsi sistem kecil dan jelas diperbaiki. Jika semua fungsi sistem terdiri dalam mengendalikan motor menggunakan GPIO dan menerima (mentransmisikan) serangkaian perintah terbatas melalui antarmuka UART, maka tidak perlu menggunakan OS, Anda dapat membuat firmware (apa yang disebut bare-metal). Pendekatan ini sering digunakan dalam mikrokontroler. Tetapi karena mikrokontroler menjadi besar (ARM 32-bit dengan beberapa KB RAM versus 8-bit AVR-ok dengan seratus byte RAM), permintaan fungsionalitas meningkat. Sekarang, ketika mengembangkan firmware, mereka menggunakan setidaknya perangkat lunak dari produsen, yang memungkinkan Anda untuk menggunakan beberapa contoh siap pakai untuk bekerja dengan mikrokontroler, misalnya,
STM32Cube .
RTOS
Tetapi karena persyaratan untuk fungsionalitas terus berkembang, firmware untuk mikrokontroler semakin banyak dibuat berdasarkan apa yang disebut RTOS. Tidak seperti sistem operasi real-time yang besar, ini adalah proyek open source yang relatif kecil yang menyediakan akses penuh ke semua kode dalam sistem. Artinya, ada kombinasi konsep: di satu sisi, kode siap pakai digunakan, dan di sisi lain, pengembang memiliki akses penuh ke semua yang ada di sistem, Anda dapat mengatakan firmware bare-metal.
Ada cukup banyak RTOS untuk mikrokontroler. Karena itu, mustahil untuk membicarakan semuanya. Saya akan memilih hanya sedikit, menurut pendapat saya, proyek yang menarik dan secara singkat berbicara tentang fitur mereka.
FreeRTOS
Mungkin salah satu proyek RTOS paling populer sekarang adalah
FreeRTOS . Ada yang mengatakan bahwa ini bukan OS penuh, tetapi hanya penjadwal. Tetapi dengan mempertimbangkan diskusi di atas tentang bare-metal, sejumlah besar mikrokontroler yang didukung, dan fakta bahwa banyak perangkat lunak aplikasi ditulis dan diintegrasikan, fungsionalitas yang kecil lebih terlihat seperti nilai daripada kerugian. Ini memungkinkan kami untuk menjadi standar de facto untuk mikrokontroler, seperti yang tertulis di situs web proyek.
Contiki
Contiki - RTOS dikembangkan oleh
Adam Dunkels , pencipta tumpukan TCP / IP yang terkenal seperti lwIP dan uIP. Saya akan mengatakan bahwa seluruh OS dibangun di sekitar tumpukan jaringan. Kehadiran dukungan IPv6 dan persyaratan sumber daya yang kecil membuat proyek ini menarik untuk membuat berbagai jenis perangkat nirkabel.
RTEMS
RTEMS Eksekutif Real-Time untuk Sistem Multiprosesor. Awalnya dikembangkan untuk militer, singkatan singkatan dari Real-Time Executive untuk Sistem Rudal, dan kemudian Eksekutif Real-Time untuk Sistem Militer. Proyek open source yang cukup tua tetapi masih hidup. Perwakilan cerah dari pendekatan libOS. Ketika perangkat lunak yang dikembangkan dihubungkan dengan OS yang sudah dirakit, yang tidak hanya kernel, tetapi juga semua layanan yang tersedia. Ini dikompilasi dan dikirim sebagai perpustakaan ke kompiler, yang cukup nyaman pada tahap awal pengembangan.
eCos
eCos Sistem Operasi Tertanam yang Dapat Dikonfigurasi. Juga proyek yang cukup lama, sebelumnya sangat populer. Gagasan utamanya adalah membuat OS yang sangat dapat dikonfigurasi, yaitu, hanya untuk memasukkan dalam kernel apa yang Anda butuhkan.
RTOS lainnya
Daftar ini berlangsung cukup lama.
Saya akan menyebutkan proyek
NuttX lain di bawah ini. Dan bagi mereka yang tertarik pada daftar yang lebih rinci, saya sarankan Anda untuk menonton
Wikipedia . Untuk mikrokontroler, saya juga akan
menyebutkan ChibiOS / RT ,
MicroC / OS (μC / OS) ,
Nut / OS ,
RIOT . Tapi tentu saja, itu semua tergantung tugas.
Arduino
Saya pikir berbicara tentang tertanam tidak akan lengkap tanpa menyebutkan Arduino. Lagi pula, seperti RaPi, mereka sangat umum dan memberikan kontribusi besar untuk mempopulerkan mikrokontroler. Saya sendiri agak skeptis tentang tema Arduino, jadi saya akan melewatkan kritik dari penggemar teknologi ini. Tetapi tentang fakta bahwa ini adalah teknologi yang sangat menarik, saya dapat memberikan
contoh mesin roti, yang dijelaskan pada hub Solusi yang sangat bagus Nah, atau contoh yang sudah dikutip
dengan robot yang mengenali garis dengan openCV , tetapi
Arduino juga digunakan di sana.
Mikrokernel
Saya tidak pernah menyebutkan konsep microkernel, yang, seperti yang diketahui banyak orang, menjadikan sistem ini andal dan dapat diprediksi. Di satu sisi, ini benar, tetapi di sisi lain, seperti biasa, tidak cukup. Lebih tepatnya, tentu saja itu benar, tetapi keyakinan bahwa konsep (arsitektur) ini akan segera mengubah sistem Anda menjadi sistem waktu-nyata yang sulit adalah khayalan. Ini lebih merupakan slogan pemasaran: "kami adalah sistem waktu nyata karena kami dibangun berdasarkan prinsip mikronukleus". Tetapi prinsip microkernel hanya memungkinkan untuk menyederhanakan pengembangan perangkat lunak, karena sebagian besar bagian dilakukan ke dalam ruang pengguna. Tetapi bagaimana jika Anda memiliki server yang rusak, yang diperlukan untuk bekerja? Anda me-reboot-nya, tetapi butuh waktu, dan jika Anda tidak memilikinya? Selain itu, arsitektur microkernel klasik memiliki kekurangannya! Misalnya, lambat, karena ada banyak panggilan sistem (transfer pesan antara server dan perangkat lunak aplikasi). Kalau tidak, semua orang akan beralih ke arsitektur microkernel murni sejak lama, dan yang, misalnya, melihat
proyek -
proyek pada L4 , tetapi ternyata begitu. Yah, dan tentu saja, banyak yang ingat
argumen Linus Torvalds dengan Andrew Tanenbaum .
Artinya, konsep mikronukleus bukan peluru perak. Tetapi sebagai ide yang sangat bagus diterapkan pada satu derajat atau yang lain di sebagian besar sistem operasi modern. Dan penciptaan sistem yang dapat diandalkan pada akhirnya masih tergantung pada pengembang akhir dan kemampuan yang disediakan sistem operasi untuk pembangunannya.
Tempat Embox di dunia sistem embedded
Saya sudah berbicara cukup banyak tentang berbagai aspek dari dunia yang tertanam, tetapi saya tidak pernah sampai ke tempat Embox di dalamnya. Saya dapat mengatakan bahwa dalam contoh yang dijelaskan di atas, mungkin tidak perlu menggunakan Embox. Selain itu, kami biasanya bertanya kepada pengguna mengapa mereka membutuhkan Embox? Jika penggunaan Embox tidak memberikan keuntungan apa pun, kami sarankan Anda mencoba sesuatu dari daftar di atas atau yang lainnya (misalnya, Android). Tetapi ada sejumlah kasus di mana penggunaan Embox memberikan keuntungan nyata.
Sistem Pengembangan Peralatan
Saya akan mulai dengan penggunaan pertama dari Embox. Dia bahkan bukan seorang Embox waktu itu, tetapi sejenis kode C dan assembler, yang memungkinkan Anda memulai dengan sangat cepat dan menjalankan kode utilitarian. Pada saat itu, itu adalah proyek untuk membantu insinyur men-debug peralatan yang dikembangkan di FPGA.
Dia tahu cara menjalankan sangat cepat, jauh lebih cepat daripada kode serupa yang ditulis menggunakan RTEMS yang telah disebutkan. Ini penting karena juga digunakan pada tahap simulasi time-lapse. Plus, mereka mulai menggunakannya pada perangkat keras nyata, untuk ini penerjemah kecil ditulis yang dapat memanggil perintah pengguna. Belakangan, arahan ini dikembangkan, dan penerjemah bahasa TCL diangkut, karena sudah tidak asing lagi bagi pengembang FPGA. Dan karena dalam konfigurasi tertentu tim memiliki akses langsung ke peralatan (ke seluruh ruang alamat), pengembang dapat melakukan tes yang cukup kompleks.Bersertifikat Linux
Salah satu aplikasi pihak ketiga pertama adalah persyaratan yang agak spesifik untuk sertifikasi kode. Ada perangkat tertentu dengan fungsi terbatas, termasuk: bekerja dengan soket (UDP), sistem file, dan beberapa fungsi lainnya. Semua fungsionalitas diimplementasikan oleh pelanggan sebagai perangkat lunak berbasis Linux. Perangkat ini bukan x86 dan bukan ARM. Itu pinggirannya. Itu perlu untuk mengesahkan kode yang digunakan dalam perangkat, karena distribusi bersertifikat tidak dapat digunakan di sana. Upaya untuk memotong kernel Linux menghasilkan sekitar 500 ribu baris kode, ditambah ada juga masalah dengan #ifdef dan makro lainnya. Dan pelanggan, mengevaluasi biaya sertifikasi produk ini, diminta untuk mempertimbangkan opsi lain. Embox pada waktu itu sudah memiliki tumpukan jaringan,sistem file dan diputuskan untuk memodifikasinya dengan mempertimbangkan persyaratan sertifikasi akun. Jadi kami mendapat bahasa deskripsi modul Mybuild, sampai batas tertentu kami memecahkan masalah dengan makro, beberapa masalah lainnya. Sebagai hasilnya, kami telah mencapai bahwa pada gambar akhir kami hanya menggunakan kode (dideklarasikan dalam konfigurasi), dan biasanya tidak memerlukan banyak untuk tugas tertentu.Linux tanpa Linux
Arah dengan sertifikasi umumnya cukup populer. Seringkali, pelanggan memiliki kode untuk Linux, tetapi untuk beberapa alasan mereka tidak dapat menggunakan OS ini di perangkat mereka. Embox memiliki kemampuan untuk dengan mudah mentransfer perangkat lunak aplikasi dari proyek open source di Linux. Dengan demikian telah porting sejumlah proyek populer, bahkan Qt (embedded-versi) atau telah dijelaskan Habré SIP-telepon . Pada saat yang sama, karena ketika menggunakan Embox hanya modul yang diperlukan yang disertakan, sumber daya untuk peluncuran jauh lebih sedikit.Gagasan untuk menjalankan aplikasi POSIX pada sistem dengan sedikit sumber daya adalah ide utama untuk proyek sumber terbuka lainnya - NuttX. Di beberapa titik, proyek ini lebih unggul dari Embox, di beberapa titik - sebaliknya. Contoh telepon Qt dan SIP, sejauh yang saya tahu, NuttX terlalu tangguh. Tetapi proyek ini benar-benar sangat menarik.Perlu dicatat juga bahwa bagian dari RTOS juga menambahkan lapisan POSIX. Misalnya, FreeRTOS atau RTEMS, yang hari ini sepenuhnya sesuai dengan POSIX Profile 52, yang berarti "satu proses, banyak utas, sistem file . " RTEMS bahkan membuat percobaan yang sukses untuk meluncurkan Qt pada mikrokontrolerLinux yang aman
Jika, di sisi lain, kita melihat rakitan statis gambar RTOS kecil, yaitu, menentukan semua fungsi pada saat pembuatan, kita dapat melihat bahwa ini memberikan perlindungan alami terhadap kode berbahaya, yaitu, virus. Tentu saja, di Linux Anda dapat membuat sistem keamanan yang sangat baik, tetapi tetap saja masalah keamanan utama terkait dengan faktor manusia (kata sandi lemah, kehilangan kata sandi, peningkatan hak pengguna, dll.). Artinya, ketika menerima hak root, semua perlindungan, pada kenyataannya, menjadi tidak relevan dan Anda dapat menginstal apa pun di mana saja. Dalam kasus perakitan statis, penyerang hanya dapat menggunakan fungsi yang ada. Ya, dia mungkin bisa mendapatkan statistik atau membuat semacam penyetelan, tetapi, Anda harus mengakui, ini jauh lebih jahat daripada dalam hal menginstal malware. Pluspada sistem universal, biaya sistem perlindungan, katakanlah, bukan nol. Dalam kasus kami, ini jauh lebih murah, karena sudah diterapkan pada tahap desain.Linux waktu nyata
Saya telah mencurahkan cukup banyak untuk menggunakan Linux sebagai sistem real-time. Dijelaskan mengapa ini sulit dicapai, serta mengapa upaya dilakukan. Jadi, kembali ke artikel yang sudah dikutip pada robot pengenalan garis OpenCV . Jika Anda melihat tautannya, Anda mungkin memperhatikan bahwa OpenCV berputar pada RaPi, dan motornya dikendalikan pada papan Arduino yang terpisah. Ada beberapa alasan untuk ini: yang pertama adalah penjadwal, yang kedua adalah manajemen berasal dari mode pengguna, dan Linux tidak memiliki akses ke perangkat keras di dalamnya. Seperti yang mungkin Anda duga, di Embox kedua masalah dapat diselesaikan lebih mudah daripada di Linux. Dan di papan yang sama dengan sumber daya yang cukup, Anda dapat menjalankan OpenCV dan mengendalikan motor.Ada beberapa perangkat yang menggabungkan fungsi Linux dan pekerjaan real-time. Contohnya adalah mesin CNC yang dikendalikan oleh antarmuka web, yang dijelaskan secara singkat oleh saya dalam sebuah artikel . Nah, jika kita membuat robot di beberapa papan, maka ini adalah sistem multi-agen .Internet hal
Embox, seperti hampir semua mikrokontroler RTOS, memiliki persyaratan sumber daya yang rendah. Di sinicontoh mainan pada stm32vl-discovery sudah dijelaskan di habr Embox diluncurkan bahkan pada MSP-430 16-bit dengan RAM 512 byte. Tetapi jika Anda melihat, misalnya, pada kode dari artikel dengan mainan, Anda akan melihat bahwa ia tidak menggunakan stream POSIX standar, tetapi penerapan stream stackless stream sendiri (benang ringan). Secara alami, jika Anda melangkah lebih jauh dan mengimplementasikan semua kode sendiri, saya yakin Anda dapat mencapai hasil yang lebih baik dalam hal biaya memori. Tetapi sensor pintar hanyalah satu bagian dari IoT. Mereka mengirimkan data ke beberapa node yang lebih kuat. Dan mereka melakukannya sesuai dengan beberapa protokol. Tetapi jika Embox juga akan diluncurkan pada node ini, dan kode perpustakaan yang mengimplementasikan protokol komunikasi akan umum, maka ini akan menyederhanakan pengembangan. Bagaimanapun, pertama-tama, kode tersebut adalah umum, dan bahkan jika ada kesalahan dalam implementasi protokol, maka itu akan diratakan olehbahwa kode yang sama akan berfungsi di kedua sisi percakapan. Dan kedua, kode dapat di-debug pada platform dengan sumber daya besar, yang jauh lebih akrab dan sederhana.Anda dapat belajar lebih banyak tentang nasib sulit proyek dengan menonton video dari salah satu pertunjukan pertama kami di CodeFreeze .Kesimpulan
Artikel ini hanya mengungkapkan segmen kecil di dunia tertanam yang beragam. Tidak disebutkan topik penting seperti peralatan rumah tangga, mobil, instrumentasi, ASU-TP. Namun seperti yang saya katakan di awal, di artikel saya hanya ingin "berbicara" tentang fitur yang dibenamkan. Saya harap artikel itu cukup menarik, dan setelah membacanya, Anda mempelajari sesuatu yang baru! Dan mari kita bahas fitur-fitur area ini di komentar.PS Yah, ya, Embox tidak hanya "tertanam", tetapi juga " opensource ". Jadi, kami mengundang Anda untuk menggunakan proyek dan tentu saja untuk berpartisipasi di dalamnya!