Beralih ke RTOS di RP2040

 (blog.brixit.nl)
1 poin oleh GN⁺ 2024-07-07 | 1 komentar | Bagikan ke WhatsApp
  • Karena pengontrol peralatan video berbasis Raspberry Pi Pico membutuhkan banyak pekerjaan bersamaan, struktur perangkat lunaknya menjadi sulit ditangani hanya dengan pico-sdk dan pemisahan dual-core
  • Pengontrol ini menangani RS-485 VISCA, Ethernet, 9 tombol RGB, joystick, dan layar sekaligus, serta perlu memproses DHCP, mDNS, dan protokol ATEM berbasis UDP
  • FreeRTOS memungkinkan sebagian implementasi melalui scheduler dan komunikasi antartask, tetapi debugging dan penggunaan ulang kode sulit karena masalah printf yang berhenti dan kurangnya abstraksi perangkat keras
  • Apache NuttX menyediakan shell, filesystem, abstraksi perangkat seperti /dev/i2c0, dan konfigurasi Kconfig, tetapi masalah I2C belakangan dikoreksi sebagai kesalahan konfigurasi sehingga sebagian besar evaluasi saat itu mungkin tidak valid
  • Zephyr terhambat oleh repositori dan SDK berukuran 5GB, definisi board, serta kompleksitas build; akhirnya pilihan condong untuk terus mencoba FreeRTOS karena paling sederhana ditempelkan ke lingkungan yang sudah ada

Mengapa RTOS menjadi diperlukan

  • Beberapa proyek mikrokontroler kecil sedang dibuat dengan berpusat pada board Raspberry Pi Pico
    • Pico mudah diintegrasikan dengan IDE berkat SDK yang memadai, perangkat keras murah, serta dukungan debugging gdb/openocd
  • Proyek saat ini adalah pengontrol perangkat keras untuk mengendalikan beberapa peralatan video
    • Perangkat yang dikendalikan adalah 2 kamera PTZ bermotor, 1 kamera tetap, dan peralatan video switching yang terhubung
  • Pengontrol kamera PTZ yang ada adalah panel tanpa merek yang mirip Marshall VS-PTC-200
    • Beberapa tahun lalu harganya €650, tetapi rasa tombol dan kualitas joystick analognya kurang baik
    • Banyak tombol tidak berfungsi pada kamera yang sedang digunakan, dan tampaknya dioptimalkan untuk kamera keamanan
    • Terhubung ke kamera melalui bus RS-485
  • Kontrol video switcher ATEM saat ini hanya dilakukan lewat panel perangkat lunak di komputer
    • Panel perangkat keras dari Blackmagic Design sangat mahal

Konfigurasi perangkat keras pengontrol

  • Desain minimum ditetapkan berupa 9 tombol, joystick, dan layar untuk antarmuka pengguna
  • Setelah mengulang desain perangkat keras beberapa kali selama 1 tahun, PCB akhirnya tersedia
    • 9 tombol RGB
    • Joystick seharga $10 yang juga ada di panel tiruan Marshall
    • TP8485E untuk berkomunikasi dengan kamera PTZ melalui RS-485
    • Modul Wiznet W5500 untuk berkomunikasi dengan video switcher melalui Ethernet
  • Setelah berbagai revisi board, semua komponen perangkat keras akhirnya berfungsi, tetapi bagian yang lebih sulit adalah perangkat lunaknya

Perangkat lunak mulai kewalahan hanya dengan pico-sdk

  • Seperti proyek RP2040 sebelumnya, proyek dimulai dengan cara mengambil pico-sdk dari proyek cmake
  • Untuk membuatnya berjalan pada tingkat yang bisa digunakan, core kedua Pico dialokasikan untuk menangani modul Wiznet, sementara core pertama menangani I/O antarmuka pengguna
    • Kedipan LED dan implementasi klien DHCP yang berjalan di core kedua masih bisa dilakukan
    • Implementasi sisa sistem menjadi jauh lebih rumit
  • Pekerjaan yang harus diproses secara bersamaan meningkat cepat
    • Menggambar antarmuka pengguna yang cukup mulus di layar
    • Mengirim perintah VISCA melalui antarmuka RS-485
    • Merespons input tombol
    • Menjaga network stack yang mencakup beberapa koneksi
  • Sisi jaringan membutuhkan pekerjaan background tersendiri
    • Dukungan DHCP yang sesuai standar harus melacak waktu kedaluwarsa dan sesekali berkomunikasi dengan server DHCP untuk mempertahankan status lease
    • mDNS diperlukan untuk menemukan otomatis IP video switcher ATEM, dan akan bagus jika keberadaan panel kontrol juga bisa diumumkan
    • Protokol ATEM sederhana, tetapi terkadang menerima data yang melebihi ukuran buffer modul Wiznet, dan jika pengiriman datagram UDP berhenti, timeout pemutusan koneksinya sangat singkat
  • Dalam kondisi seperti ini, membagi pekerjaan dengan RTOS tampak lebih tepat daripada terus menumpuk loop sendiri

FreeRTOS: sederhana tetapi kurang abstraksi

  • FreeRTOS secara teknis disertakan di dalam pico-sdk, tetapi tutorial memakai cara mengunduh salinan baru, jadi cara itu diikuti apa adanya
  • Di antara RTOS yang ditinjau, FreeRTOS tampak paling sederhana, dan terutama menyediakan scheduler serta komunikasi antartask
    • Strukturnya membuat task dengan xTaskCreate lalu memulai scheduler dengan vTaskStartScheduler
    • IPC dapat digunakan dalam bentuk mengirim status tombol ke task LED menggunakan queue
  • Setelah digunakan beberapa hari, codebase terbagi ke banyak task meskipun fitur nyata masih sedikit
    • buttonsTask: melakukan polling GPIO expander I2C untuk memeriksa input tombol dan memasukkan pesan ke queue tombol
    • ledTask: mengatur warna RGB tombol tertentu berdasarkan pesan ledQueue
    • mainTask: menjalankan loop utama yang memperbarui status proyek sesuai input tombol
    • networkTask: berkomunikasi dengan modul Wiznet
    • dhcpTask: dibuat oleh networkTask saat kabel jaringan terhubung
    • mdnsTask: dibuat oleh dhcpTask setelah mendapatkan alamat IP
    • atemTask: dibuat saat mDNS menerima respons perangkat ATEM
    • viscaTask: belum melakukan apa pun, tetapi harus mengirim data melalui port RS-485
  • Jumlah task menjadi banyak meskipun perangkat keras belum melakukan apa pun selain muncul di jaringan
  • Masalah paling merepotkan adalah printf selalu menyebabkan berhenti
    • Debugger gdb berfungsi, tetapi tidak cocok untuk cara memeriksa dengan mencetak lalu lintas DHCP
  • FreeRTOS tidak menyediakan abstraksi perangkat keras, sehingga kode yang ditulis untuk berkomunikasi dengan beberapa chip sulit digunakan ulang dengan mudah
  • Setelah itu dicoba membuat proyek FreeRTOS bersih dan memindahkan fitur, tetapi karena tidak nyamannya debugging buta tanpa output serial, opsi lain pun dilihat

Apache NuttX: struktur ala Unix dan kesalahan konfigurasi

  • Apache NuttX terlihat lebih dekat ke sistem operasi umum, dan memperlakukan mikrokontroler seperti sistem Unix
  • Tutorial mengarahkan untuk mengambil pico-sdk dan mengatur environment variable
    • SDK sudah ada di /usr/share dan environment variable juga sudah tersedia, tetapi build gagal karena masalah izin ketika NuttX mencoba menimpa file version.h milik pico-sdk
  • Setelah membuild firmware NuttX minimal dan menghubungkan ke port serial, shell sungguhan muncul
    • Perintah seperti uptime, uname, dan uname -a berfungsi
    • Versi yang ditampilkan adalah NuttX 12.5.1 dan targetnya arm raspberrypi-pico
  • Karena mengikuti cara Unix, tampaknya aplikasi bisa ditulis dan dijalankan otomatis saat boot
    • Ada filesystem, dan perangkat keras diekspos sebagai abstraksi seperti /dev/i2c0 dan /dev/adc0
  • Bagian yang disukai adalah konfigurasi berbasis menuconfig/Kconfig
    • Ini cara yang familier dari pengembangan Linux
    • Ada sistem driver perangkat keras sungguhan, dan driver chip GPIO expander yang digunakan untuk tombol juga sudah tersedia
    • Pengaturan mux pin RP2040 juga bisa ditentukan di menuconfig, sehingga tidak perlu memelihara konstanta nomor pin terpisah atau banyak menulis kode inisialisasi bus I2C
    • Utilitas pengujian I2C juga bisa disertakan ke firmware
  • Awalnya operasi dasar I2C tampak tidak berfungsi
    • Dalam pembaruan berikutnya, hal ini dikoreksi bahwa sebenarnya I2C berfungsi baik, dan bus I2C rusak karena kesalahan konfigurasi
    • Disebutkan bahwa sebagian besar evaluasi lain di bagian NuttX tersebut kemungkinan tidak valid
  • Saat itu belum jelas bagaimana memberi tahu NuttX bahwa tombol GPIO berada di balik GPIO expander, maupun bagaimana menghubungkan GPIO expander ke bus I2C
  • Setelah configure.sh gagal, repositori berada dalam keadaan tidak konsisten sehingga repositori NuttX harus dikloning ulang beberapa kali
    • Ada situasi ketika distclean juga tidak bekerja dengan benar karena alasan yang sama
  • Pendekatan Unix-like awalnya terlihat bagus, tetapi tidak ingin menangani path filesystem palsu di mikrokontroler
    • Sistem produksi juga tidak membutuhkan shell; cukup kode yang berjalan

Zephyr: SDK besar dan hambatan definisi board

  • Pilihan berikutnya adalah Zephyr, yang menyediakan utilitas Python untuk pengaturan proyek
  • Pada langkah pertama, repositori Git sekitar 5GB diambil
    • Di dalamnya termasuk library HAL untuk banyak chip
    • Ini juga memengaruhi konfigurasi cmake global pengguna
  • Tutorial mengharuskan instalasi Zephyr SDK
    • Zephyr SDK mencakup toolchain, compiler, assembler, linker, dan alat build untuk tiap arsitektur yang didukung
    • Tool host seperti QEMU dan OpenOCD juga disertakan
  • Karena sudah ada beberapa toolchain ARM, tidak ingin membuild compiler untuk semua arsitektur atau mengambil yang sudah dibuild
  • Untuk build tanpa Zephyr SDK, opsi cross compile disetel
    • ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
    • CROSS_COMPILE=/usr/bin/arm-none-eabi-
    • west build -p always -b sparkfun_pro_micro_rp2040 samples/basic/blinky
  • Raspberry Pi Pico sebenarnya tidak didukung, hanya board lain yang memakai SoC yang sama yang didukung
    • Karena SoC-nya sama, proses dilanjutkan dengan menganggapnya sebagai board yang secara praktis mirip
  • Segera muncul masalah bahwa demo blinky tidak bisa dibuild
    • Demo tersebut membutuhkan definisi led0 sebagai target yang akan berkedip
    • Sparkfun Pro Micro RP2040 tidak memiliki LED GPIO sederhana, melainkan LED addressable WS2812B
  • Mengikuti manual board kustom, proses dilanjutkan dengan menyalin definisi board lain, tetapi bahkan setelah memperbaiki error dan warning build, build untuk board target tetap tidak berhasil

Akhirnya kembali ke FreeRTOS

  • Dari tiga RTOS tersebut, hanya FreeRTOS yang berhasil membuild sebagian aplikasi nyata
  • Masalah printf kemungkinan harus diselesaikan seperti panduan online, yaitu menggantinya dengan implementasi printf lain dan memanggil fungsi lain di tempat yang diperlukan
  • Ke depannya, rencananya adalah terus mencoba FreeRTOS
    • Karena dibandingkan RTOS lain, ini satu-satunya pilihan yang bisa diintegrasikan relatif sederhana ke lingkungan yang sudah ada

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-07
Komentar Hacker News

  • Penulis ini tampaknya memandang RTOS seperti lingkungan Arduino, atau sesuatu yang boleh diharapkan akan berjalan setelah sekadar dicoba-coba. Kebanyakan tidak begitu.
    Saat ini cukup banyak Arduino yang di dalamnya sudah memakai mbed atau FreeRTOS, dan ada juga cara untuk mengeksposnya, jadi untuk gaya penulis mungkin pilihan itu lebih cocok.
    Zephyr mudah digunakan dan dukungan CLion-nya juga bagus, tetapi kita tidak bisa berharap semuanya bekerja tanpa memasang toolchain. Pi Pico juga jelas didukung, dan saat saya mencobanya sendiri tidak ada masalah.
    Ringkasnya, FreeRTOS didukung hampir di mana-mana, tetapi drivernya umumnya spesifik SoC/perangkat sehingga merepotkan, dan API-nya juga tidak ramah, meski bisa dibiasakan. Jika ingin memakai Bluetooth, harus mencari stack-nya sendiri.
    Zephyr mendukung abstraksi perangkat keras sungguhan dan mendukung sebagian besar SoC, tetapi mungkin perlu sedikit pekerjaan untuk board. Stack Bluetooth disediakan, dan mungkin perlu sedikit menambahkan dukungan HCI.
    NuttX dukungannya tidak luar biasa, tetapi kalau bisa membuatnya berjalan, itu pilihan yang cukup keren. Dukungan industri masih belum kuat. Ada juga mbed, tetapi saya lewatkan di sini.
    Di dunia RTOS sebenarnya, biasanya orang memilih yang didukung oleh vendor SoC. Kalau Nordic berarti Zephyr, kalau NXP berarti FreeRTOS, dan seterusnya, supaya bisa mendapat dukungan yang baik.

    • Kalau boleh bertanya singkat, ini pengembangan untuk board prototyping atau sedang membuat firmware perangkat OEM?
      Saya belum pernah melihat proyek firmware perangkat OEM yang para developernya tidak kesulitan dengan Zephyr. Saya juga belum pernah bertemu developer yang membuat firmware nyata untuk produk rilis dan merasa abstraksi perangkat keras Zephyr membantu.
      Bukan berarti orang seperti itu tidak ada, tetapi selama kira-kira 5 tahun terakhir saya belum menjumpainya.
    • “Zephyr mudah digunakan” tidak sesuai dengan pengalaman saya.
      Menurut saya, materi pemasaran Zephyr sangat cantik. Namun di balik kemewahan itu ada kegemukan berlebihan, kompilasi yang sangat lambat, dan lingkungan yang sulit untuk mulai digunakan.
    • Kenapa mbed dilewatkan? Justru di situlah bagian yang “terbaik”.

  • Memasang toolchain secara sistem-wide seperti cara UNIX tradisional itu menyakitkan, dan jujur saja bukan pendekatan yang terlalu cerdas.
    Kalau bekerja sendiri mungkin baik-baik saja, tetapi ketika banyak developer menangani banyak proyek dengan target berbeda, banyak waktu habis untuk mencari tahu masalah build dan konfigurasi.
    Terus memakai Python untuk tooling juga tidak membantu. Saya tidak mengerti kenapa harus memakai bahasa yang membawa masalah versinya sendiri dan berperilaku berbeda di tiap komputer developer.
    Saya sudah sekitar 10 tahun melakukan embedded development sebagai hobi dan pekerjaan, dan saya tidak paham sikap yang menganggap bukan masalah ketika satu minggu habis hanya untuk menyamakan environment semua orang dalam sebuah proyek.
    Ini masalah nyata, menyebalkan, membuang waktu, dan tidak perlu.
    Tool seharusnya berupa binary yang ditautkan statis. Mau ditulis dengan Rust, Go, C, atau C++ tidak masalah, tetapi saya berharap prioritasnya adalah tool yang kokoh dan bisa dipercaya akan berjalan dengan cara yang sama terlepas dari apa yang terpasang di komputer, bukan pengembangan tambal sulam.
    Python tidak memberikan itu, dan marah serta bersikap defensif alih-alih menanggapi masalah ini lebih serius juga tidak membantu.
    Meski begitu, hal seperti PlatformIO berada di arah yang benar. Saya tahu itu proyek Python dan kadang menjadi masalah, tetapi lebih jarang dibanding tool lain, dan gagasannya benar.
    Toolchain, SDK, dan library harus dikelola, konfigurasi proyek harus sederhana, dan build harus dapat direproduksi di mana pun dan kapan pun.
    Saya berharap industri embedded lebih menyadari nilai upaya terstruktur bersama. Saya mengenal banyak orang yang bekerja di produsen MCU besar, dan saya selalu kecewa karena mereka umumnya sibuk menyelesaikan masalah langsung mereka sendiri sehingga tampak berpandangan sempit terhadap kebutuhan developer.

    • Sekarang saya tidak memakai apa pun yang mengandung tool Python. Terlalu jarang bekerja dengan baik pada percobaan pertama.
      Saya punya proyek keyboard yang berjalan di RP2040 dan firmwarenya ditulis dengan Rust. Dengan hanya repositori dan tanpa toolchain Rust, prosedur untuk melakukan flash adalah sebagai berikut.
      (instal rustup)
      $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
      $ rustup target add thumbv6m-none-eabi
      $ cargo install elf2uf2-rs
      * alihkan keyboard ke mode bootloader *
      $ cargo run --release
      Di sini rustup dan Cargo menangani sebagian besar manajemen toolchain dan build, dan keduanya benar-benar luar biasa. Proyek Python bahkan tidak mendekati.
    • Bukankah Docker atau tool container lain bisa menjadi kandidat yang bagus? Alih-alih memasang toolchain secara lokal, build saja di container berbasis image yang berisi toolchain persis yang dibutuhkan.
    • Setelah mengembangkan aplikasi Android, standar saya untuk bagian ini jadi tinggi.
      Cukup jalankan satu perintah, maka baik di lokal maupun CI semuanya tersetel dan berjalan dengan cara yang sepenuhnya sama, memakai versi build tool dan library yang sama.
      Karena itu, setiap kali harus kembali berurusan dengan CMake dan Make sambil bergulat memasang library, rasanya menyiksa. Sangat berbeda dari pendekatan seperti compile 'library-name-here'.
    • Saya rasa orang tidak memilih Python karena keunggulannya sebagai bahasa tooling. Dari sudut pandang itu, Python tidak hebat, dan binary yang ditautkan statis lebih baik.
      Sebaliknya, mereka memilihnya karena ekosistem library. Untuk analisis data, visualisasi, dan komputasi ilmiah, tidak ada opsi yang sebanding dalam bahasa lain.
      Ini adalah area yang tidak ingin kita implementasikan ulang dari awal. Bug mudah masuk di bagian seperti stabilitas numerik, sehingga 99% hasilnya benar, tetapi 1% bisa tampak masuk akal namun sepenuhnya salah.
    • Saya punya tool command-line yang ditulis dengan C# pada 2011 dan sampai sekarang masih berjalan begitu saja dengan baik.

  • Secara pribadi, saya mulai memindahkan proyek RP2040 ke Rust dan Embassy
    Rust memang butuh sedikit adaptasi, tetapi saya cukup menyukainya. Ini bukan RTOS, tetapi memenuhi banyak kebutuhan yang biasanya membuat kita merasa perlu memakai RTOS

    • Kalau menempuh jalur ini, saya sarankan mulai dulu dengan crate rp2040-hal, lalu ketika mulai terasa menyakitkan mengelola banyak task, baru lihat Embassy atau RTIC
      Rust dan Cargo menghilangkan kerepotan build dan flashing untuk RP2040, atau STM32. Sejauh ini ini lingkungan embedded paling nyaman yang pernah saya pakai
    • Saya juga melihatnya serupa. Alasan orang beralih ke RTOS umumnya adalah library dan manajemen dependensi, dan dengan Rust, Cargo, serta crates.io, hal-hal itu nyaris sudah tersedia secara bawaan
      Banyak aplikasi tidak memakai MPU. Lalu tinggal pertimbangkan keamanan memori Rust dan kompleksitas firmware keseluruhan yang berkurang tanpa RTOS
    • Sepenuhnya setuju. Secara umum embedded Rust memberi saya pengalaman yang sangat baik
      Async pada executor Embassy juga bekerja sangat baik, sehingga banyak mengurangi rasa sakit dalam proses desain RTOS
    • 100% setuju. Embassy itu hebat dan saya benar-benar menyukainya
      Jika ditambah antarmuka PIO untuk RP2040, kodenya menjadi sangat sederhana dan indah, serta menghasilkan konfigurasi yang sulit dicapai dengan prosesor lain

  • Pi Pico didukung 100% di Zephyr. https://github.com/zephyrproject-rtos/zephyr/tree/main/board... Mungkinkah dokumentasinya tidak dicek? https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi...
    Selain itu, dalam banyak situasi, cara penggunaan yang dimaksud bukan memakai satu instalasi “main” Zephyr, melainkan memasukkan modul eksternal yang dibutuhkan ke west.yml proyek
    Berbagi instalasi Zephyr yang sama di beberapa proyek adalah pembahasan tersendiri, tetapi memasang semua toolchain dan HAL yang mungkin bukan satu-satunya cara

    • Kalau tidak ingin memasang Zephyr SDK, membangun dengan toolchain GNU Arm Embedded semestinya juga hal sepele, jadi saya kurang tahu mengapa itu tidak berhasil

  • ThreadX, yang sekarang open source, tidak disebut
    https://github.com/eclipse-threadx/threadx/

    • RIOT juga bisa menjadi alternatif lain
      https://github.com/RIOT-OS/RIOT
    • Saya tidak tahu mengapa ThreadX tidak lebih sering disebut dalam daftar seperti ini. Relatif sederhana untuk digunakan dan dipahami

  • Perbandingan opsi RTOS-nya bagus
    Secara pribadi, saya melihat MicroPython sebagai jalur yang lebih mudah. Multitasking kooperatif berbasis async/await cocok untuk saya
    Dalam proyek terbaru, saya menangani 6 motor stepper, beberapa LED, dan pemindaian tombol, dan semuanya tampak real-time bagi pengguna

    • Komputer mini seperti ini jauh lebih kuat daripada komputer rumahan 8-bit dan 16-bit, sehingga MicroPython sudah cukup untuk menggantikan kasus penggunaan BASIC pada sistem awal
      Masih mengejutkan bahwa banyak orang belum benar-benar memahami betapa sedikitnya sumber daya yang dulu tersedia bagi kita, namun kita tetap memakai bahasa tingkat tinggi
    • Jika tidak ada kebutuhan real-time yang ketat seperti pada pengontrol PTZ dan penggunaan memori aplikasinya kecil, MicroPython tampak seperti pilihan yang produktif
      Saat mencoba MicroPython di ESP32, saya menyukai dukungannya terhadap interrupt handler dengan gaya yang terasa Pythonic. Saya rasa RP2040 juga didukung dengan cara serupa
    • Dalam kasus ini, bukankah seharusnya sinyal motor stepper dihasilkan oleh periferal hardware seperti RMT pada ESP32, bukan langsung dibuat oleh kode Python?
      Pada mikroskop saya, kontrol motor stepper yang nyaris real-time ditangani oleh board FluidNC, lalu saya mengendalikannya lewat protokol serial ringan
      Namun saya sedang melihat https://pypi.org/project/micropython-stepper/, dan ini tampaknya memakai timer hardware dan kode Python
    • Benar, ini sepertinya akan menjadi proyek MicroPython yang sederhana

  • Saya ingin sekali mencoba Hubris dalam proyek sungguhan (https://hubris.oxide.computer/reference/)
    Pendekatan arsitekturnya cukup sesuai dengan arah yang saya tuju di bidang embedded. Hanya saja saya melakukannya dengan cara yang lebih menyakitkan memakai C
    Ini juga tidak terlalu berbeda dari cara melakukannya dengan Erlang/Elixir di lingkungan hosted
    Dalam situasi memori lebih terbatas sehingga tidak mampu menampung banyak stack, Embassy tampaknya pilihan yang baik

  • Proyek embedded baru harus selalu, benar-benar selalu, dimulai di mesin virtual. Jangan mencampur tool di sistem yang sama
    Dalam proyek komersial saya, ini adalah penyebab nomor satu masalah kualitas
    Jika memulai proyek dengan chipset baru atau vendor baru, buat VM baru, pasang hanya tool vendor di VM itu, lalu build di sana
    Pengembangan eksperimental boleh dilakukan di mesin lokal non-VM sendiri. Tetapi rilis harus selalu dilakukan dari VM. Dan tolong sinkronkan VM dengan workstation pengembangan
    Saat ini saya sedang mengalami penderitaan besar menangani build firmware yang wajib diperbaiki ketika pengembang aslinya sedang cuti. Tidak ada yang bisa mengakses workstation orang itu, VM yang disiapkan tertinggal 6 bulan, dan pelanggan bertanya mengapa mereka harus membayar biaya seluruh tim untuk sesuatu yang di seluruh dunia hanya bisa dilakukan oleh satu programmer istimewa

    • Lebih baik lagi, pakai container. Saya sudah bertahun-tahun tidak memakai mesin virtual, dan sama sekali tidak merindukannya
    • Apakah Nix dan flakes bisa membantu untuk lingkungan build yang dapat direproduksi?
    • Saya bisa merasakan penderitaan itu
      Menurut saya, rilis harus dibuild oleh sistem CI. Saat tag rilis dipasang di git, setelah tes lolos, binary akan dihasilkan

  • Jika memilih FreeRTOS, kecil kemungkinan akan salah besar. Pada titik ini, praktis sudah menjadi standar industri

    • Solusi apa yang ada untuk masalah membuat printf() berfungsi?
      Kelihatannya cukup merepotkan

  • Pernah punya pengalaman yang mirip dengan tulisan asli
    Jadi saya membuat sendiri timer green thread sederhana
    Memang tidak mendukung manajemen proses sungguhan seperti kernel sebenarnya dan tidak memberikan jaminan apa pun, tetapi itu memungkinkan saya melangkah lebih jauh dibanding penjadwalan bare-metal dan menghindari kekacauan bernama RTOS
    Anggap saja seperti callback timer JavaScript di C yang menerima struct konteks opsional
    Saya bisa menangani kueri ke berbagai sensor, memproses sinyal masuk, mengambil keputusan kontrol, dan mengirim perintah, masing-masing dengan periode yang berbeda
    Sebelum merusak hidup dengan arsitektur yang lambat dan abstrak seperti ini, saya sangat menyarankan mencoba pendekatan seperti ini terlebih dahulu