[Worldmaster 0]

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

Помогите понять в чем преимущество алгоритмов.

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

Пакет поступает на комп по сути по запросу с компа через FT602.

Есть два варианта алгоритма:

1. Вроде как самый простой. FT602 можно управлять потоком сигналом, пусть будет OE. Так вот вариант один при запросе с компа плис триггерит камеру и она начинает отправку кадра с первого пикселя. Далее за счет того что скорости приборов разные я удерживаю OE в 1 и все ждут пока наберется какой нибудь буфер данных. 16 пикселей например. Потом опускаю OE и отправляю этот кусок, затем опять ставлю 1 и опять жду. И так далее дергаю ногу пока не будет получен весь кадр. 

Как преимущество вижу что я всегда буду получать на комп новые данные кадра.

 

2. Вариант 2. Организую 2 буфера. Чтение и запись. Один процесс занимается исключительно записью в буфер. Чтение происходит из буфера чтения. Процесс обработки заключается в том что при достижении половины буфера записи инициируется передача данных в RAM. Если из буфера чтения считана половина то инициируется добавка из RAM.

Данные пишуться в RAM циклично, читаются также циклично. Суть в том чтобы с компа подавать запрос на правильное количество байт. Но там по условиям апи надо задавать количество для чтения.

Как мне кажется это хорошо потому что по сути неблокирующие операции. Но чтение происходит быстрее чем получение новых кадров и может так получится что подгружаться из RAM могут данные с прошлого цикла.

С одной стороны частота камеры около 300 кадров в секунду. теоретически процесс который будет сниматься не будет таким быстрым и вроде как данные с предыдущего кадра сильно картину не должны испортить.

Вот как вы считаете как все таки сделать правильно что ли.. или логичнее. И еще надо учесть что камера будет вторая потом. То есть ее также надо будет впихнуть в процесс.

 

В плисе выделить буфер под кадр 256к слов по 32бита никак не получается. то есть раму все равно придется пользовать.

Или может существуют какие нибудь рамы чтобы можно было с одной стороны писать а с другой стороны одновременно читать? Но я такие не нашел. 

 

 

[_pv 79]

там есть FIFO внутри ft602, а так же режим 245 с дерганием WR хоть на каждый отдельный байт. зачем городить то же самое снаружи да ещё и какими-то блоками по 32 байта?

[Maverick_ 15]

работаем по заполнению и освобождению фифо на FT602

если скорость поступления image from camera > скорости USB 3.0 (FT602) тогда через буферизацию кадра изображения внешней памяти (SDRAM, DDR, SRAM)

[Worldmaster 0]

В 11.10.2023 в 17:58, _pv сказал:

а так же режим 245 с дерганием WR хоть на каждый отдельный байт.

Этот режим и использую. Но буфер размером всего 4096 байт. А после заполнения куда девать данные с камеры пока идет передача?? 

И к тому же как быть в случае с двух камер? Данные же идут одновременно. И их надо стыковать. Вначале одну строку одной камеры затем строку со второй. 

И размер картинки не сжатый 320*320 при 300 fps.

 

В 11.10.2023 в 18:53, Maverick_ сказал:

если скорость поступления image from camera > скорости USB 3.0 (FT602) тогда через буферизацию кадра изображения внешней памяти (SDRAM, DDR, SRAM)

То есть из SDRAM лить сразу в фифо ?? А пока идет команда отправки в фифо данные с камеры то куда девать?

 

[_pv 79]

27 minutes ago, Worldmaster said:

Этот режим и использую. Но буфер размером всего 4096 байт. А после заполнения куда девать данные с камеры пока идет передача?? 

И к тому же как быть в случае с двух камер? Данные же идут одновременно. И их надо стыковать. Вначале одну строку одной камеры затем строку со второй. 

И размер картинки не сжатый 320*320 при 300 fps.

буфер 16k, его вроде можно не по 4кб на 4 канала, а все 16к на один канал сделать

данные с камеры 30МПикселей/c, 60 если с двух, что меньше чем скорость запихивания в фифо 400МБайт/c.

и меньше чем скорость USB3 с которой данные из фифо забирают, и есть подозрение что у ft60x буфер сделан достаточного размера, чтобы в его размер скорость передачи данных особо не упиралась.

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

[Worldmaster 0]

В 11.10.2023 в 23:11, _pv сказал:

буфер 16k, его вроде можно не по 4кб на 4 канала, а все 16к на один канал сделать

Нельзя. 

Цитата

When the FT600 or FT601 is configured as the 245 Synchronous FIFO bus or 1 channel in the multiChannel FIFO bus mode, the FIFO buffer is configured as 4 KB * 2 (double buffered) each on the RX and
TX channels.
 

Или это значит что 8кб на RX и 8 на TX?? 

Но везде в коде фигурирует что запись за одну транзакцию надо делать 4kb.

 

В 11.10.2023 в 23:11, _pv сказал:

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

Тогда придется разбирать кадр на стороне компа. Это не очень хорошо.

 

[Maverick_ 15]

Мое мнение с камеры кадры постоянно отправлять на комп, если команда с ПК пришла то примениться она уже на следующем кадре или через несколько кадров

Cкорость принятия данных с камеры:

320*320*3*8*300 =7.4*10^8 bit

2* 7.4*10^8  = 1.5*10^9 bit/s

По логике скорость 1,5Гбита/с - комп должен успевать принимать данные с камер, если драйвер + программа будет хорошо работать и операционка правильно настроена.

То можно кадры отправлять сразу на ПК, но если ПК подвиснет будет потеря данных.

Рассмотрите вариант работы через SDRAM память, чтобы исключить потерю кадров (возможную) - не знаю насколько критично Вам потеря кадра/части кадра, и чтобы иметь возможность отправлять на комп целыми кадрами

Как альтернатива - логика ждет начало нового кадра и его отправляет - после возникновения сбоя передачи

 

скорость работы SDRAM какая? У Вас SDRAM или DDR3/4?

если DDR3/4 тогда можно организововать двойную буфферизацию - думаю скорости памяти должно хватить - желательно посчитать, попробовать вначале (например передавать значения счетчика - будут видны пропуски данных)

[_pv 79]

47 minutes ago, Worldmaster said:

Нельзя. 

Quote

When the FT600 or FT601 

так ft602 или ft600/601?

там в примерах гоняют видео с 148.5МГц пиксельклоком. 16ти битным YCrCb,

ваши 60МГц с двух камер, пусть даже и полноцветные 24 бита, всё равно меньше.

смешивать картинки от двух камер через линию, через 32байта или через 4кб в плане разбора от через пиксельного не особо отличается, не хотите разбирать на стороне компа - ищите память под кадровый буфер.

а у ft602 для этого 4 канала есть, сам разберёт. ему только номер канала надо подмешивать в младший байт в начале записи в фифо.

[Worldmaster 0]

В 12.10.2023 в 09:23, _pv сказал:

так ft602 или ft600/601?

Да. Перепутал. 601 у меня чип.

 

В 12.10.2023 в 09:23, _pv сказал:

а у ft602 для этого 4 канала есть, сам разберёт

не разберет. У них в апи 4 точки endpoint. и при запросе данных нужно конкретно читать с нужного endpoint.

Поэтому я принято решение использовать 245 режим. Рама то есть встроенная. Хочется чтобы это было максимально быстро. А так при запросе придется держать FT в ожидании пока кадр сформируется в SDRAM, затем передавать в буфер. 

 

В 12.10.2023 в 08:32, Maverick_ сказал:

скорость работы SDRAM какая? У Вас SDRAM или DDR3/4?

обычная sdram на 166мгц. Она работает через корку и максимальный блок который можно записать это 255 байт. А еще сюда прибавить время на подачу команд и ожидание Tras после записи. 

 

Но потихиньку прихожу к выводу что надо и правда при запросе с ft дергать камеру и начинать сливать данные в комп сколько может. А пока буфер ft освобождается писать в временный буфер без SDRAM. по идее FT же должна быстро освобождать его.