Господа, подскажите в какую сторону двигаться, а то я как от Иван перед камнем- направо пойдешь... налево пойдешь...

Задача следующая - необходимо с ARM7 контроллера гнать данные на DM164 (драйвер полноцветных светодиодов) со скоростью 1,5 Мбайт/сек. Само устройство - долго объяснять его принцип работы, да и заказчик пожелал особо не распространяться о деталях, в общем, представьте себе что это видеоэкран из RGB светодиодов размерами 40х240 штук.
Данные должны читаться с SD карты с FAT16.

Возможно два варианта: читается блок 57600 байт (28800 по 16 бит) и гоняется 30 раз в секунду, либо непрерывно читается поток данных состоящих из блоков того же размера, 30 раз в секунду.
Для првого варианта соответственно есть два подварианта - каждый раз читать его с флешки, либо один раз загнать в память, после чего циклически передавать по SPI.

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

Учитывая вышеизложенное возможно несколько вариантов:

1. Попроще - максимально адаптировать содержимое файла, чтобы гнать из него информацию сразу на драйвер. Т.Е. карта и драйвер сидят на одном SPI, контроллер обращается к карте, инициирует чтение данных, а перед собственно чтением включает CS на драйвере и данные идут минуя контроллер. Сам контроллер конечно следит за процессом, проверят периодически состояние кнопок и пр.
Но чует мое сердце, что есть подвох в этой простоте и без RAM не обойтись.
С использованием RAM тоже несколько вариантов.

2. Взять контроллер потолще - с 64 кб RAM. 57600 используем под данные, остальные 6кб на посторонние нужды - за глаза. Разбить ее на блоки по 240 байт, блок передали, записали с флешки новый, читаем следующий блок и т.д. Однако в этом случае придется в два раза повысить скорость чтения данных, т.е. 3 мБайт/сек, а максимальная частота драйвера DM164 всего 25 Мгц. Не получится.

3. Взять простой контроллер и использовать внешнюю RAM. Однако мне все равно не совсем понятно, даже если организовать две страницы видеопамяти, как с ними работать - если надо передавать допусти 100 байт в секунду, то ведь их одновременно надо читать, не понадобится ли удвоение скорости чтения и передачи?

4. Взять контроллер их серии SE - там вообще мед - встроенный интерфейс под внешнюю RAM под внешнюю FLASH, в описании сказано, что скорость обмена данными благодаря этому чуть ли не в 5 раз больше. Однако нужен ли такой навороченный камень?

В общем, кто что скажет, какие во всем этом есть подводные камни, проверенные способы, может обойтись первым вариантом?
Только не предлагайте ПЛИС, мне и так ARM7 с нуля осваивать.


Спасибо.

Можно еще использовать DMA канал.
Настраиваешь канал от SPI до регистра(буфера) откуда выводишь.
При получении данных с карты они автоматом будут грузиться в буфер(регистр).
Это не полное решение, конечно. Все зависит от железа.
Из сообщения не ясно зачем такая скорость вывода на таком экранчике с малым разрешением...

Как будто препятствий не видно
Один процесс последовательно вычитывает с SD карты (скорей всего по частям, ну например 1/4) буфер фрейма, а второй гонит его в SPI по DMA.
для получения 30 фреймов (при 16 битах на 1 LED), по SPI нужна будет скорость 240*40*3*16*30 фреймов = 13,824 Мбит.
Двух буферов иметь не надо, фактически промежуточный буфер находиться в DM164. После передачи всего фрейма защелкиваем его (т.е перегружаем в DM164 из сдвигового регистра в пар.) и пошли выводить следующий.

ИМХО тогда уж обратите внимание на CORTEX M3 от ST.
Гораздо получше, да и перспективнее.

Я все таки не понял про одновременность.
По идее чтобы не только прочитать но и отправить нужно вдвое больше процессорного времени. В ARM7 есть многозадачность?
Нельзя ли по подробней про SPI с DMA. DMA есть во всех ARM7?



Что такое "пар." ? И поподробней, что вы подразумеваете, говоря что промежуточный буфер находится в DM164?



В этом случае карта и драйвер светодиода будут сидеть на разных линиях?


И еще... возможно я не совсем правильно понял принцип работы DM164 - ее можно включить в 8-битный режим?

И еще... возможно я не совсем правильно понял принцип работы DM164 - ее можно включить в 8-битный режим?

Чета не увидел возможности прицепить DM164 к SPI.
Нужен как минимум синхронный постоянный глобальный клок и стробирующие загрузку каждого чипа DM164 импульсы помимо битового клока и данных.
8-и битовый режим сделать можно, но это только облегчит конвертирование RGB палитры, а физически гнать всегда придется все те же 16 бит на пиксел.
Чтобы брать непрерывно и без задержек из SD карты 2 МБайта в сек и еще из файловой системы да по SPI понадобится оверклокинг минимум.

Кстати, забыл написать - готов заменить SD карту какой-нибудь не слишком дорогой DataFlash мегов этак на 256.

Кстати, по поводу тех кто писал про низкую скорость - вот здесь http://kazus.ru/lenta/view/0_6566_0.html написано, что контроллеры серии SE могут передавать по SPI до 25 Мбит/сек.
Прокомментируйте.
Никто так и не высказался по поводу варианта "1" предложенного мной в первом посте. Сгородить что-то вроде програмного SPI, который будет обращаться к карте, давать ей команду передавать данные по линии идущей в драйвер, соответственно, управляя при этом его ногами. То есть сам SPI не будет задействован, ибо нет необходимости передавать данные в регистр, читать и изменять регистры, проверять флаги. Если уж сильно нужно будет, откажусь от FAT и придумаю что-нибудь попроще. Надеюсь вы поняли суть идеи.
Лично я не вижу каких-либо препятствий.

Могут, так же как S и X. Но это предел.


Будет дикий тормоз. Возьмите лучше контроллер с двумя аппаратными SPI. Еще нужно учитывать, что карта имеет свои тормоза, и читать с нее непрерывный поток без буферизации не получится.

Почему? Объясните не беря в расчет тормозов sd карты.


Ох... думал-думал и неожиданно понял: а ведь мне FAT то и не нужна. Карта, куда для удобства будут записываться файлы не будет вставляться в девайс. Она будет вставляться в девайс, с которого одна и та же информация будет переписыаваться в несколько устройств и уже с них читаться

Посему пересматриваю техзадание:
- FAT не нужна. Формат придумаю сам.
- рассмотрю в качестве памяти любой вариант типа DataFlash, NAND flash, который по своей сути даст наибольшее удобство и быстродействие.

По поводу непрерывности. Можете ли вы выразить в секундах, тактах, в процентах от общего времени те задержки, которые будет давать DS карта?



Если я не ошибаюсь, то это X серии и все ARM9 ?
Два SPI могут работать с одним и тем же потоком данных одновременно? Скорость выхода данных будет равна скорости их непрерывного поступления? Я правильно понял?

Да вроде глобальный клок и не должен быть синхронным.
Что касается загрузки, то после выдачи всех данных для всех DM164 выставляется общий строб загрузки (программно).


пар. = параллельный (поленился однако сразу написать)
у DM164 есть сдвиговый регистр (shift reg), а в параллельный (data latch) данные попадают токо после подачи строба загрузки (LTH).


DMA есть не во всех ARM, но Вам надо тот который имеет DMA.

Сообщение отредактировал Шурила - Feb 7 2009, 18:43

Параметр индивидуален для каждой карты, записан в CSD. Достаточно, чтобы создать проблемы при отсутствии буферизации.


X, ARM7.


Работать будут с чем скажете. По поводу скорости вопроса не понял.

aaarrr


Ну попытайтесь понять мои ламерские объяснения. Весьма условно: вот я передаю данные - скорость SPI равна CLK/2 . 16 тактов - 1 байт. А если контроллер принимает и передает информацию, то он должен за 16 тактов принять байт, записать его в свой регистр, потом за следующие 16 тактов второй SPI должен передать этот байт, в итоге 2кратное снижение скорости. Если думаешь как это сделать транзитно, то невольно приходишь к мысли, а не заменить ли контроллер проводом? Тут бит появился, там его тут же приняли. Задача контроллера только организовывать сеанс сязи и тактировать его. Какие же при этом будут тормоза?




Можно ли из DataFlash, NAND flash по одному проводу непрерывно без тормозов считывать данные и передавать их прямо в драйвер? Контроллер будет только дергать CS и другими управляющими ножками памяти и драйвера. Что ж все упорно игнорируют и не желают комментировать этот вариант?

Если я неграмотно выражаюсь, то вот как то же самое предложила сделать ваша коллега http://electronix.ru/forum/index.php?showt...st&p=506002 Обещает 10 Мбит/с для AVR. Там же мне советуют просто взять ARM и ни в чем себе не отказывать. А тут оказывается и ARM маловато.

Идея ваша просто очень дикая.
Сами SD карты и NAND флеши представляют из себя гемор высшей пробы.

В SD картах в самих стоит контроллер которому пофиг че вы от него хотите, он может неожиданно тормознуть на чтении любого сектора если решит что там у него чета не в порядке.
Т.е. неприятный фликер у вас на экране гарантирован хоть FAT хоть не FAT в карте будет.

NAND-ы же и все что на их основе гарантированно всегда имеют битые сектора, которые имеют тенденцию размножаться.
Без контроля ошибок читать из NAND-ов можно позволить только в любительских некоммерческих дивайсах.
Если у вас такой, то дерзайте.

Еще вижу проблему, что управление памятью на NAND и SD ведется посредством двунаправленного обмена.
На передачу пакета нужно дать команду.
Если предполагается делать хитрые коммутации чипселектов с целью юзать один SPI порт то надо помнить, что коммутация пинов у ARM-ов производится медленнее чем у AVR и недетерминировано.

Каким же тогда образом без фликеров осуществляется ну хотя бы проигрыш МР3 шки или видеофайла с флешки? Чтение на скорости превышающей скорость проигрывания и последующая буферизация?



Ладно, я тут еще немного подумал - видеофильмы крутить на экране нужды нет, будет максимум кадров 100.
Что скажете насчет внешней SRAM емокстью около 5 Мбайт и достаточной скоростью и относительно невысокой ценой?



ну... если не обрабатывать данные, тогда и AVR справится )))

Еще одна безумная идея- может быть поставить две SRAM по 56 кбайт, в одну грузить данные - напрямую, тактирую и контроллируя процесс контроллером, либо поставить какой нибудь кастрированный AVR для загрузки из Flash в SRAM, из другой в то же время читать, контроллируя процесс тем же образом . Потом менять местами. Надежная защита от фликеров.

Из DataFlash можно, без пауз и на приличной скорости. Но у них объем малый, а цена высокая.


На самом деле Вам нужен не очень скоростной контроллер, но с быстрым SPI, нормальным контроллером SD и достаточно большим количеством памяти (внешней, учитывая объемы).