Akses ke Redd Ban di Jembatan FTDI

Kami telah menyelesaikan blok teori besar yang menunjukkan cara membangun subsistem FPGA untuk kompleks Redd; bagaimana mengatur komunikasi antara FPGA dan prosesor pusat kompleks; betapa mudahnya menyimpan aliran data berkecepatan tinggi dalam RAM, yang terhubung langsung ke FPGA, untuk transfer santai mereka selanjutnya ke prosesor pusat (atau sebaliknya, untuk memasukkan data ke dalam RAM ini untuk output cepat berikutnya ke saluran). Kami meninjau teknik penelusuran prosesor Nios II. Kami dapat mengoptimalkan kinerja sistem prosesor berdasarkan Nios II sehingga pekerjaan berjalan seefisien mungkin. Secara umum, kami telah mempelajari semua teori minimum yang diperlukan, dan sudah saatnya untuk beralih ke praktik dengan merancang perangkat yang tidak terlalu rumit, tetapi praktis berguna ... Tapi ada satu TETAPI.

Dari komentar di artikel, saya perhatikan bahwa beberapa pembaca percaya bahwa Redd dan FPGA seperti Lenin dan Partai. Bahwa mereka terkait erat. Faktanya, ini tidak benar sama sekali. Saya hanya ingin memulai percakapan tentang kompleks Redd dengan sesuatu yang menarik, tetapi apa yang bisa lebih menarik daripada FPGA? Nah, dan memulai percakapan, menginterupsi sekilas itu bodoh. Dan akhirnya, blok logis besar selesai. Dan untuk menunjukkan bahwa FPGA jauh dari keseluruhan Redd, saya mengusulkan untuk membuat sekitar tiga artikel tentang hal-hal yang tidak terkait dengannya. Nah, dan setelah menyelesaikan blok ini, sudah pergi ke praktik FPGA.

Pendahuluan

Yang paling menakjubkan adalah begitu saya memutuskan untuk menyimpang dari topik lain, bos yang baik melemparkan saya ke dalam pertempuran yang sulit pada sebuah proyek di mana pekerjaan sedang berlangsung dengan bahasa VHDL dan Xilinx FPGA. Pertama, itu sebabnya untuk waktu yang lama saya tidak mengambil pena pada umumnya, dan kedua, jelas bahwa persiapan artikel praktis memerlukan sejumlah besar percobaan. Agak sulit untuk berurusan dengan VHDL / Verilog dan Xilinx / Altera secara bersamaan. Jadi, istirahat dalam cerita tentang FPGA harus dilakukan.

Jadi Pada artikel pertama dari seri ini, kami telah memeriksa diagram struktural kompleks Redd. Mari kita lakukan sekali lagi.



Dalam artikel hari ini, para ahli Linux tidak mungkin menemukan banyak informasi yang berharga, tetapi layak untuk melihat gambar secara dangkal. Mereka yang, seperti saya, terbiasa bekerja dari Windows, akan menemukan daftar teknik siap pakai yang memungkinkan Anda untuk bekerja dengan kompleks. Secara umum, artikel ini akan membawa keterampilan mereka dan kelompok pembaca lain ke penyebut yang sama.

Blok UART (Port Serial)

Dalam diagram blok, kita melihat pengontrol FT4232 yang mengimplementasikan 4 port serial (UART):



Tetapi jika Anda berbicara sedikit lebih global, maka kompleks Redd tidak memiliki empat, tetapi enam port serial. Hanya disebutkan empat memiliki tingkat CMOS, dan dua lagi disolder pada motherboard, karena kompleksnya didasarkan pada PC biasa.



Dengan demikian, mereka memiliki level - RS232 (plus atau minus 12 volt). Port RS232 - semuanya jelas dengan mereka, mereka ditampilkan dalam bentuk dua konektor DB-9 standar,



dan di mana mencari garis dengan level CMOS? Secara umum - pada konektor umum. Pinout-nya ditunjukkan dalam diagram sirkuit listrik. Ada, antara lain, kontak yang terkait dengan UART.



Secara eksternal, konektor ini terlihat sebagai berikut:



Cara menggunakannya tergantung pada tugas. Anda dapat memanfaatkan untuk menghubungkan setiap perangkat. Pendekatan ini bermanfaat jika seseorang menggunakan kompleks Redd untuk menguji perangkat yang diproduksi secara berkala dari jenis yang sama. Namun tujuan utama dari kompleks ini masih men-debug peralatan yang sedang dikembangkan. Dan dalam hal ini, lebih mudah untuk terhubung dengannya secara sementara. Pola sementara ini terlihat di screensaver untuk semua artikel: Kabel Aruino dimasukkan langsung ke konektor. Tentu saja, menghitung kontak masih menyenangkan, dan jika mereka secara tidak sengaja terbang, sangat sulit untuk mengembalikan switching sehingga lebih mudah untuk menyambungkan kembali semuanya dari awal; Oleh karena itu, untuk memudahkan kehidupan, ada papan riser yang dapat Anda hubungkan setidaknya dengan bantuan konektor dua baris, setidaknya dengan kabel Arduino yang sama.

Akses Perangkat Lunak UART

Port serial adalah elemen yang mapan dan terstandarisasi, oleh karena itu, bekerja dengannya tidak melalui beberapa pustaka FTDI tertentu, tetapi melalui sarana standar. Mari kita lihat bagaimana alat ini terlihat di Linux.

Nama port

Dari sejumlah artikel dan forum di jaringan, dapat disimpulkan bahwa nama port yang disediakan oleh USB-Serial adapter berada dalam format / dev / ttyUSB0, / dev / ttyUSB1, dan seterusnya. Di Linux, semua perangkat dapat dilihat menggunakan perintah yang sama seperti untuk melihat direktori biasa (pada kenyataannya, perangkat adalah file yang sama). Mari kita lihat nama apa yang ada di sistem kita. Kami memberikan perintah:
ls / dev /



Nama-nama yang menarik bagi kami disorot dengan warna merah. Sesuatu yang banyak dari mereka. Port mana yang sesuai dengan apa? Mereka yang fasih di Linux tahu ribuan mantra untuk semua kesempatan. Tetapi bagi mereka yang masih bekerja dengan Windows 3.1 (yah, sejajar dengan wanita tua RT-11 yang saat itu cukup riang), masih sulit untuk diingat, seiring bertambahnya usia yang baru lebih sulit untuk diingat. Karena itu, lebih mudah untuk menemukan semuanya setiap waktu, menggunakan cara-cara sederhana. Dan saya menyoroti pintu masuk ke jalan sederhana ini dengan bingkai hijau. Serial subdirektori bersyarat. Sekarang kita melihat / dev / namespace. Dan mari kita lihat ruang / dev / serial :



Hebat! Kami mempelajari hierarki, lihat ruang / dev / serial / by-id . Melihat ke depan, saya akan mengatakan bahwa untuk tampilan yang benar, Anda perlu menggunakan perintah ls dengan sakelar -l (terima kasih kepada bos saya untuk klarifikasi). Yaitu, kami memberikan perintah:
ls –l / dev / serial / by-id



Di satu sisi, semuanya baik-baik saja. Sekarang kita tahu nama mana di ruang / dev / ttyUSBX yang sesuai dengan perangkat mana. Secara khusus, port yang dikelola oleh jembatan FT4232 (Quad) memiliki nama dari ttyUSB3 hingga ttyUSB6 . Tetapi di sisi lain, ketika mempertimbangkan situs ini, saya menyadari bahwa di Paris di kamar berat dan ukuran harus ada ruang di mana standar kekacauan ditempatkan ... Karena entah bagaimana Anda harus dapat mengukur nilainya. Baiklah, katakanlah kekurangan port / dev / ttyUSB0 dan / dev / ttyUSB1 dapat dengan mudah dijelaskan. Tetapi bagaimana menjelaskan bahwa port “asli” berdasarkan keturunan jembatan FTDI yang terinstal diberi nomor dari tiga teratas, dan pengontrol Prolific pihak ketiga, yang dimasukkan untuk proyek tertentu, mengambil port nomor 2? Bagaimana seseorang bisa bekerja di lingkungan seperti itu? Besok seseorang akan memasukkan pengontrol lain ke kompleks (karena kompleks memungkinkan kelompok pengembang yang berbeda untuk bekerja dengan peralatan yang berbeda pada saat yang sama), dan port-port bergerak kembali. Port apa yang perlu kita daftarkan di file konfigurasi untuk aplikasi yang berfungsi?

Ternyata semuanya tidak begitu buruk. Pertama, nama kuning / dev / ttyUSB3 dan nama biru / dev / serial / by-id / usb-FTDI_Quad_RS232-HS-if00-port0 adalah dua alias dari perangkat yang sama. Dan opsi kedua juga bisa disajikan sebagai nama port, tetapi sudah lebih permanen daripada yang pertama. Benar, dalam hal ini, semuanya agak buruk. Kontroler eksternal berbasis FT4232 dapat dicolokkan ke dalam kompleks, dan itu sudah perlu untuk menangani penomoran mereka. Dan di sini "kedua" datang untuk membantu kami. Yakni, konvensi penamaan alternatif lain. Kita ingat bahwa direktori / dev / serial tidak hanya berisi subdirektori / by-id , tetapi juga subdirektori / by-path . Kami memeriksa isinya (terletak di bagian bawah gambar berikutnya, di bawah garis merah).



Semuanya di sini terkait dengan arsitektur fisik. Dan saya sudah mengatakan berkali-kali bahwa semua pengontrol di dalam kompleks disolder ke papan, sehingga hierarki internal tidak akan berubah. Dengan demikian, nama /dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.0-port0 akan menjadi yang paling sulit.

Secara total, kami memiliki cara berikut untuk mencari nama port (harus dilakukan sekali, hasil untuk instance Anda dari kompleks dapat dimasukkan ke dalam tabel dan digunakan terus-menerus):

1. Keluarkan perintah ls –l / dev / serial / by-id .
2. Keluarkan perintah ls –l / dev / serial / by-path .
3. Dari hasil poin 1, cari nama port yang sesuai dengan port yang diperlukan dari jembatan yang diperlukan. Temukan nama port yang sama di hasil paragraf 2. Ambil nama fisik yang sesuai dengan paragraf ini.

Untuk port yang dilayani oleh pengontrol di motherboard, semuanya sedikit lebih rumit. Di sini Anda tidak dapat membuat jalan dari perintah paling sederhana " ls / dev ", tetapi Anda harus mengingat sesuatu (baik, atau setidaknya ingat bahwa Anda dapat menghubungi di sini untuk bantuan). Di mana-mana dikatakan bahwa nama port yang umum adalah ttyS0-ttyS3 . Pertanyaannya tetap, pada nama apa port nyata dalam sistem kita? Saya menemukan mantra berikut untuk menjawab pertanyaan ini:
ls / sys / class / tty / * / perangkat / driver

Berikut ini respons sistem terhadapnya:



Ternyata kita perlu menggunakan nama / dev / ttyS2 dan / dev / ttyS3 . Kenapa - saya tidak tahu. Tetapi satu hal yang menyenangkan: di sini tidak ada perubahan khusus yang diramalkan, oleh karena itu konstanta ini dapat diingat dan digunakan tanpa rasa takut bahwa mereka akan berubah.

Pengembangan kode

Saat mengembangkan, Anda harus menggunakan Panduan Pemrograman Serial yang luar biasa untuk Sistem Operasi POSIX (tautan langsung pertama yang Anda dapatkan adalah https://www.cmrr.umn.edu/~strupp/serial.html , tetapi tidak ada yang tahu berapa lama itu akan hidup). Sangat penting bahwa ini memberi tahu cara bekerja dengan set sinyal penuh, karena port di kompleks sepenuhnya diimplementasikan. Benar, hari ini kita hanya akan menggunakan garis Tx dan Rx.

Biasanya saya memberikan hasil osilogram, tetapi sekarang ternyata saya dalam kondisi yang hampir nyata: kompleks ini terletak di tempat yang tidak terjangkau oleh tangan saya, jadi saya tidak dapat menghubungkan probe osiloskop. Untuk melihat setidaknya beberapa hasil, atas permintaan saya, rekan menambahkan beberapa posting ke kompleks sesuai dengan skema klasik berikut:



Mari kita coba transfer dari satu port ke port lainnya. Dalam kasus kami, port /dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.2-port0 dan /dev/serial/by-path/pci-0000:00:15.0- terhubung usb-0: 6.5: 1.3-port0 .

Kita sudah membahas bagaimana program untuk prosesor pusat Redd ditulis dalam salah satu artikel sebelumnya , jadi hari ini kita akan membatasi diri kita hanya pada teks program yang ditulis di bawah kesan Panduan Pemrograman Serial untuk dokumen Sistem Operasi POSIX . Sebenarnya, hal menarik utama yang ada adalah mengalihkan strategi penerimaan ke pembacaan non-blocking, sisanya sepele. Namun demikian, mengingat kekacauan dalam contoh pada jaringan pada topik ini, lebih baik untuk memiliki sampel sepele di tangan (akan ditunjukkan nanti bahwa bahkan contoh berdasarkan dokumen yang luar biasa ini tidak bekerja 100%, kode di bawah ini berbeda dari kanon yang dijelaskan di dalamnya dalam satu baris, tetapi lebih pada kanon di bawah).


Jalankan - kami mendapatkan hasil yang diprediksi:

 hello from ReddUARTTest! 14 read operations Read Data: FF FE FD FB 

Dapat dilihat bahwa 4 byte membutuhkan 14 upaya, yaitu pembacaan tidak menghalangi. Terkadang sistem mengembalikan status "tidak ada data baru", dan program tersebut tertidur selama satu milidetik.

Secara umum, semuanya baik-baik saja, tetapi tanpa osiloskop, saya tidak dapat memastikan bahwa dua port berdasarkan chip yang sama benar-benar mengatur kecepatan. Saya sudah melompat pada kenyataan bahwa kecepatannya sama (untuk itu dia punya satu controller), tetapi bukan yang saya pesan. Setidaknya mari kita periksa apakah setidaknya dikontrol. Untuk melakukan ini, saya akan mengatur kecepatan port penerima menjadi dua kali lipat dari port transmisi. Dan mengetahui fisika dari proses transfer data, Anda dapat memprediksi bagaimana data ini terdistorsi selama penerimaan. Mari kita lihat transfer byte 0xff dalam bentuk grafis. S - bit mulai (selalu ada nol) bit, bit P - stop (selalu ada satu), 0-7 - bit data (untuk 0xFF konstan - semua unit).



Sekarang mari kita overlay tampilan ini dengan tampilan bagaimana semuanya akan dilihat oleh penerima yang beroperasi pada kecepatan dua kali lipat:



Bagus Nilai "1111 1110" harus diterima (data sedikit lebih maju, yaitu 0xFE. Bagian kedua dari nilai yang ditransmisikan tidak mempengaruhi penerimaan, karena unit sesuai dengan keheningan di telepon. Artinya, kami mentransmisikan satu byte, satu byte juga akan datang.

Kami akan membuat grafik yang sama untuk verifikasi, yang akan sesuai dengan nilai 0xFE yang dikirimkan:



Harapkan nilai "1111 1000" atau 0xF8. Baiklah, mari kita verifikasi apa yang diharapkan dengan nilai 0xFD yang diteruskan:



Kami mendapatkan nilai 0xE6. Nah, untuk nilai yang ditransmisikan 0xFB, kami mendapatkan 0x9E yang diterima (Anda dapat memplot grafik dan melihatnya sendiri). Hebat! Kami mengubah satu baris tunggal dalam aplikasi pengujian, menggantikan kecepatan 9600 dengan 19200:

  int fd2 = OpenUART("/dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.2-port0", 19200); 

Kami memulai dan mendapatkan hasil kerja ini:

 hello from ReddUARTTest! 9 read operations Read Data: FE F8 E6 9E 

By the way, saya tidak sia-sia melakukan pemeriksaan ini. Pada awalnya saya menggunakan fungsi pengaturan kecepatan lainnya (pasangan cfsetispeed / cfsetospeed), dan mereka tidak berfungsi! Berkat tes ini, masalah telah diidentifikasi dan diselesaikan tepat waktu. Saat bekerja dengan peralatan, Anda tidak akan pernah bisa memercayai intuisi. Semuanya harus diperiksa!

Manajemen saluran listrik 220 volt

Secara umum, saluran listrik 220 volt tidak terkait dengan topik artikel (jembatan FTDI), tetapi mereka terkait dengan topik bagian ini (port serial). Mari kita lihat mereka.



Ketika kami mencantumkan port, kami melihat nama ini:



Ini adalah port serial virtual. Ini sangat virtual sehingga tidak masalah parameter apa pun yang dimilikinya (kecepatan port, jumlah bit, format paritas, dll.). Tidak peduli parameter apa pun yang telah ia atur, ia masih dapat menangani perintah dengan sempurna. Dan tim inilah yang mengendalikan outlet listrik di kompleks.



Ketika mengembangkan sistem perintah, diputuskan untuk meninggalkan antarmuka perintah yang kompleks. Manajemen membutuhkan satu byte, tanpa membingkai string dan embel-embel lainnya, meskipun byte bersifat tekstual (sehingga dapat dengan mudah ditransfer dari terminal saat debugging). Keringkasan ini mudah dijelaskan: antarmuka string memungkinkan Anda menangani gangguan dalam saluran UART yang tidak aman. Tetapi dalam kasus kami, secara fisik, pekerjaan berjalan melalui saluran USB, yang dilindungi oleh kode kontrol siklik. Memproses aliran balik memerlukan penulisan kode tambahan atau buffer yang terus-menerus disiram, yang tidak selalu nyaman. Itu sebabnya tidak ada tolok ukur untuk string, tidak ada jawaban. Diyakini bahwa salurannya stabil. Jika Anda menginginkan respons, Anda dapat secara eksplisit memintanya. Artinya, kinerja blok selalu dapat dengan mudah diperiksa dengan mengirim byte tambahan setelah perintah.

Pertimbangkan perintah yang dapat dikirim:

Perintah '?' (tanda tanya) adalah satu-satunya yang mengembalikan respons. Menanggapi itu, 3 byte selalu datang, masing-masing sesuai dengan keadaan salah satu outlet. Sebenarnya, negara sesuai dengan perintah. Misalnya, 'abc' - ketiga outlet sekarang dimatikan, 'Abc' - yang pertama dinyalakan, yang kedua dan ketiga mati, dll.

Untuk percobaan dengan subsistem ini, saya sarankan tidak menulis program khusus (tidak berbeda dari yang diberikan sebelumnya, hanya data yang dikirim ke port akan berbeda), tetapi menggunakan alat OS dan bermain secara interaktif dengan soket.

Setelah banyak percobaan dengan melacak port melalui perintah cat dan mengirim perintah dalam jendela paralel menggunakan program echo, saya menyadari bahwa untuk beberapa alasan saya tidak dapat mencapai hasil dalam sepasang terminal ssh berbasis dempul (bahkan bermain dengan port yang hanya memiliki bahwa dia bereksperimen dengan sempurna dengan programnya). Karena itu, saya harus menginstal program minicom standar. Biarkan saya mengingatkan Anda perintah instalasi:
sudo apt-get minicom

Selanjutnya, jalankan dengan perintah:
minicom –D / dev / ttyACM0

Nama port pendek, karena dengan eksperimen manual itu paling mudah untuk masuk. Dalam pekerjaan perangkat lunak, seperti biasa, lebih baik menggunakan nama yang terkait dengan hierarki perangkat keras. Sekali lagi, saya perhatikan bahwa saya tidak mengkonfigurasi parameter port lain karena ini virtual. Ini akan bekerja dengan pengaturan apa pun.

Kemudian kami menekan tanda tanya di terminal dan langsung (tanpa umpan baris) kami mendapat respons



Ini berarti bahwa semua outlet saat ini dimatikan. Katakanlah kita ingin menghidupkan outlet kedua. Tekan ibukota 'B'. Tidak ada reaksi di layar. Tekan '?' Sekali lagi, kami mendapat baris baru dengan jawabannya:



Semuanya berfungsi. Jangan lupa mematikan 220 volt (perintah 'b'). Anda dapat keluar dari terminal dengan menekan ctrl + A, lalu X. Eksperimen selesai.

Ban SPI dan I ² C

Bus SPI (yang juga dapat bekerja dalam mode Quad-SPI) dan I ² C diimplementasikan dalam kombinasi dengan jembatan universal. Artinya, secara umum, kompleks memiliki dua jembatan, yang masing-masing dapat diaktifkan baik dalam mode SPI atau di I ² C. Dalam diagram struktural, bagian yang sesuai terlihat seperti ini:



Inti dari menyalakan bus akhir terlihat dari diagram sirkuit listrik. Pertimbangkan hanya satu dari dua pengontrol:



Dengan demikian, bus SPI dan I ² C tidak bersinggungan dengan cara apa pun. Pembatasan penggunaan bersama mereka hanya ditentukan oleh pembatasan yang diberlakukan oleh FTDI pada pengontrol FT4222H. Sayangnya, dokumentasi menyatakan bahwa hanya satu antarmuka yang dapat aktif pada satu waktu:



Cara mengelola baris CFG1_0..CFG1_1 dan CFG2_0..CFG2_1, kami akan bertemu di artikel berikutnya. Sekarang kami percaya bahwa mereka semua dibatalkan.

Secara umum, pekerjaan dengan controller dijelaskan dengan sangat baik dalam dokumen FT4222H USB2.0 TO QUADSPI / I2C BRIDGE IC , oleh karena itu kami tidak akan mempertimbangkan fitur mode kontrol pengendali. Semuanya sangat jelas dari dokumen tersebut.

Sedangkan untuk dukungan perangkat lunak, deskripsinya dapat ditemukan dalam dokumen yang tak kalah luar biasa. Kami telah bekerja dengan jembatan FTDI dua kali: di paruh kedua artikel ini dan di paruh kedua ini . Oleh karena itu, membandingkan dokumen ini dengan artikel-artikel ini, Anda dapat dengan cepat mengetahuinya dan mulai menulis kode Anda sendiri. Biarkan saya tunjukkan kode referensi yang mengirim data ke bus SPI, tanpa memikirkan detail implementasinya, sepertinya sudah dianalisis dengan FT2232.

Bagian Bus SPI

Pengembang kode untuk mikrokontroler sering menggunakan bus SPI sebagai generator frekuensi yang telah ditentukan. Memang, pulsa yang dihasilkan murni secara terprogram melalui jalur GPIO tergantung pada banyak faktor. Pertama, percabangan, memutar loop, membutuhkan siklus prosesor. Kedua, gangguan, DMA dan faktor-faktor lain yang tidak terduga dapat mengganggu prosesor. SPI lebih atau kurang stabil, tahu diri Anda berhasil memasukkan byte ke buffer. Aplikasi khas dari blok SPI, yang tidak memiliki hubungan langsung dengan SPI itu sendiri, adalah kontrol RGB LEDs, yang keakuratan pengaturan durasi pulsa sangat penting.

Sayangnya, ini tidak dapat diterima untuk jembatan FTDI. Fragmen kode di atas akan menghasilkan pulsa ini di bus:



Dalam hal ini, aturan operasi SPI tidak dilanggar, dari sudut pandang bus ini, semuanya berfungsi dengan benar. Perlu diingat bahwa solusi khusus yang biasa pada pengendali tidak akan berfungsi di sini. Benar, kompleks ini memiliki banyak konektor USB gratis. Semua blok non-standar dapat dikembangkan secara terpisah dan terhubung dengannya.

Bagian ban I ² C

Satu-satunya hal yang masuk akal adalah untuk menunjukkan tidak adanya resistor pull-up untuk bus I ² C di sisi kompleks. Tapi ini normal: di sisi perangkat yang berfungsi, masih ada lift. Saat ini, pull-up dapat dilakukan ke tegangan apa pun, sehingga masuk akal jika diatur pada perangkat target.

Kesimpulan

Hari ini kami memperoleh keterampilan praktis dalam bekerja dengan ban yang diterapkan oleh jembatan FTDI. Secara umum, bekerja dengan mereka adalah standar, hanya saja semua pengetahuan dirangkum dalam satu artikel, sehingga tidak mencari mereka sedikit demi sedikit. Lain kali kita akan mempertimbangkan modul yang mengontrol perangkat non-standar, yang diimplementasikan berdasarkan pengontrol STM32. Dalam diagram struktural, bagian ini sesuai dengan itu:



Tapi sungguh, semuanya sedikit lebih menarik di sana ...