Скоростной девайс с USB интерфейсом - нужен совет, нужен совет опытных людей... Опции

[MSL]

Нужно сделать высокоскоростное USB устройство, которое будет общаться с PC. С выбором контроллера для юсб особой альтернативы, как я понял нет - Cypress. Проблема в другом - переданные в пакете команды и данные необходимо выводить по заданым алго на несколько GPIO пинов (8 шт) и читать с этих пинов с частотой до 20Mhz (а желательно и выше). Т.е. в связке с cypress нужен как можно более быстрый и как можно менее навороченный (не нужны CAN, Ethernet и пр.) МК, в котором можно по мере необходимости апдэйтить программу. такая вот засада... кто сталкивался с похожей задачей - подскажите плиз как лучше реализовать. спасибо!

Сообщение отредактировал MSL - Apr 13 2007, 20:38

[scifi]

Попробуйте поискать микроконтроллер с high-speed USB, шиной для внешней памяти и DMA. Ввод-вывод на 8 пинов можно сделать через внешнюю шину и DMA, а процессор будет эти данные окучивать и пересылать по USB.

[Alex11]

20 МГц для микроконтроллера многовато, особенно если это не просто пересылка, а еще и какие-то разборки по алгоритмам. Я бы поставил DSP от TI серии 55хх, он уже вполне должен успеть.
Я, конечно, понимаю, что Cypress проще в программировании, но есть еще Philips и PLX. С последним я не работал, но по описанию выглядит очень хорошо.
Еще один вариант построения системы - пустить данные в обход процессора в FPGA и там шевелить пинами, тогда требования к процу резко ниже.

[vmp]

переданные в пакете команды и данные необходимо выводить по заданым алго на несколько GPIO пинов (8 шт) и читать с этих пинов с частотой до 20Mhz (а желательно и выше).

Для начала почитайте о возможностях GPIF в Cypress FX2LP (CY7C68013A) в документе EZ-USB Technical Reference Manual. Вполне возможно, что вам удастся обойтись этими возможностями, не привлекая внешние процессора.

[MSL]

спасибо всем, кто откликнулся и посоветовал.. пока изучаю мануалы TI на TMS320VC5509A и TUSB6250 (TUSB6250 это мк с hi-speed USB и ядром как у cypress, но вроде побыстрее - 60мг и тактов на команду меньше). Поскольку устройство будет принимать и передавать данные со скоростью от сотен килобайт до нескольких мегабайт в секунду - full speed думаю будет достаточноЖ-) Основная нагрузка будет ложится на разбор команд из юсб пакета. Даже самая простая low-level команда - такая как выставить пины в соотв. с переданными байтами, с определенными задержками и чтением указанных пинов через заданные интервалы будет выполняться уже за десятки команд (а будут и команды сотоящие из low-level команд). 013a никак не потянет все это на 20mhz. Поэтому, пока склоняюсь к TMS320VC5509A, хоть там и новое для меня ядро. C удовольствием сделал бы на МК с ARM9, т.к. с arm все для меня понятно, но пока не нашел ненавороченного мк с арм9...

[vmp]

013a никак не потянет все это на 20mhz.

Сразу видно - документацию не читал.
В Cypress FX2 данные обычно идут в обход процессора, сразу на FIFO или GPIF. Процессорное ядро там нужно только для начальной конфигурации и (иногда) для разбора высокоуровневых команд. Данные же там обрабатываются аппаратно без участия процессорного ядра.

[MSL]

Сразу видно - документацию не читал.
В Cypress FX2 данные обычно идут в обход процессора, сразу на FIFO или GPIF. Процессорное ядро там нужно только для начальной конфигурации и (иногда) для разбора высокоуровневых команд. Данные же там обрабатываются аппаратно без участия процессорного ядра.

да ну не могу ж я ЗНАТЬ ВСЕ о разных МК только прочитав манулы-)) ЗНАТЬ можно только после того как что-то на чем то сделал, наступив на все грабли...

постараюсь пояснить что я имел в виду... Например, я послал устройству команду 0x81 0xAA 0xBB, таких команд может быть несколько. Например, с помощью МК она должна по битам с 0го вывести байт 0хАА на пин0 а байт 0хВВ на пин1, прочитав при выводе состояние пин2, пин3, пин4 и отправив эти 3 байта сразу, потому что бит7 в байте команды подразумевает ответ немедленно и данные должны быть отправлены сразы не дожидаясь заполнения буфера.

так вот вопрос - подскажите тогда, как знающий человек, сколько байт и пакетов я должен послать к 013а, чтобы сайперс выполнил эту последовательность через GPIF и я получил данные и привел их к виду 3х байт?

[vmp]

постараюсь пояснить что я имел в виду... Например, я послал устройству команду 0x81 0xAA 0xBB, таких команд может быть несколько. Например, с помощью МК она должна по битам с 0го вывести байт 0хАА на пин0 а байт 0хВВ на пин1, прочитав при выводе состояние пин2, пин3, пин4 и отправив эти 3 байта сразу, потому что бит7 в байте команды подразумевает ответ немедленно и данные должны быть отправлены сразы не дожидаясь заполнения буфера.

так вот вопрос - подскажите тогда, как знающий человек, сколько байт и пакетов я должен послать к 013а, чтобы сайперс выполнил эту последовательность через GPIF и я получил данные и привел их к виду 3х байт?

Как минимум 1 обмен типа OUT и 1 обмен типа IN. Только не с 3 байтами - GPIF вращать байты не умеет. Это лучше сделать на хосте и послать развернутые данные на нужный endpoint. Далее GPIF выдаст их на шину данных (8 или 16 бит) с нужной частотой и нужными стробами.
C входными данными аналогично.

Формат обмена придется изменить, возложив больше работы на центральный процессор. При его гигагерцах это оправданно.

Если все-таки нужно высокое быстродействие - то тогда на шину FX2 можно повесить FPGA, какой-нибудь Циклон-2 за $15. Конфигурированием её может заниматься тот же FX2. Все ПО и зашивка FPGA могут грузиться с хоста.

[Alex11]

Учтите еще одно соображение. Даже для high-speed USB частота обмена командами довольно низкая, и если Вы хотите иметь 20 МГц в режиме команда - действие - ответ, то, скорее всего, у Вас ничего не получится. Высокая скорость на USB достигается только при передаче потока данных. В режиме команда - ответ можно рассчитывать максимум на то, что в одном микрофрейме (125 мкс) придет команда, следующий микрофрейм будет пропущен, т.к. с ответом не успеть к началу, и в следующем будет ответ. Следующая команда может быть получена еще через микрофрейм. Т.е. 4 микрофрейма на обмен. И это в лучшем случае. Некоторые контроллеры привязывают такой обмен к фрейму 1 мс даже для high speed USB. Посмотрите, насколько можно изменить Ваш протокол на потоковый или крупноблочный, чтобы много действий подряд было задано в одной команде.

[scifi]

Поскольку устройство будет принимать и передавать данные со скоростью от сотен килобайт до нескольких мегабайт в секунду - full speed думаю будет достаточноЖ-)

Вы что-то путаете: Full Speed - это до 12 Мбит/с, т.е. до 1,5 Мбайт/с.

да ну не могу ж я ЗНАТЬ ВСЕ о разных МК только прочитав манулы-)) ЗНАТЬ можно только после того как что-то на чем то сделал, наступив на все грабли...

Всё знать и не надо. Надо знать, сможет ли данный МК справиться с поставленной задачей. А это можно выяснить, прочитав руководства.

постараюсь пояснить что я имел в виду... Например, я послал устройству команду 0x81 0xAA 0xBB, таких команд может быть несколько. Например, с помощью МК она должна по битам с 0го вывести байт 0хАА на пин0 а байт 0хВВ на пин1, прочитав при выводе состояние пин2, пин3, пин4 и отправив эти 3 байта сразу, потому что бит7 в байте команды подразумевает ответ немедленно и данные должны быть отправлены сразы не дожидаясь заполнения буфера.

Здесь могу только согласиться с vmp: либо меняйте протокол обмена, либо ставьте ПЛИС.

[MSL]

Учтите еще одно соображение. Даже для high-speed USB частота обмена командами довольно низкая, и если Вы хотите иметь 20 МГц в режиме команда - действие - ответ, то, скорее всего, у Вас ничего не получится. Высокая скорость на USB достигается только при передаче потока данных. В режиме команда - ответ можно рассчитывать максимум на то, что в одном микрофрейме (125 мкс) придет команда, следующий микрофрейм будет пропущен, т.к. с ответом не успеть к началу, и в следующем будет ответ. Следующая команда может быть получена еще через микрофрейм. Т.е. 4 микрофрейма на обмен. И это в лучшем случае. Некоторые контроллеры привязывают такой обмен к фрейму 1 мс даже для high speed USB. Посмотрите, насколько можно изменить Ваш протокол на потоковый или крупноблочный, чтобы много действий подряд было задано в одной команде.

да, я понимаю, что по юсб в режиме команда - ответ я не получу откликов с такой частотой и что на стороне PC задержки уже в мс - есть некоторый опыт работы с юсб-) Протокол обмена и будет делаться потоковым с блоками данных в десятки килобайт (но точно здесь уже точно ничего не скажешь - потому как это будет уже зависеть от того, что за девайс будет сделан). Просто МК должен с макс. скоростью исполнять все полученные команды из буфера. Только в начале приема/передачи данных будет что-то типа хэндшэйка и определение параметров передачи данных, а дальше в потоке все. Одна из причин почему я упираю на то, что мк должен выполнять команды - он должен контролировать правильность выполнения/передачи данных и некоторых случаях прекращать разбирать команды и сообщать об ошибке, чтобы не привести оконечное устройство в ступор (ну или оно было просто отсоединено и пр.).

Вы что-то путаете: Full Speed - это до 12 Мбит/с, т.е. до 1,5 Мбайт/с.

сорри, я знаю - просто написал желаемую на данный момент цифру, что в голове сидела...

Здесь могу только согласиться с vmp: либо меняйте протокол обмена, либо ставьте ПЛИС.

еще раз могу сказать все только спасибо, что советы/поправки! На данных момент исходя из того, что было сказано я прихожу к выводу, что реализовывать нужное устройсто нужно при помощи hi-speed USB (коих нет так много и все-таки хочется иметь на будующее возможность передачи со скоростью больше full) контроллера плюс быстрой ПЛИС или МК, который будет только выполнять принятые команды... Как говорится, пока ясно, что еще ничего не ясно..(( Выбор ПЛИС, буфер обмена между ПЛИС и юсб контроллером, его размер и приемрный принцип их общения... буду думать...-)