Статья описывает практику применения описанной техники и не ставит целью охватить все глубины и возможности современной аппаратуры. Это один из вариантов решения поставленной задачи.
Описание: нужно передавать немалые объёмы данных (к примеру, по 50 Мбайт/сек), сформированные контроллером некоторого прибора, в компьютер c Windows для последующей их математической обработки, отображения в некотором виде на экране, ну и прочего…
Варианты решения:
- Построим контроллер, с интерфейсом Gigabit ethernet на ПЛИС
- То же, но на какой-то штуке (к примеру, AX88180)
- Ваш вариант
Первый вариант простым не будет. Если делать по чесноку, то дорого. Реализация каждого протокола — вопрос времени и умения программиста, но это не та задача, на которую хочется тратить время, при создании прибора. Без протокола или только до уровня UDP — сложности совместимости. Добавить что-то новое — как лошадь объездить.
Второй вариант — тоже не подарок. Реализация интерфейса ради интерфейса — не цель проекта. А такая микросхема съест кучу ног, которые могли бы пригодиться. В итоге ПЛИС растёт, плата растёт, бюджет растёт. А простоты нет…
В связи с этим, решились на эксперимент — построить конгломерат Ethernet на компьютере и контроллера с интерфейсом USB. Небезызвестный производитель FTDI относительно недавно предложил решение для USB3.0 на базе FT600. А этот маленький компьютер будет связывать между собой большой и удобный Windows управляемый ПК с контроллером, возможно обрабатывать первичные данные.
Встаёт вопрос, а как же будет работать маленький компьютер?
Желание использовать для этого дела Windows почему-то даже не появилось, а вот Linux — вариант реальный. Но беда в том, что ни кто в команде не знает, что с ним делать. Не долго думая на виртуальной машине появился Ubuntu Desktop. Да он работает. Сомнений не было, но хотелось посмотреть. Теперь к делу…
Я не буду описывать все мучения человека, который 20 лет пользовался Windows и тут на тебе — Linux. Но я постараюсь дать указания, куда смотреть и что искать, если что-то идёт не так.
Этапы:
- Выбор компьютераОдноплатные компьютеры пока брать не хотелось, т.к. не везде есть USB 3.0, не в каждом Gigabit Ethernet, который может вдруг понадобиться, да и реальная производительность таких плат — вопрос. Взял решение в коробочке с процессором Intel, крайне похожее на nuc: HDD 500Gb, RAM 2Gb, USB 3.0, Ethernet 100/1000. Не думаю, что это принципиальный вопрос.
- Ставим Ubuntu ServerИдем cюда. Качаем последнюю версию с надписью LTS, что означает долгосрочную поддержку и выход обновлений до 5 лет.
У меня был Ubuntu Server 16.04.2.
Ставим на пк с флэшки. Для этого: инструкция, как ставить на флэшку загрузочный образ, и инструкция, как ставить ОС.
Не забудьте при установке поставить галочку OpenSSH server, для доступа по сети к компьютеру. Будем передавать файлы и управлять компьютером с помощью утилит из Putty.
- Настраиваем и дополняем серверПомимо непосредственного контакта с контроллером, требуется создать экосистему, позволяющую компилировать проект (мне показалось удобным это делать на прототипе, а не на рабочей машине с кросс компиляцией), выделять IP адрес для управляющего компьютера пользователя. Самый удобный вариант установки дополнительных пакетов — использование онлайн хранилища deb пакетов, доступного через apt-get, что работает при подключении к интернету. К счастью, это не единственный вариант установки. Если хочется не зависеть от интернета и каких-то изменений в библиотеках и пакетах, то можно выкачать нужные пакеты и устанавливать их самому с помощью:
sudo dpkg -i <имя_пакета>.deb
Но для этого нужно знать все зависимости. К примеру, установка isc-dhcp-server потянула у меня следующие пакеты:
— libisccfg-export140
— libirs-export141
— isc-dhcp-server_4.3.3
Для начала, подключаем к интернету сервер через маршрутизатор, который ему выделит IP (если что ищите в поисковике настройки файла /etc/network/interfaces ), и делаем следующее:
Установка компилятора
Примеры драйверов FTD3XX от FTDI написаны на C++11. Можно ставить компилятор g++, а при компиляции нужно будет указать опцию -std=c++11
sudo apt-get install g++
Вводим пароль и соглашаемся.
Теперь в папке, где есть правильный Makefile можно написать
и будет компилироваться проект, но об этом позже.make
Установка DHCP сервера
Я использовал isc-dhcp-server. На ubunte пишем:
sudo apt-get install isc-dhcp-server
Вводим пароль и соглашаемся.
- Ставим драйвер от FTDI
- Компилируем программу
- Делаем демона для автозагрузки и слежения за программой
- Контролируем процессы
На данном этапе хочу остановиться и посмотреть отзывы уважаемых читателей, а главное знающих людей. Может стоит вносить коррективы. Тем не менее, по результатам появится вторая часть, более содержательная.
Комментарии (26)
Ryppka
05.08.2017 23:58+4Также неясно, зачем Windows. )) Ну, и не уверен, что g++ без build-essentials будет достаточно. В юзер спейсе с USB на линуксе, пожалуй, проще, но в целом соглашусь с предвдущим оратором.
akhrapotkov
07.08.2017 09:03Особенность прикладного ПО в том, что оно уже давно живёт и работает на Windows. Один из вопросов, при работе с windows напрямую, в том, что само устройство должно заканчиваться гигабитным ethernet'ом, но тогда сильно возрастает сложность реализации контроллера (кол-во памяти, производительность, поддержка протоколов). Представленное решение решает вопрос памяти, поддержки протоколов, производительности. А также, при решении задачи обработки данных на сервере, позволит упростить требования к ПК, сможет, в будущем, обеспечить доступ в интернет, для обновления ПО, диагностики и прочего.
Ryppka
08.08.2017 09:43А «слоеный пирог» с линух-одноплатником не пойдет? Там можно было бы и без USB передавать на linux?
akhrapotkov
08.08.2017 10:06Linux-одноплатник требует какого-то интерфейса между платой с микроконтроллером и системой на linux. Варианты есть, конечно. К примеру, можно найти одноплатный компьютер с интерфейсом PCI или ISA. Но в него тоже пойди залезь. Если PCI, то это делается на плис. Если дешево — то нужно много ног и разбираться в этом интерфейсе, потом драйвер. Если хочется меньше тратить ног, то выйдет дорого (PCI express). Тут же и среда разработки нужна. Даже не знаю, какой есть ещё быстрый интерфейс? Бывает быстрый интерфейс для подключения камеры, но это как-то не то.
Ryppka
08.08.2017 10:10Все равно мне кажется, что полноразмерный писюк годится только для прототипа и proof of concept. Одноплатник и по SPI какому-нить можно подключить или я что-то путаю?
akhrapotkov
08.08.2017 10:22На самом деле, там не полноразмерный пк, а в маленьком корпусе. Да и можно всегда поменять на любой, место позволяет. Проблема в том, что нужно много данных передавать и быстро. Ethernet 100 МБит реально на контроллере STM32 дает 60 МБит стандартными пакетами. А нужно раз в 8 больше. Конечно, пока это концепт. Как всё сложится — увидим. Боюсь, что всё-таки придется осваивать PCI express.
Ryppka
08.08.2017 16:0260 мбит Х 8 == 100 мбит ethernet?
Dima_Sharihin
08.08.2017 16:16В тексте речь шла про поток данных около 50 мегабайт в секунду, что соответствует 419 430 400 бит в секунду. И это без фрейминга и оверхеда протоколов (да хотя бы UDP)
по SPI какому-нить можно подключить
Внезапно SPI — медленный интерфейс. Даже на быстрых МК его скорость будет не больше 80-100 мегабит в секунду. И, обычно, чем навороченнее SoC, тем более ущербный на нем SPI и прочая низкоуровневая периферия.
Ryppka
08.08.2017 16:20Каюсь в незнании, но пропустит ли такой объем сотка? или это пиковая скорость и вы планируете буферировать и сбрасывать постепенно?
Dima_Sharihin
08.08.2017 16:29Сотка не пропустит принципиально ну вообще. Нужно понимать, что MAC, IP, UDP/TCP уровни вносят свой оверхед
и вы планируете буферировать и сбрасывать постепенно?
Эти вопросы лучше задавать автору статьи)
akhrapotkov
09.08.2017 15:03Выходит так. Если с обработкой на ubuntu всё выйдет быстро, то достаточно будет 100Мбит/сек. Если не выйдет или реализую только часть, то нужно будет передавать все данные, тогда бы гигабит подошел. Но в современных компах гигабит есть без проблем, поэтому не вызывает опасения такая реализация. Данные будут идти большими кусками.
Dima_Sharihin
09.08.2017 15:15Проблема тут уже не в скорости канала, а в алгоритме, что успеет отработать все эти данные в разумный период времени.
Вы рассматривали способы сокращения их объема?
Является ли задача вычислений непрерывной (к примеру мониторинг электросети) или кратковременной, но очень информативной (сейсморазведка).
Может достаточно найти большую оперативкуakhrapotkov
09.08.2017 15:25Одно включение может давать под гигабайт данных. Современные пк этим не удивишь и можно было бы передавать всё медленно, но сокращение времени обработки = увеличению количества.
Dima_Sharihin
08.08.2017 10:31Можно взять что-то вроде платы на базе 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 мегабайт в секунду, то это скорее всего не просто микроконтроллер
akhrapotkov
08.08.2017 10:49Я обдумывал, как можно использовать готовые одноплатные компьютеры, но не сложилось уверенности в таком решении. Мне кажется, что нужно будет буферизировать данные на контроллере, т.к. ОС будет прерывать работу интерфейса.
Сейчас всё строится от части по второму пути.Dima_Sharihin
08.08.2017 10:53PRU-ICSS — это все-таки независимая от ARM подсистема с собственной шиной и тактированием. Она продолжит работать даже когда ARM захлебнулся в потоке собственных событий.
Можно выделить область памяти в DDR под кольцевой буффер и раз в N тактов пинать хостовый контроллер с указанием до какого индекса в нем уже заполнены данные.
Upd: Главное, чтобы у вас хватило пропускной способности самой этой платы. Можно, конечно, взять зверя типа AM5728, но нужна ли вам такая числодробилка с двумя DSP (не считая ARM Cortex A15 и Cortex M4) на борту — еще вопрос
akhrapotkov
08.08.2017 11:13Звучит интересно. Но меня всегда отпугивали сложные решения от Texas instruments, не всегда понимаешь как это будет работать и что нужно для этого. Дикие datasheet. Попробую вникнуть. Хотя, здесь могут возникнуть проблемы с тем, что на этой плате сложно обрабатывать данные, так сказать на вырост (статистика, усреднение, исключение данных, вычисление интегралов). А если передавать их наверх, то нужен гигабитный ethernet.
Dima_Sharihin
08.08.2017 11:22Соглашусь, что порог входа в SoC от TI повыше, чем у той же малины или "рандомной материнки на Intel", но после недели-другой вдумчивого гугления и чтения даташитов все становится на свои места.
Дикие datasheet
Они на то и даташиты, чтобы быть дикими.
По своему опыту разницы в оных между ST, TI и AD особо не замечал.
На этой плате сложно обрабатывать данные
Простите, но этот зверек (C66x DSP) умеет делать 32 16-битных умножения или 4-float за такт при тактовой в 600/750МГц, куда уж быстрее? Дальше только FPGA
Изкоробки есть даже OpenCL (хотя нужен ли он — вопрос).
нужен гигабитный ethernet
Быстрый канал связи нужен вообще всегда, хотя бы для целей отладки
akhrapotkov
07.08.2017 09:42По поводу USBIP. Я не очень понимаю, как это мне должно помочь. Да, отлично, пролетят данные из USB в Ethernet. Но протокол кто будет реализовывать (не знаю, как работает USBIP)? Но самое интересное не это. Хочется в конце концов обрабатывать данные, а не пересылать их и всё. В принципе, такое и написать можно самому, имея USB драйвер от FTDI это просто.
Прошу прощения, если я несу чушь, не знаком в сущности с USBIP.pvvv
09.08.2017 10:44USBIP должен пробросить USB через ethernet прозрачно, как будто бы железка подключена к локальному usb.
Никаких протоколов реализовывать не надо.
но в каком оно сейчас состоянии — не знаю. последние обновления были в 2012.
nckma
Не понятно зачем во всей этой истории Ubuntu server и Ethernet.
Ну и подключали бы сразу ваше USB3 устройство к Windows.
Afterk
Может быть, программа умеет принимать данные только по сети. Или драйвера для нужного USB Device Class у FTDI нет.
nckma
Автор пишет Небезызвестный производитель FTDI относительно недавно предложил решение для USB3.0 на базе FT600.
Похоже он строит свой девайс на FT600 и для этого чипа есть и драйвера и библиотеки и примеры программирования.
akhrapotkov
Так точно