Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вопрос по производительности и колличеству ОЗУ
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
asen
есть задача декодировать MPEG4 c разрешениями до 320х180 и частотой када до 25 шт в сек !
Задача сохранить данные на SD карте и в разжатом виде и потом разжатый поток выводить на экран ! с режиме 25 кдров в секунду! вопрос смогут ли данные ядра на своих частотах 70-80 МГц сделать это и сколько примерно будет занимать по времени разжатие ролика в один час например ??? прошу аргументированно если можно! cranky.gif
MikePic
Улыбнуло описание темы biggrin.gif
asen
что именно не так прошу указать !
MikePic
Цитата(asen @ Jan 30 2009, 12:35) *
что именно не так прошу указать !


Цитата
процессоры с ядами ARM7-TDMI(LPC24) и Contex-M3(STelectr)


С "ядами" - понятно, что описались. А вот спутать название ядра с маркой презервативов...
Artem_Petrik
Декодированием MPEG4 не занимался, но могу сказать, что когода мпег4 только появился, у меня был комп с pentium 166 не MMX, так он его декодировать не умел. Понятно, что на компе операционка, и многое другое ресурсы жрет, чего у вас не будет, но все же думаю, что указанные вами микроконтроллеры задачу не потянут.
У меня в смартфоне стоит ARM11 на 230МГц - тот проигрывает без вопросов.
Так что смотреть нужно ИМХО как минимум на ARM9 благо они сейчас по цене почти как седьмые (поддерживающие внешнюю SDRAM и FLASH)
diwil
не смогут.
176х144 и 15fps YUV420 на v5TE занимает примерно 20МГц.
Так что только декодирование предложеного формата на не влезет в v4 по мипсам.
про запись на карточку, вывод на ЛСД (420->565 тоже что-то займет), не говоря уж про собственно чтение потока smile.gif можно забыть.
asen
что конкретно они не смогут ведь допустим есть видео файл лежащий на карте мы его оттуда сначало читаем неспеша и декодируем не в реальном режиме данные и складываем информацию в виде битовых таблиц по кадрам снова на карту получаеться огромный файл не сжатой граф информации допустим разжытый он занимает пусть 1Гб дальше мы начинаем этот файл со свистом вытаскивать от туда пусть со скоростью 25Мбит/сек что при глубене цвета 12 бит вполне хватает для вывода разрешения 180Х320Х25Х12=17280000 бит/сек где уское место ????
Artem_Petrik
Ну так сразу надо было указывать, что обработка ведется не в реалтайме. Ато писали 25 кадров в секунду....
Если всего пара кадра в секунду вас устроит - другой вопрос, пожно пробовать.
Не в реал тайме можно и на MCS51 сделать smile.gif
Правда несжатого видео на карту совсем немного влезет. в гиг всего минут 8...
cioma
Можете глянуть на Atmel AVR32AP7000 - хоть и не ARM, но под Вашу задачу может подойти идеально.
dENIM
а еще интереснее в этом вопросе TMS320DM355
и денег он стоит не особо
правда БГА
MikePic
Гулять, так гулять: http://www.mt-system.ru/index.php?id=39466
Это "Новый ARM11 микроконтроллер от Samsung Semiconductors S3C6400"
asen
Ну господа я в курсе что можно воткнуть туда камень с произвидительностью несколько гигафлопс и который будет стоить как пол родины только это не будет оптимальным решением! Да и монтаж сильно проблематичен БГА и дорог пока и плата стоит прилично будет! Поэтому тут применение корпусов с шариковыми контактами отвергаеться сразу и на долго !:) Пока просматривалось решение точнее связка User int+SD+RF tranf+LPC213X--> ADSP-BF532 соедененные по паралельному интерфейсу ДСПника и программному порту с АРМки запрос очередной порции по прерыванию! Вопрос сможет ли LPCха вычитывать из карты c FAT32 видио данные сжатые со скоростью 1-2 Мбит/с и передавать програмно в ДСП???
OFF: Кстати указанный выше камень интересный ! Особенно для медийных применений жалко что кана нет а так оч даже заманчиво!!!
MikePic
Насчёт считывания из карты со скоростю 1-2 МБит/с не скажу. Смотря какой интерфейс. У меня чистое чтение по SPI (~7,37МГц) из AT45 с проверкой CRC страницы идёт со скоростью ~3,5МБит/с, но процу то ещё надо чем-то заниматься. С фатом гораздо тяжелее будет, тут уж лучше брать проц со встроенным интерфейсом MMC/SD. В DSP (TMS5509a) удалось записывать по SSP (14,75МГц последовательный интерфейс + поддержка протокола) со скоростью ~7,2МБит/с. При сопряжении DSP с LPC через параллельный интерфейс следует учесть такие особенности, как необходимость считывания флага готовности данных на HPI - у TMS-ки была такая фишка, а у LPC в EMC не предусмотрено.

Да, а не проще ли решить эту задачу полностью средствами DSP? У той же TMS5509a есть интерфейс MMC/SD. Уверен, что в семействе ADSP тоже найдётся

А насчёт CANа - можно у Renesas SUPER-H посмотреть, например
cornflyer
если устройство работает от сети - тогда можно сделать кодек MPEG4 на ПЛИС....
или купить маленькую промышленную мамку с флэшовым винтом и нормальным процом
а по поводу шариковых корпусов - их надо ставить на маленькую платку с нормальными штырьками и заказывать в производство
asen
у вас читается нанд флешка там ясно скорость поидее выше только что вам мешает сделать спи по живей ? скажем можно сделать 20Мгц а потом оставшееся время чем другим заниматься! А насчет использования ДСП у ADSP нет аппаратного покрайней мере у тех что в планарных корпусах! А делать на ДСП все сразу и чтение и управление мадемом радио не факт что при программном чтении данных с карты у дсп будет хватать времени процессорного для декодирования видео! А на каких TMSах есть интерфейс у карты и планарный корпус ???
MikePic
Цитата(asen @ Feb 3 2009, 12:49) *
А на каких TMSах есть интерфейс у карты и планарный корпус ???

Я же написал - на TMS320VC5509a, например.

Цитата
On-Chip Peripherals:
... Up to 2 MultiMedia/Secure Digital Card Interfaces


У меня она в проекте, но работу с microSD организовал средствами LPC2214, т.к. TMS-ка забита под самые помидоры
WDT
Мне тут похожий вопрос задал заказчик.
Надо сделать устройство для записи и проигрывания видео хотя бы 15 кадров в сек.
Вход от USB WEB камеры, запись на SD/MMC карту и вывод на TV(композитный) и на TFT дисплей 480х240.
Если применить камень LPC 2478. Вроде есть возможность подключить WEB камеру, есть интерфейс для карты, есть интерфейс RGB для индикатора.
На ТV вывести через энкодер от RGB.
Аргументированных ответов не нашел, поэтому вопрос – возможно ли такое сделать и при каких условиях???
aaarrr
Цитата(WDT @ Feb 5 2009, 14:24) *
Аргументированных ответов не нашел, поэтому вопрос – возможно ли такое сделать и при каких условиях???

Нет, невозможно. Во-первых, "вход от USB WEB камеры" - это уже целый пласт проблем. Во-вторых, производительности LPC2478 будет недостаточно для воспроизведения видео.
WDT
Цитата(aaarrr @ Feb 5 2009, 14:47) *
Нет, невозможно. Во-первых, "вход от USB WEB камеры" - это уже целый пласт проблем. Во-вторых, производительности LPC2478 будет недостаточно для воспроизведения видео.

Так не честно отвечать :-)))
Насчет USB WEB камеры проблемы конечно есть , но ведь возможно?

>>USB 2.0 full-speed dual port device/host/OTG controller with on-chip PHY and associated DMA controller.

Насчет видео -- тут рядышком на рынке продается GPS модуль с выводом на ТV. Его сделали на атмеловском ARM, даже без встроенного RGB.
Просто с ног на R2R и потом через энкодер 1645 на ТВ. Неплохо показывает 320х240.
Мне ж не надо супер качество...


Ты конечно гуру, но мне НЕДОСТАТОЧНО просто сказать -- это невозможно...
aaarrr
Цитата(WDT @ Feb 5 2009, 15:14) *
Насчет USB WEB камеры проблемы конечно есть , но ведь возможно?

Если разберетесь с камерой, то записывать видео вполне возможно.

Цитата(WDT @ Feb 5 2009, 15:14) *
Насчет видео -- тут рядышком на рынке продается GPS модуль с выводом на ТV. Его сделали на атмеловском ARM, даже без встроенного RGB.
Просто с ног на R2R и потом через энкодер 1645 на ТВ. Неплохо показывает 320х240.
Мне ж не надо супер качество...

Не надо путать развертку и декодирование видео. Через R2R DAC можно и AVR'ом что-нибудь да нарисовать.
WDT
Я тут прикинул...
При разрешении камеры 352 x 288=101376 пикселей.
Умножить на цветность 16 бит.
Получается один кадр 1622016 байт один кадр.
15 кадров в секунду -- 24330240 байт в сек.
Чего-то не получается по скорости -- у LPC2478 (12MBit/sec).
Может быть я где-то ошибку допустил, ведь есть же камеры работающие на 12ти мегабитах?
aaarrr
Цитата(WDT @ Feb 7 2009, 12:15) *
Может быть я где-то ошибку допустил, ведь есть же камеры работающие на 12ти мегабитах?

Про компрессию забыли. Как раз та вещь, которая позволяет упихать видео в 12 мегабит и не позволяет использовать маленький ARM для этой задачи.
WDT
Цитата(aaarrr @ Feb 7 2009, 17:46) *
Про компрессию забыли. Как раз та вещь, которая позволяет упихать видео в 12 мегабит и не позволяет использовать маленький ARM для этой задачи.

То есть, если видеопоток с камеры уже закодирован в определенный (известный) формат, то его можно прямиком или через какой-то буфер писать в карту памяти, а потом проигрывать на компе?
Например схема: USB--DMA до буфера -- DMA до SSP может прокатить?
aaarrr
Цитата(WDT @ Feb 10 2009, 09:46) *
То есть, если видеопоток с камеры уже закодирован в определенный (известный) формат, то его можно прямиком или через какой-то буфер писать в карту памяти, а потом проигрывать на компе?

В определенный, но, увы, далеко не обязательно известный.

Цитата(WDT @ Feb 10 2009, 09:46) *
Например схема: USB--DMA до буфера -- DMA до SSP может прокатить?

Организация записи потока - это дело десятое в данном случае. Нужно сначала научиться его получать, и разобраться, что он в себе содержит.
defunct
Цитата(WDT @ Feb 7 2009, 11:15) *
Я тут прикинул...
При разрешении камеры 352 x 288=101376 пикселей.
Умножить на цветность 16 бит.
Получается один кадр 1622016 байт один кадр.
15 кадров в секунду -- 24330240 байт в сек.

Расчет неверный, биты умножаете на пикселы и почему-то получаете байты на кадр.

352x288x16 = 198Kbyte.
15 кадров в секунду будет -
15 * 198Kbyte = 2.9Mbyte/s (слегка сжать и влезете в 1.5Mbyte/s full-speed usb)
WDT
Цитата(defunct @ Feb 11 2009, 03:42) *
Расчет неверный, биты умножаете на пикселы и почему-то получаете байты на кадр.

352x288x16 = 198Kbyte.
15 кадров в секунду будет -
15 * 198Kbyte = 2.9Mbyte/s (слегка сжать и влезете в 1.5Mbyte/s full-speed usb)

Действительно неверный :-))) Во я лопух.
Тут уже вопрос в другом -- в каком формате камера передает данные, как и говорил, товарищ aaarrr:-(((
А с этим сложнее...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.