Pendahuluan
Saya sudah lama ingin belajar teknik pemrograman blok UDB di pengendali PSCC Cypress, tetapi entah bagaimana semua tangan saya tidak mencapai. Maka, muncul masalah yang bisa dilakukan. Memahami materi dari jaringan, saya menyadari bahwa rekomendasi praktis untuk bekerja dengan UDB terbatas pada berbagai variasi penghitung dan PWM. Untuk beberapa alasan, semua penulis membuat variasi mereka dari dua contoh kanonik ini, sehingga deskripsi tentang sesuatu yang lain mungkin menarik bagi pembaca.
Jadi Ada masalah untuk mengelola garis panjang LED RGB WS2812B secara dinamis. Pendekatan klasik untuk masalah ini diketahui. Anda dapat mengambil Arduino yang sepele, tetapi di sana output berjalan secara terprogram, jadi ketika data sedang di-output, yang lainnya idle, jika tidak diagram waktu akan gagal. Anda dapat mengambil STM32 dan mengeluarkan data baik melalui DMA ke PWM, atau melalui DMA ke SPI. Teknik dikenal. Saya bahkan, pada suatu waktu, secara pribadi mengendalikan garis enam belas dioda melalui SPI. Tapi overhead bagus. Satu bit data dalam LED menempati 8 bit dalam memori untuk kasus PWM dan dari 3 hingga 4 bit (tergantung pada kesejukan PLL pada pengontrol) untuk SPI. Meskipun ada beberapa LED, ini tidak menakutkan, tetapi jika ada, katakanlah, beberapa ratus, maka 200 * 24 = 4800 bit = 600 byte data yang berguna harus secara fisik disimpan dalam buffer lebih dari 4 kilobyte untuk opsi PWM atau lebih dari 2 kilobyte untuk SPI- opsi. Untuk indikasi buffer yang dinamis, harus ada beberapa, dan STM32F103 memiliki RAM untuk semua hal sekitar 20 kilobyte. Bukannya kami telah mengalami tugas yang tidak dapat direalisasi, tetapi alasan untuk memeriksa apakah ini dapat diimplementasikan pada PSoC tanpa perlu menghabiskan RAM tambahan, cukup signifikan.
Referensi teori
Pertama, mari kita cari tahu binatang seperti apa UDB itu dan bagaimana mereka bekerja dengannya. Film instruksional yang luar biasa dari produsen controller akan membantu dalam hal ini.
Mulai menonton
dari sini , dan kemudian di akhir setiap video akan ada tautan ke seri berikutnya. Langkah demi langkah, Anda akan memperoleh pengetahuan dasar dan mempertimbangkan contoh kanonik “kontra”. Nah, dan sistem kontrol lampu lalu lintas.
Hampir sama, tetapi potong kecil-kecil, bisa Anda
lihat di sini . Video saya tidak diputar, tetapi dapat diunduh dan dilihat secara lokal. Antara lain, ada juga contoh kanonik dari implementasi PWM.
Solusi jadi
Agar tidak menemukan kembali roda (dan sebaliknya - untuk mempelajari metodologi dari pengalaman orang lain), saya mencari-cari di jaringan untuk mencari solusi yang sudah jadi untuk mengendalikan LED RGB. Solusi paling populer adalah StripLightLib.cylib. Tetapi selama bertahun-tahun sekarang ia memiliki rencana untuk menambahkan dukungan Tambahkan DMA. Tetapi saya ingin mencoba solusi yang tidak tergantung pada prosesor pusat. Saya ingin memulai proses dan melupakannya, fokus pada persiapan frame berikutnya.
Solusi yang memenuhi keinginan saya ditemukan di
https://github.com/PolyVinalDistillate/PSoC_DMA_NeoPixel .
Semuanya diterapkan di sana pada UDB (tetapi LED hanya alasan, tujuannya adalah untuk belajar UDB). Ada dukungan untuk DMA. Dan proyek di sana jelas diatur dengan indah.
Masalah solusi dipilih sebagai dasar
Bagaimana "firmware" dalam proyek PSoC_DMA_NeoPixel diatur, mereka yang ingin dapat melihatnya setelah membaca artikel. Ini akan memperbaiki materi. Untuk saat ini, saya hanya akan mengatakan bahwa saya pertama kali menyederhanakan logika dari firmware asli tanpa mengurangi sumber daya yang dikonsumsi (tetapi menjadi lebih mudah dipahami). Kemudian ia mulai bereksperimen dengan mengganti logika otomat, yang menjanjikan perolehan sumber daya, tetapi mengalami masalah serius. Dan dia memutuskan - itu tidak dihilangkan! Dan keraguan samar mulai menyiksaku: apakah penulis Inggris memiliki masalah yang sama? Demo-nya berkedip sangat indah dengan LED. Tetapi bagaimana jika kita mengganti pengisian yang indah dengan "semua unit" dan mengontrol hasilnya bukan dengan mata kita, tetapi dengan osiloskop?
Jadi, seseram mungkin (Anda bahkan bisa mengatakan "secara brutal") kami membentuk data:
memset (pPixelArray,0xff,sizeof(pPixelArray));
Dan di sini kita melihat gambar seperti itu pada osiloskop:
Bit pertama memiliki lebar berbeda dari yang lain. Saya diminta untuk mengirim semua unit, tetapi tidak semua pergi. Di antara mereka memusatkan perhatian! Ubah pemindaian:
Lebar berbeda untuk setiap bit kedelapan.
Secara umum, contoh ini sebagai solusi independen tidak cocok, tetapi sebagai sumber inspirasi - sempurna. Pertama, ketidakmampuannya tidak terlihat dengan mata (LED masih cerah, mata tidak melihat bahwa mereka bersinar pada setengah maksimum), tetapi kodenya terstruktur dengan baik, menyenangkan untuk menjadikannya sebagai dasar. Kedua, contoh ini menyediakan ruang untuk menemukan cara untuk menyederhanakan, dan ketiga, ini membuat Anda berpikir bagaimana memperbaiki cacat. Hal yang paling penting adalah memahami materiil! Jadi sekali lagi, setelah membaca artikel, saya sarankan mencoba mengurai contoh aslinya, menyadari cara kerjanya.
Bagian praktis
Sekarang kita mulai berlatih. Kami sedang menguji aspek-aspek utama pengembangan firmware untuk UDB. Pertimbangkan hubungan dan teknik dasarnya. Untuk melakukan ini, buka
versi proyek saya . Blok kiri menyimpan informasi tentang file kerja. Secara default, tab
Source terbuka. Sumber utama proyek adalah file
main.c. Sebenarnya, tidak ada file lain yang berfungsi di grup
File Sumber .
Grup
Generated Source berisi fungsi perpustakaan. Lebih baik tidak mengeditnya. Setelah setiap perubahan "firmware" UDB, grup ini akan dibuat ulang. Jadi, di mana deskripsi kode untuk UDB di idyll ini? Untuk melihatnya, Anda perlu beralih ke tab
Komponen :
Penulis proyek asli membuat set komponen dua tingkat. Di tingkat atas terletak sirkuit
NeoPixel_v1_2.cysch . Ini bisa dilihat dari skema utama:
Komponennya adalah sebagai berikut:
Dukungan perangkat lunak untuk skema ini akan dibahas nanti. Sementara itu, cari tahu bahwa itu sendiri adalah unit DMA biasa dan simbol tertentu
NeoPixDrv_v1 . Blok misterius ini dijelaskan di atas di pohon, yang mengikuti dari tooltip berikut:
"Firmware" UDB
Buka komponen itu (file dengan ekstensi
.cyudb ). Gambar yang dibuka sangat besar. Kami mulai mengerti apa itu.
Tidak seperti penulis proyek asli, saya menganggap transmisi setiap bit data dalam bentuk tiga bagian yang sama (dalam waktu):
- Bagian awal (selalu 1)
- Bagian data
- Hentikan bagian (selalu 0)
Dengan pendekatan ini, sejumlah besar penghitung tidak diperlukan (dalam aslinya ada sebanyak tiga buah, yang menghabiskan banyak sumber daya). Durasi semua bagian adalah sama dan dapat diatur menggunakan satu register. Dengan demikian, grafik transisi firmware berisi status berikut:
Status
diam . Mesin tetap di dalamnya sampai data baru tiba di FIFO.
Dari video pelatihan, tidak sepenuhnya jelas bagi saya bagaimana keadaan mesin terkait dengan ALU. Penulis menggunakan komunikasi sebagai hal yang biasa, tetapi saya, sebagai pemula, tidak bisa langsung melihatnya. Mari kita lihat secara detail. Gambar di atas menunjukkan bahwa kondisi
Idle dikodekan dengan nilai 1'b0. 3'b000 akan lebih benar, tetapi editor akan mengulang semuanya semuanya sama. Input dari blok
Datapath dijelaskan seperti ini:
Jika Anda mengklik dua kali pada mereka, versi yang lebih rinci akan muncul:
Ini berarti bahwa bit nol dari alamat instruksi ALU sesuai dengan bit nol dari variabel yang menetapkan keadaan mesin. Yang pertama adalah yang pertama, yang kedua adalah yang kedua. Jika diinginkan, variabel apa pun dan bahkan ekspresi dapat dicocokkan dengan bit alamat dari instruksi ALU (dalam versi asli, bit kedua dari alamat instruksi ALU dicocokkan dengan ekspresi, dan dalam versi saat ini tidak digunakan secara eksplisit, tetapi sebagai contoh pembawa otak sangat jelas, maka Anda dapat melihatnya).
Jadi Dengan pengaturan input saat ini, yang merupakan kode status biner mesin, instruksi ALU seperti itu digunakan. Ketika kita dalam keadaan
menganggur memiliki kode 000, instruksi nol digunakan. Ini dia:
Saya sudah tahu dari entri ini bahwa ini adalah NOP dangkal. Tetapi Anda dapat mengklik dua kali dan membaca versi lengkap:
NOP tertulis di mana-mana. Register tidak diisi dengan apa pun.
Sekarang mari kita
cari tahu apa jenis bendera misterius
! NoData , memaksa mesin untuk meninggalkan keadaan
idle . Ini adalah jalan keluar dari blok
Datapath . Secara total, hingga enam pintu keluar dapat dijelaskan. Hanya saja
Datapath dapat menghasilkan lebih banyak bendera, tetapi tidak ada sumber daya jejak yang cukup untuk semua orang, jadi kita perlu memilih enam (atau kurang) yang benar-benar kita butuhkan. Berikut adalah daftar pada gambar:
Jika Anda mengklik dua kali padanya, detailnya akan terungkap:
Berikut adalah daftar lengkap dari bendera yang dapat ditampilkan:
Setelah memilih bendera yang diperlukan, Anda harus memberi nama. Mulai sekarang, sistem memiliki bendera. Seperti yang Anda lihat, bendera
NoData adalah nama untuk
status blok rantai
F0 (kosong) . Artinya, tanda bahwa tidak ada data di buffer input. Ah
! NoData , masing-masing,
inversinya . Tanda ketersediaan data. Segera setelah data memasuki FIFO (terprogram atau menggunakan DMA), bendera akan dihapus (dan inversinya terkokang), dan pada siklus jam berikutnya, otomaton akan keluar dari status siaga dan memasuki kondisi
GetData .
Seperti yang Anda lihat, robot akan keluar dari kondisi ini tanpa syarat setelah berada di dalamnya tepat satu siklus clock. Tidak ada tindakan yang ditunjukkan pada grafik transisi untuk keadaan ini. Tetapi Anda harus selalu melihat apa yang ALU akan lakukan. Kode status adalah 1'b1, yaitu, 3'b001. Kami melihat alamat yang sesuai di ALU:
Ada sesuatu. Tidak memiliki pengalaman membaca apa yang ditulis di sini, buka dengan mengklik dua kali pada sel yang sesuai:
Oleh karena itu ALU itu sendiri masih tidak melakukan tindakan apa pun. Tetapi isi FIFO0, yaitu data yang berasal dari program atau blok DMA, akan ditempatkan dalam register A0. Ke depan, saya akan mengatakan bahwa A0 digunakan sebagai register geser, dari mana byte akan keluar dalam bentuk serial. Register A1 akan menempatkan nilai register D1. Secara umum, semua register D biasanya diisi dengan perangkat lunak sebelum perangkat keras mulai aktif. Kemudian, ketika memeriksa API, kita akan melihat bahwa jumlah tick tick dimasukkan dalam register ini, yang menentukan durasi bit ketiga. Jadi Di A0, nilai yang bergeser turun, dan di A1, durasi bagian awal bit. Dan pada beat berikutnya, mesin dipastikan akan masuk ke state
Constant1 .
Seperti yang disiratkan oleh nama negara, konstanta 1. dihasilkan di sini, mari kita lihat dokumentasi untuk LED. Beginilah cara unit dipindahkan:
Dan ini dia - nol:
Garis merah saya tambahkan. Jika kita mengasumsikan bahwa durasi pertiga sama, maka persyaratan untuk durasi pulsa (diberikan dalam dokumentasi yang sama) terpenuhi. Artinya, setiap impuls terdiri dari unit awal, bit data dan nol berhenti. Sebenarnya, unit awal ditransmisikan ketika mesin dalam keadaan
Constant1 .
Dalam kondisi ini, mesin mengunci unit di pemicu internalnya. Nama pemicunya adalah
CurrentBit . Dalam proyek asli, itu umumnya merupakan pemicu yang menetapkan keadaan otomat bantu. Saya memutuskan bahwa mesin itu hanya akan membingungkan semua orang, jadi saya baru saja memulai pemicu. Itu tidak dijelaskan di mana pun. Tetapi jika Anda memasukkan properti status, catatan berikut ini terlihat dalam tabel:
Dan di bawah negara pada grafik ada teks seperti itu:
Jangan khawatir dengan simbol sama dengan. Ini adalah fitur editor. Dalam kode Verilog yang dihasilkan (secara otomatis dihasilkan oleh sistem yang sama) akan ada panah:
Constant1 : begin CurrentBit <= (1); if (( CycleTimeout ) == 1'b1) begin MainState <= Setup1 ; end end
Nilai yang terkunci pada pemicu ini adalah output dari seluruh blok kami:
Artinya, ketika mesin memasuki kondisi
Constant1 , output dari blok yang kami kembangkan akan mendapatkan satu. Sekarang mari kita lihat bagaimana ALU diprogram untuk alamat 3'b010:
Kami mengungkapkan elemen ini:
Unit 1 dikurangi dari register A1. Nilai output ALU masuk ke register A1. Di atas, kami menganggap bahwa A1 adalah penghitung jam yang digunakan untuk mengatur durasi pulsa output. Biarkan saya mengingatkan Anda bahwa itu boot dari D1 pada langkah terakhir.
Apa kondisi untuk keluar dari negara?
CycleTimeOut . Dijelaskan di antara output sebagai berikut:
Jadi, kami menyatukan logika. Pada keadaan sebelumnya, isi register D1 yang sebelumnya diisi oleh program masuk ke register A1. Pada langkah ini, mesin menerjemahkan pemicu
CurrentBit menjadi satu, dan dalam ALU, register A1 berkurang pada setiap siklus clock. Ketika A1 menjadi nol, bendera akan dinaikkan secara otomatis, yang penulis beri nama
CycleTimeout , sebagai akibatnya mesin akan beralih ke keadaan
Setup1 .
Status
Setup1 menyiapkan data untuk mentransmisikan pulsa yang bermanfaat.
Kami melihat instruksi ALU di 3'b011. Saya akan segera membukanya:
Tampaknya ALU tidak memiliki tindakan. Operasi NOP. Dan output ALU tidak bisa kemana-mana. Tapi ini tidak benar. Tindakan yang sangat penting adalah pergeseran data dalam ALU. Faktanya adalah bit
pembawa di antara output terhubung ke rantai
ShiftOut kami:
Dan sebagai hasil dari operasi shift ini, nilai yang digeser itu sendiri tidak akan sampai ke mana pun, tetapi rantai
ShiftOut akan mengambil nilai bit paling signifikan dari register A0. Artinya, data yang harus ditransmisikan. Di bawah keadaan grafik, dapat dilihat bahwa nilai ini, yang meninggalkan ALU dalam rantai
ShiftOut , akan dimasukkan ke pemicu
CurrentBit . Biarkan saya tunjukkan gambarnya lagi agar tidak memundurkan artikel:
Transmisi bagian kedua bit dimulai - nilai langsungnya adalah 0 atau 1.
Kami kembali ke instruksi untuk ALU. Selain apa yang telah dikatakan, dapat dilihat bahwa isi register D1 lagi akan dimasukkan ke register A1 untuk mengukur durasi sepertiga kedua pulsa lagi.
Status
DataStage sangat mirip dengan kondisi
Constant1 . Otomat hanya mengurangi satu dari A1 dan memasuki keadaan berikutnya ketika mencapai nol. Biarkan saya menunjukkannya seperti ini:
dan seperti ini:
Kemudian muncul keadaan
Setup2 , esensi yang sudah kita ketahui.
Dalam keadaan ini, pemicu
CurrentBit diatur ulang ke nol (karena sepertiga dari pulsa akan ditransmisikan, bagian stop, dan selalu nol). ALU memuat konten D1 ke A1. Anda bahkan dapat melihatnya dalam catatan singkat dengan mata terlatih Anda:
Keadaan
Constant0 sepenuhnya identik dengan keadaan
Constant1 dan
DataStage . Kurangi unit dari A1. Ketika nilai mencapai nol, keluar ke status
ShiftData :
Keadaan
ShiftData lebih kompleks. Dalam instruksi yang sesuai untuk ALU, tindakan berikut dilakukan:
Daftar A0 digeser oleh 1 bit, dan hasilnya dimasukkan kembali ke A0. Di A1, isi D1 sekali lagi dimasukkan untuk mulai mengukur mulai ketiga untuk bit data berikutnya.
Lebih baik untuk mempertimbangkan panah keluaran dengan mempertimbangkan prioritas akun, yang kami klik dua kali pada negara
ShiftData .
Jika bukan bit terakhir yang ditransmisikan (tentang bagaimana flag ini dibentuk, sedikit lebih rendah), maka kami mentransfer satu untuk bit berikutnya dari byte saat ini.
Jika bit terakhir ditransmisikan dan tidak ada data di FIFO, kita pergi ke keadaan siaga.
Akhirnya, jika bit terakhir ditransmisikan, tetapi ada data dalam FIFO, kita pergi ke pemilihan dan transmisi byte berikutnya.
Sekarang tentang penghitung bit. Hanya ada dua baterai di ALU: A0 dan A1. Mereka sudah ditempati masing-masing oleh register geser dan penghitung waktu tunda. Oleh karena itu, penghitung bit digunakan secara eksternal.
Klik dua kali di atasnya:
Nilai saat boot adalah enam. Itu dimuat menggunakan bendera
LoadCounter yang dijelaskan di bagian variabel:
Yaitu, ketika byte data berikutnya diambil, konstanta ini dimuat sepanjang jalan.
Ketika mesin memasuki kondisi
ShiftData , penghitung mengurangi nilai. Ketika mencapai nol,
TerminalCount output terhubung, terhubung ke sirkuit
seedBit FinalBit kami. Sirkuit inilah yang menetapkan apakah mesin akan mentransfer bit berikutnya dari byte saat ini atau mentransfer byte baru (baik, atau menunggu paket data baru).
Sebenarnya, semuanya dari logika. Bagaimana sinyal
SpaceForData dihasilkan , yang menetapkan keadaan output
Hungry (memberi tahu unit DMA bahwa mungkin untuk mengirimkan data berikutnya), pembaca diundang untuk melacak secara independen.
Dukungan perangkat lunak
Penulis proyek asli memilih untuk membuat dukungan perangkat lunak untuk seluruh sistem di blok yang menjelaskan solusi terintegrasi. Biarkan saya mengingatkan Anda, kita berbicara tentang blok ini:
Dari level ini, ada kontrol atas unit perpustakaan DMA dan semua bagian yang termasuk dalam bagian UDB. Untuk mengimplementasikan API, pembuat dokumen asli menambahkan file header dan program:
Format tubuh dari file-file ini membuat Anda sedih. Seluruh kesalahan adalah cinta pengembang PSoC Designer untuk "yang murni". Oleh karena itu nama makro dan kilometer yang mengerikan. Organisasi kelas di C ++ akan berguna di sini. Setidaknya kami memeriksa ini ketika menerapkan RTOS MAX kami: ternyata indah dan nyaman. Tapi di sini Anda bisa berdebat banyak, tetapi Anda harus menggunakan apa yang kami biarkan turun dari atas. Saya hanya akan menunjukkan secara singkat seperti apa fungsi API yang mengandung makro ini:
volatile void* `$INSTANCE_NAME`_Start(unsigned int nNumberOfNeopixels, void* pBuffer, double fSpeedMHz) {
Aturan main ini harus diterima. Sekarang Anda tahu dari mana menarik inspirasi dari ketika mengembangkan fungsi Anda (yang terbaik untuk melakukan ini dalam proyek asli). Dan saya lebih suka membicarakan detailnya, mengambil opsi yang sudah diproses oleh generator.
Setelah menghasilkan kode (dijelaskan di bawah) file ini akan disimpan di sini:
Dan tampilan sudah bisa dibaca dengan sempurna. Ada dua fungsi sejauh ini. Yang pertama menginisialisasi sistem, yang kedua memulai transfer data dari buffer ke garis LED.
Inisialisasi mempengaruhi semua bagian sistem. Ada inisialisasi penghitung tujuh-bit, yang merupakan bagian dari sistem UDB:
NP_Neo_BITCNT_Start();
Ada perhitungan konstan yang harus dimuat ke dalam register D1 (saya ingat bahwa ia menetapkan durasi masing-masing bit ketiga):
unsigned char fCyclesOn = (unsigned char)(0.35/(1.0/(fSpeedMHz))); CY_SET_REG8(NP_Neo_DPTH_D1_PTR, fCyclesOn+1);
Menyiapkan blok DMA mengambil sebagian besar fungsi ini. Buffer digunakan sebagai sumber, dan FIFO0 dari blok UDB digunakan sebagai penerima (NP_Neo_DPTH_F0_PTR dalam catatan kilometer). Penulis memiliki bagian dari pengaturan ini dalam fungsi transfer data. Tapi, menurut saya, melakukan semua perhitungan demi setiap transmisi terlalu boros. Terutama ketika Anda menganggap bahwa salah satu tindakan di dalam fungsi terlihat sangat, sangat banyak.
Fungsi kedua dengan latar belakang yang pertama adalah puncak laconicism. Hanya saja yang pertama dipanggil pada tahap inisialisasi, ketika persyaratan kinerja cukup gratis. Selama operasi, lebih baik untuk tidak membuang-buang siklus prosesor pada apa pun yang berlebihan:
void NP_Update() { if(NP_g_pFrameBuffer) { CyDmaChEnable(NP_g_nDMA_Chan, 1); } }
Jelas tidak cukup fungsionalitas untuk bekerja dengan beberapa buffer (untuk menyediakan buffering ganda), tetapi secara umum, diskusi tentang fungsionalitas API berada di luar cakupan artikel. Sekarang yang utama adalah menunjukkan bagaimana cara menambahkan dukungan perangkat lunak ke firmware yang dikembangkan. Sekarang kita tahu bagaimana melakukannya.
Pembuatan proyek
Jadi, seluruh bagian firmware siap, API ditambahkan, apa yang harus dilakukan selanjutnya? Pilih item menu
Build-> Generate Application .
Jika semuanya berjalan dengan baik, Anda dapat membuka tab
Hasil dan melihat file dengan ekstensi
rpt .
Ini menunjukkan berapa banyak sumber daya sistem masuk ke dalam implementasi firmware.
Ketika saya membandingkan hasilnya dengan yang ada di proyek asli, jiwa saya menjadi lebih hangat.
Sekarang buka tab
Source dan mulai bekerja dengan bagian perangkat lunak. Tapi ini sudah sepele dan tidak memerlukan penjelasan khusus.
Kesimpulan
Saya berharap bahwa dari contoh ini, pembaca telah belajar sesuatu yang baru dan menarik tentang pekerjaan praktis dengan blok UDB. Saya mencoba untuk fokus pada tugas tertentu (kontrol LED), serta pada metodologi desain, karena saya harus memahami beberapa aspek yang jelas bagi para spesialis. Saya mencoba untuk menandai mereka sementara ingatan pencarian masih segar. Adapun masalah yang diselesaikan, diagram waktu untuk saya ternyata tidak begitu ideal seperti yang dari penulis pengembangan asli, tetapi mereka cocok dengan toleransi yang ditentukan dalam dokumentasi untuk LED, dan sumber daya sistem secara signifikan kurang.
Faktanya, ini hanya sebagian dari informasi non-standar yang ditemukan. Secara khusus, dari sebagian besar materi, tampaknya UDB hanya berfungsi baik dengan data serial, tetapi tidak demikian halnya. Ditemukan Catatan Aplikasi, yang secara singkat menunjukkan bagaimana Anda dapat mengemudi dan memparalelkan data. Kami dapat mempertimbangkan contoh spesifik berdasarkan informasi ini (meskipun tidak mungkin untuk menaungi FX2LP, pengontrol lain dari Cypress: PSoC memiliki kecepatan bus USB yang lebih rendah).
Kepalaku berputar-putar ide tentang bagaimana memecahkan masalah "flashing" printer 3D, yang telah lama menyiksaku. Di sana, interupsi melayani motor stepper melahap hanya persentase waktu CPU yang gila. Secara umum, saya berbicara banyak tentang interupsi dan waktu prosesor dalam sebuah
artikel tentang RTOS MAX . Ada perkiraan bahwa untuk servis motor stepper dimungkinkan untuk mengambil semua gubuk sementara sepenuhnya ke UDB, meninggalkan prosesor tugas komputasi murni tanpa takut bahwa ia tidak akan punya waktu untuk melakukan ini dalam slot waktu khusus.
Tetapi hal-hal ini hanya bisa dijadikan alasan jika topiknya menarik.