Не уверен, что у меня получится это реализовать )).
Там есть ещё одна проблема, которая заключается в скорости чтения/записи данных во внешнюю память. Сейчас камера выдаёт 25 fps. С разрешением 320x240 времени хватает на запись данных не бёрстами. При увеличении угла поворота возможность записи бёрстами сходит на нет т.к. адреса пикселей находятся не в одном ряду, а это означает что каждую запись надо делать начиная с открытия ряда, выдержки tRRD, tRP для SDRAM, закрытия ряда. Это очень сильно влияет на производительность. Отсюда, если выбирать данные из SDRAM по столбцам, то на каждый пиксель надо тратить уйму времени, да плюс ещё и входные данные от камеры надо успевать записывать, а HDMI контроллер не ждёт, он работает на 25Мгц. По этому для данной реализации куда дешевле по времени все процедуры преобразования производить на записи, а чтение пусть работает бёрстами по строкам.
А нет никакого фреймбуфера, есть только область памяти в SDRAM в которую пишется кадр, а затем читается из неё в FIFO, а оттуда в HDMI. Работает на EP2C8F256.
Идею я понял. Попробую повращать читателя, а не писателя как сейчас сделано.
Ну это на Си так легко сделать, на ПЛИС не знаю. Вы предлагаете сначала записать кадр без изменения, затем расчитать параметры нового изображения, затем вычитывать из записанного кадра в новый расчитанный кадр, а потом снова вычитывать из нового и выводить на экран. Этот метод хорош при наличии фреймбуфера, который заменит нам «буфер=1», у меня его нет.
Там проще можно сделать. Можно ресайз нового кадра делать чтобы он вписывался в наш фрейм 320x240.
Дело ещё и в том, что уменя места в ПЛИС на подобную обвязку может нехватить. Сам CORDIC отожрал неприлично много ресурсов.
Да, будет. Потерпите немного, пожалуйста. Мне надо доработать кое-какие блоки. В сыром виде не люблю работу сдавать. Но это будет не гитхаб, скорее всего, а просто архив с проектом т.к. проект лежит в домашнем SVN, а поддерживать 2 репозитория мне, признаться, лениво.
Прежде чем что-то увеличивать надо продумать архитектуру системы и требования к ней. Если Вы хотите обрабатывать все строки одновременно и это критично для Вас, то, скорее всего, от использования SDRAM придётся отказаться и заменить её на что-то более быстрое или выбрать ПЛИС с большим объёмом блочной памяти, чтобы весь кадр хранить в ней, а не во внешней памяти. Такие кристаллы наверняка есть, но и цена на них в разы больше. Отсюда и последствия — удорожание изделия. А может, достаточно будет пересмотреть архитектуру и продумать её по-новому.
На практике происходет пропуск первой строки и в фифо остаётся последняя после конца кадра. Она может быть выведена в первую строку следующего кадра или в следующую после последней строки предыдущего кадра (смещение изображения на одну строку вниз). Я принял решение не обрабатывать её совсем, чем городить логику по её спасению ). Я просто ресет на фифо подаю по завершении кадра, а в первую строку черный цвет идёт. Меня пока эта реализация устраевает.
А почему именно speex? Он же отъедает много ресурсов у контроллера. Почему, например, не G711 aLaw или uLaw? У них полоса всего 64 килобита, они табличные и ресурсы не едят.
HDL Designer использую потому, что осваивать ПЛИС начал на FPGA Advantage под Windows, затем переехал на Linux и FA в полном наборе не нашел, а к HDS привык. На А9, да, данные брал из фреймбуфера. Первые опыты были на SAM9G20 лет 5 назад. Результаты меня не впечатлили. Сейчас в ящике лежит платка на Allwinner H3, вот на ней стоит попробовать, но это потом.
Там есть ещё одна проблема, которая заключается в скорости чтения/записи данных во внешнюю память. Сейчас камера выдаёт 25 fps. С разрешением 320x240 времени хватает на запись данных не бёрстами. При увеличении угла поворота возможность записи бёрстами сходит на нет т.к. адреса пикселей находятся не в одном ряду, а это означает что каждую запись надо делать начиная с открытия ряда, выдержки tRRD, tRP для SDRAM, закрытия ряда. Это очень сильно влияет на производительность. Отсюда, если выбирать данные из SDRAM по столбцам, то на каждый пиксель надо тратить уйму времени, да плюс ещё и входные данные от камеры надо успевать записывать, а HDMI контроллер не ждёт, он работает на 25Мгц. По этому для данной реализации куда дешевле по времени все процедуры преобразования производить на записи, а чтение пусть работает бёрстами по строкам.
Идею я понял. Попробую повращать читателя, а не писателя как сейчас сделано.
Боюсь оказаться неправым, но что-то мне подсказывает, что это не совсем возможно.
Там проще можно сделать. Можно ресайз нового кадра делать чтобы он вписывался в наш фрейм 320x240.
Дело ещё и в том, что уменя места в ПЛИС на подобную обвязку может нехватить. Сам CORDIC отожрал неприлично много ресурсов.