AVR

Рад что нашлось решение по фен-шую, но я имел ввиду что заменить массив и сам generate на что-то иное. Наверное чем дальше, тем неудобнее будет мое решение.

Раз эксперты говорят нельзя, попробую предложить еще одно решение, возможно о котором не часто вспоминают. Если возможности языка не позволяют что-то, почему бы это не генерировать... скриптом?! Ну языке Python или кому что ближе и приятнее. Вот я на Python никогда не стесняюсь что-то вспомогательное генерить рядом с верилогом.

Предлагаете вручную выпилить работу с I2C? В принципе это вариант. Попробую его обязательно и отпишусь. Lattice поставляет платы для подключения Crosslink к Raspberry конкретно и именно такая плата переходник у меня сейчас. Там ноль информации про I2C, документация молчит. Завтра первый рабочий день, буду пытать техподдержку, явная же проблема тут в наличии Меня просто смущает что MIPI CSI-2 D-PHY это интерфейс, неразрывно связанный с CCI(I2C), но ядро Lattice Crosslink вообще не считает нужным выбросить наружу SDA/SCL. Мне в личные сообщения человек подсказал что на Jetson TX2 от Crosslink принималось вообще без I2C, видимо у Raspberry это явно не так, о чем писали мне выше

./raspiraw -f 25 -w 640 -h 480 Using i2C device /dev/i2c-0 RaspiRaw: Probing sensor ov5647 on addr 36 RaspiRaw: Probing sensor imx219 on addr 10 RaspiRaw: Probing sensor adv7282 on addr 21 RaspiRaw: No sensor found. Aborting Но шлейф подключен, кадры генерируются (смотрю на светодиодах), клоки на плате есть. Оно хочет I2C. С штатной камерой Raspberry работает нормально. Тут что угодно может быть не так

Я нагло заявлю что лучше бы на Python, ой не бейте меня

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

У Crosslink есть демка CrossLinkDualCSI2toCSI2DemoKitUG117.pdf и там на пятой же странице показано как они пробросили I2C с обоих сенсоров, там стоит типа I2C-мультиплексор Проблема Crosslink в его версии CMOS в CSI2 что в документации ни слова о I2C или CCI, ни то как его подключать, никак его пробрасывать. На отладочной плате тактовые входы шарятся с I2C, т.е. если надо клок с генератора на плате - задействуй I2C. Не понимаю, как тогда быть??? Подозреваю двунаправленность. Техподдержка где плату покупал пока на каникулах

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

Спасибо, честно говоря не знал!

Теперь я тоже сижу с крослинком. Сделал генератор с простым паттерном - пока просто заливка одним цветом 640x480, ровно 25 кадров в секунду. Научился я это моделировать. Есть у меня переходник для Raspberry Pi на выход tx connector 1. Сама Raspberry Pi 3 работает с реальным сенсором. Остается ключевой вопрос - а где там IO0/1 подключать и SDA/SCL??? Неужели оно двунаправленное и не требуется работает через IO0/1 и CCI (он же I2C)? Я завтра попробую вот просто так, но с живым сенсором оно не работало так. Я надеюсь что Crosslink реализует двунаправленный CSI-2 и тогда за IO0/1+I2C оно не полезет. Видимо расберишный сенсор камеры не давал поток без этих команд, а если крослинг погонит поток и без этого, то надеюсь примет.

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

Не, меня сотрудники Резонита поправили. Заказал, неделю назад уже, толщиной 1.5 мм, допускается толщина от 1.37 до 1.77 мм, и 1.5 мм входит в этот диапазон. Но меня беспокоит, что они называют погрешность +/- 0.3 мм что запредельно много и может запросто уничтожить всю совместимость, но другого выбора мне не дали. Но инженер Резонита успокоил меня что такие большие отклонения это редкость. Действительно, металлизация уже учтена в итоговой толщине платы. Плюс, они не смогли мне предложить необходимую по стандарту обработку краев, смешно но мне придется это делать напильником ))))) Для прототипа сойдет.

Подскажите, пожалуйста, использование например FPGA со встроенным PCI-E уже гарантирует, что как минимум физическая часть будет успешно проходить такие тесты? Или каждое отдельное устройство должно прогоняться через такие процедуры, разве может неудачная разводка провалить тесты?

Сколько гигабит будет в PCI-E 5.0? Всё еще медь?

Документация на него есть?