Get best of the week

Apa SDK nRF Connect baru untuk Nordic? Evolusi, revolusi atau alternatif?

Pekan lalu, Nordic Semiconductor menambahkan dukungan seri nRF52 ke nRF Connect SDK.



Pertanyaan utama yang dimiliki kebanyakan orang adalah apa itu dan mengapa itu penting? Pertanyaan ini sangat relevan bagi mereka yang memiliki pengalaman dengan nRF5 SDK, dan ada banyak dari mereka.

Saya segera mencatat bahwa artikel ini terutama ditulis untuk mereka yang menggunakan pendekatan tradisional dalam pengembangan level Cortex-M atau perangkat dekat. Oleh karena itu, beberapa definisi dan analogi mungkin tidak sepenuhnya benar dari sudut pandang mereka yang bekerja pada level tinggi (melihat apa yang terjadi di sisi Linux), tetapi akan lebih mudah untuk dipahami bagi mereka yang baru memulai dengan cara ini.

Komentar dan klarifikasi selalu diterima.

Sedikit tentang siapa Nordik dan bagaimana mereka melakukannya dengan baik sekarang
Nordic . , , Bluetooth Low Energy, 90% . : Starline, Pandora, Scher-Khan . Redmond, Ready4Sky. . 2 .

Nordic Semiconductor 40%, 2.5 , (TI). , . , Samsung Xiaomi Nordic , , .

, Nordic, , . nRF5x STM ( ).

:

  • ( )
  • SDK
  • ( )
  • Altium

, Nordic Semiconductor .

Di sini muncul pertanyaan utama, mengapa SDK baru dirilis dan apa bedanya dengan SDK saat ini? Jika demikian, semuanya baik-baik saja dengan solusi saat ini. SDK nRF5

saat ini bekerja berdasarkan antrian sederhana, dan dalam kebanyakan kasus ini cukup untuk melaksanakan hampir semua tugas (meskipun beberapa perusahaan masih menggunakan SDK mereka sendiri, tetapi ini adalah pengecualian dari aturan). SDK nRF Connect yang baru menggunakan pendekatan yang sangat berbeda berdasarkan Zephyr RTOS. Pertimbangkan perbedaannya lebih detail. RTOS (RTOS) memiliki kelebihan dan kekurangan tertentu. Yang terakhir termasuk:


  • overhead tambahan untuk mempertahankan OS
  • kerumitan pengembangan pada proyek-proyek sederhana
  • peningkatan kompleksitas build

Sisa dari RTOS adalah:

  • peningkatan keandalan karena kontrol aliran individu

Di dalam Nordic, ini menjadi menarik dan relevan sejak diperkenalkannya sistem baru dalam paket (SIP) dengan LTE Cat-M / NB-IoT / GPS - seri nRF91. SIP ini memiliki kinerja yang lebih tinggi karena inti Cortex-M33 baru dan persyaratan lain untuk komponen jaringan, yang muncul karena transisi dari BLE ke jaringan seluler. Inovasi lain di sini adalah modem SDR, yang bekerja pada inti yang terpisah dan dengannya diperlukan untuk mengatur interaksi internuclear. Untuk pertama kalinya, SDK berbasis RTOS muncul di sini, dan bagi mereka yang pertama kali mengalami pendekatan baru, itu menimbulkan sejumlah pertanyaan, mulai dari tahap persiapan. Seorang asisten khusus juga dirilis untuk perakitan yang benar dari lingkungan pengembangan - Getting Started Assistant. Dia memberi tahu Anda komponen mana yang perlu Anda instal (ada banyak di antaranya, lihat di bawah), dan memeriksa apakah semuanya sudah diinstal dengan benar.

gambar

Dari sudut pandang ini, kita dapat membandingkan transisi ke Zephyr dengan penampilan massa ARM Cortex-M pertama dan transisi ke 32 bit. Sekarang mayoritas menggunakan 32-bit MK sebagai yang utama, tentang yang ada artikel tentang Habré. Ini juga menceritakan tentang transisi, yang pada awalnya tampak tidak perlu rumit. Namun seiring waktu, hampir semua orang sampai pada kesimpulan bahwa ini telah menjadi standar.

Perlu dicatat bahwa Zephyr OS bukan satu-satunya RTOS yang berjalan pada chip Nordic. Contoh proyek dengan FreeRTOStersedia di SDK v.11 mulai tahun 2016, dan bahkan lebih awal di SDK v.9 ada dukungan Keil RTX untuk keluarga nRF51 (2015). Namun, sebelumnya ini lebih banyak fungsi eksperimental dan dukungan disediakan untuk tingkat yang lebih besar oleh produsen RTOS. Yang pada prinsipnya benar sekarang.

Dukungan Zephyr tidak resmi untuk keluarga nRF5x muncul kembali pada tahun 2016 .

Zephyr Nordic memutuskan untuk membuat SDK yang sepenuhnya baru di RTOS sekarang.

Ada sejumlah prasyarat untuk ini:

  • Sejumlah teknologi diwarisi dari Linux:

    • bekerja dengan stream, antrian dalam waktu nyata (terutama penting untuk protokol yang tergantung waktu seperti BLE)
    • perpustakaan untuk jaringan dan keamanan
    • model deskripsi perangkat keras yang fleksibel dengan optimasi energi
    • perpustakaan untuk bekerja dengan periferal (sensor, dll.)

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

Untuk memahami bagaimana perubahan dramatis telah terjadi, diagram struktural dari dokumentasi resmi sangat cocok. Gray menunjukkan komponen yang merupakan bagian dari Zephyr.

gambar

Dalam praktiknya, ketika menerapkan pendekatan ini, sejumlah masalah kognitif muncul. Pengembang yang terbiasa dengan produk dan solusi mengalami disonansi dengan sejumlah besar perubahan.

Pertimbangkan versi pengembangan pada Windows, karena akan menimbulkan lebih banyak pertanyaan mengenai mereka yang terbiasa mengembangkan di Linux.

Paket-paket berikut diperlukan:

  • Chocolatey (pengelola paket)
  • Git (sistem kontrol versi)
  • Ninja (sistem build berorientasi kecepatan)
  • CMake (sistem build tingkat tinggi)
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

Bagi seseorang yang dihadapkan dengan seperangkat utilitas serupa untuk pertama kalinya, mungkin tampak bahwa semuanya tidak perlu rumit dan paradigma lama dapat digunakan, bahwa pendekatan yang ada untuk pengembangan cukup efektif. Namun, jika Anda melihat lebih dalam, maka semuanya menjadi jauh lebih menarik.

Sebagai contoh, Chocolatey dan pip memungkinkan Anda untuk menginstal semua paket yang diperlukan melalui konsol untuk OS dan Python, masing-masing. Dan Python sendiri, seperti kebanyakan perangkat lunak yang dipertanyakan, dimasukkan ke dalam satu perintah:

hoco install python xxx

Itu juga diperbarui dengan satu perintah:

choco upgrade all

Pendekatannya agak tidak biasa bagi pengguna Windows, bagi mereka yang akrab dengan manajer paket konsol di Linux (apt, zypper, dll.), Bukan hal yang baru. Saya sering memperhatikan situasi bahwa pengembang perangkat lunak untuk MK memperbarui perangkat lunak hanya ketika menginstal ulang OS pada PC. Tentang mengapa itu buruk kita tidak akan berbicara, saya hanya mencatat bahwa di sini masalah ini diselesaikan secara otomatis.

Inovasi di bidang konfigurasi dan perakitan proyek jauh lebih menarik.

Ninja dirancang dan diposisikan sebagai pengganti untuk membuat dan fokus pada kecepatan membangun. Ini sangat baik dalam aplikasi ketika perlu untuk membangun kembali proyek dengan banyak file kecil, di mana tidak ada perubahan. Efeknya bisa berupa urutan besarnya, atau bahkan dua, lihat tes .

Cmakepada gilirannya, ini memungkinkan menghasilkan file konfigurasi untuk Ninja dalam bahasa (scripting) tingkat tinggi untuk platform di mana perakitan akan berlangsung. Tentang Cmake dapat dibaca di Habré, misalnya, di sini , di sini dan di sini ,
GPerf menghasilkan tabel petunjuk, yang menghemat memori, lihat langkah 3 dari perakitan di bawah ini.

Kita juga harus memperhatikan pendekatan baru untuk deskripsi besi. Devicetree muncul , menggambarkan struktur perangkat keras perangkat. Ini adalah hasil langsung dari dukungan Zephyr oleh Linux Foundation.

Kelebihannya adalah bahwa deskripsi perangkat keras sekarang dalam file .dts terpisah, yang memiliki struktur sederhana, mudah untuk memodifikasi, dan, sebagai akibatnya, port kode antara berbagai keluarga chip.
Sebagai contoh, sejauh yang saya bisa menggambarkan semuanya, saya akan memberikan dtsi dasar pada nRF52840 , yang pada gilirannya digunakan dalam deskripsi papan nRF52840-DK nrf52840dk_nrf52840.dts.Jumlah
motherboard yang didukung oleh Zephyr sudah lebih dari 200 .

Seperti yang dinyatakan sebelumnya, Nordic pertama kali merilis Zephyr pada seri nRF91, kemudian pada nRF53, dan sekarang akhirnya mencapai nRF52 yang paling masif.

Beralih ke RTOS memungkinkan untuk memecahkan masalah mengadaptasi kode untuk perangkat keras baru. Bahkan di antara chip satu keluarga, transisi memerlukan sumber daya tertentu dari sisi pengembangan, jika disertai dengan transisi ke perangkat lunak lain (perpustakaan BLE yang dikompilasi). Belum lagi transisi, misalnya, dari seri 51 atau 91 ke 52, ketika platform perangkat keras itu sendiri berubah secara signifikan. Sekarang tugas ini akan diselesaikan dengan lebih mudah dan lebih cepat.

Besi di Nordic terus ditingkatkan, tetapi ini harus ditulis secara terpisah. Dalam kerangka artikel ini, kami hanya dapat mencatat bahwa fokusnya adalah integrasi dengan RTOS, keselamatan, efisiensi energi, dan peningkatan saluran radio (BLE 5.2). Terima kasih bisa mengatakan dual-core Cortex-M33, ARM Cryptocell dan ARM TrustZone.

Untuk membangun devicetree digunakanDevice Tree Compiler , yang merupakan bagian dari MSYS2 (sistem build yang ditingkatkan berdasarkan Cygwin dan MinGW-64).

Bagian kedua dari konfigurasi proyek adalah di KConfig (Kernel config), yang juga diwarisi dari Linux. Ini memungkinkan Anda untuk memilih blok yang diperlukan melalui antarmuka grafis dan mengatur parameter untuk perakitan untuk tugas tertentu, yang sangat penting dalam kondisi sumber daya sistem yang terbatas pada sebuah chip.

Anda dapat menggunakan utilitas tradisional seperti menuconfig, atau dalam kerangka Segger Embedded Studio (IDE yang direkomendasikan resmi) ada antarmuka bawaan yang dapat diluncurkan melalui item menu yang sesuai: Proyek> Konfigurasi nRF Connect SDK Project



Contoh konfigurasi proyek dengan SSL / TLS berdasarkan nRF9160 disajikan di bawah ini. Seperti yang dapat Anda lihat di dalamnya, Anda dapat mengkonfigurasi fitur perangkat keras dari proyek (platform, jumlah utas, modul kernel plug-in), dan perangkat lunak (kunci, alamat, dll.).





Pertimbangkan tahapan-tahapan perakitan proyek: Ada lima total:

  • Konfigurasi - pemrosesan awal semua konfigurasi (devicetree, KConfig), pada output kita mendapatkan file header yang menjelaskan perangkat keras dan konfigurasi untuk Ninja
  • Pra-perakitan (I) - memproses struktur pada tingkat tinggi, mengkompilasi file sistem dan offset (offset), membuat tabel panggilan
  • Perakitan awal (II) - kompilasi kode sumber utama dan mengemasnya ke dalam arsip, menghubungkan
  • (III) — (GPerf),
  • - (IV) — hex, bin

Anda dapat membaca lebih lanjut tentang sistem perakitan Zephyr dengan gambar-gambar dalam dokumentasi resmi . Ada cukup banyak teks dan gambar, jadi kami tidak akan mempertimbangkan detail dalam artikel ini.
Penting untuk dipahami bahwa alat yang digunakan di sini bukan pengganti untuk C preprocessor (cpp) dan C linker (ld). Keduanya digunakan pada semua tahap kecuali pasca pemrosesan. Namun, hasil pekerjaan mereka mengalami peningkatan tambahan, yang memungkinkan keduanya secara signifikan mengurangi waktu perakitan dan persyaratan memori.

Anda tidak dapat langsung membandingkan hasil program yang dibuat di dua SDK. Karena perpustakaan dan pendekatannya sangat berbeda dan belum ada tes seperti itu. Orang pasti bisa mengatakan bahwa solusi terasa baik pada chip menengah dan top-end di baris (nRF52832 dan lebih tinggi), masih ada cadangan sumber daya yang besar. Namun, tidak dapat dikatakan bahwa SDK baru tidak berlaku pada chip yang lebih muda seperti nRF52810. Perlu untuk mempertimbangkan masalah secara lebih rinci.

Kembali ke pertanyaan dalam judul artikel, kita dapat mengatakan bahwa paradigma ini jelas merupakan kenyataan baru. Yang sekilas membawa perbaikan signifikan. Setidaknya 2 keluarga chip baru dari produsen BLE terbesar di dunia bekerja dengan tepat dan hanya pada teknologi ini dan tidak ada pengembalian yang diharapkan. Menurut saya, ini adalah revolusi yang sudah dipersiapkan sebelumnya.

Pembaruan : Pada tanggal 14 Mei, Nordic mengadakan webinar tentang SDK baru di mana ia mengumumkan bahwa semua versi BLE lebih tua dari 5.0 hanya akan tersedia di nRF Connect SDK. Dengan demikian, Directino Finding alias AoA / AoD (BLE 5.1) dan LE Audio (BLE 5.2), yang banyak ditunggu, akan membawa mereka dengan alat baru tahun ini dan perubahan dalam pengembangan akan datang lebih cepat dari yang diperkirakan.

Temuan:

  • Perubahannya radikal, kode yang bekerja dengan nRF5 SDK saat ini tidak kompatibel dengan yang baru (nRF Connect SDK)
  • Beralih ke RTOS dengan Devicetree dan KConfig memungkinkan Anda mendapatkan tingkat abstraksi tambahan untuk perangkat keras, yang pada gilirannya secara signifikan mempercepat pengembangan dan transfer proyek ke platform baru
  • Beralih ke Zephyr membawa dukungan untuk sejumlah besar protokol dan perpustakaan di luar kotak, untuk perangkat IoT, yang paling menarik adalah fungsi jaringan dan keamanan, di mana Linux secara tradisional kuat
  • Zephyr OS menggunakan sejumlah alat selama perakitan, yang secara signifikan dapat mengurangi waktu perakitan dan persyaratan memori, yang sangat penting untuk aplikasi tertanam
  • SDK baru memungkinkan penggunaan pengembang tingkat tinggi, yang jauh lebih banyak di pasar daripada yang tingkat rendah. Ini memecahkan masalah personil dan meningkatkan pangsa pasar.

More articles:


All Articles