[maxntf 0]

Появилась задача передать кадр с камеры через 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 служит только для симуляции составных систем, а не для программирования ПЛИС.

 

[des00 25]

Ознакомившись с данной темой, выяснил, что JPEG кодек нужно делать аппаратный на ПЛИС. Поскольку с ПЛИС не работал, придется начинать все с нуля!

5 тем ниже сорцы жпега коммерческого

 

[ArtemDement 0]

Появилась задача передать кадр с камеры через GPRS.

 

Берите камеру с JPEG-кодером на борту.

 

Вот, например, с параллельным выходом.

 

А эта с MIPI-выходом.

[maxntf 0]

Берите камеру с JPEG-кодером на борту.

Такой вариант не пройдет.

Задача не стоит решить ее любой ценой. Просто появилась такая задача и за одно повод начать изучать ПЛИС.

Скачал себе ISE WebPACK (Free).

На сколько мне удалось понять из того немного что я успел бегло просмотреть, CPLD с данной задачей не справится, поскольку там только логика, а мат. часть по сжатию jpeg там не реализовать. Или я ошибаюсь?

Встречал вариант декодера, где стоит АЦП + CPLD + RAM + dsPIC. Кажется мне, что именно PIC и занимается сжатием в jpeg, а ПЛИС только для того чтоб быстро перегнать видео поток в память, а затем организовать интерфейс dsPIC с памятью.

Можно ли на FPGA реализовать CPLD + dsPIC?

Хотя с другой стороны для FPGA нужна конфигурационная ПЗУ. Тогда получается нужно АЦП + FPGA + ПЗУ + RAM, и вопрос что рациональней? А работа с пиками мне намного ближе.

Изменено 13 июля, 2012 пользователем maxntf

[Alex11 3]

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

[maxntf 0]

Я понял, что нужно FPGA.

Будем потихоньку разбираться с ПЛИС, и реализовывать свою задачу на FPGA. Для начала я думаю просто обработка одной картинки, ни какого real time.

1. Посоветуйте на каком камне это лучше реализовать. На сколько я понял у FPGA есть немало своего RAM, так что внешняя память для хранения одной небольшой картинки не потребуется?

 

2. Помогите с выбором средств отладки и систем проектирования с учетом моей задачи:

- среда разработки (если можно с ссылкой где скачать с кряком)? WebPack-а бесплатного мне кажется не хватит?

- симулятор? Про встроенный ISim читал что он не совсем корректно работает?

- макетная плата?

- что еще может понадобиться?

Изменено 14 июля, 2012 пользователем maxntf

[MMishan 0]

Если не предпологается использовать аппаратные блоки 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, в РадиоПромДизайн в питере есть отладка на складе.

Изменено 14 июля, 2012 пользователем MishaN

[ArtemDement 0]

А откуда такая тяга к ПЛИС ? Ведь в проекте всеравно будет еще и контроллер. JPEG можно сжимать при некоторых условиях даже на AVR, так возьмите в проект ARM вместо PIC и все дела.

[maxntf 0]

MishaN спасибо за информацию, но я решил на Xilinx начать, много книг интересных по этим ПЛИС нашел.

А откуда такая тяга к ПЛИС ? Ведь в проекте всеравно будет еще и контроллер...

Я писал, что встречал вариант с dsPIc + ПЛИС (вполне возможно, что можно заменить на PIC24/32 и без ПЛИС), если делать на FPGA то зачем тогда МК, а в будущем возможно и внешний АЦП.

Изменено 15 июля, 2012 пользователем maxntf

[yes 5]

Я писал, что встречал вариант с dsPIc + ПЛИС (вполне возможно, что можно заменить на PIC24/32 и без ПЛИС), если делать на FPGA то зачем тогда МК, а в будущем возможно и внешний АЦП.

 

реализация на МК проще чем на ПЛИС, получившийся результат, при прочих равных, для МК будет лучше (ну там адаптивное кодирование, переход на JPEG2000 и т.п. улучшения и расширения делать проще), стоимость продукта дешевле

 

применять ПЛИС имеет смысл тогда, когда задача не решается на МК, а этот случай не тот.

 

по моему, полезнее умение "обработка изображений", чем "программирование ПЛИС", поэтому лучше освоить хорошо первое на МК

 

по поводу аппаратуры - посмотрите на это

http://www.analog.com/en/processors-dsp/bl...kfin_Processors

http://www.ti.com/lsds/ti/dsp/platform/c60...nce/device.page

 

 

 

[Alex11 3]

yes, Вы только не упоминайте jpeg2000 всуе. Его не то, что на МК, а на DSP прилично не сделать (в смысле за разумное время преобразования). Только человека запутаете. А в остальном - полностью согласен. Лучше для начала на процессоре каком-нибудь сделать.

[_4afc_ 25]

3. Язык программирования на сколько я понимаю VHDL без вариантов (для Xilinx). Сам имею опыт программирования на Си, но на сколько я понял SystemC служит только для симуляции составных систем, а не для программирования ПЛИС.

 

Можно сконфигурить внутри Xilinx 32-разрядный процессор с частотой до 100МГц и писать на нём под Си сколько влезет.

А когда заработает - перенести потихоньку ресурсоёмкие блоки обработки в VHDL.

При таком пути лучше начать с компиляции извесных кодеков на PC без ПЛИС вообще.

 

2. Чтение потока с АЦП (формат YCbCr), блоками 8 х 8 сжимать на лету в JPEG и сохранять в память.

 

для 8х8 "на лету" вам сначала надо считать с АЦП в память ПЛИС 8 строк изображения. Т.е. для 640х480 - 10240 байт.

К АЦП что прицеплено - PAL камера? Незабудте что с неё пойдут полукадры которые лучше не смешивать в кадры.

И скорость считывания с АЦП прикиньте из этого может вылезти ограничение на скорость static RAM.

 

1. Организация интерфейса IIC, для получения команд от микроконтроллера, и чтения данных микроконтроллером из памяти.

 

Я понимаю, GPRS - канал медленный, но не проще выдавать данные из ПЛИС по запросу через I2S или на МК таких нет?

 

 

А откуда такая тяга к ПЛИС ? Ведь в проекте всеравно будет еще и контроллер. JPEG можно сжимать при некоторых условиях даже на AVR, так возьмите в проект ARM вместо PIC и все дела.

 

Только не нужно забывать, что приведённый кодек от Rst7 - кодирует чёрно-белое изображение.

И кроме того закодированное таким образом изображение при просмотре на Win7 имеет не 256, а 16 градаций яркости воимя стандартизации.

 

 

yes, Вы только не упоминайте jpeg2000 всуе. Его не то, что на МК, а на DSP прилично не сделать (в смысле за разумное время преобразования). Только человека запутаете. А в остальном - полностью согласен. Лучше для начала на процессоре каком-нибудь сделать.

 

Да уж в jpeg2000 применяется арифметическое кодирование для сжатия (ЕБКОД). Медленный как черепаха даже на DSP.

Вот он как раз на плис просится! Вопрос где взять его вменяемую реализацию?

[faa 4]

Ознакомившись с данной темой, выяснил, что JPEG кодек нужно делать аппаратный на ПЛИС.

Вот тут посмотрите - есть и схема и прошивки.

[Rst7 5]

Только не нужно забывать, что приведённый кодек от Rst7 - кодирует чёрно-белое изображение.

 

Ну если так хочется, могу поделиться аналогичным проектом под ARM. Там кодируется цветное изображение. А сделано на LPC2132 (если мне не изменяет память), SAA7113 в качестве АЦП и микросхеме SDRAM (не помню какой).

[_4afc_ 25]

Ну если так хочется, могу поделиться аналогичным проектом под ARM. Там кодируется цветное изображение. А сделано на LPC2132 (если мне не изменяет память), SAA7113 в качестве АЦП и микросхеме SDRAM (не помню какой).

 

Мне было-бы любопытно взглянуть как минимум на цветной кодер в вашем исполнении.

Ибо свой корявенький уже написан, работает, но не стандартен.