-
Постов
161 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о svedach
-
Звание
Частый гость
- День рождения 03.05.1982
Контакты
-
ICQ
Array
Информация
-
Город
Array
Посетители профиля
2 443 просмотра профиля
-
Sony IMX287 калибровка задержек LVDS
svedach опубликовал тема в Оптика и оптоэлектроника
Принимаю данные в FPGA, использую аппаратные IDELAYE2. В мануале на сенсор нет описания режима, при котором можно калибровать задержки, он всегда выдает коды синхронизации (раньше использовали CMV300 - так там такой режим специально предусмотрен). Т.е. нет стабильного значения на линии, для которого можно было бы пройти по всем задержкам и определить оптимальное значение. Оптимальное определяю как середину диапазона (наиболее широкого) задержек, в котором сигнал стабилен. Может кто уже работал с этими сенсорами и есть где-то такой режим, просто я не нашел? Или калибровать задержки надо как-то по другому? -
CMOS сенсор PYTHON (NOIP1SN1300/500/300) - режим ZROT
svedach опубликовал тема в Оптика и оптоэлектроника
Может кто-то работал с этим сенсором? Чтобы получить максимальную частоту кадров, я использую режим ZROT, для чего я записываю значение 0x0835 в регистр 192 и значение 0x0000 в регистр 193. В то же время я получаю горизонтальный сдвиг изображения (как на скриншоте). Если я убираю режим ZROT, то изображение встает на место. Может быть, мне нужно записать еще несколько значений в некоторые регистры? -
Может быть у кого-то был опыт запуска ThreadX в режиме SMP (symmetric multi processing) на Zynq-7000. Вроде в исходниках на гите (https://github.com/azure-rtos/threadx) есть порт, но не удается его запустить (проц подвисает на ошибке обращения к памяти). Буду рад любой помощи, кроме отсылок к Linux - проект устоялся и переходить на него нет смысла (сейчас все работает под ThreadX с одним ядром).
-
Добрый день! Вроде никаких особых требований к бланкингу нет, есть диаграмма подачи управляющих сигналов на сенсор (вроде все соотношения я выдерживаю): TXN pulse - Active Low Global Photodiode Transfer This pulse transfers signal charges from the photodiode to the pixel storage node. TXN’s rising edge triggers the frame readout. In a normal case, the TXN pulse should be positioned during vertical blank. However, if the user wants to push the frame rate limit, TXN can be placed after the last wavetable timing or during the last row readout like the diagram above. In this case, the vertical blank will be small to allow more frame rate. Самое интересное, что проблема не зависит от частоты кадров - т.е. что 5 Гц, что 1000 Гц - одинаково проявляется. Связывался с производителем, но они пока ничем не помогли (пересылал им дамп регистров, времянку генерируемых сигналов - от них замечаний небыло).
-
Немного реанимирую тему... Сейчас вернулся к работе с матрицей и столкнулся с проблемой шумящих точек в начале кадра: все перепробовали: чистили питание, перепроверили десерилизаторы, ставили/убирали терминаторы. Ничего не повляило. Если вырезать из матрицы горизонтальный кусок, который вычитывается (регион интереса) - проблема остается... Такое впечатление, что в начале кадра внутри матрицы что-то происходит, но непонятно, что. Может кто сталкивался с таким?
-
Спасибо, Rob. Умом тоже это понимал, но вдруг там FIFO какие есть или что-то иное... Вобщем проблема решена. Вместо анализа s2mm sts, ожидаю сигнал s2mm_wr_xfer_cmplt и после него формирую прерывание. При этом все работает как ожидается. Спасибо всем, откликнувшимся!
-
Это конечно можно, только не совсем понимаю, что это даст. Я почти уверен, что к моменту обработки прерывания весь путь данными еще не пройден и я увижу данные с латентностью 1 прерывание. Мне нужно в момент обработки прерывания гарантированно иметь данные в ДДР...
-
Добрый день. Есть кастомное ядро, которое через Xilinx DataMover и AXI SmartConnect (обслуживает еще других мастеров) пишет пару десятков байт в DDR. Полный путь такой: После записи (проверяется статус по шине s2mm sts) ядро генерирует прерывание. По прерыванию ARM забирает данные из памяти, при этом не забыв инвалидировать кеш (Xil_DCacheInvalidateRange((uint32_t)_mu_hw_vals, (valSize | 0xFF))). Вопрос состоит в следующем: как мне быть уверенным, что когда ARM отрабатывает прерывание, данные уже реально дошли до DDR - т.е. прошли через AXI SmartConnect и внутренности PS? Вопрос возник из-за того, что если поставить точку останова перед инвалидацией кеша, то данные видны, если после - то нет, но видны на следующем прерывании (подозреваю, что видны старые - от предыдущего прерывания). Есть ли какой-то механизм, обеспечивающий ожидание, что вся цепочка завершена и данные действительно записались в DDR? Или может я неправильно выстроил цепочку и надо зайти с драгой стороны?
-
Похоже все-таки не работает... Может кто использовал?
-
Xilinx SDK использование _Generic из c11
svedach опубликовал тема в Среды разработки - обсуждаем САПРы
Захотелось облегчить жизнь немного и использовать _Generic: #define mBlock_createInput(array, uid, label, defValue)\ _Generic((defValue), float_t: mBlock_createInputF,\ int: mBlock_createInputI,\ char*: mBlock_createInputS,\ default: 0) cJSON* mBlock_createInputF(cJSON* array, char* uid, char* label, float_t defValue); cJSON* mBlock_createInputI(cJSON* array, char* uid, char* label, int32_t defValue); cJSON* mBlock_createInputS(cJSON* array, char* uid, char* label, char* defValue); В коде использую так: mBlock_createInput(group, "MIN_VALUE", "Minimal value", 0.0); Код компилируется и работает. Но постоянно висит ошибка "Syntax error": Подскажите, пожалуйста, почему? В опциях компилятора включал --std=c11, но не помогло. Как я понимаю ругается проверка синтаксиса, но компиляция проходит и все работает... -
Последовательность правильная (только надо отслеживать сохранение проекта...). Возможно внесли изменения и не нажали "Сохранить" - отсинтезился проект с ошибкой/не полный...
-
думаю проблема в dcm_locked - он не заведен никуда. Попробуйте завести его на FCLK_RESET0_N для начала
-
Обычно блоки подключаются через AXI Interconnect. Выложите полностью скриншот блочного проекта.
-
Добавьте скриншот.
-
Работаю с LUX1310, только монохромной. Проблема вертикальных полос - неравномерность усилителей АЦП. Их 16 шт. и полосы повторяются через 16 столбцов. Полностью компенсировать не удается - с ростом температуры значения плывут... Сам устраняю подстраивая уровень черного и усиление для каждого канала (АЦП). У нас кстати матрица сильно греется, у Вас есть такая проблема? Иногда появляется горизонтальная линия, положение которой зависит от времени экспозиции - это связываю с тем, о чем говорил polyvyannyy... Динамический диапазон на больших FPS у матрицы, кстати, меня разочаровал...