Bekerja dengan kompleks ban custom Redd

Pada artikel terakhir, kami mulai berkenalan dengan cara bekerja dengan ban standar dan terkenal yang menggunakan kompleks Redd, setelah itu saya berjanji untuk beralih ke cara mendapatkan akses ke ban yang lebih eksotis di dalamnya. Tetapi setelah berbicara dengan beberapa kenalan, saya tiba-tiba menyadari bahwa tidak semua orang membaca artikel yang ditulis tentang kompleks Redd di luar siklus ini. Dan, karenanya, tidak semua orang tahu mengapa ban ini ditambahkan ke kompleks sama sekali. Anda dapat, tentu saja, hanya merujuk ke artikel itu , tetapi bagi saya tampaknya akan lebih tepat untuk menceritakan kembali bagian yang sesuai dengan referensi ke tema siklus khusus ini. Oleh karena itu, hari ini kami akan mempertimbangkan tidak hanya masalah praktis, tetapi juga teoritis tentang ban yang dijual oleh kompleks Redd.

Bagian teoritis yang membosankan

Apa yang akan kita pertimbangkan

Mari kita singkat (sejauh mungkin) membahas beberapa masalah teoritis untuk memahami dengan jelas mengapa semuanya dilakukan dalam kompleks Redd satu atau lain cara. Pertama-tama, tugas utama kompleks ... Anehnya, sebagai bagian dari seri artikel ini, saya belum pernah menulis tentang itu. Ya, dan saya tidak berencana untuk menulis. Faktanya adalah bahwa tugas utama adalah akses remote bersama untuk debugging perangkat keras tertentu (dari mikrokontroler ke sistem prosesor multi-core besar). Reservasi waktu kerja, menyediakan akses fisik melalui saluran keburaman rata-rata (dan bukan hanya ideal) dan kesenangan lainnya. Debugging dapat melalui JTAG atau melalui alat lain yang disediakan oleh lingkungan pengembangan. Sebuah tim besar sedang mengerjakan ini, semuanya sangat menarik di sana, tetapi saya tidak suka birokrasi apa pun, jadi saya tidak ingin menulis tentang topik-topik itu. Mungkin di masa depan, orang lain akan mengisi celah ini ... Sementara itu, saya menulis tentang alat bantu kompleks.

Ya, ya, semua yang telah saya jelaskan selama lebih dari enam bulan hanyalah hal-hal yang dirancang untuk membantu pengembang.

Mengapa di Redd, ban standar yang rumit diimplementasikan

Sangat sering Anda harus mengembangkan peralatan tanpa memiliki akses sendiri. Mari kita lihat contoh spesifik proyek yang memiliki tautan bagus. Di sini, misalnya, adalah helikopter favorit saya. Kami di sini, dan helikopter ada di Swedia. Selain itu, kami memerintahkan pengembangan di musim dingin, ketika helikopter secara fisik tidak dapat melakukan fungsi yang kami terapkan untuk mereka (yaitu, pemupukan tanah di hutan: tanah pada waktu itu berada di bawah salju). Ternyata perangkat yang dipasang di helikopter harus ditiru selama proses debug, dan terbang - secara virtual.

Tapi itu debugging. Saat menguji suatu proyek, emulasi adalah satu-satunya pilihan. Penguji harus memeriksa semuanya dalam jumlah maksimum mode, memilah berbagai kombinasi. Plus, ia harus menciptakan situasi dengan kondisi kritis dan darurat (seperti pekerjaan yang merusak bagi penguji). Bagaimana cara melakukannya pada peralatan nyata? Hanya pada emulator.

Bagaimana komunikasi dengan perangkat modern? Biasanya - melalui bus standar, karena pengembang perangkat cenderung terhubung melalui sesuatu yang sudah diketahui konsumen. Itu hanya Redd dan akan bertindak sebagai emulator banyak perangkat. Bus-busnya terhubung dengan blok yang dikembangkan. Dan unit akan yakin bahwa itu bekerja dengan peralatan nyata, tidak tahu bahwa di ujung ban bukan sekelompok besi, tetapi kompleks Redd, di mana sejumlah emulator berputar.

Saat bekerja dengan peralatan nyata, ban dapat bertindak sebagai penganalisa, logging bekerja dengan perangkat keras nyata untuk menganalisis penerbangan jika terjadi masalah.

Secara umum, harus ada ban sebanyak mungkin, dan set mereka sangat bervariasi. Meskipun, dalam segala hal Anda perlu tahu ukurannya. Nah, kalau saja karena setiap bus membutuhkan biaya dan menghabiskan ruang dalam kasing, dan juga pada konektor. Sekarang mari kita pertimbangkan strategi apa yang paling baik digunakan untuk mengendalikan bus-bus ini secara terprogram.

Siapa yang akan memimpin pengembangan kode untuk Redd

Di perusahaan-perusahaan modern, jam kerja Yang Mulia berada di garis depan. Faktanya adalah bahwa ini adalah sumber daya yang sangat mahal dalam banyak hal (uang, waktu pengembangan, ketersediaan spesialis pada saat tertentu untuk ini dan tugas-tugas lain dari perusahaan, dll.), Jadi jika manajemen dapat menghemat waktu, ia akan melakukannya. Jika mungkin untuk tidak menambahkan pengembang ke tim, mereka tidak akan ditambahkan. Jika dimungkinkan untuk melakukan semuanya dalam waktu yang lebih singkat, mereka akan melumpuhkan pengembang sehingga mereka dapat melakukannya dalam waktu yang lebih singkat.

Oleh karena itu, tidak mungkin mereka memberikan spesialis perorangan untuk menulis emulator. Dan jika mereka melakukannya, mereka akan menjadi programmer biasa yang bekerja di perusahaan yang sama.

Kenapa saya menulis ini. Dalam beberapa artikel, itu dianggap chic ketika beberapa bahasa khusus digunakan untuk tugas-tugas servis ban non-standar. Saya memiliki kesempatan untuk bekerja dengan sesuatu seperti ini. Biarkan saya menggambarkan kesan saya pada contoh hal-hal yang pernah diterbitkan. Di sini, misalnya, https://www.astrosoft.ru/about/clients/bvg-group/case-959/ . Selain itu, bahasa GOST baru-baru ini keluar bahkan GOST. Pendapat saya adalah ini: apa yang diperlukan pada akhir 70-an - awal 80-an, maka sama sekali tidak diperlukan pada akhir kuartal pertama abad XXI. Berikut ini adalah artikel yang luar biasa dari Konstantin Chizhov, di mana hal terpenting dari bahasa itu (grup kontak) dengan sempurna dan hampir gratis diimplementasikan melalui metaprogramming di C ++ http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na- si.html . Artikel ini memeriksa semuanya untuk AVR. Saya melakukan pemeriksaan hebat opsi perpustakaan untuk Cortex M, hasilnya luar biasa juga. Pengoptimal mengemas segala sesuatu sedemikian rupa sehingga pengembangan langsung di assembler tidak akan memberikan keuntungan apa pun. Dan ini tidak hanya berlaku untuk grup kontak, tetapi secara umum untuk semua driver dari mcucpp. Sangat disayangkan bahwa pihak berwenang tidak membiarkan ideologi ini masuk ke dalam RTOS MAX, sehingga hasil penelitian tidak masuk ke publikasi. Tetapi di rumah saya hanya menggunakan perpustakaan ini.

Semua hal lain yang diimplementasikan pada YASTEK juga dikemas dengan sempurna dalam konstruk C ++. Tetapi interaktivitas untuk operator di persimpangan tahun tujuh puluhan dan delapan puluhan tidak. Benar, itu bukan dalam kompiler Pascal, C dan bahasa lainnya. Sebagian besar waktu, kompiler adalah batch dan hanya menghasilkan teks assembler tanpa alat debugging. Ketika membuat remake YASTEC, kami menambahkan operator untuk menampilkan data ke layar dan bahkan debugger interaktif, tetapi bagaimanapun, ini adalah setengah tindakan terhadap latar belakang apa yang terjadi di lingkungan pengembangan yang sudah jadi untuk bahasa pemrograman biasa. Singkatnya, saat-saat ketika ada alasan teknis untuk membuat bahasa khusus YASTEK lama hilang. Saat ini, dalam bahasa pemrograman yang umum, orang dapat mencapai hal yang sama, dan banyak lagi.

Seseorang mungkin mengatakan bahwa bukan ahli C ++ yang menulis kode di sana, tetapi kustomisasi biasa ... Begitulah adanya, tetapi saya telah mencatat bahwa programmer biasa akan menulis kode untuk Redd. Tidak ada gunanya bagi manajemen untuk menjaga spesialis sempit untuk tugas-tugas sesekali. Dan tidak masuk akal bagi spesialis biasa untuk mempelajari bahasa lain.

Dan fitur ekspresif apa lagi yang akan dimiliki? Saat mengembangkan emulator, Anda mungkin membutuhkan hal-hal yang sepenuhnya eksotis. Misalnya, untuk emulator GPS dalam mode interaktif, kami mengontrol menggunakan joystick. Bahasa berorientasi masalah apa yang mendukungnya? Dan fleksibilitas bahasa-bahasa ini masih. Akhirnya, penggunaan kembali kode dalam YESTEK yang dibahas tidak sesuai, tetapi pencarian solusi yang sudah jadi di jaringan ... Bahkan dalam bahasa umum, itu bukan hanya untuk menemukan contoh yang baik , tetapi juga eksotis.

Hal yang sama berlaku untuk kasus seperti itu , yang dengan lancar berubah menjadi kasus seperti itu . Dalam kerangka otomatisasi perusahaan, SIMATIC dengan konfigurasi lanjutan dan sistem pemrogramannya bagus, tetapi untuk proyek kecil itu menciptakan lebih banyak masalah daripada yang dipecahkan, oleh karena itu ia diganti dengan solusi yang lebih universal.

Secara total, kami menyimpulkan bahwa pekerjaan programmer biasa dalam bahasa mereka yang biasa untuk Redd. Untuk tugas-tugas lain - ini dibahas, dan khusus untuk tugas-tugas tambahan yang diselesaikan oleh kompleks Redd, itu normal.

Bagaimana cara mengimplementasikan ban

Tetapi jika kita mengatakan bahwa programmer biasa akan menggunakan ban dalam bahasa mereka yang biasa, maka perpustakaan untuk bekerja dengan bus-bus ini harus sespesifik mungkin. Secara khusus, kalimat itu segera dicatat: "Dan mari kita masukkan mikrokontroler di kompleks, dan programmer akan menulis semuanya pada mereka." Opsi ini lagi membutuhkan spesialis dalam pengontrol ini. Plus, itu membutuhkan sinkronisasi serius antara subsistem. Diputuskan bahwa, jika mungkin, programmer harus bekerja pada prosesor pusat PC yang sudah dikenal. "Tapi bagaimana dengan FPGA?" Anda bertanya. Yah, oops, mungkin semua orang memperhatikan bahwa untuk FPGA saya memilih ideologi "pengembangan minimum pada Verilog, paling tidak asing bagi pemrogram". Di sana Anda tidak dapat melakukannya dengan lebih nyaman. Tapi kami bekerja keras.

Jadi, implementasi ban biasa. Dengan UART, semuanya jelas. Dengan SPI / I ² C, berbagai opsi dipertimbangkan, karena tidak ada standar de facto yang ditetapkan untuk PC. Tetapi ada keinginan untuk melakukan tanpa opsi untuk menulis satu set lengkap: "firmware" dari controller, driver dan perpustakaan. Saya ingin menyiapkan sesuatu. Namun demikian, kami sampai yang terakhir mempertimbangkan opsi dengan mikrokontroler yang menerapkan pada tingkat USB sebagai debugger dari Cypress. Poin ini dimasukkan oleh temuan yang dijelaskan dalam artikel tentang DMA . Tidak mungkin untuk menjamin bandwidth yang diminta dalam TOR jika semua bus dengan aliran data yang sebelumnya tidak dikenal bekerja secara bersamaan. Dan jika tersebar di beberapa pengontrol - kita bersandar pada bandwidth USB 2.0 FS. Karena itu, hanya jembatan FTDI. Satu jembatan adalah satu fungsi, dan USB 2.0 HS menyediakan bandwidth.

Ngomong-ngomong, di bagian terakhir, saya selalu merujuk pada bahasa C ++ yang umum. Faktanya adalah bahwa pada tahap perjalanan hidup saya ini adalah bahasa pemrograman utama saya (meskipun ini tidak selalu terjadi). Tetapi solusi standar, mereka adalah yang standar untuk bekerja dengan sempurna dalam bahasa lain yang umum saat ini, baik itu Python, Java atau yang lainnya. Karena itu, jika seorang spesialis dalam bahasa-bahasa itu dilemparkan ke dalam pertempuran, ia, menggunakan bahasa-bahasa ini, akan melakukan segalanya dengan mudah. Itulah keindahan solusi universal.

Tetapi ada beberapa ban yang konyol untuk meletakkan chip FTDI mahal. Kami akan berbicara tentang bagaimana penerapannya di kompleks.

Seribu hal kecil

Mengapa kompleks Redd memiliki SD-Card yang diaktifkan

Sejumlah perangkat yang sedang dikembangkan memperbarui "firmware" mereka menggunakan kartu SD. Paling sering, "firmware" dituangkan ke kartu dalam bentuk file, setelah itu perangkat mati, dan ketika dihidupkan, ia mendeteksi file pembaruan dan menerapkannya. Baru-baru ini saya mencoba-coba papan baru untuk salah satu printer 3D saya. Di sana, "firmware" Marlin 2.0, setelah beberapa perintah-M (saya tidak ingat kode persisnya), membuka konten SD melalui bus USB, jadi saya bisa menyuntikkan pembaruan tanpa trik. Saya terhubung melalui USB, setelah itu saya tahu saya mematikan / menghidupkan daya (bagaimana melakukannya menggunakan kompleks Redd, kami memeriksa di artikel sebelumnya ), memberi perintah untuk menghubungkan SD-card ke USB, menunggu disk muncul, mengisi "firmware", mematikan power / hidup lagi, dan menunggu . Firmware telah diperbarui. Tapi tidak semuanya begitu indah. Terkadang kartu SD perlu disiapkan terlebih dahulu. Omong-omong, jika Anda menambahkan kurva "firmware" ke printer 3D, opsi ideal yang dijelaskan di atas juga tidak akan berfungsi, dan Anda juga harus menyiapkan kartu terlebih dahulu. Dan ketika berkembang, buatlah "firmware" yang tidak berfungsi - beberapa hal sepele.

Untuk kasus ini, kompleks Redd memiliki kartu SD yang diaktifkan. Pada diagram sirkuit listrik, itu dimasukkan sebagai berikut:



Pada awalnya, kami mencoba menemukan solusi khas yang memungkinkan pengalihan bus SDIO (bukan SPI, yaitu SDIO, perangkat juga dapat bekerja melalui antarmuka ini) melalui FPGA. Ternyata solusi yang indah tidak ada. Bahkan solusi dari pabrikan FPGA sangat kompleks dan tidak terlalu kredibel. Oleh karena itu, disediakan kunci analog yang secara fisik menghubungkan kartu ke konektor eksternal atau ke pembaca sebagai bagian dari Redd. Oleh karena itu, algoritma operasi adalah sebagai berikut: terhubung ke pembaca, menyiapkan file menggunakan OS Linux, terhubung ke perangkat target. Kami menggunakannya di sana.

Karena bekerja dengan sistem file bukan milik hal-hal penting (kami hanya menyiapkan data, sehingga tidak diperlukan kecepatan khusus), diputuskan untuk membuat pembaca berdasarkan mikrokontroler STM32F103. Dukungan untuk SDIO penuh hanya dalam versi maksimum chip ini. Dan karena pengontrol ini memiliki banyak kontak gratis, diputuskan untuk membuat fungsi kecepatan rendah lainnya. Pertimbangkan fragmen diagram sirkuit listrik, dari mana daftar mereka akan terlihat.



Sebenarnya, sinyal yang terkait dengan pengalihan kartu SDIO dan SD disorot dengan warna merah. Kami melanjutkan untuk mempertimbangkan warna lampu latar yang tersisa.

SPI flash drive

Teknik umum kedua untuk memperbarui "firmware" perangkat target adalah dengan flash drive SPI. Saat ini, ini semakin bukan SPI, tetapi Quad-SPI. Prinsipnya sama. Mengisi data, kemudian menghubungkan flash drive ke perangkat dan menyalakannya. Mekanisme Bootstrap akan "menyedot" firmware ke dalam RAM saat startup.

Skema yang sama diterapkan di sini - dengan switch analog:



Nah, garis yang terkait dengan bekerja dengan flash drive disorot dalam warna hijau.

Relai Status Solid Rendah

Secara berkala, tugas muncul untuk mensimulasikan penekanan tombol pada perangkat. Situasi khas: penguji perlu memeriksa pengoperasian menu perangkat target. Tidak, sekali Anda bisa membahas semua poin, tetapi jika pengembang melakukan perubahan? Untuk mengotomatiskan proses, lebih baik jika tombol untuk menavigasi menu akan dibuat secara otomatis (tangkapan layar dapat diambil baik oleh OS pada perangkat target atau dengan memindai bus yang menuju layar menggunakan sniffer ke FPGA). Nah, ada banyak tugas lain di mana Anda perlu mensimulasikan pemrograman tombol tekan. Untuk ini, relay solid-state ditambahkan ke sirkuit:



... dan garis kontrol mereka disorot dengan warna biru.

Mengkonfigurasi Jembatan USB-SPI / I ² C

Dalam artikel sebelumnya, saya mencatat bahwa jembatan FTDI di mana SPI dan I ² C bus diimplementasikan memiliki kaki kontrol CFG0 dan CFG1. Secara umum, kemungkinan besar, tidak ada yang perlu mengubah nilai default (semua nol), tetapi jika perlu, garis yang mengontrol sinyal ini juga meninggalkan pengontrol STM32 yang dipermasalahkan dan disorot dengan warna ungu.

Reset perangkat USB

Selama pengembangan sistem, diputuskan bahwa, secara teoritis, perangkat dapat "membeku". Misalnya, jembatan FTDI dari seri pertama memiliki sifat "beku" dengan "tanah" yang tidak stabil. Ya, itu lebih dari sepuluh tahun yang lalu. Ya, di dalam kompleks, bumi sangat stabil, karena jembatan berada di gedung yang sama dengan komputer. Tapi tiba-tiba saja. Secara umum, dalam Kerangka Acuan diletakkan kemungkinan mengatur ulang salah satu perangkat. Permintaan yang sesuai dihasilkan oleh pengontrol STM32 yang sama dan disorot dengan warna kuning.

Akses terprogram ke pengontrol STM32

Seperti yang Anda lihat, sebagian besar perangkat yang dijelaskan di atas tidak standar. Lebih tepatnya, kebanyakan dari mereka dapat diklasifikasikan sebagai GPIO, tetapi tidak ada standar de facto untuk itu. Bagian tersulit dari perangkat adalah pembaca kartu SD. Oleh karena itu, diputuskan untuk mengimplementasikan fungsionalitas SD Reader pada pengontrol STM32 (untungnya, lingkungan STM Cube MX memungkinkan Anda untuk melakukan ini dengan menulis hanya beberapa baris kode Anda sendiri), dan mengimplementasikan sisa fungsi sebagai permintaan Vendor ke Perangkat Penyimpanan Massal yang mendasari pembaca. Tetapi seperti yang diputuskan beberapa artikel yang lalu, narasi besar tidak nyaman untuk dibaca. Oleh karena itu, prinsip-prinsip mengirim perintah ke Mass Storage Device dari Linux dan contoh-contoh akses terprogram ke perangkat yang dihasilkan akan diperiksa pada waktu berikutnya.