Вопрос по производительности и колличеству ОЗУ, процессоры с ядами ARM7-TDMI(LPC24) и Contex-M3(STelectr) Опции

[asen]

есть задача декодировать MPEG4 c разрешениями до 320х180 и частотой када до 25 шт в сек !
Задача сохранить данные на SD карте и в разжатом виде и потом разжатый поток выводить на экран ! с режиме 25 кдров в секунду! вопрос смогут ли данные ядра на своих частотах 70-80 МГц сделать это и сколько примерно будет занимать по времени разжатие ролика в один час например ??? прошу аргументированно если можно!

[MikePic]

Улыбнуло описание темы

[asen]

что именно не так прошу указать !

[MikePic]

что именно не так прошу указать !

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

С "ядами" - понятно, что описались. А вот спутать название ядра с маркой презервативов...

Сообщение отредактировал MikePic - Jan 30 2009, 10:46

[Artem_Petrik]

Декодированием MPEG4 не занимался, но могу сказать, что когода мпег4 только появился, у меня был комп с pentium 166 не MMX, так он его декодировать не умел. Понятно, что на компе операционка, и многое другое ресурсы жрет, чего у вас не будет, но все же думаю, что указанные вами микроконтроллеры задачу не потянут.
У меня в смартфоне стоит ARM11 на 230МГц - тот проигрывает без вопросов.
Так что смотреть нужно ИМХО как минимум на ARM9 благо они сейчас по цене почти как седьмые (поддерживающие внешнюю SDRAM и FLASH)

[diwil]

не смогут.
176х144 и 15fps YUV420 на v5TE занимает примерно 20МГц.
Так что только декодирование предложеного формата на не влезет в v4 по мипсам.
про запись на карточку, вывод на ЛСД (420->565 тоже что-то займет), не говоря уж про собственно чтение потока можно забыть.

[asen]

что конкретно они не смогут ведь допустим есть видео файл лежащий на карте мы его оттуда сначало читаем неспеша и декодируем не в реальном режиме данные и складываем информацию в виде битовых таблиц по кадрам снова на карту получаеться огромный файл не сжатой граф информации допустим разжытый он занимает пусть 1Гб дальше мы начинаем этот файл со свистом вытаскивать от туда пусть со скоростью 25Мбит/сек что при глубене цвета 12 бит вполне хватает для вывода разрешения 180Х320Х25Х12=17280000 бит/сек где уское место ????

[Artem_Petrik]

Ну так сразу надо было указывать, что обработка ведется не в реалтайме. Ато писали 25 кадров в секунду....
Если всего пара кадра в секунду вас устроит - другой вопрос, пожно пробовать.
Не в реал тайме можно и на MCS51 сделать
Правда несжатого видео на карту совсем немного влезет. в гиг всего минут 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 посмотреть, например

Сообщение отредактировал MikePic - Feb 2 2009, 13:29

[cornflyer]

если устройство работает от сети - тогда можно сделать кодек MPEG4 на ПЛИС....
или купить маленькую промышленную мамку с флэшовым винтом и нормальным процом
а по поводу шариковых корпусов - их надо ставить на маленькую платку с нормальными штырьками и заказывать в производство

[asen]

у вас читается нанд флешка там ясно скорость поидее выше только что вам мешает сделать спи по живей ? скажем можно сделать 20Мгц а потом оставшееся время чем другим заниматься! А насчет использования ДСП у ADSP нет аппаратного покрайней мере у тех что в планарных корпусах! А делать на ДСП все сразу и чтение и управление мадемом радио не факт что при программном чтении данных с карты у дсп будет хватать времени процессорного для декодирования видео! А на каких TMSах есть интерфейс у карты и планарный корпус ???

[MikePic]

А на каких 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.
Аргументированных ответов не нашел, поэтому вопрос – возможно ли такое сделать и при каких условиях???

Сообщение отредактировал WDT - Feb 5 2009, 11:27

[aaarrr]

Аргументированных ответов не нашел, поэтому вопрос – возможно ли такое сделать и при каких условиях???

Нет, невозможно. Во-первых, "вход от USB WEB камеры" - это уже целый пласт проблем. Во-вторых, производительности LPC2478 будет недостаточно для воспроизведения видео.

[WDT]

Нет, невозможно. Во-первых, "вход от 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]

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

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

Насчет видео -- тут рядышком на рынке продается 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]

Может быть я где-то ошибку допустил, ведь есть же камеры работающие на 12ти мегабитах?

Про компрессию забыли. Как раз та вещь, которая позволяет упихать видео в 12 мегабит и не позволяет использовать маленький ARM для этой задачи.

[WDT]

Про компрессию забыли. Как раз та вещь, которая позволяет упихать видео в 12 мегабит и не позволяет использовать маленький ARM для этой задачи.

То есть, если видеопоток с камеры уже закодирован в определенный (известный) формат, то его можно прямиком или через какой-то буфер писать в карту памяти, а потом проигрывать на компе?
Например схема: USB--DMA до буфера -- DMA до SSP может прокатить?

[aaarrr]

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

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

Например схема: USB--DMA до буфера -- DMA до SSP может прокатить?

Организация записи потока - это дело десятое в данном случае. Нужно сначала научиться его получать, и разобраться, что он в себе содержит.

[defunct]

Я тут прикинул...
При разрешении камеры 352 x 288=101376 пикселей.
Умножить на цветность 16 бит.
Получается один кадр 1622016 байт один кадр.
15 кадров в секунду -- 24330240 байт в сек.

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

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

[WDT]

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

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

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