Cortex M0 + Hi Speed Usb. Существуют ли такие? Опции

[vladimir_orl]

Здравствуйте.

Скажите, кто нибудь встречал Cortex-M0 с Hi Speed Usb на борту?
Или что-нибудь подобное?

[adnega]

Здравствуйте.

Скажите, кто нибудь встречал Cortex-M0 с Hi Speed Usb на борту?
Или что-нибудь подобное?

Дык, двухядерники у NXP (http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/).

Вам ведь Phy тоже нужен?

А почему M0? Деньги? Потребление?

[toweroff]

А потянет ли M0 такой поток? Ему бы мегабайт/сек-то обработать, т.е. FS

[Дмитриос]

А потянет ли M0 такой поток? Ему бы мегабайт/сек-то обработать, т.е. FS

Аппаратная поддержка DMA и 204 МГц таковой. Если вам нужно складывать отчёты с АЦП и прибавлять к ним константу -- ну почему нет то?. )

[jcxz]

А почему M0? Деньги? Потребление?

Наверное автор собирается писать на асме, а команд M3/M4 он не знает

[Xenia]

Если проц такой крутой, что тянет Hi Speed USB, то производитель не станет экономить на системе инструкций, выбирая урезанную. Поэтому поиски такого МК столь же бесперспективны, как поиски быстроходного Феррари в корпусе Запорожца.

[jcxz]

Если проц такой крутой, что тянет Hi Speed USB, то производитель не станет экономить на системе инструкций, выбирая урезанную. Поэтому поиски такого МК столь же бесперспективны, как поиски быстроходного Феррари в корпусе Запорожца.

Т.е. - CY7C68013A - это из области фантастики? Ведь там даже не M0, а вообще какой-то 8051

[_pv]

Т.е. - CY7C68013A - это из области фантастики? Ведь там даже не M0, а вообще какой-то 8051

и что там тот 8051 с highspeed делать может, так сбоку стоит, рядом с GPIF.

[Xenia]

Т.е. - 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 не лежала.

[_pv]

Что же касается конкретно CY7C68013A, то это жульничество, а не HS-USB .
...
Формально это действительно HS-USB, т.к. по этому каналу этот МК может принимать и передавать данные, но по реальной скорости обмена на протяжении хоть сколько-то продолжительного времени та скорость и рядом с HS-USB не лежала.

да не, 45МБайт/с народ выжимает, только это в обход МК напрямую мост на внешнюю параллельную шину, а 8051 там только чтоб дескриптор хосту отдать на старте.

да и вообще ftdi вон ft600 уже c usb3.0 сделала, в чем радость-то от наличия USB именно в МК? тем более M0
так как с hi speed даже M4-то ничего особо сделать не сможет, на потоках в 40МБайт/с только успеет просто данные переложить в USB.

[jcxz]

USB - это в основном аппаратная реализация, для которой, в общем-то, совершенно все равно, какая у МК система команд. Ведь по протоколу USB самое большее - 1-2 байта для подтверждения принятия посылки требуется пробить.

Да ну!?
А как-же запросы дескрипторов, управление эндпоинтами с различными типами передач и т.п.? И это в device, не говоря о хост.
И это только при работе через эндпоинты, не говоря уже о том, если нужна работа с какими-то профилями.
Это вообще-то не аппаратно всё делается (слишком громоздко было-бы). Загляните в любой USB-стек на ARM - именно он этим и занимается,
но никак не аппаратный контроллер. Размеры исходников USB-стеков обычно == десятки кБ.

...
А попробуйте со строками теста работать, если у вас все регистры длинные. Так это же застрелиться проще!

В Вас чувствуется адепт чего-то 8-битного Наверно AVR.
Вообще-то любой ARM/Cortex имеет вполне себе нормальный набор команд чтения/сохранения 8-разрядных переменных.
Команды эти такого-же размера и имеют все те же режимы адресации и т.п. как и 32-битные - никакой ущербности.
Т.е. для ARM/Cortex никакой разницы нет - работать с 32-битными или 8-битными данными.
И совершенно не нужно 8-битные данные паковать в 32-битные и потом вытаскивать их сдвигами, как Вы пишете.
(разве только для ускоренного копирования, так это только '+').
Откройте любое описание системы команд ARM/Thumb или Thumb-2. Ну или любой *.lst-файл компилятора.

Работа с 8-битными данными только как с пакованными необходима (из известных мне архитектур) только на семействе TI DSP C55x.
Только там нет 8-битных команд обращения к памяти.

В этом смысле показателен пример архитектуры i86-i64, которую вполне можно считать потомком архитектуры 8051. К настоящему времени регистры там выросли до 64-бит, а некоторые (SSE) чуть ли не до 512. Тем не менее, практически все задачи/приложения до сих пор запускаются в том самом древнем режиме, когда операции по умолчанию подразумеваются однобайтовыми (8/16-разрядными), а для более длинных перед каждой командой ставится префикс (дополнительный байт, указующий на изменение разрядности следующей за ним операции).

Опять неправда Ваша
Я, в своё время, много писал на x86 и кое-что ещё помню.
Во-первых - префикс изменения разрядности операндов там ставится не перед более длинной, а перед операцией, разрядность которой не соответствует текущему режиму CPU. Если CPU в 16-битном режиме, то он будет перед 32-битными командами; если-же CPU в 32-битном
режиме, то префикс будет перед 16-битными командами (не знаю как там с 64-битными - к этому времени я уже ушёл из мира x86).
Так что если CPU в 32-битном режиме, то самыми короткими будут именно операции с 32-битными данными.
А операции с 8-битными там вообще всегда были более ущербны (команды имеют больший размер, чем команды работы с нативной разрядностью CPU).
И задачи на x86 под виндой (и думаю другими ОС) сейчас не запускаются в 16-битном режиме. Разве только древние DOS-овские.

Что же касается конкретно CY7C68013A, то это жульничество, а не HS-USB . Сами посудите, что может cделать МК с потоком 480 Mb/s, если у него самого тактовая частота 12-24-48 MHz? Т.е. здесь именно тактовая частота тормозит производительность, а отнюдь не система инструкций. То, что там сделано - это лишь наполнение буфера размером 512 байт (специально сделанного на быстрой памяти вне общего пространства ОЗУ), а потом МК медленно из него сосет и переваривает байты, отвечая на последующие запросы хоста, что он занят и принять новую посылку не может. Формально это действительно HS-USB, т.к. по этому каналу этот МК может принимать и передавать данные, но по реальной скорости обмена на протяжении хоть сколько-то продолжительного времени та скорость и рядом с HS-USB не лежала.

И с CY7C68013A Вы я вижу не знакомы
А я для него писал ПО.
Он состоит из двух частей:
медленной (ядро x51 с возможностью программной обработки endpoint-ов, медленно конечно);
и быстрой (GPIF-интерфейс, который конфигурится ядром x51, но после этого работает самостоятельно как простой конечный автомат на жёсткой логике и позволяет осуществлять быстрый обмен с внешней параллельной шиной (тут уже упоминали про десятки МБ/сек, у меня было немножко поменьше, но всё равно)).
А 48 МГц позволяет обмениваться с внешней шиной до 96МБ/сек в пределе при соответствующей временной диаграмме, прописанной в GPIF.