STM32F4 dan HAL

Jadi saya telah bereksperimen beberapa saat dengan STM32F407 (Saya baru mengenal ARM) dan memutuskan untuk menulis aplikasi sederhana menggunakan pustaka HAL karena tampaknya ST telah menghentikan Pustaka Periferal Standar. Jadi pertanyaan saya adalah, apa gunanya HAL? Bukankah StdPeriph melakukan tugasnya? Mengapa mereka menghentikannya untuk HAL? Bagi saya sepertinya HAL benar-benar berantakan.

Dokumentasinya AWFUL, setidaknya untuk StdPeriph ada referensi lengkap yang diatur dengan cukup baik untuk dengan mudah menemukan apa yang Anda inginkan ( http://stm32.kosyak.info/doc/ ). Untuk HAL ada PDF jelek ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ) yang memiliki struktur yang tampaknya acak. Membaca bagian apa pun, misalnya tentang periferal, sepertinya saya tidak mengerti persyaratan untuk mengkonfigurasinya dan menyesuaikannya dengan benar. Itu lebih mirip catatan pribadi dari seseorang yang tidak ingin melupakan hal-hal, daripada referensi.

Saya tahu saya dapat menggunakan CubeMX untuk menginisialisasi GPIO dan mengkonfigurasi periferal, tetapi tujuan saya adalah melakukannya sendiri jadi saya mengerti lebih baik operasi mereka, tidak ada perangkat lunak yang melakukan semuanya untuk saya. Apakah saya melakukan sesuatu yang salah? Apakah pemula ARM dalam diri saya yang membingungkan saya? Atau apakah dokumentasi yang tersedia itu buruk?

Membuat perpustakaan Anda sendiri cukup sederhana. Dokumentasi spec register mereka cukup bagus, sebagian besar jika tidak semua periferal mudah dipasang. Saya merasa jauh lebih menyakitkan untuk menggunakan perpustakaan mereka. tapi mungkin itu hanya aku. Ini berlaku untuk st, nxp, ti, atmel untuk beberapa nama (tidak terlalu banyak untuk intel dan microchip).

Mengapa mereka mengganti perpustakaan, bisa karena sejumlah alasan, beberapa bos baru mengambil alih, beberapa divisi ditutup dan yang lain mengambil alih. Pemasaran menginginkan citra baru untuk produk tersebut. Seperti yang disebutkan ElectronS, bisa menjadi upaya untuk menjauh dari perangkat keras lebih untuk menarik pengguna yang tidak mau atau tidak mampu melakukan bare metal. Saya akan melangkah lebih jauh tentang itu dan mengatakan mereka mungkin mencoba bersaing dengan fenomena Arduino. Yang tidur dan semua orang selalu berusaha melakukan dan gagal (bahkan sebelum Arduino).

Bagaimanapun juga semakin jauh dari perangkat keras itu semakin membengkak dan lebih lambat, sehingga semakin banyak Anda harus menghabiskan per unit untuk rom, ram dan mhz. Hanya agar Anda bisa menghabiskan jumlah waktu pemrograman yang sama? Hanya melakukannya secara berbeda?

Anda mengatakan Anda berasal dari dunia PIC, sekarang mereka melakukan pekerjaan yang baik-baik saja dengan peralatan, dokumen chip mereka sangat mengerikan, beberapa yang terburuk. mereka dikompensasi dengan perpustakaan dan kotak pasir.

Pada akhirnya, cobalah berbagai pilihan, coba produk yang bersaing untuk melihat bagaimana alat mereka membandingkan. Banyak hal yang dapat Anda lakukan secara gratis hanya untuk melihat apakah itu masuk akal dan Anda dapat menyusun barang. Mungkin bahkan menggunakan set instruksi simulator. Temukan yang cocok untuk Anda.

Catatan, opsi tanpa pustaka kalengan SELALU tersedia untuk Anda. Anda tidak terbatas pada toolchain apa yang dapat Anda gunakan, sistem operasi host apa, ide apa, editor, dll. Mereka mungkin menempel pada Anda pada pemrograman bagian-bagian, jika opsi mereka sangat terbatas dalam hal pindah ke beberapa chip lain atau vendor jika Anda bisa.

Untuk menjual produk chip seperti ini, mereka harus menyediakan lingkungan pengembangan baik itu milik mereka atau barang gratis yang direkatkan bersama. Dan mereka cenderung menyatukan perpustakaan. Itu hanya harus terlihat cukup baik dan kedipan contoh yang dipimpin bekerja dengan cukup baik untuk membuat manajemen Anda atau tim perangkat keras Anda mendesain produk mereka, maka ketika produk papan Anda dilemparkan ke dinding ke perangkat lunak, adalah ketika rasa sakit tidak atau tidak tiba. Jika hampir berhasil tetapi tidak cukup merupakan kemenangan besar bagi vendor chip karena Anda sekarang akan membayar untuk dukungan teknis untuk itu sedikit terakhir. Jadi adalah kepentingan terbaik mereka untuk berada di sana tetapi tidak cukup.

Vendor chip hanya perlu terlihat cukup baik untuk mendapatkan kemenangan desain. Mereka harus terus meningkatkan (mengubah) produk untuk menarik pelanggan baru dan lama. Jadi mereka harus melakukan overs, seberapa jauh jarak dan berapa banyak perpustakaan sebelumnya yang terus didukung, bervariasi. Jadi hampir semua perpustakaan yang Anda gunakan akan hilang pada akhirnya. Jadi belajar beradaptasi (atau jangan gunakan barang-barang mereka dan pergi sendiri, yang dapat Anda dukung tanpa batas). Memang, idealnya, Anda hanya perlu mengembangkan aplikasi sekali per produk, membuat firmware Anda sempurna (semoga berhasil jika menggunakan perpustakaan pihak ketiga), dan Anda tidak perlu kembali dan menemukan komputer yang akan memuat toolchain mereka jika Anda dapat menemukan salinannya, dan ingat bagaimana menggunakan perpustakaan lama itu. Ingat tidak hanya Anda harus menyimpan kode sumber Anda, tetapi Anda harus menyimpan semua alat dan dokumen mereka.

Pustaka mereka hanya didukung pada biasanya satu toolchain, di bawah satu mungkin dua IDE dan kadang-kadang hanya pada Windows, dan versi tertentu. Sekali lagi Anda tidak memiliki batasan itu, pasti bukan untuk ARM, jika Anda melakukan hal Anda sendiri. Anda selalu dapat membaca salah satu / semua perpustakaan mereka untuk melihat bagaimana mereka melakukan sesuatu. Tapi itu seringkali sangat menakutkan, mereka tidak menggunakan pengembang tim A mereka untuk perpustakaan, saya telah mengekstrak beberapa baris kode untuk bertanya kepada kandidat wawancara apa yang salah dengan kode ini.

untuk menghemat waktu dan tenaga baik di sisi silikon dan sisi perangkat lunak mereka sangat sering mendaur ulang ip yang sama, jadi setelah Anda melihat bagaimana perangkat bekerja pada salah satu chip mereka sering bekerja dengan cara yang sama pada banyak chip lainnya. Ya sistem jam bisa rumit dengan atau tanpa perpustakaan mereka. Peluang yang tinggi untuk merusak chip, di situlah sebagian besar chip / board bricking saya terjadi. Membantu memahami cara kerja chip mereka, misalnya AVR's, sebagian besar jika tidak semua, dapat diprogram ulang saat chip di reset, sehingga setiap kode buruk yang mengacaukan pin yang diperlukan untuk memprogram ulang, atau menggantung logika yang diperlukan untuk memprogram ulang, tidak masalah, Anda dapat memprogram ulang chip tersebut. Beberapa vendor ini (st adalah satu) memiliki bootloader internal yang dapat Anda pilih menggunakan tali (BOOT0 misalnya di dunia st),

Satu ukuran cocok untuk semua, tidak ada yang cocok. Terutama berlaku untuk perangkat lunak. Jadi setiap upaya untuk mengabstraksi perangkat keras, hanya membuatnya lambat dan kembung. Mungkin juga dapatkan chip yang lebih besar dan jalankan linux di atasnya, jika itu yang Anda cari. Banyak dari ini karena para pengembang, tidak ingin tangan mereka kotor, jadi kami pada dasarnya meminta ini, dan mereka mencoba untuk memasoknya.

Sekali lagi, jangan mengunci diri Anda di st atau vendor mana pun (kecuali sudah terlambat dan manajemen dan atau tim perangkat keras telah menempelkannya kepada Anda, perhatikan bahwa produk stm32 bagus dan mudah digunakan). Melihat-lihat. TI memasukkan banyak telur ke dalam keranjang korteks-m4. Anda dapat melakukan beberapa hal pada sejumlah produk lengan ini serta solusi yang didukung vendor.

Satu hal yang selalu dapat Anda andalkan, adalah bahwa mereka akan mengubah perpustakaan dari waktu ke waktu dan pada akhirnya berhenti mendukung perpustakaan yang sudah biasa Anda gunakan.

Biarkan saya memberi tahu Anda bahwa banyak dari kita berbagi kekecewaan yang sama yang Anda miliki dengan perpustakaan HAL, mereka memang didokumentasikan dengan buruk dan samar-samar dan masih baru mengandung banyak bug.

Jadi untuk menjawab pertanyaan Anda mengapa ST memutuskan HAL sederhana:

1. Mereka ingin membuat lapisan abstraksi perangkat keras yang dalam bahasa Inggris berarti mereka ingin pengembangan dan kode perangkat lunak independen dari mikro-controller, jadi jika Anda menulis kode hari ini untuk stm32f4 dan Anda perlu beberapa tahun untuk bermigrasi ke stm32f7 itu akan mudah dan kode akan sangat modular.

2. Ini juga memungkinkan lebih banyak pengembang seperti programmer perangkat lunak untuk bekerja dengan mikrokontroler tanpa benar-benar memahami atau masuk ke detail mendalam tentang bagaimana perangkat keras mencapai tugas. Perusahaan seperti ST dan TI (memulai jalan ini sekarang) sedang mencoba untuk membuat pengembangan tertanam mirip dengan pengembangan kode PC di mana Anda menggunakan driver tingkat tinggi untuk mengembangkan kode FAST. Kecanggungan dan kurangnya optimasi dalam driver dan perpustakaan mereka dikompensasi oleh kinerja tinggi dari perangkat ARM.

3. Saya pikir STM32cubeMX adalah alat yang hebat jika Anda menggunakan perpustakaan HAL, karena pekerjaan yang paling memakan waktu adalah menginisialisasi periferal dan sekarang Anda dapat melakukannya dalam waktu yang sangat singkat, dengan antarmuka visual yang dapat dengan mudah diubah tanpa mempengaruhi kode pengguna (jika Anda menulis kode di tempat yang sesuai) Anda dapat menggunakan Stm32cubeMx dan kemudian meninjau kode dan mencoba memahami bagaimana dan mengapa mereka menggunakan setiap fungsi, dengan cara ini Anda mencoba menyelesaikan latihan dan memiliki solusi manual terdekat untuk koreksi yang merupakan IMO yang bagus.

4. Inti ARM cukup kompleks sehingga metode lama yang kami gunakan pada pengontrol mikro 8-bit seperti menangani register secara langsung (menulis C dengan cara perakitan) tidak layak, memakan waktu dan membuat kode sulit dipelihara karena arsitektur yang rumit (periksa pengaturan jam misalnya)

Saya tahu ini akan panjang dan penuh opini, tetapi karena kami baru saja (berhasil) merilis produk baru menggunakan HAL, saya pikir ini layak untuk dipertimbangkan. Juga, saya tidak bekerja untuk ST, saya benci setiap bit HAL, hampir memulai kembali proyek dengan StdPeriph, saya merasakan sakitnya - tetapi sekarang saya mengerti mengapa.

Pertama, sedikit latar belakang. Kami mengembangkan sistem telemetri berdaya sangat rendah, dan produk kami ditenagai oleh STM32L1. Ketika kami mulai mengerjakan firmware, kami memiliki pilihan yang biasa untuk perangkat ST (bare metal): melakukan semuanya dengan tangan, menggunakan perpustakaan StdPeriph, atau menggunakan HAL. Orang-orang ST meyakinkan kami untuk pergi dengan HAL - jadi kami lakukan. Itu menyakitkan, kami harus mengatasi bug dalam perangkat lunak (bagian I2C membuat kami gila untuk beberapa waktu) dan saya masih tidak suka arsitektur keseluruhan. Tapi itu berhasil.

Ketika saya beralih dari desktop ke embedded, sedikit lebih dari setahun yang lalu, saya terpana oleh sesuatu yang aneh yang tidak bisa saya sebutkan atau bahkan pahami. Seiring waktu saya dapat memahami apa yang - atau lebih tepatnya, apa yang terjadi - dunia yang tertanam dalam transisi. Silikon semakin murah setiap hari dan MCU lebih kuat dan serbaguna. Semakin banyak perangkat, terlepas dari ukurannya, kebutuhan daya, bergantung pada MCU generik. Semakin banyak perusahaan bergabung dalam permainan, membawa gerombolan pengembang baru dengan berbagai latar belakang. Budaya "rata-rata" menjauh dari "pria EE tradisional dengan keterampilan pemrograman" menjadi "pria SW dengan pengetahuan perangkat keras yang tidak jelas".

Apakah ini baik atau buruk itu tidak relevan. Itu terjadi begitu saja. Sebenarnya, itu juga terjadi pada dunia perangkat lunak, lebih dari sekali. Boom web pada tahun 2000 menarik pemula PHP / MySQL - katakan saja ada register di CPU, mereka akan menjawab "Saya menggunakan Linux, jadi tidak ada Registry di OS saya". Sebelumnya, OS multi-pengguna yang berjalan dalam mode terlindungi memungkinkan pengembang yang malas untuk tidak pernah membuat ISR dalam seluruh karir mereka dan baik-baik saja . Bahkan sebelumnya, keyboard dan layar membuat pemukul kartu dan produsen printer menjadi gila.

_{Dan ya, tren saat ini membuat saya pribadi sedih, karena saya melihat pengembang bodoh kagum dengan teknologi mengkilap terbaru, sementara sama sekali tidak dapat menghubungkan mereka dengan sejarah. Ketika saya melihat saya yang lebih muda mengkodekan permainan dalam Javascript dengan WebGL pada 2015, saya ingin berteriak "Tidak ada yang baru! Saya melakukan hal yang sama dengan C ++ dan 3Dfx SDK pada tahun 1995!". Yang tidak diceritakan oleh ceritanya adalah permainannya berjalan di ponsel saya, sedangkan game saya membutuhkan PC gamer (dan installer, dan saya tidak bisa mendorong pembaruan oleh web). Yang benar adalah, dia bisa berkembang adalah permainan dalam satu bulan, di mana saya melakukan hal yang sama dalam enam, atau dua belas.}

Jelas, baik ST atau TI atau Intel atau siapa pun yang memproduksi chip tidak mau ketinggalan. Dan mereka benar. HAL adalah respons ST, dan sebenarnya cukup baik, tidak hanya di sisi bisnis atau pemasaran, tetapi di sisi teknik juga. Alasan mengapa itu terdengar terletak pada nama:

Lapisan Abstraksi Perangkat Keras

Jika ada yang lain, inilah yang harus Anda ingat. HAL adalah upaya untuk menjauh dari perangkat keras. Ini adalah rekayasa yang baik karena memungkinkan kami memisahkan fungsi dari detail. Layering adalah apa yang memungkinkan untuk mengembangkan program kompleks - satu abstraksi di atas yang lain, ke perangkat keras. Abstraksi sebenarnya adalah alat paling ampuh yang kita miliki untuk mengelola kompleksitas . Saya sangat meragukan siapa pun di planet ini yang dapat memprogram peramban web dalam perakitan untuk CPU tertentu.

Pergeseran budaya memang sulit untuk dicerna, tetapi karena saya harus memperhitungkan bahwa orang tidak perlu membaca Seni Pemrograman Komputer Knuth untuk mengembangkan aplikasi web, dunia EE harus mengakui ada pendatang baru yang dapat (dan akan!) Mengembangkan kode tertanam tanpa membaca Manual Referensi Suci Sialan .

Berita baiknya adalah pemain baru tidak berarti kurang bekerja untuk pemain yang lebih tua - justru sebaliknya, IMHO. Siapa yang akan mereka panggil ketika hal-hal "tidak berhasil?" Jika Anda memiliki RTFM (tidak seperti mereka), dan jika Anda tahu apa yang dilakukan oleh setiap bit dari konfigurasi yang tidak jelas ini, Anda memiliki keuntungan.

Antara bacaan dan eksperimen Anda, cukup ikuti HAL. MCU baru? Tidak masalah. Jalur MCU baru? Tidak masalah juga (saya mengkodekan tes pada STM32F4 Nucleo hanya dalam sehari dengan CubeMX, dan kemudian hanya porting ke perangkat kami ... rasanya benar ). Mengejek untuk tes unit? Tidak masalah. Daftar ini terus berlanjut, karena abstraksi itu baik.

Tentu saja, HAL itu sendiri tidak 100% OK. Dokumentasinya mengerikan (tetapi Anda memiliki RT F HRM, bukan?), Ada bug, ST baru saja melempar versi beta kepada kami (tampaknya cukup standar akhir-akhir ini) dan dukungan publik mereka adalah lelucon. Tetapi tidak melepaskan HAL akan lebih buruk.