Цитата(jcxz @ Dec 12 2014, 22:24)
Т.е. - CY7C68013A - это из области фантастики? Ведь там даже не M0, а вообще какой-то 8051.
USB - это в основном аппаратная реализация, для которой, в общем-то, совершенно все равно, какая у МК система команд. Ведь по протоколу USB самое большее - 1-2 байта для подтверждения принятия посылки требуется пробить. Т.е. по своей природе USB - последовательный интерфейс с аппаратной трансляцией битов в поток байт, а потому длина размера регистров здесь столь же мало востребована, как и в передаче UART, I2C или SPI.
По большому счету, длинные регистры (16-, 32- бит и выше) нужны только для long/float-арифметики и для обмена с ОЗУ (чтобы прочитать/записать больше байт за один такт). Собственно, для реализации самих "контрольных" функций контроллеру не только достаточно 8-битых регистров, но и крайне неудобно работать, если они длиннее. Представьте себе, что I/O-функции всех регистров сосредоточены в одном длинном 64-битном регистре - понимаете, как станет неудобно дрыгать отдельными ножками? Так же и с чтением из него - больше времени потратите на бесконечные вырезки и сдвиги из этого регистра. А попробуйте со строками теста работать, если у вас все регистры длинные. Так это же застрелиться проще!
Короче говоря, 8-битные операции это скорее хорошо, чем плохо. А плохо оно становится только в арифметике с числами, размером в 2 и 4 байта. Вот тут действительно нужны длинные регистры, иначе такая арифметика будет крайне неэффективна по скорости выполнения. Вот и получается, что длинные регистры - хорошо для арифметического процессора, но плохо для контролера, и наоборот. Ну, а поскольку современные МК нагружены еще массой других работ по горло (даже Linux по нынешним временам на них ставят), то им приходится труднее всего, т.к. приходится совмещать трудносовместимое.
В этом смысле показателен пример архитектуры i86-i64, которую вполне можно считать потомком архитектуры 8051. К настоящему времени регистры там выросли до 64-бит, а некоторые (SSE) чуть ли не до 512. Тем не менее, практически все задачи/приложения до сих пор запускаются в том самом древнем режиме, когда операции по умолчанию подразумеваются однобайтовыми (8/16-разрядными), а для более длинных перед каждой командой ставится префикс (дополнительный байт, указующий на изменение разрядности следующей за ним операции). А почему так, если устанавливается такой режим исключительно по требованию? - Да ровно потому, что без однобайтных операцией совсем тоскливо жить.
Что же касается конкретно CY7C68013A, то это жульничество, а не HS-USB
. Сами посудите, что может cделать МК с потоком 480 Mb/s, если у него самого тактовая частота 12-24-48 MHz? Т.е. здесь именно тактовая частота тормозит производительность, а отнюдь не система инструкций. То, что там сделано - это лишь наполнение буфера размером 512 байт (специально сделанного на быстрой памяти вне общего пространства ОЗУ), а потом МК медленно из него сосет и переваривает байты, отвечая на последующие запросы хоста, что он занят и принять новую посылку не может. Формально это действительно HS-USB, т.к. по этому каналу этот МК может принимать и передавать данные, но по реальной скорости обмена на протяжении хоть сколько-то продолжительного времени та скорость и рядом с HS-USB не лежала.
Cortex M0 + Hi Speed Usb. Существуют ли такие?
Nov 13 2014, 12:37
