Jump to content

    

MIPI на MAX10

21 hours ago, aaarrr said:

Для RPi есть вот такой проект, если нет задачи непременно эмулировать поддерживаемый сенсор.

Спасибо, очень интересная ссылка, как минимум на время отладки это поможет. Но мне нужно еще аппаратное сжатие, а raspiraw может не позволить этого

Share this post


Link to post
Share on other sites
В 04.07.2019 в 18:04, AVR сказал:

Добрый день! :)

И вот, пройдя большой путь настройки RPi, ковыряния device-tree, заставив работать это всё на своем макете с покупным сенсором, сумел нацедить I2C обмен сенсора и RPi, вот мои данные: cci.txt

Завтра повспоминаю, покопаюсь. У меня задача была как раз обратная - исключить RPi, а сигнал с сенсора забрать на ПЛИС. Точно помню, что без видеопотока CSI что-то висло,  когда только I2C подключено было. А вот при отключении I2С, но при наличии потока CSI помнится работало. Это когда я конфигурировал сенсор другим процом снаружи, а от RPi просто i2c отрезал. Но возможно на I2C я в это время сажал еще один такой же сенсор, у которого CSI был отрезан. Надо проверить.

Share this post


Link to post
Share on other sites

Нет, приходится сажать на i2c еще один сенсор,  чтобы видео CSI2 работало. Там похоже драйвер контролирует как минимум ack по i2c. Если просто отрезать - не работает. Глубже уже не копал, просто ack ему надо или еще что-то. 

Для проверки можете оставить только i2c от сенсора до RPI и подать CSI видео со своего девайса. Так точно работает. А потом, когда все заработает, сделать заглушку на ПЛИС, которая прикинется сенсором на i2c. 

Share this post


Link to post
Share on other sites
On 7/8/2019 at 1:49 PM, alexPec said:

Для проверки можете оставить только i2c от сенсора до RPI и подать CSI видео со своего девайса. Так точно работает. А потом, когда все заработает, сделать заглушку на ПЛИС, которая прикинется сенсором на i2c

Хорошая мысль, прекрасный план. Попробую просто запрашивать 640x480 с сенсора в raspivid, а сам подсовывать ему свой поток, думаю там четкой связи по времени придерживаться не нужно, раз ему нужно просто видеть ответы по I2C.

Share this post


Link to post
Share on other sites
11 часов назад, AVR сказал:

Хорошая мысль, прекрасный план. Попробую просто запрашивать 640x480 с сенсора в raspivid, а сам подсовывать ему свой поток, думаю там четкой связи по времени придерживаться не нужно, раз ему нужно просто видеть ответы по I2C.


Да, у меня после команд сенсору видео с разницей порядка нескольких секунд появлялись. Там есть какой-то таймаут на  появление видеопотока, но большой.

 

Share this post


Link to post
Share on other sites
On 7/12/2019 at 9:27 AM, alexPec said:


Да, у меня после команд сенсору видео с разницей порядка нескольких секунд появлялись. Там есть какой-то таймаут на  появление видеопотока, но большой.

 

А, секунды, нормуль. У меня есть eval альтеровского MIPI CSI-2 ядра на TX. Не компилируется но моделируется. Вот я из него тайминги выдеру, там достаточно 160 МГц на одной lane для 640x480. Очень надеюсь что распберишка не откажется кушать на 160 МГц, 160 ведь не 1600. Знаю только что минимум это 80 МГц.

Share this post


Link to post
Share on other sites
On 7/12/2019 at 9:27 AM, alexPec said:

Да, у меня после команд сенсору видео с разницей порядка нескольких секунд появлялись. Там есть какой-то таймаут на  появление видеопотока, но большой.

Прошу помощи!

Просимулил IP ядро MIPI CSI-2 от альтеры. Линии high speed поймал в файл. Анализирую скриптом на Python. Так начинается поток:

1110000000000000000000000000000000000000000000000000000000000000000000111010111100000100000000100000011000000001000001010000001100000111000000001000010010000010100001101000000110000101100000111000011110000000010001000100001001000110

Если найти синхробайт и перевести это в массив байт, выходит вот что:

hdr(32)= 01111000001000000001000000110000
data(5164) orig: 1E 04 08 0C 10 14 18 1C 20 24 28 2C 30 34 38 3C 40 44 48 4C 
data(5164) swap: 78 20 10 30 08 28 18 38 04 24 14 34 0C 2C 1C 3C 02 22 12 32

Тут у меня swap это байты с перевернутым ходом бит (0x10 и 0x08 очевидный пример). Почему я уверен что это правильные байты? Хоть и IP ядро зашифровано по самые помидоры, но единственное что там открыто это байты на передачу, там есть тестовая реализация передающей части. Их я и увидел в симуляторе, и... они именно такие, какие извлекает мой скрипт.

 

В чем состоит моя проблема? Я не могу посчитать ECC, не могу понять где тут заголовок. И вроде стандарт четко всё описывает. Причем у меня на Python есть ECC как по 24 битам так и по 64 битам. Правильно считает синдром, умеет корректировать ошибку, детектировать две ошибки. Корректность реализации ECC я установил из примера в стандарте. Но к сожалению, в стандарте не вижу нормального тестового вектора.

 

Такой вектор есть для подсчета CRC16 - тут у меня всё сходится, считается верно. Но от ECC я уже в панике, работа завязла. И ни в каких проектах с гитхаба, будь то TX/RX, не могу увидеть что и как они считают для ECC.

 

Что можно предпринять, что еще попробовать? Что-то в каком-то режиме может запустить?

Share this post


Link to post
Share on other sites
22 часа назад, AVR сказал:

В чем состоит моя проблема? Я не могу посчитать ECC, не могу понять где тут заголовок. И вроде стандарт четко всё описывает. Причем у меня на Python есть ECC как по 24 битам так и по 64 битам. Правильно считает синдром, умеет корректировать ошибку, детектировать две ошибки. Корректность реализации ECC я установил из примера в стандарте. Но к сожалению, в стандарте не вижу нормального тестового вектора.

 

Ну сам я этот ECC не считал, я просто видел поток с камеры. Именно с камеры. Сколько я помню из всего это MIPI, CSI и DSI вроде разные вещи (т.е. RX и TX), отличаются прилично. Помню что захватил поток с камеры и со спецификацией CSI все это сходилось, как положено.

Что касается ECC - покопался тут у себя, нашел от латтиса такую штуку (файлик). Там есть функция get_ecc, и там через XORы доступно расписано как он вычисляется. Думаю тому вычислению можно верить.

csi2_model.v

Share this post


Link to post
Share on other sites
On 9/16/2019 at 9:09 PM, alexPec said:

Что касается ECC - покопался тут у себя, нашел от латтиса такую штуку (файлик). Там есть функция get_ecc, и там через XORы доступно расписано как он вычисляется. Думаю тому вычислению можно верить.

csi2_model.v

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

Share this post


Link to post
Share on other sites
On 9/16/2019 at 9:09 PM, alexPec said:

Что касается ECC - покопался тут у себя, нашел от латтиса такую штуку (файлик). Там есть функция get_ecc, и там через XORы доступно расписано как он вычисляется. Думаю тому вычислению можно верить.

csi2_model.v

Погонял я эту реализацию из этого файла. Понял как мне надо байты переставить. С моей реализацией видимо сходится - уже хорошо. Однако как бы я не изворачивался, переворачивал байты биты, порядок, как бы не возвращал порядок бит ECC - я всё еще не могу получить нормальное ECC для заголовков, я вообще заголовков корректных не вижу, хотя структура данных регулярная и старт-последовательность корректная.

 

Это меня пугает. Не понимаю на что теперь опереться. Битовая последовательность корректно начинается, байты на передачу совпадает с тем что скушал мой парсер из симуляции. Я в тупике.

 

Где бы еще референс потоки взять? Альтеровская документация на их ядро тупо ничего полезного не сообщает.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now