AVR

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

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

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

Мне нужно сгенерировать в ПЛИС паттерн и принять его в Raspberry Pi (3 Model B). Нужно чтобы вместо покупной камеры с MIPI CSI-2 работал мой источник в ПЛИС с моей прошивкой. Понимание формата фреймов MIPI CSI-2 есть, макетная плата с RPi Compute Module есть, есть захваченный CCI обмен, есть ПЛИС подключенная ко второму порту CSI-2 на RPi. Ну почти всё есть, но не могу собрать целую картину. Сомневаюсь что если я просто подам CSI-2 поток минимально допустимого разрешения то вдруг всё чудесным образом заработает. Это сложная для меня задача, но я за нее взялся, и очень хочу завершить. Подводных камней тут миллиард, регистры сенсора не ясны и неясно нужен ли этот CCI вообще. Но чисто электрически схема есть, он будет давать нужные уровни как по стандарту MIPI CSI-2. В ПЛИС у меня есть мой генератор, он уже умеет все эти клоки подавать и данные, считать ECC, считать CRC payload-а, ну всё есть, пока для 1-lane. Почти

Добрый день! :) И вот, пройдя большой путь настройки RPi, ковыряния device-tree, заставив работать это всё на своем макете с покупным сенсором, сумел нацедить I2C обмен сенсора и RPi, вот мои данные: cci.txt Первое что смущает, там имеют запросы без ответов. Просто по 1 байту, даже адрес регистра не передает. И только я полез в спецификацию читать регистры... и не нашел там никаких стандартных регистров. Где же тогда читать про то, какие регистры есть в сенсоре? Мне нужно просто обмануть распберишку, что моя ПЛИС это сенсор. Более того, я вижу в некоторых реализациях, например от Altera, про I2C упоминания НЕТ. Даже если в моей имитации MIPI CSI-2 не требуется контроль усиления и прочего, для детектирования сенсора все равно нужен CCI/I2C или всё же нет? Просто думаю, может перескочить этот этап, и просто подать минимально поддерживаемое на RPi разрешение 640x480 - авось заработает, не?

Прошло много времени, уже не актуально?

Что значит "или не IP"? Имеется ввиду не-IP-протокол?

Самые "кровавые" споры это о терминологии...

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

Никто с этим не спорит, но есть минимальные требования и кварц этому условию удовлетворяет. Удачи! Но если вдруг что, Вы знаете почему ;)

Работы USB от RC цепочки не будет до тех пор, пока Нибиру не сместится на небосклоне еще немного. В общем, переходите на внешний кварц, только он обладает необходимой стабильностью.

Так и есть - кода драйвера нет, это лишь тестовая программа. Автор темы, плохо читая то что его просят, лишь задерживает решение своей проблемы. У меня есть догадки почему у него не работает, но без кода драйвера я это понять не смогу.

Не все переваривают VHDL (в плане, могут легко его читать). Если можно, выложить TLP в простом виде: 0F 44 5C 31 ... и так далее. Второе, с помощью каких функций и каких параметров были получены адреса, в которые ПЛИС пытается закармливать пакеты? Где уверенность, что хост готов их принимать по именно этим адресам? Вы самое интересное/важное от публики прячете :) Вроде с Вами уже обсуждали, что в x86 чуть ли не три "вида адресов", они должны быть корректно отображены, и то что годится в пространстве ядра, не годится для адресов шины и требуется отображение. Вот это я и хочу видеть. Я конечно, судя по моему аватару, Linux-озабоченый, но код драйвера Windows понять смогу.

В "бар" ведь пишет ПК, так? И в том же предложении "ПК игнорирует запросы" - а они откуда? Кто же задает эти адреса? Захардкодили что ли? Не помню я проблем, когда пробовал на PCI-E 3 разъеме, никаких отличий быть не должно. Скорее отличие в том, что тепличные условия эксперимента сменились на другом ПК и всё сломалось, т.к. было неверно изначально.

На счет дробления не скажу, но Вы попробуйте сначала поймать то что приходит, а раскладывать... не поверите, по... адресу! :) Там же адреса у пакетов есть. Берем начальный адрес + величину payload.