Bagaimana cara debug program mikrokontroler? JTAG diambil, osiloskop adalah beberapa hari / minggu dan program ini di-debug. Ini akan menjadi jawaban yang khas, dan dalam kebanyakan kasus itu akan benar ... Tetapi tidak selalu. Mikrokontroler memecahkan masalah yang sangat berbeda, dan dalam artikel ini kami akan mempertimbangkan apa yang harus dilakukan jika Anda perlu mengembangkan perangkat lunak tingkat rendah yang rumit untuk mengendalikan peralatan listrik apa pun, misalnya, konverter frekuensi untuk motor listrik, konverter muatan baterai DC / DC untuk kereta api, korektor daya, servos dan dll. Peralatan, di mana kiloamperes mengalir dan PWM kilovolt, di mana setiap peralihan kunci inverter IGBT dihitung, di mana waktu respons mikrokontroler ke situasi abnormal diukur dalam mikrodetik, dan peralatan itu sendiri dalam wadah tertutup dipasang dan dioperasikan di suatu tempat di pabrik Yakutia.Jika Anda ingin tahu fitur apa yang diterapkan pada metode debugging ini, selamat datang di cat.

Fitur sistem kontrol debugging

Apa saja fitur dari debugging mikrokontroler (MK) yang melakukan tugas-tugas seperti itu? Pertama, ketika MK bekerja dengan peralatan listrik, itu tidak bisa dihentikan.MK dengan bantuan PWM mengendalikan tombol daya, mengatur banyak nilai di koridornya - arus fase motor, tegangan tautan DC, kecepatan, posisi badan kerja, dll. Jika Anda menghentikan MK saat bekerja di breakpoint, maka dalam kasus terbaik peralatan akan mati karena perlindungan perangkat keras, dan yang terburuk, semuanya akan meledak (jika sakelar daya tetap dihidupkan dalam posisi "satu" atau dengan satu siklus kerja). Oleh karena itu, cara klasik debugging adalah "berjalan melalui langkah-langkah dengan debugger" dalam tugas-tugas tersebut. Jadi Anda hanya dapat menjalankan “modul perangkat lunak yang benar-benar mentah di atas meja sebelum dimasukkan pertama kali pada peralatan nyata.

Kedua, ini adalah kompleksitas perangkat lunak tingkat rendah. Ukuran bagian .text code code program adalah 50-200 Kbytes untuk kode program yang mengontrol perangkat keras secara eksklusif (tanpa driver komunikasi tingkat tinggi, dll.) - ini adalah situasi khas untuk mikrokontroler dari beberapa drive servo industri. Oleh karena itu, mikrokontroler dari seri kontrol motor digunakan untuk tugas-tugas tersebut, yang menggabungkan pada saat yang sama perangkat yang sangat maju, kinerja tinggi, dan ukuran memori yang relatif besar (untuk MK). Sebagai contoh dari impor MK, 32-bit MK Instruments dari Texas Instruments C2000 series, dari chip K1921VK01T NIIET OJSC domestik dapat dikutip. Perangkat lunak untuk MK semacam itu biasanya berisi puluhan atau ratusan ribu bariskode C / C ++ yang dioptimalkan dengan sempurna, yang tidak bisa di-debug dengan “mengedipkan LED”, “printfom di UART” atau dengan mengamati operasi kaki-kaki osiloskop eksternal.

Ketiga, pengontrol sistem kendali drive listrik paling sering berdiri di dalam konverter daya, yang kasusnya ditutup, dan kadang-kadang bahkan disegel. Karena itu, akses melalui JTAG sudah menjadi masalah besar, jika hanya untuk firmware (dengan daya mati). Dan masalah yang lebih serius adalah debugging JTAG dengan power on. Di sini, JTAG yang terisolasi secara galvanis dan anti bising harus digunakan (kami gunakan untuk MK TI JTAG SAURIS dengan isolasi galvanik internal - mahal, tetapi berfungsi).

Keempat, tidak ada sistem operasi!Kita dapat meramalkan bagaimana beberapa orang memiliki ide "yah, karena Anda memiliki tugas yang sulit, letakkan mikrokontroler normal dengan Linux dan tulis aplikasi reguler untuknya, perbarui perangkat lunak dari flash drive". Sistem kontrol peralatan daya adalah sistem waktu-nyata yang sangat sulit. Bukan berarti Linux, bahkan tidak semua sistem operasi real-time khusus cocok untuk tugas-tugas seperti itu. Misalnya, gangguan pada ADC dengan membaca dan rata-rata data analog dapat disebabkan dengan frekuensi hingga 100 kHz. Pada saat yang sama, itu hanya akan berisi selusin atau dua baris kode - pengumpulan data saluran analog, beberapa pemeriksaan perlindungan berkecepatan tinggi dan keluar - semuanya, tidak ada lagi yang bisa dilakukan. Jika Anda menginstruksikan gangguan seperti itu ke beberapa penjadwal tugas OS, maka dengan menjalankannya sendiri akan membutuhkan lebih banyak sumber daya. Belum lagi, khususnya,untuk Linux, alih-alih satu chip MK, Anda harus meletakkan dua lagi di papan - RAM eksternal dan memori flash, mengalokasikan sekelompok kaki kristal berharga pada mereka, menggunakan papan enam-lapisan untuk kabel yang tepat, dapatkan waktu boot MK yang besar (kadang-kadang ketika ada kegagalan daya atau timer pengawas waktu) mulai bekerja sebelum mesin berhenti!), memiliki masalah dengan integritas sistem file, dan banyak lagi.

Nah, fitur kelima - sistem kontrol tingkat rendah untuk drive listrik dan peralatan listrik lainnya (berbeda dengan tugas komunikasi pada antarmuka yang berbeda, PLC, pengontrol semua jenis alarm, remote, dll.) Terutama menerapkan algoritma sistem kontrol otomatis. Yaitu: setengah perangkat lunak terdiri dari berbagai jenis struktur tertutup dengan pengontrol PID, blok saturasi, zona mati, tabel ketergantungan satu sama lain, filter, pengamat, pengatur intensitas, perencana gerakan, dan lainnya. Perhitungan dalam perangkat lunak tersebut dilakukan dengan frekuensi tertentu - katakanlah, pada frekuensi 10 kHz, interupsi dipicu dan menghitung semua blok yang terdaftar, yang bersama-sama membentuk struktur kontrol peralatan yang diperlukan. Dalam algoritma seperti itu, debugging langkah-demi-langkah tidak membantu - paling sering, pada setiap langkah, setiap modul menghasilkan apaapa yang diharapkan darinya - pada kenyataannya, semua filter, regulator, dll ini telah di-debug selama bertahun-tahun dan ada beberapa kejutan di sana.Masalah muncul selama operasi seluruh struktur secara keseluruhan - masing-masing unit bekerja secara individual, dan proses pengaturan yang diinginkan tidak terjadi seperti yang diharapkan . Dan masalahnya ternyata adalah penyesuaian ratusan parameter dan koefisien blok ini, serta dalam struktur yang dirangkum dari mereka - mungkin Anda perlu menambahkan sirkuit stabilisasi baru di suatu tempat, menambahkan blok prediksi, batasan, dll. Oleh karena itu, ini adalah "batu di kebun" lain dari debugging langkah-demi-langkah dan pesan debugging printf: Anda perlu men-debug lebih sering daripada tidak kode program itu sendiri, tetapi struktur kontrol otomatis yang dirakit. Jika seseorang tidak tahu apa itu (struktur), maka di sini adalah struktur paling sederhana dari kontrol vektor tanpa sensor dari motor sinkron:

Setiap kotak kadang-kadang beberapa rumus, dan kadang-kadang modul pada selusin atau dua halaman kode. Modul ini memiliki input / output, serta beberapa variabel status (misalnya, bagian integral dari pengontrol PI dan sebagainya). Mereka yang ingin juga dapat melihat struktur serupa di halaman Wikipedia . Karena sistem kontrol ditutup, operasi salah satu unit yang salah (atau pengaturannya yang salah) menyebabkan ketidakmampuan operasi seluruh struktur. Dan untuk menemukan persis di mana masalahnya - itu adalah tugas lain.

Bagaimana cara men-debug-nya?

Jadi apa yang harus dilakukan, bagaimana cara men-debug-nya? Osiloskop eksternal? Tidak akan membantu Osiloskop, tentu saja, diperlukan untuk debugging beberapa masalah perangkat keras murni, tetapi mereka hanya dapat melihat nilai input dan output dari mikrokontroler, dan ratusan variabel di dalam struktur akan tetap berada di belakang layar. Nah, Anda akan melihat bahwa arus fasa motor tersentak aneh, dan tegangan output inverter anehnya tersentak. Dan mengapa - blok mana di dalam perangkat lunak MK mengarah ke ini (atau motor atau sensor posisi atau sesuatu yang mengarah ke kurva ini) - masih belum jelas.

Model? Ya, ini bantuan yang bagus.Paling sering, pengembangan struktur manajemen yang kompleks dimulai dengan pemodelan. Dalam hal TAU dan dalam bentuk persamaan diferensial, objek kontrol dijelaskan, sistem kontrol yang diusulkan dibangun (seperti pada gambar di atas, misalnya), dan kemudian semua ini direalisasikan ... baik, yang suka apa, tapi standar de facto adalah Simulink Matlab. Di dalamnya, Anda dapat "menggambar" struktur bersama dengan model objek kontrol, menggunakan "longgar" dalam bentuk integrator, adders, fungsi transisi, dll. Anda dapat menggunakan paketnya untuk memodelkan sirkuit listrik, di mana terdapat kunci IGBT siap pakai, motor listrik, resistor, kapasitor, dan lainnya, memberikan pada belas kasihan programmer matlab implementasi yang digambar dalam bentuk persamaan diferensial, dan menggambar struktur kontrol itu sendiri sudah dalam bentuk “lepas-daun” itu sendiri.Dan Anda dapat menulis semua blok yang diperlukan di matlab di C. Metode ini nyaman karena kode program yang di-debug dalam matlab dapat dengan mudah disalin ke mikrokontroler. Biasanya tahap ini selalu mengikuti "gambar", ketika struktur sistem kontrol setelah pekerjaan penelitian tentang pemodelan kurang lebih terbentuk. Tetapi seringkali parameter objek tidak diketahui apriori, atau mereka dikenal sangat tidak akurat - tidak pernah perangkat lunak yang bekerja dalam model mulai bekerja dengan baik pada objek juga. Juga tidak mungkin untuk menempatkan "segalanya" dalam model - transient switching transistor, saturasi dari sirkuit magnetik, arus eddy, kopling kapasitif, parameter mengambang dari suhu dan dari contoh ke instance, gangguan di sana-sini ... Dan kadang-kadang objek pengaturan sangat rumit,bahwa lebih mudah untuk melakukan pengembangan struktur kontrol untuk itu langsung di fasilitas.

, , () - . , , «» – , , - ? ( – , « », ).

Ada juga sejumlah produk yang memungkinkan Anda untuk "menggambar" program secara langsung untuk mikrokontroler. Termasuk Matlab yang sama mampu menghasilkan kode-C untuk merek-merek terkenal MK berdasarkan model di Simulink. Diduga, Anda dapat menggambar dan men-debug struktur yang ditarik dari sistem kontrol pada komputer dalam model, dan kemudian mengunggahnya ke MK - dan Anda selesai, ayo pergi! Dan bahkan lingkungan seperti itu memungkinkan Anda untuk men-debug struktur kontrol yang ditarik tepat di dalam MK, menonton variabel, dll., Dan di situs produk tersebut ada banyak proyek demo untuk sistem paling kompleks yang "diprogram" dengan cara ini. Tetapi karena semua proyek nyata masih diprogram dengan "tangan" untuk beberapa alasan, kita dapat menebak bahwa ada sesuatu yang salah dengan "menggambar". Tetapi di sini bahkan sulit untuk menggambarkan apa sebenarnya, padahal tidak, itu saja. Argumen utama menentang– . Anda menekan tombol di lingkungan yang "bekerja dengan baik" dan berharap generator kode mengerjakan sisanya untuk Anda. Untuk beberapa sistem sederhana, di mana kinerja MK adalah "di belakang mata", jadwal pengembangan sangat ketat, dan tidak ada yang tahu cara memprogram di perusahaan yang memulai proyek ... maka ya, Anda mungkin dapat mencoba "menggambar" program. Tetapi jika itu tidak berfungsi sebagaimana mestinya, atau akan memiliki beberapa kesalahan yang sangat spesifik, maka tidak akan ada lagi kesempatan untuk debug itu. Dan untuk tugas yang kompleks, di mana bahkan ketika pemrograman dengan tangan dengan kinerja MK selalu menjadi masalah, menggambar tidak cocok hanya karena kurangnya sumber daya - bahasa pemrograman apa pun selain tingkat yang lebih tinggi (lebih tinggi dari gambar) menghasilkan kode mesin yang kurang optimal. Dan optimasi tingkat rendah yang akan dilakukan oleh seorang programmer Csistem seperti itu tidak akan dapat melakukan (menghitung blok dari struktur yang sama dengan pencatatan jam kerja yang berbeda, menggunakan nilai cache dari sinus dan cosinus, mengganti fungsi pembagian dengan mengalikan dengan nilai yang disiapkan sebelumnya, atau hal-hal yang sangat rumit sepertiseperti itu , dll.).

Dengan demikian, Anda harus menulis perangkat lunak Anda, dan menulis dalam C. Dan satu atau lain cara, Anda perlu men-debug perangkat lunak Anda, dan itu perlu pada objek. Mungkin, semua orang pada titik ini dalam artikel sudah memahami bahwa struktur kontrol hanya dapat didebug dengan melihat osilogram variabel internal , mis. melihat grafik dari waktu ke waktu, bagaimana variabel ini atau itu dalam perubahan C - katakan, "output dari blok itu, yang kelima dari kiri, secara bersamaan dengan input yang ketiga dari kanan". Mendapatkan gambar seperti ini:

Dan ini hanya bisa dilakukan dengan menggunakan mikrokontroler itu sendiri. Anda tidak bisa hanya mengambil dan meletakkan antarmuka komunikasi cepat eksternal dan mengirim "naik" nilai beberapa variabel, secepat mungkin, dan membangun grafik di sistem tingkat atas. Karena tidak ada antarmuka komunikasi, MK akan memiliki waktu untuk melakukan hal ini dengan frekuensi transien yang diatur terjadi. Dan jika Anda berhasil, maka semua sumber daya MK akan pergi ke pemeliharaan antarmuka komunikasi ini. Oleh karena itu, mereka melakukan ini - mereka merekam bentuk gelombang dalam RAM MKhanya menjadi sebuah array. Biasanya banyak poin yang tidak perlu - ambil momen yang tepat kapan tepatnya untuk menulis data: letakkan pemicu yang tepat di awal perekaman. Dan kemudian Anda dapat melihat apa yang diberikan oleh blok-blok atau sistem kontrol ini pada saat kegagalan, bagaimana ia berkembang, apa yang coba dilakukan MK. Tentu saja, semua variabel tidak dapat langsung diosilasi sekaligus - tetapi dalam praktiknya, dalam pengalaman kami, ada cukup, katakanlah, empat array masing-masing 256 poin - semacam osiloskop empat saluran menggunakan alat MK. Jika kerusakan peralatan lebih dari sekali seminggu, maka debugging bukan masalah - dalam satu percobaan kita melihat 4 variabel ini, di berikutnya kita mengganti setengah dengan yang lain, lihat lagi ... sampai unit yang rusak ditemukan, atau sampai kita menghapus semua yang terjadi pada semua blok dan jangan pergi untuk melihat "rekaman", menggaruk tempat yang berpikir apa ...

Bagaimana cara menembak osilograms seperti itu? Perangkat lunak apa yang bisa melakukan ini? Apa antarmuka komunikasi ini maju? Sebenarnya, Texas Instruments adalah pemimpin dalam produksi mikrokontroler motorcontrol, karena ia melakukan segalanya untuk ini: Code Composer Studio (lingkungan pengembangan mereka) plus MK waktu nyata. Mode real-time adalah ketika melalui JTAG lingkungan pengembangan dapat meminta dan menulis data dalam memori RAM MK tanpa menghentikannya. Bahkan bukan hanya tanpa henti, tetapi tanpa gangguan sedikit pun pada pekerjaannya. Mode ini tersedia di semua seri MK2000, tetapi membutuhkan JTAG yang mahal dan cepat untuk menggunakannya, yang mendukungnya. Tapi selain mode itu sendiri, MK harus memiliki sesuatu yang sesuai di bagian belakang kabel: lingkungan pengembangan Code Composer Studio mampu membangun bentuk gelombang di luar kotak.Selain itu, baik dalam mode paling sederhana, ketika pengguna menetapkan nama variabel C dan melihat perubahan waktu pada grafik, dan lingkungan meminta data dengan frekuensi yang dapat digunakan (biasanya baik, jika Hertz 10), dan dalam mode menampilkan array dalam memori di bentuk gelombang - yaitu apa yang dijelaskan di atas. , , , Code Composer Studio JTAG .Pada saat yang sama, perangkat dapat terus bekerja seolah-olah tidak ada yang terjadi. Alat ini telah berhasil digunakan selama lebih dari sepuluh tahun, dan, pada kenyataannya, ideologi debugging (sepertinya, tapi saya bisa salah) diusulkan oleh Texas. Di semua proyek demo mereka ada modul datalogger (yang mencatat array bentuk gelombang) dan manual menjelaskan cara menggunakannya. Ngomong-ngomong, di sini Anda perlu melempar batu ke taman ARM. Mereka juga memiliki mode real-time, dan pada arsitektur ini ada MK yang dapat mengendalikan motor listrik. Namun, dalam lingkungan pengembangan saya tidak menemukan fungsi grafik, bahkan jika mode real-time didukung. Misalnya, dalam Keil yang dicintai semua orang, bahkan tidak mungkin untuk secara normal mengubah nilai variabel pada MK yang sedang berjalan - itu terus diperbarui,dan nilai baru yang dimasukkan oleh pengguna di jendela dihapus ... Belum lagi grafik di sana. Mungkin seseorang di komentar akan menyarankan opsi kerja? Atau itu "tidak ada yang butuh", dan karena itu tidak berfungsi?

Tetapi ada masalah dengan metode debugging ini, bahkan melalui Code Composer Studio. Dan masalah ini adalah JTAG. Seperti yang dikatakan, konektornya tidak selalu tersedia, dan paling sering pada peralatan berjalan dan tidak tersedia sama sekali. Dan, sejujurnya, tidak nyaman untuk duduk beberapa meter dari megawatt converter, menonton osilogram kerjanya, dan sangat terkonsentrasi dan terkonsentrasi untuk mengitari tombol "stop" mikrokontroler dengan mouse, bagaimana jika jari bergetar di sepanjang jalan? Apakah Anda tahu bagaimana touchpad buggy saat menggunakan PWM yang kuat? Dan jika lingkungannya gagal? Bagaimana dengan JTAG? Semuanya, broads?

Babakh biasa

Selain itu, osilogram dalam lingkungan pengembangan ditampilkan dalam nilai "sebagaimana adanya" dalam C, tanpa penskalaan apa pun, di jendela grafik yang berbeda, tanpa unit pengukuran khusus (ingat bahwa dalam grafik ini 0,342 adalah volt, mereka harus dikalikan dalam pikiran dengan 540 untuk mendapatkan unit fisik, dan di sini 1,2 adalah ampere dengan skala 800A). Dan tidak nyaman dan menakutkan. Namun, tidak semua MK dan lingkungan pengembangan dapat menonton osilogram! Tiba-tiba milikmu bukan Texas? Karena itu, kami memutuskan untuk menemukan cara lain.

Keputusan kami

Sebenarnya, jika kita tidak perlu debugging langkah-demi-langkah, lalu apa masalahnya? Kami mengganti semua yang kami lakukan melalui JTAG dengan antarmuka komunikasi lainnya dan membuat cangkang level atas kami sendiri, yang membangun grafik seperti yang kami inginkan. Untung!

Jadi kami melakukannya. Antarmuka komunikasi kami memilih CAN, protokol - CANopen. Mengapa CAN adalah antarmuka komunikasi industri yang sangat baik, tahan kebisingan, memiliki arbitrase perangkat keras, akses non-destruktif ke bus, konfirmasi perangkat keras dari paket, dan pada saat yang sama - hanya dua kabel dan ground. Ini lebih baik daripada semua RS, dan kurang mengerikan dari Ethernet (yang agak eksotis pada kontrol motor MK). Mengapa canopen Sebenarnya, ada dua protokol umum untuk CAN, ini adalah J1939 ("otomotif") dan CANopen (peralatan mesin, otomatisasi, sensor, dll.). Tidak ada banyak perbedaan di antara mereka, tetapi CANopen tampaknya lebih fleksibel bagi kami, jadi kami menerapkannya di stack (driver) kami sendiri. Siapa yang tidak tahu apa-apa tentang CANopen - fungsi utamanya, seperti banyak protokol untuk MK, adalah untuk menyediakan akses ke kamus objek (daftar variabel dalam C MK) di alamat tertentu. Ini dapat dilakukan dengan dua cara utama:Pesan SDO dari jenis respons permintaan, serta pesan PDO dalam bentuk nilai pengiriman konstan berdasarkan penghitung waktu atau peristiwa (mengatur tingkat atas dari apa yang harus dikirim dan kapan). Ada juga berbagai layanan layanan seperti pesan darurat, pesan tentang keberadaan perangkat di jaringan (detak jantung), dll. Seorang penyihir di jaringan tidak diperlukan: siapa pun yang ingin - mengirim, kepada siapa mereka inginkan - menerima.

Kami membuat tumpukan CANopen tidak hanya untuk MK, tetapi juga untuk komputer dalam bentuk perpustakaan. Dan sudah berdasarkan itu, Windows menulis lingkungan tingkat atas sendiri. Pertama, mereka hanya membuat akses ke variabel kamus objek sehingga memungkinkan untuk melihat dan mengubah pengaturan sistem kontrol (dan ada ratusan dari mereka, omong-omong!), Kemudian mereka membuat grafik dengan secara berkala menanyakan parameter kamus objek melalui jaringan, dan kemudian menambahkan pemuatan bentuk gelombang dari array MK (Selain itu, pilihan apa yang akan osilograf juga dibuat dari objek variabel dari kamus). Kami mendapatkan semuanya yang sama yang memberikan debugging melalui JTAG. Atau tidak? Tidak, karena saya juga memerlukan fungsi memperbarui perangkat lunak via CAN. Terlepas dari kehadiran bootloader CAN di Texas MK, kami memutuskan untuk membuatnya sendiri, karena yang standar tidak CANopen dan dapat mengganggu pengoperasian perangkat lain di jaringan saat kami menjahit satu, serta perangkat dapat mengganggu firmware. Selain itu, ada masalah dengan koreksi kesalahan dan kehilangan pesan (meskipun BISA sangat baik, kadang-kadang crash, dan firmware adalah hal yang sangat penting agar tidak membuat verifikasi atau coba lagi mengirim bagian yang rusak). Oleh karena itu, kami menerapkan "programmer" kami melalui jaringan CAN , tetapi dalam kerangka protokol CANOpen. Sekarang semuanya. Sekarang kami dapat sepenuhnya meninggalkan JTAG, menggunakannya hanya sekali, untuk memprogram MK baru.

Pada saat yang sama, pendekatan ini membuka cakrawala debugging baru yang belum pernah kita lihat sebelumnya. Karena kami membuat lingkungan tingkat atas dengan mata tidak hanya pada programmer, tetapi juga pada “orang biasa,” kami membuat semua parameter nama-nama berbahasa Rusia dan membuat dokumentasi untuk installer untuk setiap parameter (dokumentasi bukan lingkungan, tetapi perangkat, tentu saja). Dan itu bermanfaat - sekarang jika ada masalah dengan drive, Anda tidak perlu "menarik" pengembang- staf layanan pelanggan dalam beberapa kasus dapat secara mandiri mendiagnosis masalah. Sekarang kita bisa mendapatkan email seperti “Drive kami mulai membuat suara aneh kadang-kadang, saya melihat osilogram dari sensor posisi, itulah yang saya lihat (gambar). Saya memeriksa landasan layar, jatuh, saya menyolder dan semuanya bekerja sebagaimana mestinya! " Dan sama sekali tidak perlu pergi ke mana pun atau terbang! "Penemuan" kedua - jika ada masalah, kami meminta pelanggan untuk menghubungkan komputer ke peralatan dan memberikan kontrol desktop jarak jauh melalui Internet - kami meluncurkan lingkungan tingkat atas kami, kami akan mengosongkan semuanya sendiri, kami memperbaiki parameter / firmware / kami katakan itu rusak - untung! Sekali lagi, Anda tidak perlu pergi ke mana pun (yang utama adalah bahwa Internet harus berada di fasilitas, setidaknya melalui jaringan seluler).

Selama bertahun-tahun, program tingkat atas ini memiliki fungsi-fungsi kecil, seperti jamur (proses alami untuk perangkat lunak yang mereka gunakan). Ini termasuk bekerja dengan log kerusakan perangkat, dan menyimpan / memuat nugget semua parameter ke file di komputer, dan mengkonfigurasi panel kontrol perangkat sebagai "panel kontrol", dan memelihara log jaringan ke file, dan mengembalikan lalu lintas jaringan BISA melalui TCP / IP, dan beberapa firmware / parameterisasi otomatis perangkat serupa di jaringan (jika ada puluhan perangkat, maka mem-flash semuanya dengan tangan Anda malas, Anda memerlukan skrip), dll.

Nah, sekarang beberapa iklan. Sekarang ini sudah menjadi alat yang sangat kuat (kami menyebutnya sebagai UniCON), yang dalam beberapa tugas terlihat lebih fungsional daripada perangkat lunak serupa dari merek terkenal untuk mengatur drive dan perangkat mereka. Selain itu, tidak terikat ke perangkat tertentu - Anda dapat mengkonfigurasi setidaknya drive listrik, setidaknya kompor, setidaknya charger - hanya kamus benda yang berubah. Sekarang di perusahaan kami, kami tidak melihat peluang untuk berhasil menyelesaikan proyek kompleks baru tanpa alat debugging CANopen kami. Untuk bekerja dengan UniCON, Anda hanya perlu menanamkan tumpukan CANopen kami di MK, setelah itu MK berubah menjadi laboratorium digital. Kami yakin bahwa semua perusahaan yang membuat sistem kontrol serius pada MK memiliki alat debugging yang serupa. Tetapi kami menawarkan solusi CANopen kami dalam bentuk produk perangkat lunak independen, karena diterapkan secara universal dalam hal independensi dari fungsi perangkat. Saat ini, kami telah mengimplementasikan tumpukan CANopen dengan fungsi lanjutan yang dijelaskan untuk Texas Instruments C2000 MK, mikrokontroler ARM mereka (misalnya, keluarga Concerto) dan untuk K1921VK01T dari NIIET OJSC. Karenanya, jika Anda perlu mengembangkan sistem kontrol untuk penggerak listrik atau objek kontrol kompleks lainnya, kami mengundang Anda untuk bekerja sama.

NB
Dalam komentar, kami menantikan kritik terhadap formulir "Jadi ada pembunuhan - itu semua sama dan gratis." Karena kami telah mencari alat debugging serupa untuk ARM untuk fungsionalitas untuk waktu yang lama, kami bahkan menemukan lingkungan pengembangan yang terkenal.

UPD: Terima kasih atas komentar Indemsys , olekl dan LeonidLeninkami menemukan fungsi pembuatan grafik di lingkungan pengembangan untuk ARM Keil dan STMStudio ketika bekerja melalui SWD. Namun, mereka tidak tahu cara menampilkan array data dari memori MK dalam bentuk grafik, yang hanya diperlukan untuk mengamati proses sistem kontrol yang bergerak cepat (tetapi STMStudio dapat menampilkan grafik dengan waktu pengambilan sampel sekitar 1 ms menggunakan data caching). Yang juga menarik adalah alat NXP FreeMaster - dalam deskripsi dan tujuannya sangat mirip dengan pengembangan UniCON kami, tetapi dengan karakteristiknya sendiri. Selain itu, Segger J-Link memiliki alat tampilan gelombang sendiri .

Metode untuk debugging perangkat lunak mikrokontroler di drive listrik

Fitur sistem kontrol debugging

Bagaimana cara men-debug-nya?

Keputusan kami

More articles: