[Art55555 0]

Требования к ПО, обеспечивающему работу платы+ USB3.1

Предполагается использование данной микросхемы.

Общая инфа

 

http://www.ftdichip.com/Products/ICs/FT602.html

ссыль на ютюбе

https://www.youtube.com/watch?time_continue...p;v=y0XTMUNLJp0

 

дружественное (подходит и для нашего 602) по 6хх серии описание

http://www.ftdichip.com/Products/ICs/FT600.html

Описание функций:

http://www.ftdichip.com/Support/Documents/...ers%20Guide.pdf

 

Требования будут представлены в несколько размытом виде, так как я не знаю, как работает USB 3.1. Предполагаю, что он работает так же, как и USB 2.0, т.е. инициатором передачи данных от платы может быть только хост.

Общая постановка задачи.

Существуют 2 режима обмена данных с платой АЦП-USB3.1

1. Блочный режим. Компьютер посылает в плату команду и ожидает от нее ответа. Между посылкой команды и ответом никакие команды не посылаются. Если за заданное время ответа не поступает, то возвращается код ошибки. Команда представляет собой блок данных, размером 50 … 65536 байт.

Ответ – блок данных размером до 2^20 + 20 байт.

На каждую команду всегда известно количество получаемых байт (это значение может передаваться в параметрах ф-ии).

 

2. Потоковый режим. В этом режиме плата генерирует поток данных, компьютер должен его получать с помощью CallBack функции. CallBack функция на стороне приложения должна выполняться максимально быстро. Задачи CallBack функции

- войти в критическую секцию (здесь может быть максимальная задержка)

- проверить переполнение буферов

- переслать блок данных в буфер

-увеличить значение счетчика буфера

- выставить событие о готовности данных (Event)

- выйти из критической секции.

 

Задач другого потока в приложении, которая работает с этой же критической секцией:

- ждать установки события о готовности данных (Event)

- войти в критическую секцию

- сбросить событие о готовности данных (Event)

- переслать блок готовых данных в другой буфер

- выйти из критической секции.

Как видно, тоже очень быстро, т.е. долгого ожидания входа в критическую секцию в CallBack функции не будет.

 

Скорость потока данных в потоковом режиме можно оценить так:

Вариант 1. Частота дискретизации 50 МГц, каждое передаваемое слово 8 байт. Итого 400 Мбайт/сек или 3200 Мбит/сек.

 

или

 

Вариант 2. Частота дискретизации 50 МГц, каждое передаваемое слово 4 байт. Итого 200 Мбайт/сек или 1600 Мбит/сек.

 

Для потокового режима должна быть предусмотрена команда “Stop”, которая прекращает непрерывную передачу данных.

 

Итого, определяется следующий набор команд:

1. Открытие USB платы.

Очевидно, это должно быть несколько команд:

- Получение количества подключенных к компьютеру плат с получением их серийных номеров и версии HardWare. Серийный номер и версия HardWare должны прописываться в EPROM USB контроллера. Для этого должен быть написан отдельный софт, который программирует EPROM контроллера и отдельный софт, который может читать записанную версию серийного номера и версиии HardWare и записывать их в EPROM.

-

2. Открытие нужной платы по серийному номеру.

3. Аппаратный сброс цифровой платы. Очевидно эта команда нужна, она должна выполняться на уровне контроллера USB, может быть путем установки сигнала на отдельной линии.

4. Программирование FPGA из отдельного файла.

5. Передачи-прием данных по I2C, если он имеется у контроллера и не задействован.

6. Передача команды (блока памяти) в плату и ожидание заданного количества байт от нее. В команде передачи задается время Time-out ожидания ответа от платы

7. Запуск потокового режима с указанием количества передаваемых байт в CallBack функции.

8. Останов потокового режима.

9. Закрытие устройства.

 

Требования к ПО.

Не должно быть никаких бесконечных циклов в потоках. Ожидание событий (прихода команды или ответа от платы – только через Event.

На первом этапе софт необходимо оформить в 32 разрядную DLL.

После отладки, необходимо будет сделать 64 разрядную DLL.

 

Предложения принимаются в личку. Уточняющие вопросы, пожалуйста, сюда.

 

 

[Manfred 0]

Ровно 3200 Mbps не получиться - это максимальная пропускная способность паралельного интерфейса микросхемы FTDI - т.е. всегда будут потерянные данные.

 

В Windows надо принимать по событию, в отдельном потоке и писать в потокозащищенное FIFO в котором уже храняться заранее сформированные буферы под пакеты максимального размера (чтобы не было динамического выделения памяти). Скорость приема будет зависить от железа компьютера.

 

Если плата FPGA вашего производства, то USB 3.0 очень чувствительно к разводке. Как линий передачи данных так и к питанию микросхемы.

 

Чтобы не было переполнений буфера можно использовать режим Bulk, тогда если данные компьютером не прочитаны микросхема на плате перестает посылать данные и выставляет сигнал FULL

 

Насчет программирования ПЛИС, то на этой микросхеме помоему не удастся съэмитировать процесс программирования ПЛИС или даже подать сигнал Reset на ПЛИС - она помоему не содержит процессора, а интерфейсы программирования ПЛИС отличаются от интерфейса FIFO

Изменено 4 апреля, 2018 пользователем Manfred

[Art55555 0]

Ровно 3200 Mbps не получиться - это максимальная пропускная способность паралельного интерфейса микросхемы FTDI - т.е. всегда будут потерянные данные.

 

ок

 

В Windows надо принимать по событию, в отдельном потоке и писать в потокозащищенное FIFO в котором уже храняться заранее сформированные буферы под пакеты максимального размера (чтобы не было динамического выделения памяти). Скорость приема будет зависить от железа компьютера.

 

Да, это тоже понятно.

 

Если плата FPGA вашего производства, то USB 3.0 очень чувствительно к разводке. Как линий передачи данных так и к питанию микросхемы.

 

USB 3.0 не разводили, DDR2-3 только. Буду благодарен за рекомендации, если что.

 

Чтобы не было переполнений буфера можно использовать режим Bulk, тогда если данные компьютером не прочитаны микросхема на плате перестает посылать данные

ок

 

Насчет программирования ПЛИС, то на этой микросхеме помоему не удастся съэмитировать процесс программирования ПЛИС или даже подать сигнал Reset на ПЛИС - она помоему не содержит процессора, а интерфейсы программирования ПЛИС отличаются от интерфейса FIFO

Хорошо, у нас процесс загрузки ПЛИС может осуществляться с флешки, не вопрос.

 

 

 

[Manfred 0]

Вы не написали где находитесь территориально, такие программы надо отлаживать с железом. Также не написали, что за IDE вы хотите использовать (Visual Studio C++/C#, C++ Qt, C++ Builder)

 

С разводкой, похоже, надо моделировать в современно САПР. С платами с которыми я работал получилось все плохо (использовали Cypress FX3), стабильно работало только на коротком кабеле. Также не следует ставить маленький разъем USB, он рвет на плате проводники, рано или поздно. Паралельная линия данных ПЛИС - FTDI также будет звинеть, особенно на кодах 0, -1 - надо использовать поменьше напряжение ножек IO и ограничить ток в ПЛИС.

 

Не понятно, что включает в себя работа, требуется ли программировать ПЛИС? Либо это только конфигурирование микросхемы FTDI и организация протокола взаимодействия на основание библиотек FTDI, детали протокола должны быть скрыты от пользователя в библиотеках dll, чтобы он самостоятельно не смог подключиться к этому устройству

Изменено 4 апреля, 2018 пользователем Manfred

[Art55555 0]

Вы не написали где находитесь территориально, такие программы надо отлаживать с железом. Также не написали, что за IDE вы хотите использовать (Visual Studio C++/C#, C++ Qt, C++ Builder)

 

С разводкой, похоже, надо моделировать в современно САПР. С платами с которыми я работал получилось все плохо (использовали Cypress FX3), стабильно работало только на коротком кабеле. Также не следует ставить маленький разъем USB, он рвет на плате проводники, рано или поздно. Паралельная линия данных ПЛИС - FTDI также будет звинеть, особенно на кодах 0, -1 - надо использовать поменьше напряжение ножек IO и ограничить ток в ПЛИС.

 

Не понятно, что включает в себя работа, требуется ли программировать ПЛИС? Либо это только конфигурирование микросхемы FTDI и организация протокола взаимодействия на основание библиотек FTDI, детали протокола должны быть скрыты от пользователя в библиотеках dll, чтобы он самостоятельно не смог подключиться к этому устройству

 

C++ Builder

Да, требуется советы по разводке. Иными словами ищется человек, который данную работу УЖЕ ВЫПОЛНЯЛ и сможет осуществить шефский контроль над USB- частью.

Да, нужно сделать что-то типа фифо на ПЛИС (хотя бы для теста).

 

[MegaVolt 25]

Да, нужно сделать что-то типа фифо на ПЛИС (хотя бы для теста).

https://github.com/AndreZheng/QM_XC7A35T_DDR3

https://github.com/AndreZheng/QM_CYUSB3014_USB3.0

 

Тут демо примеры для китайской борды с FX3 там как раз есть пример фифо.

 

[Art55555 0]

https://github.com/AndreZheng/QM_XC7A35T_DDR3

https://github.com/AndreZheng/QM_CYUSB3014_USB3.0

 

Тут демо примеры для китайской борды с FX3 там как раз есть пример фифо.

 

Да, спасибо, посмотрим.

Тем не менее, нужен человек, который возьмётся за USB-вую часть.

 

[yes 5]

у FTDI есть демо платки для FT60x, по два варианта Xilinx/Altera 601/602, то есть 4 варианта. для каждого выбрана одна из дешевых демо-плат с ПЛИСиной. ну и соответственно проект(ы), который максимально загружает FT60x со стороны плисины + примеры для винды, которые измеряют пропускную способность.

 

имхо, самый простой способ посмотреть "систему в целом"

 

[archip 0]

Нашли исполнителя?

[Art55555 0]

у FTDI есть демо платки для FT60x, по два варианта Xilinx/Altera 601/602, то есть 4 варианта. для каждого выбрана одна из дешевых демо-плат с ПЛИСиной. ну и соответственно проект(ы), который максимально загружает FT60x со стороны плисины + примеры для винды, которые измеряют пропускную способность.

 

имхо, самый простой способ посмотреть "систему в целом"

 

Да я знаю, что есть такие платы, примеры тоже видел. Дело в том, что мне нужно именно то, что написано в ТЗ (см выше). Целью темы не "раскачать" и найти проблему, а найти исполнителя, который уже знаком с данной тематикой.

За материалы отдельное спасибо, они, безусловно, помогут как по железу, так и по программному обеспечению.