Comments 26
Ну и подключали бы сразу ваше USB3 устройство к Windows.
В тексте речь шла про поток данных около 50 мегабайт в секунду, что соответствует 419 430 400 бит в секунду. И это без фрейминга и оверхеда протоколов (да хотя бы UDP)
по SPI какому-нить можно подключить
Внезапно SPI — медленный интерфейс. Даже на быстрых МК его скорость будет не больше 80-100 мегабит в секунду. И, обычно, чем навороченнее SoC, тем более ущербный на нем SPI и прочая низкоуровневая периферия.
Сотка не пропустит принципиально ну вообще. Нужно понимать, что MAC, IP, UDP/TCP уровни вносят свой оверхед
и вы планируете буферировать и сбрасывать постепенно?
Эти вопросы лучше задавать автору статьи)
Проблема тут уже не в скорости канала, а в алгоритме, что успеет отработать все эти данные в разумный период времени.
Вы рассматривали способы сокращения их объема?
Является ли задача вычислений непрерывной (к примеру мониторинг электросети) или кратковременной, но очень информативной (сейсморазведка).
Может достаточно найти большую оперативку
Можно взять что-то вроде платы на базе Texas Instruments Sitara и написать код взаимодействия с внешней периферией для PRU-ICSS на обычном Си. Оговорюсь сразу, что возможно конкретно BeagleBone Black/Green вам не подойдет, там Ethernet только 10/100.
К примеру можно организовать 32-битный синхронный параллельный порт. Для 50 мегабайт в секунду тактирование такого порта будет около 13-15 мегагерц, что для 200-мегагерцового ядра PRU вполне подъемная задача (вроде как). В любом случае у AM335x таких ядер 2, а у AM437x и AM57x уже четыре, так что нагрузку можно распределять.
Главное, чтобы у платы были свободные PRU-GPI и PRU-GPO-порты.
Вариант номер два — использовать GPMC (general purpose memory controller) и заставить устройство сбора данных "прикинуться" оперативкой. Если мы говорим про 50 мегабайт в секунду, то это скорее всего не просто микроконтроллер
Сейчас всё строится от части по второму пути.
PRU-ICSS — это все-таки независимая от ARM подсистема с собственной шиной и тактированием. Она продолжит работать даже когда ARM захлебнулся в потоке собственных событий.
Можно выделить область памяти в DDR под кольцевой буффер и раз в N тактов пинать хостовый контроллер с указанием до какого индекса в нем уже заполнены данные.
Upd: Главное, чтобы у вас хватило пропускной способности самой этой платы. Можно, конечно, взять зверя типа AM5728, но нужна ли вам такая числодробилка с двумя DSP (не считая ARM Cortex A15 и Cortex M4) на борту — еще вопрос
Соглашусь, что порог входа в SoC от TI повыше, чем у той же малины или "рандомной материнки на Intel", но после недели-другой вдумчивого гугления и чтения даташитов все становится на свои места.
Дикие datasheet
Они на то и даташиты, чтобы быть дикими.
По своему опыту разницы в оных между ST, TI и AD особо не замечал.
На этой плате сложно обрабатывать данные
Простите, но этот зверек (C66x DSP) умеет делать 32 16-битных умножения или 4-float за такт при тактовой в 600/750МГц, куда уж быстрее? Дальше только FPGA
Изкоробки есть даже OpenCL (хотя нужен ли он — вопрос).
нужен гигабитный ethernet
Быстрый канал связи нужен вообще всегда, хотя бы для целей отладки
Прошу прощения, если я несу чушь, не знаком в сущности с USBIP.
Взгляд снизу вверх или Ubuntu Server для разработчика электроники. Часть 1