Перейти к содержанию
    

Помогите продумать архитектуру проекта на ARM7

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

 

Задача следующая - необходимо с 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 до регистра(буфера) откуда выводишь.

При получении данных с карты они автоматом будут грузиться в буфер(регистр).

Это не полное решение, конечно. Все зависит от железа.

Из сообщения не ясно зачем такая скорость вывода на таком экранчике с малым разрешением...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как будто препятствий не видно :rolleyes:

Один процесс последовательно вычитывает с SD карты (скорей всего по частям, ну например 1/4) буфер фрейма, а второй гонит его в SPI по DMA.

для получения 30 фреймов (при 16 битах на 1 LED), по SPI нужна будет скорость 240*40*3*16*30 фреймов = 13,824 Мбит.

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

... мне и так ARM7 с нуля осваивать.

ИМХО тогда уж обратите внимание на CORTEX M3 от ST.

Гораздо получше, да и перспективнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я все таки не понял про одновременность.

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

Нельзя ли по подробней про SPI с DMA. DMA есть во всех ARM7?

 

сдвигового регистра в пар.)

 

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

 

Настраиваешь канал от SPI до регистра(буфера) откуда выводишь

 

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

 

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чета не увидел возможности прицепить DM164 к SPI.

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

8-и битовый режим сделать можно, но это только облегчит конвертирование RGB палитры, а физически гнать всегда придется все те же 16 бит на пиксел.

Чтобы брать непрерывно и без задержек из SD карты 2 МБайта в сек и еще из файловой системы да по SPI понадобится оверклокинг минимум. ;)

 

 

Я все таки не понял про одновременность.

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

Нельзя ли по подробней про SPI с DMA. DMA есть во всех ARM7?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чтобы брать непрерывно и без задержек из SD карты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, по поводу тех кто писал про низкую скорость - вот здесь http://kazus.ru/lenta/view/0_6566_0.html написано, что контроллеры серии SE могут передавать по SPI до 25 Мбит/сек.

Прокомментируйте.

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

Лично я не вижу каких-либо препятствий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

написано, что контроллеры серии SE могут передавать по SPI до 25 Мбит/сек.

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

 

Сгородить что-то вроде програмного SPI, который будет обращаться к карте, давать ей команду передавать данные по линии идущей в драйвер, соответственно, управляя при этом его ногами. Лично я не вижу каких-либо препятствий.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Будет дикий тормоз.

 

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

 

 

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

 

Посему пересматриваю техзадание:

- FAT не нужна. Формат придумаю сам.

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

 

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

 

Возьмите лучше контроллер с двумя аппаратными SPI.

 

Если я не ошибаюсь, то это X серии и все ARM9 ?

Два SPI могут работать с одним и тем же потоком данных одновременно? Скорость выхода данных будет равна скорости их непрерывного поступления? Я правильно понял?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чета не увидел возможности прицепить DM164 к SPI.

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

Да вроде глобальный клок и не должен быть синхронным.

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

 

сдвигового регистра в пар.)

пар. = параллельный (поленился однако сразу написать)

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

 

DMA есть во всех ARM7?

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

Изменено пользователем Шурила

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Если я не ошибаюсь, то это X серии и все ARM9 ?

X, ARM7.

 

Два SPI могут работать с одним и тем же потоком данных одновременно? Скорость выхода данных будет равна скорости их непрерывного поступления? Я правильно понял?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

aaarrr

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

 

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

 

 

Параметр индивидуален для каждой карты, записан в CSD

 

Можно ли из 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-ов можно позволить только в любительских некоммерческих дивайсах.

Если у вас такой, то дерзайте. :biggrin:

 

Еще вижу проблему, что управление памятью на NAND и SD ведется посредством двунаправленного обмена.

На передачу пакета нужно дать команду.

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

 

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

 

Ладно, я тут еще немного подумал - видеофильмы крутить на экране нужды нет, будет максимум кадров 100.

Что скажете насчет внешней SRAM емокстью около 5 Мбайт и достаточной скоростью и относительно невысокой ценой?

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...