STM32F4 dan HAL


23

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?


Apakah sesuatu seperti ChibiOS mungkin lebih cocok untuk Anda? Mereka memiliki RTOS tetapi juga HAL yang sangat baik yang dapat Anda gunakan tanpa RTOS.
IgorEE

ST belum menghentikan Perpustakaan Periferal Standar, tetapi mereka tidak akan merilis versi baru untuk keluarga yang lebih baru. Mereka telah menyatakan (di suatu tempat di forum mereka tetapi sepertinya saya tidak dapat menemukannya) bahwa mereka akan terus mendukung SPL untuk keluarga yang telah dirilis untuk (termasuk STM32F4). Karena Anda baru mengenal ARM, mungkin yang terbaik adalah menggunakan HAL. Saya memiliki banyak sekali modul yang telah ditulis menggunakan SPL sehingga transisi akan menyusahkan dan saya telah menundanya. Ini buruk karena sekali saya memutuskan untuk menggunakan keluarga baru, akan ada lebih banyak kode untuk port ke HAL
Tut

Ebook ini: leanpub.com/mastering-stm32 adalah pengantar yang bagus untuk pemula (tetapi juga untuk profesional) ke dunia STM32.
Lorenzo Melato

Jawaban:


13

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.


Argumen hebat tentang pengembangan perpustakaan Anda sendiri, hampir yakin dan saya ingin mencobanya, menurut Anda apa yang akan saya butuhkan selain dari manual referensi stm32fxx? haruskah saya juga membaca manual arm core? Apakah saya akan menggunakan CMSIS? bagaimana saya akan mengakses register dan memori? dapatkah Anda menjelaskan lebih lanjut atau memberikan contoh tentang cara memulai
ElectronS

beberapa hal lagi untuk dipikirkan. setiap baris kode menambah risiko. menjelaskan kepada bos Anda bahwa Anda berencana untuk menggunakan puluhan hingga ratusan ribu baris kode orang lain, tanpa meninjau setiap bit yang Anda gunakan. lapisan kode, khususnya saat abstrak, menyebabkan binari menjadi lebih besar dan kinerja turun. Jadi sekali lagi jelaskan kepada atasan Anda bahwa 10 juta unit produk akan dikenakan biaya 35 sen tambahan per atau 3,5 juta dolar karena Anda memilih untuk menggunakan perpustakaan karena Anda malas.
old_timer

bos Anda dapat merekrut pasukan orang untuk menggantikan Anda untuk uang sebanyak itu, minta setiap baris kode ditinjau sehingga mereka tidak mendapatkan 10.000 unit dan mendapati mereka harus membuangnya di seluruh bug perangkat lunak yang disebabkan oleh menggunakan perangkat lunak berisiko. dan gunakan bagian yang lebih kecil yang lebih murah pada laju jam yang lebih lambat yang menggunakan daya lebih sedikit dan berjalan lebih lama pada satu pengisian daya baterai. terkadang itu sepadan dengan usaha. dan tentu saja, terkadang tidak.
old_timer

terima kasih untuk lebih banyak poin yang Anda nyatakan, tetapi bisakah Anda menjawab pertanyaan saya, tentang cara terbaik untuk memulai? menggunakan file CMSIS dan HAL .h untuk mendaftarkan nama dan lokasi memori ??
Elektron

Tidak ada yang "terbaik", menggunakan kata itu menjadikannya pendapat pribadi, bukan fakta. Cukup pilih satu dan mulai, atau lakukan seperti yang saya bisa, coba satu sampai Anda menabrak blok jalan, lalu coba yang lain, dan yang lain, dan berkeliling mendorong setiap blok jalan kembali ke blok jalan berikutnya sampai satu atau semua menerobos.
old_timer

14

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)


6
Ini semua sangat bisa dimengerti, tetapi semua ini berlaku untuk StdPeriph juga, bukan? Maksud saya, ini sudah merupakan perpustakaan abstraksi perangkat keras, jadi apa gunanya membuat yang baru alih-alih memperbaiki yang lama? Saya benar-benar ingin tahu, saya sangat baru di ARM, saya telah menggunakan PIC selama bertahun-tahun.
John

Terlebih lagi untuk perpustakaan yang mematuhi CMSIS
Scott Seidman

1
@ John, sejauh yang saya mengerti HAL lebih abstrak dan kurang tergantung perangkat keras dari perpustakaan standar.
Elektron

12

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.


Saya melihat dari mana Anda berasal. Seperti yang saya pahami, hal-hal (sayangnya) berjalan seperti Arduino, mencoba menyembunyikan sebanyak mungkin kenyataan dari programmer untuk memikat lebih banyak orang perangkat lunak tingkat tinggi ke dalam pemrograman perangkat keras, dan ini adalah alasan di balik perpustakaan seperti HAL. Namun melihat betapa buruknya dokumentasi itu dan kekacauan total juga, saya tidak berpikir mereka akan berhasil melakukannya dalam waktu dekat.
John

@ John: HAL tidak menyembunyikan "realitas". Semuanya ada untuk Anda atur. Semua bagian bersifat opsional - mis. Anda mungkin hanya ingin menggunakan makro untuk mengakses register, atau hanya driver tertentu (mis. I2C) atau semuanya termasuk ISR dan konfigurasi jam. Pilihanmu. Namun, saya setuju bahwa dokumentasinya sangat buruk. (Saya sudah memberi tahu ST dan mereka berjanji akan mengerjakannya BTW)

Kami mengulangi melakukan hal yang sama dengan alat baru. Karena alat baru menjanjikan untuk membuat pekerjaan lebih mudah dan lebih cepat sehingga hemat biaya. Tetapi kita masih melakukan hal yang sama, karena manusia masih sama, tidak peduli apakah itu 2095 atau 1995. Pilihan yang tersisa bagi kita adalah jika kita mengikuti alat baru atau tetap dengan alat yang sudah kita kenal.
Jony
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.