Interface dengan sensor modern:Driver ADC yang disurvei
Dalam posting terakhir, kami memeriksa bagaimana dalam aplikasi tertanam modern, pengembang harus membuat antarmuka yang memisahkan detail implementasi driver tingkat rendah dari kode aplikasi. Antarmuka ini menyediakan abstraksi arsitektur yang meningkatkan skalabilitas dan portabilitas untuk kode aplikasi dengan membuatnya kurang bergantung pada perangkat keras.
Sekarang kita akan mulai melihat beberapa cara berbeda agar pengembang dapat mengimplementasikan driver ADC berdasarkan teknik yang telah kita bahas dalam 3 teknik desain driver untuk mikrokontroler. Dalam artikel ini, kita akan membahas lebih detail bagaimana kita dapat menggunakan teknik polling dan membahas perbedaan antara driver yang memblokir dan yang tidak memblokir.
Memblokir atau Tidak Memblokir, itulah Pertanyaannya
Saat mengembangkan driver apa pun untuk mikrokontroler, pengembang harus memutuskan apakah driver mereka akan memblokir atau tidak memblokir. Pengemudi yang memblokir pada dasarnya menghentikan eksekusi kode sampai pengemudi menyelesaikan tugasnya. Misalnya, implementasi tipikal untuk printf yang dipetakan ke UART adalah memblokir.
Saat Anda melakukan panggilan seperti:
printf(“Halo Dunia!”);
Seorang pengembang tahu bahwa baris kode apa pun yang mengikuti pernyataan itu tidak akan dieksekusi sampai seluruh "Hello World!" pernyataan telah dicetak UART. "Halo Dunia!" berisi dua belas byte, 96 bit, tetapi jumlah waktu pernyataan akan memblokir tergantung pada baud rate UART. Untuk UART yang dikonfigurasi pada 1 Mbps, Anda akan mengharapkan sekitar 96 mikrodetik. Untuk UART yang dikonfigurasi pada 9600 bps, Anda akan mengharapkan sekitar 10.000 mikrodetik! Itu perbedaan besar tergantung pada bagaimana perangkat keras dikonfigurasi dan dapat mempengaruhi eksekusi program secara dramatis dengan driver UART dikonfigurasi sebagai driver pemblokiran.
Driver non-blocking adalah driver yang tidak menghentikan eksekusi program saat driver menyelesaikan tugasnya. Misalnya, printf dan driver UART dari contoh sebelumnya dapat dikonfigurasi sehingga tidak memblokir dan sebaliknya memungkinkan aplikasi untuk terus mengeksekusi sementara setiap byte ditransmisikan keluar UART. Hal ini dapat membuat aplikasi yang lebih efisien dalam keadaan yang tepat tetapi memerlukan pengaturan tambahan seperti menggunakan interupsi, DMA atau setidaknya buffer transmisi.
Memutuskan cara mendesain driver Anda bergantung pada aplikasi dan perangkat keras Anda. Misalnya, jika UART dikonfigurasi untuk 1 Mbps, menulis driver non-blocking mungkin tidak akan mendapatkan banyak keuntungan dari sudut pandang efisiensi dan sebenarnya dapat menyebabkan lebih banyak masalah daripada perbaikan melalui kompleksitas program tambahan. Namun, jika aplikasi memanggil 9600 bps, di mana kode aplikasi diblokir selama 10 milidetik, memiliki driver non-pemblokiran dapat secara dramatis meningkatkan efisiensi program dan risiko masalah kompleksitas pengaturan waktu tambahan jauh lebih sedikit dan lebih mudah dikelola.
Ikhtisar Driver ADC Tertanam
Penting untuk dicatat bahwa dalam satu blog saya tidak dapat melakukan semua langkah yang diperlukan untuk menulis driver ADC lengkap. Saya dapat dengan mudah menulis makalah dua puluh halaman di atasnya atau memberikan seluruh webinar dan mungkin masih belum mencakup semua detailnya, tetapi setidaknya kita dapat melihat beberapa bagian inti.
Ada beberapa cara untuk mengatur driver ADC, tetapi cara yang saya suka untuk mengaturnya memerlukan tiga komponen:
Pengemudi tingkat rendah
Kode aplikasi
Modul konfigurasi
Driver tingkat rendah mengambil modul konfigurasi selama inisialisasi dan menyiapkan perangkat keras berdasarkan konfigurasi. Driver tingkat rendah menyediakan lapisan abstraksi perangkat keras umum (HAL) yang kemudian dapat digunakan oleh kode aplikasi. Panggilan ADC HAL harus generik sehingga aplikasi tingkat tinggi dapat mengonfigurasi perangkat keras dengan cara apa pun yang diperlukan dan agar dapat digunakan kembali dan dapat diskalakan. Misalnya, beberapa panggilan ADC HAL yang pernah saya gunakan sebelumnya meliputi:
AdcError_t Adc_Init(const AdcConfig_t * Config);
AdcError_t Adc_StartConversion(void);
bool Adc_ConversionComplete(void);
void Adc_RegisterWrite(Alamat const uint32_t, Nilai const uint32_t);
uint32_t Adc_RegisterRead(Alamat uint32_t);
void Adc_CallbackRegister(AdcCallback_t const Function, TYPE (*CallbackFunction)(type));
Tiga API pertama menyediakan kemampuan untuk menginisialisasi perangkat keras ADC, memulai konversi, dan kemudian memeriksa status konversi. Tiga fungsi terakhir dirancang untuk memungkinkan skalabilitas ke perangkat keras tingkat rendah. Misalnya, jika HAL tidak memberikan opsi yang diperlukan oleh aplikasi seperti mengonversi saluran ADC tunggal, HAL dapat diperpanjang menggunakan fungsi Adc_RegisterRead dan Adc_RegisterWrite. Ini memberikan fleksibilitas berdasarkan kebutuhan aplikasi tanpa membuat API yang berlebihan.
Menulis Pemblokiran Driver ADC Sederhana
Kita dapat menulis driver ADC yang sangat sederhana yang berada di atas lapisan perangkat keras. Misalnya, kita dapat membuat fungsi sederhana bernama Adc_Sample yang memulai perangkat keras ADC dan kemudian menyimpan semua hasilnya dalam buffer yang kemudian dapat diakses oleh aplikasi. Buffer yang menyimpan nilai analog menghitung nilai tidak perlu hanya menyimpan satu nilai tetapi dapat menyimpan beberapa nilai yang nantinya dapat dirata-ratakan atau difilter berdasarkan kebutuhan aplikasi. Versi pemblokiran untuk fungsi pengambilan sampel mungkin terlihat seperti berikut:
Seperti yang Anda lihat dalam kode ini, loop while memblokir eksekusi hingga perangkat keras ADC menyelesaikan konversinya dan kemudian menyimpan nilai dalam buffer aplikasi.
Menulis Driver ADC Tanpa Pemblokiran Sederhana
Mengonversi driver pemblokiran ke kode non-pemblokiran cukup sederhana, tetapi akan memerlukan perubahan pada kode aplikasi tingkat yang lebih tinggi. Misalnya, saat ini, jika aplikasi ingin mengambil sampel sensor, pengembang akan memanggil:
Adc_Sample();
Dalam versi non-pemblokiran, pengembang harus memeriksa nilai kembalian dari Adc_Sample untuk melihat apakah sampel sudah selesai dan siap digunakan. Hal ini memungkinkan sampel untuk berjalan di latar belakang, kode aplikasi untuk terus berjalan dengan pembaruan berikut untuk kode driver kami:
Kesimpulan
Seperti yang telah kita lihat di posting ini, ada beberapa cara untuk menulis ADC dan implementasinya dapat memblokir, atau tidak memblokir berdasarkan kebutuhan kita. Driver pemblokiran cenderung lebih sederhana dan kurang lengkap daripada driver non-pemblokiran tetapi mereka bisa menjadi tidak efisien. Driver non-blocking memungkinkan kode lain untuk berjalan saat driver bekerja, tetapi kode aplikasi masih perlu check-in pada status yang dengan sendirinya tidak efisien dalam implementasi polling.
Pada artikel berikutnya dalam seri ini, kita akan membahas bagaimana kita dapat menulis aplikasi yang mengambil sampel sensor melalui periferal ADC yang menggunakan interupsi.
