|
JPEG кодек, с чего начать? |
|
|
|
Jul 13 2012, 08:08
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
Появилась задача передать кадр с камеры через GPRS. Есть устройство с GPRS модемом на борту, управляет всем PIC. Есть интерфейса IIC, к которому собственно и нужно подключить JPEG кодер. Этот кодер должен работать по принципу - получил команду по IIC снять кадр, выполнил кодирование в JPEG, и сохранил его в свою память. После чего можно по шине IIC эту картинку по кускам вытянуть из памяти кодера, и передать через GPRS. Ознакомившись с данной темой, выяснил, что JPEG кодек нужно делать аппаратный на ПЛИС. Поскольку с ПЛИС не работал, придется начинать все с нуля! Насколько я понимаю, алгоритм работы такого кодера примерно такой - в ПЛИС обрабатываем кадр полученный с выхода АЦП, на лету кодируем его в JPEG и сохраняем в какую ни будь static RAM. После чего обеспечиваем доступ к памяти по интерфейсу IIC. Кодер должен состоять: АЦП, ПЛИС, static RAM. Задачи, реализуемые на ПЛИС: 1. Организация интерфейса IIC, для получения команд от микроконтроллера, и чтения данных микроконтроллером из памяти. 2. Чтение потока с АЦП (формат YCbCr), блоками 8 х 8 сжимать на лету в JPEG и сохранять в память.
Чтоб не тратить даром времени, хотелось бы сразу выяснить несколько вопросов. Решил остановиться на ПЛИС от Xilinx (может не совсем правильный выбор?). 1. Какую выбрать среду разработки и средства отладки (бесплатную), не пойму что у них там с лицензиями? Отладочный комплект оборудования? 2. Какой ПЛИС подойдет для моей задачи? 3. Язык программирования на сколько я понимаю VHDL без вариантов (для Xilinx). Сам имею опыт программирования на Си, но на сколько я понял SystemC служит только для симуляции составных систем, а не для программирования ПЛИС.
|
|
|
|
|
Jul 13 2012, 15:18
|

Местный
  
Группа: Свой
Сообщений: 446
Регистрация: 19-09-09
Из: Санкт-Петербург
Пользователь №: 52 460

|
Цитата(maxntf @ Jul 13 2012, 12:08)  Появилась задача передать кадр с камеры через GPRS. Берите камеру с JPEG-кодером на борту. Вот, например, с параллельным выходом. А эта с MIPI-выходом.
|
|
|
|
|
Jul 13 2012, 15:57
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
Цитата(ArtemDement @ Jul 13 2012, 19:18)  Берите камеру с JPEG-кодером на борту. Такой вариант не пройдет. Задача не стоит решить ее любой ценой. Просто появилась такая задача и за одно повод начать изучать ПЛИС. Скачал себе ISE WebPACK (Free). На сколько мне удалось понять из того немного что я успел бегло просмотреть, CPLD с данной задачей не справится, поскольку там только логика, а мат. часть по сжатию jpeg там не реализовать. Или я ошибаюсь? Встречал вариант декодера, где стоит АЦП + CPLD + RAM + dsPIC. Кажется мне, что именно PIC и занимается сжатием в jpeg, а ПЛИС только для того чтоб быстро перегнать видео поток в память, а затем организовать интерфейс dsPIC с памятью. Можно ли на FPGA реализовать CPLD + dsPIC? Хотя с другой стороны для FPGA нужна конфигурационная ПЗУ. Тогда получается нужно АЦП + FPGA + ПЗУ + RAM, и вопрос что рациональней? А работа с пиками мне намного ближе.
Сообщение отредактировал maxntf - Jul 13 2012, 16:14
|
|
|
|
|
Jul 13 2012, 18:20
|
Гуру
     
Группа: Свой
Сообщений: 2 106
Регистрация: 23-10-04
Из: С-Петербург
Пользователь №: 965

|
Тут все зависит от задачи. Если научиться работать с ПЛИС - то делайте на ней, с нуля это займет не меньше года, зато потом будете хорошо разбираться в предмете. Если нужно все-таки устройство, то оцените потребную скорость сжатия. На PIC'е это займет неделю (условно), на dsPIC - раза в 4-8 быстрее. Если нужен какой-нибудь real time, то либо серьезный DSP, либо ПЛИС, и, конечно, FPGA, т.к. в CPLD это просто не влезет.
|
|
|
|
|
Jul 14 2012, 23:09
|
Участник

Группа: Участник
Сообщений: 42
Регистрация: 2-06-12
Из: Минск
Пользователь №: 72 138

|
Если не предпологается использовать аппаратные блоки DSP то посомтрите на серию XO2 от Lattice. Это малобюджетная серия. Если считать что JPEG займет примерно 2500LUTs то Вам подойдет XO2-4000 (примерно 8-15USD в зависимости от массовости производства). Кстати XO2 лидер по энергопотреблению, на тот случай если у Вас батарейки. http://www.latticesemi.com/products/cpld/machxo2/index.cfmПростейшая отладка с эмулятором на борту: http://www.latticesemi.com/products/develo...eakoutboard.cfm(цена в европпе 49USD) Если нужно жать очень быстро и нужны аппартные DSP то подойдет чуть подороже серия XP2, самая маленькая XP2-5 http://www.latticesemi.com/products/fpga/xp2/index.cfmи подобная же отладка http://www.latticesemi.com/products/develo...elopmentkit.cfmИ та и другая серии со встроенной Flash как для конфигурации так и для пользовательских данных. Среда разработки Diamond, включает всебя всё (включая Synplify компилятор и Aldec симулятор). Реальные сигналы можно смотреть с помощью Revil У Lattice есть партнер, которые сертифицированный поставлет JPEG, но скорее всего это за очень хорошие деньги, поэтому лучше поискать на opencores Lattice также дает свои открытые (в исходниках Verilog) и ни чем не ограниченные ядра 8 и 32 процессоров и среду разработки с компилятором и отладчиком. 8 битное ядро занимает 1200LUTs. Таким образом Ваше решение влезет в один корпус и ненадо даже PIC контроллера. XO2 сделана на технологии 65нм, никто не может объеденить FPGA с FLASH вместе по столь малой технологии, кроме Lattice Начните с XO2, в РадиоПромДизайн в питере есть отладка на складе.
Сообщение отредактировал MishaN - Jul 14 2012, 23:18
|
|
|
|
|
Jul 15 2012, 05:59
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
MishaN спасибо за информацию, но я решил на Xilinx начать, много книг интересных по этим ПЛИС нашел. Цитата(ArtemDement @ Jul 15 2012, 08:17)  А откуда такая тяга к ПЛИС ? Ведь в проекте всеравно будет еще и контроллер... Я писал, что встречал вариант с dsPIc + ПЛИС (вполне возможно, что можно заменить на PIC24/32 и без ПЛИС), если делать на FPGA то зачем тогда МК, а в будущем возможно и внешний АЦП.
Сообщение отредактировал maxntf - Jul 15 2012, 07:16
|
|
|
|
|
Jul 16 2012, 15:02
|
Гуру
     
Группа: Свой
Сообщений: 2 198
Регистрация: 23-12-04
Пользователь №: 1 640

|
Цитата(maxntf @ Jul 15 2012, 09:59)  Я писал, что встречал вариант с dsPIc + ПЛИС (вполне возможно, что можно заменить на PIC24/32 и без ПЛИС), если делать на FPGA то зачем тогда МК, а в будущем возможно и внешний АЦП. реализация на МК проще чем на ПЛИС, получившийся результат, при прочих равных, для МК будет лучше (ну там адаптивное кодирование, переход на JPEG2000 и т.п. улучшения и расширения делать проще), стоимость продукта дешевле применять ПЛИС имеет смысл тогда, когда задача не решается на МК, а этот случай не тот. по моему, полезнее умение "обработка изображений", чем "программирование ПЛИС", поэтому лучше освоить хорошо первое на МК по поводу аппаратуры - посмотрите на это http://www.analog.com/en/processors-dsp/bl...kfin_Processorshttp://www.ti.com/lsds/ti/dsp/platform/c60...nce/device.page
|
|
|
|
|
Jul 18 2012, 08:32
|

Профессионал
    
Группа: Свой
Сообщений: 1 262
Регистрация: 13-10-05
Из: Санкт-Петербург
Пользователь №: 9 565

|
Цитата(maxntf @ Jul 13 2012, 12:08)  3. Язык программирования на сколько я понимаю VHDL без вариантов (для Xilinx). Сам имею опыт программирования на Си, но на сколько я понял SystemC служит только для симуляции составных систем, а не для программирования ПЛИС. Можно сконфигурить внутри Xilinx 32-разрядный процессор с частотой до 100МГц и писать на нём под Си сколько влезет. А когда заработает - перенести потихоньку ресурсоёмкие блоки обработки в VHDL. При таком пути лучше начать с компиляции извесных кодеков на PC без ПЛИС вообще. Цитата(maxntf @ Jul 13 2012, 12:08)  2. Чтение потока с АЦП (формат YCbCr), блоками 8 х 8 сжимать на лету в JPEG и сохранять в память. для 8х8 "на лету" вам сначала надо считать с АЦП в память ПЛИС 8 строк изображения. Т.е. для 640х480 - 10240 байт. К АЦП что прицеплено - PAL камера? Незабудте что с неё пойдут полукадры которые лучше не смешивать в кадры. И скорость считывания с АЦП прикиньте из этого может вылезти ограничение на скорость static RAM. Цитата(maxntf @ Jul 13 2012, 12:08)  1. Организация интерфейса IIC, для получения команд от микроконтроллера, и чтения данных микроконтроллером из памяти. Я понимаю, GPRS - канал медленный, но не проще выдавать данные из ПЛИС по запросу через I2S или на МК таких нет? Цитата(ArtemDement @ Jul 15 2012, 09:17)  А откуда такая тяга к ПЛИС ? Ведь в проекте всеравно будет еще и контроллер. JPEG можно сжимать при некоторых условиях даже на AVR, так возьмите в проект ARM вместо PIC и все дела. Только не нужно забывать, что приведённый кодек от Rst7 - кодирует чёрно-белое изображение. И кроме того закодированное таким образом изображение при просмотре на Win7 имеет не 256, а 16 градаций яркости воимя стандартизации. Цитата(Alex11 @ Jul 18 2012, 02:34)  yes, Вы только не упоминайте jpeg2000 всуе. Его не то, что на МК, а на DSP прилично не сделать (в смысле за разумное время преобразования). Только человека запутаете. А в остальном - полностью согласен. Лучше для начала на процессоре каком-нибудь сделать. Да уж в jpeg2000 применяется арифметическое кодирование для сжатия (ЕБКОД). Медленный как черепаха даже на DSP. Вот он как раз на плис просится! Вопрос где взять его вменяемую реализацию?
|
|
|
|
|
Jul 18 2012, 08:51
|
Знающий
   
Группа: Свой
Сообщений: 726
Регистрация: 14-09-06
Из: Москва
Пользователь №: 20 394

|
Цитата(maxntf @ Jul 13 2012, 12:08)  Ознакомившись с данной темой, выяснил, что JPEG кодек нужно делать аппаратный на ПЛИС. Вот тут посмотрите - есть и схема и прошивки.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|