Помогите продумать архитектуру проекта на 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 с нуля осваивать.


Спасибо.

[WDT]

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

[Шурила]

Как будто препятствий не видно
Один процесс последовательно вычитывает с 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-битный режим?

[AlexandrY]

Чета не увидел возможности прицепить 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 и придумаю что-нибудь попроще. Надеюсь вы поняли суть идеи.
Лично я не вижу каких-либо препятствий.

[aaarrr]

написано, что контроллеры серии 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.

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

[aaarrr]

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

[AlexandrY]

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

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

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

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

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

[Зверюга]

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



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

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

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

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

[aaarrr]

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

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


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

[Зверюга]

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

Подсказать что-нибудь можете?
Быстрый SPI это сколько? А то ведь в ARM7 вроде как и на 30 МГц можно работать.
Контроллер SD - помоему он только в ARM9 появляется.

Можно ли из DataFlash, NAND flash по одному проводу непрерывно без тормозов

А как же пост #13 Александра? Кому верить?

Так и не услышал комментариевна вот это:

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

И если все-таки использовать SD, то какой скорости чтения с использованием FAT и SPI режима на частоте контроллера 60МГц можно добиться?
Если она превышает 15 МБит/c то может действительно добавить SRAM и буферизовать?

Вот нашел бенчмарк прадва для LPC - там с SD карты чуть ли не 7 Мбайт/сек читается. Как?

[Зверюга]

Вот бенчмарк http://elm-chan.org/fsw/ff/img/rwtest2.png

[sensor_ua]

с SD карты чуть ли не 7 Мбайт/сек читается. Как?

Вам же внятно сказали, что контроллер карты (внутри который) отдаёт данные достаточно быстро, но когда ему нужно спокойненько сообщает, что занят и продолжает заниматься своими делами.
В спецификации на SD v2 (SDHC) (файл с sdcard.org Simplified_Physical_Layer_Spec.pdf) указаны размеры AU - Table 4-41: Maximum AU size, а далее в рамочке примечание и там есть - The host should use the maximum AU Size (4 MB) to determine host buffer size. Делаю вывод - обеспечение заявляемых скоростей учитывает наличие буфера у хост-контроллера.
Тут тоже бенчмарки
http://www.embedded-os.de/index.html?pcfat_port.htm

[Зверюга]

Вам же внятно сказали

Нет, мне сказали невнятно. Ибо я спрашивал потом, какова длительность этих тормозов карты, в секундах, в тактах, в проценте процессорного времени - мне не ответили, хотя чувствуется, что люди зна.т об этом явно не из мануалов, а из собственного опыта. И самое главное - итоговая средняя скорость чтения превысит требуемые 1,5 мБайт/сек? Если да, тогда мне надо делать буфер.

Опять таки, мне тут уже два раза писали про буферизацию. Что есть буферизация? Это чтение данных из карты в буфер "впрок" на более высокой скорости с последующе передачей их из буфера на номинальной скорости, пока карта тормозит? Я правильно понял? Тогда с учетом практических факторов - упомянутых "длительности тормозов карты, в секундах, в тактах, в проценте процессорного времени" каков объем буфера должен быть? На чем его организовать, может использовать внешнюю SRAM?

Нельзя ли использовать 2 или 4 флешки, и читать из них данные параллельно? Типа как RAID 0?

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

aaarrr, вы как специалист по драйверам светодиодов, скажите, а может быть мне для моей задачи стоит ограничиться 8 битами? Я слаб в английском, так и не понял, в младшем брате DM164 - DM163 можно пользоваться только 8-битным банком, а 6-ти битный запрограммировать 1 раз и не трогать? Мне бы хотя бы в 2 раза урезать скорость данных.

http://www.gaw.ru/html.cgi/txt/publ/memory/nand.htm

В описании сказано что там есть буфер.Так какого же еще буфера для этой системы надо?

[AlexandrY]

Хм, работа по исследованию характеристик скорости чтения из разных SD карт в зависимости от разных условий может оказаться дороже всего вашего проекта.
Скажем было такое наблюдение: у SanDisk вариации времени чтения на файлах одинаковой длины могут достигать 30%, а у Kingston - 4%
Но это как нарвешься.
Чем более изношенная карта, тем сильнее вариации.

Вам надо иметь как минимум 2-а буфера вмещающих целые кадры на внешней RAM
А лучше делать адаптивную буфферизацию, как только фиксируется нехватка данных на вывод сразу увеличивать количество буферов.
Если взять ARM с 2-я SPI и грузить экран через оба SPI, то проблем с недостаточной скоростью загрузки можно избежать.
С SD картами лучше работать через специализированный 4-х битный интерфейс.

Вам бы подошел STM32F103xE.
Там аж 3-и SPI по 18 МГц, т.е. 54 Mbit/s в сумме . Есть интерфейсы и к SD карте и к NAND и к PSRAM
Только надо проверить мультиплексирование пинов, а то не всякая конфигурация может оказаться реализуемой.
Может внешняя RAM и не понадобится, у STM32 неплохая шинная матрица и потоки из NAND и SPI как бы могут пересылаться напрямую по DMA минуя шину инструкций.

Нет, мне сказали невнятно. Ибо я спрашивал потом, какова длительность этих тормозов карты, в секундах, в тактах, в проценте процессорного времени - мне не ответили, хотя чувствуется, что люди зна.т об этом явно не из мануалов, а из собственного опыта. И самое главное - итоговая средняя скорость чтения превысит требуемые 1,5 мБайт/сек? Если да, тогда мне надо делать буфер.

Опять таки, мне тут уже два раза писали про буферизацию. Что есть буферизация? Это чтение данных из карты в буфер "впрок" на более высокой скорости с последующе передачей их из буфера на номинальной скорости, пока карта тормозит? Я правильно понял? Тогда с учетом практических факторов - упомянутых "длительности тормозов карты, в секундах, в тактах, в проценте процессорного времени" каков объем буфера должен быть? На чем его организовать, может использовать внешнюю SRAM?

[Зверюга]

Если взять ARM с 2-я SPI и грузить экран через оба SPI, то проблем с недостаточной скоростью загрузки можно избежать.

Так ведь проблема не в скорости передачи данных из контроллера в экран, а в загрузке данных из флешки в контроллер или буфер.
Собственно, грузить экран можно и дерганьем ног, а 2 SPI использовать для загрузки буферов. Вот только мне непонятна архитектура их буфера, 2х-SPI и одной sd карты. Был бы благодарен за объяснение на пальцах или в виде схемки.

Вам бы подошел STM32F103xE.
Там аж 3-и SPI по 18 МГц, т.е. 54 Mbit/s в сумме . Есть интерфейсы и к SD карте и к NAND и к PSRAM

через efind.ru не нашел его цены.
Работает ли он с SD картами в SD режиме?

В принципе я готов поставить две или три NAND flash и грузить буфер из них, если это возможно. Как тогда организовать буфер? Я не имею опыта в создании таких схем.

Может внешняя RAM и не понадобится, у STM32 неплохая шинная матрица и потоки из NAND и SPI как бы могут пересылаться напрямую по DMA минуя шину инструкций.

Простите мне мою тупость, но я понял ситуацию так:
проблема не со скоростью контроллера, а с непостоянной скоростью загрузки данных из карты. Стало быть, нужно грузить из карты в буфер SRAM, с максимальной скоростью, превышающей скорость отдачи данных из буфера. И если средняя скорость загрузки данных из карты будет выше, то все получится. Либо писать данные в две флешки и грузить из их одновременно в буфер.

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

[Dog Pawlowa]

... Извините за назойливость.

Ага, именно это качество Вы демонстрируете :-)
Примите как данность - с SD картой работать реально со скоростью сотни килобайт в секунду. Сравнение файловых систем где-то было в инете, но я ссылку не сохранил. По моему, где-то тут на форуме в какой-то из тем было.
Поставьте внешнюю RAM, SDRAM большого объема, организуйте буфер и забудьте проблему, по сравнению со стоимостью собственно ридеборда, стоимость контроллера стремится нулю. Да и всей электроники по сравнению с механикой

[Зверюга]

Гуглил про организацию буфера - мало чего полезного нашел.
Ну хоть подтолкните пожалуйста в нужном направлении. Как читать и как передавать, как в этом случае использовать преимущество 2-х SPI.

Да и по поводу памяти - искал информацию по микросхемам чтранные вещи - попадаются микрухи на 1Мбит стоимость по 600-800 рублей, что-то дорого, модуль DDR компьютерный на 256 МБ стоит рублей 200.

[Зверюга]

Гуглил про организацию буфера - мало чего полезного нашел.
Ну хоть подтолкните пожалуйста в нужном направлении. Как читать и как передавать, как в этом случае использовать преимущество 2-х SPI.

Да и по поводу памяти - искал информацию по микросхемам чтранные вещи - попадаются микрухи на 1Мбит стоимость по 600-800 рублей, что-то дорого, модуль DDR компьютерный на 256 МБ стоит рублей 200.

[WDT]

Слушай , Зверюга! Один мой товарищ делал некий девайс. В нем он выводил звук следующим образом.
На DataFlash 8МБит записывал звуковой файл. Потом Давал команду на чтение по SPI и получал данные на сдвиговый регистр на выходе R2R и усилок.
Говорил , что работает.
Я так понял и ты хочешь что-то подобное, но с матрицей светодиодов?

[wangan]

ой чувствую заказчик не получит результат как минимум полгода

Сообщение отредактировал wangan - Feb 10 2009, 08:53

[Зверюга]

WDT - ну я же расписал выше. Примерно то же самое, но только скорость поболее будет.
Выдать 1,5 мбайт/сек наверное проблемы не будет. Проблема даже не в приеме данных, а в том что карта их не будет отдавать с постоянной скоростью, если я правильно понял форумцев.
Мне упорно твердят про 2 SPI, но я только никак не могу понять, как через них можно одновременно читать, если карта одна и давать команду на чтение типа SPI_READ придется по очереди, пока один SPI байт не примет, к другому не обратиться.

Что я пока смог себе уяснить - так это то, что буфер заполняется со скоростью большей чем нужно для отдачи информации, что компенсирует провалы в чтении (при условии, что средняя скорость чтения будет выше, я уже отказался от FAT). А вот правильно ли я это понял или нет, мне не говорят. Я готов поставить несколько флешек и читать с них параллельно, до почему-то кажется, что есть более изящные способы.

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

А заказчик, мой друг и не торопит. Как раз полгода, не менее, было оговорено.

[WDT]

WDT - ну я же расписал выше. Примерно то же самое, но только скорость поболее будет.
Выдать 1,5 мбайт/сек наверное проблемы не будет. Проблема даже не в приеме данных, а в том что карта их не будет отдавать с постоянной скоростью, если я правильно понял форумцев.
Мне упорно твердят про 2 SPI, но я только никак не могу понять, как через них можно одновременно читать, если карта одна и давать команду на чтение типа SPI_READ придется по очереди, пока один SPI байт не примет, к другому не обратиться.

Что я пока смог себе уяснить - так это то, что буфер заполняется со скоростью большей чем нужно для отдачи информации, что компенсирует провалы в чтении (при условии, что средняя скорость чтения будет выше, я уже отказался от FAT). А вот правильно ли я это понял или нет, мне не говорят. Я готов поставить несколько флешек и читать с них параллельно, до почему-то кажется, что есть более изящные способы.

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

А заказчик, мой друг и не торопит. Как раз полгода, не менее, было оговорено.

Два SPI это два аппаратных SPI... То есть даешь команду на чтение по одному SPI когда он ответит через DMA передастся автоматом в регистр второго SPI. Время и ресурсы экономятся сильно.
От FAT отказываться смысла нет -- если блоки(кластеры) данных идут ПОДРЯД, то какая разница...
Ты же изначально прочитываешь Главную загрузочную запись, Загрузочную запись раздела, FAT и вычисляешь где данные.

Тут мне кажется никто, в том числе и я, не понимают что это за девайс:-))) Сказал бы уж что за хрень такая?
Например, непонятно зачем такая скорость при выводе на такой дохленький экранчик(240 на 40)??? Для вывода видео все равно не пойдет, а для вывода информации или каких-то эффектов скорости особой не надо. Тем более ты пользуешься каким-то там драйвером.

[Зверюга]

Скорость высокая? Так гр-н Шурила выше все расписал.

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

Уже 50 минут 5 человек смотрят тему и все молчат )))

[wangan]

Тут мне кажется никто, в том числе и я, не понимают что это за девайс:-))) Сказал бы уж что за хрень такая?

Что непонятного - бегущая строка

[Зверюга]

wangan, тепло)))

[wangan]

Ну тогда курсовик валют, но думаю через полгода нужды в нем не будет все будет колом плохо

[sensor_ua]

Уже 50 минут 5 человек смотрят тему и все молчат )))

Дык ссылал тебя на спецификацию, но, похоже, читать её не досуг.
4.13.6 Speed Class Definition
находишь Class 6 на графике Figure 4-9: Three Performance Curves.
IMNHO,

240*40*3*16*30 фреймов = 13,824 Мбит

явно больше, чем 6 Мбит.

[Зверюга]

sensor_ua, почему недосуг, яж писал, что я уже понял это. Да вот только меня продложают соблазнять DMA и 3 SPI.

[aaarrr]

Да и по поводу памяти - искал информацию по микросхемам чтранные вещи - попадаются микрухи на 1Мбит стоимость по 600-800 рублей, что-то дорого, модуль DDR компьютерный на 256 МБ стоит рублей 200.

Статика по определению дороже, а уж в розницу - тем более.

Что я пока смог себе уяснить - так это то, что буфер заполняется со скоростью большей чем нужно для отдачи информации, что компенсирует провалы в чтении (при условии, что средняя скорость чтения будет выше, я уже отказался от FAT). А вот правильно ли я это понял или нет, мне не говорят.

Правильно поняли.

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

Рецепт:
- Берем контроллер с аппаратным интерфейсом SD, одним или более SPI, внешней шиной. Добавляем к нему память по вкусу - SRAM, SDRAM etc.
- Если есть несколько SPI, можно разделить экран на соответствующее количество частей.
- Организуем в памяти 2 буфера размером в экран. Из одного будем разворачивать, во второй в это время загружать данные.
- Пишем развертку на SPI, DMA и таймерах.
- Организуем здоровый буфер для чтения SD, пишем процедуры его обслуживания.
- Пишем процедуру, перебрасывающую данные в буфер экрана из буфера SD.

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

[Зверюга]

Организуем здоровый буфер для чтения SD, пишем процедуры его обслуживания.

Но если скорость чтения 6 Мбит/сек, а нам надо 13 Мбит, то каким образом нас спасет буфер?
Или же интерфейс SD в контроллере позволяет читать карту в SD режиме?

[MikePic]

явно больше, чем 6 Мбит.

Только в спеке указаны не мегабиты, а мегаБАЙТЫ, на сколько я помню

НеSDHC обычная карта microSD Toshiba 2GB, которая устанавливается в мои девайсы в тесте выдаёт 19,5МБайт/с чтение, 10,5МБайт/с запись. Максимальная скорость на записи, естественно, развивается при работе с большими блоками, при чтении - аналогично, но со своими особенностями (см. спеку).

[aaarrr]

Или же интерфейс SD в контроллере позволяет читать карту в SD режиме?

А зачем бы он был нужен, если бы не умел?

[Зверюга]

НеSDHC обычная карта microSD Toshiba 2GB, которая устанавливается в мои девайсы в тесте выдаёт 19,5МБайт/с чтение, 10,5МБайт/с запись.

Каким образом устроен обмен данными в Вашем девайсе?

2 Буфера размером в экран и огромный буфер для SD локализуются в одной микросхеме?

Добавляем к нему память по вкусу - SRAM, SDRAM etc

Плюсы и минусы предложенных вариантов?.
порылся в efind.ru - половина предложений это планки, я так понял, вставляющиеся в слоты компьютера.
В остальных случаях непонятно - каков их обхем и организация.
Вы бы не могли привести пример доступных SDRAM с ценой и объемом. Если есть возможность достать недорогую микру на 16-32 МБ, я же видеофильмы не собираюсь крутить, мне кадров 500 хватит за глаза. Загружу весь файл и буду до бесконечности читать его из микросхемы.

[aaarrr]

Плюсы и минусы предложенных вариантов?.

SRAM - просто и дорого, малый объем (но Вам все равно хватит).
SDRAM - нужен контроллер.

Вы бы не могли привести пример доступных SDRAM с ценой и объемом. Если есть возможность достать недорогую микру на 16-32 МБ,

Например, K4S561632 - 32МБайт.

[Dog Pawlowa]

SDRAM - нужен контроллер.

С учетом того, что он встроенный во много ARMов, это не проблема.

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

[aaarrr]

С учетом того, что он встроенный во много ARMов, это не проблема.

А в еще боьлшее число не встроен. Впрочем, это сокращает возможность выбора, что в данном конкретном случае скорее плюс

[Зверюга]

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

Неповторяющееся видео конечно хорошо, но необязательно.

В любом случае, даже если анимация будет гоняться через SDRAM, то хотелось бы сократить время ее загрузки с карты.

[aaarrr]

В любом случае, даже если анимация будет гоняться через SDRAM, то хотелось бы сократить время ее загрузки с карты.

- возьмите контроллер с железным SD.
- возьмите быструю SD-карту.
- загружайте данные с использованием DMA и команды READ_MULTIPLE_BLOCK.
Все, быстрее не будет.

[Зверюга]

А в еще боьлшее число не встроен. Впрочем, это сокращает возможность выбора, что в данном конкретном случае скорее плюс

Как раз встроен в SE серию от Атмел. Контроллера SD там нет, если я не ошибаюсь, но зато с SPI и DMA будет 20 Мбит/сек. ПОскольку в свете изменившегос ТЗ, непрерывность загрузки с карты не нужна, то эти 20 мБит/сек, пусть и с провалами устроят.

Потихоньку ситуация начинает проясняться, спасибо за советы. Хотя... непрерывное видео было бы конечно не плохо, так сказать для универсальности.

[aaarrr]

SPI и DMA будет 20 Мбит/сек

Не будет. Надо учитывать еще оверхед на команды и задержки карты.
И у SE только один SPI. Правда, если работать в режиме "забиваем с карты все ОЗУ - показываем анимацию", то хватит.

[Зверюга]

возьмите контроллер с железным SD.
- возьмите быструю SD-карту.
- загружайте данные с использованием DMA и команды READ_MULTIPLE_BLOCK.

Спасибо. Погуглить, в каких контроллерах такая начинка есть я могу. ОДнако хотелось бы услышать ваши рекомендации. Все таки желательно чтобы контроллер был распространен, без геморроя в освоении, чтобы информации и примеров по нему в сети было достаточно. А то привык я к ATMEL...

возьмите контроллер с железным SD.
- возьмите быструю SD-карту.
- загружайте данные с использованием DMA и команды READ_MULTIPLE_BLOCK.

А если сделать так, то какую скорость следует ожидать?

[aaarrr]

Все таки желательно чтобы контроллер был распространен, без геморроя в освоении, чтобы информации и примеров по нему в сети было достаточно. А то привык я к ATMEL...

Я бы, возможно, взял какой-нибудь из ARM9 от того же Атмела. Но назвать это простым решением не могу.

А если сделать так, то какую скорость следует ожидать?

Предельную для карты. Точной цифры никто не даст, так как все они разные.

[Dog Pawlowa]

А если сделать так, то какую скорость следует ожидать?

У нас порт efsl на ARM7 через интерфейс SD без DMA дает около 100 килобайт в секунду на коротких файлах.

На половине имеющейся SDRAM можно расположить 50 кадров мультфильма разрешения VGA (на 2 секунды).

Так что для непрерывного видео требуется другой подход. И он реализован в дешевых китайских видеоплэйерах - с использованием винчестера.

Кстати, может лучше сделать адаптер сигналов TFT дисплея в сигналы ридеборда на какой-нить PGA и использовать готовый прибор?

[WDT]

Чего-то не нашел даташит на этот драйвер DM164...

[aaarrr]

DM164

[WDT]

Я тут о чем подумал, Зверюга... У меня посветка на RGB диодах в девайсе. Так вот -- диоды через ШИМ работают эффективно только в нижней трети заполнения. То есть если добавлять заполнение ШИМа от нуля, то они сначала быстро становятся яркими, а потом яркость почти не изменяется. Так может не имеет смысла так много разрядов на цвет держать? Может быть вообще достаточно 7-ми цветов +белый? Тогда и памяти на борту хватит и не надо заморачиваться со скоростями. Ну например 240*40*(4бит цветности). Еще можно использовать палитру. То есть , в память на место пикселя записывать указатель на цвет в палитре. Тогда получится 240*40*8бит(256 цветов). Я думаю больше и не надо. А то поставил себе какую-то сверх задачу...

[Зверюга]

Чего-то не нашел даташит на этот драйвер DM164...

вот http://www.e-neon.ru/catalog/id/3291275#3291275

WDT

Да я давно думал, как бы перевести драйвер в 8-битный режим. Да вот беда не переводится. МОжно конечно писать 8-ми битный файл, а "левые" биты сочинять на ходу - но на сколько при этом увеличится процессорное время... Впрочем это надо обдумать. 8 бит - 16 000 000 цветов - за глаза, плюс, при таком маленьком разрешении эти полутона просто не будут востребованы. Я понимаю, если на 1600 точек растянуть от 000000 до 0000FF, а на 240...

В тоже время выигрыш всего в два раза. То есть если не изобретать, даже с 8 битами не успеем. А если изобретем, то и 16 потянем.

WDT

Да я давно думал, как бы перевести драйвер в 8-битный режим. Да вот беда не переводится. МОжно конечно писать 8-ми битный файл, а "левые" биты сочинять на ходу - но на сколько при этом увеличится процессорное время... Впрочем это надо обдумать. 8 бит - 16 000 000 цветов - за глаза, плюс, при таком маленьком разрешении эти полутона просто не будут востребованы. Я понимаю, если на 1600 точек растянуть от 000000 до 0000FF, а на 240...

В тоже время выигрыш всего в два раза. То есть если не изобретать, даже с 8 битами не успеем. А если изобретем, то и 16 потянем.

Хм.... я тут прикинул - а ведь ничего переводить не надо - просто в драйвер посылать первые 8 бит, остальные 8 тактов пусть драйвер думает, что ему шлют информацию, а информация будет - нули. ПРи этом цвет будет тот же, правда урезаный до 8 бит. То есть 50% времени мы занимаемся благими делами.

Итак, ТЗ снова меняется. Надо всего 650 кбайт/сек.

[aaarrr]

8 бит - 16 000 000 цветов - за глаза

8 бит - это очень мало, особенно для видео (не знаю, что у Вас).
Для получения более-менее качественной картинки нужно вводить гамма-коррекцию и использовать минимум 10 бит ШИМ.

[Rst7]

Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)? Распаковка практически не заберет скорости (при правильном подходе к делу скорость будет сравнима с побайтовым копированием), но зато снизит нагрузку на канал чтения данных с карточки?

[aaarrr]

Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)? Распаковка практически не заберет скорости (при правильном подходе к делу скорость будет сравнима с побайтовым копированием), но зато снизит нагрузку на канал чтения данных с карточки?

Оно, возможно, стоит, но мы до сих пор не знаем, что это за табло, и какого рода информацию оно отображает.

[rezident]

Так вот -- диоды через ШИМ работают эффективно только в нижней трети заполнения. То есть если добавлять заполнение ШИМа от нуля, то они сначала быстро становятся яркими, а потом яркость почти не изменяется.

Это видимый эффект. Интенсивность свечения СИД прямо пропорциональна среднему току, протекающему через него. А вот у человеческого глаза логарифмическая чувствительность к яркости объекта, что следует учитывать при регулировке.

[Зверюга]

Качественного видео не надо. В лучшем случае картинка как в анимированном баннере. С резкими переходами цвета, оляпистая.

Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)?

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

[WDT]

8 бит - это очень мало, особенно для видео (не знаю, что у Вас).
Для получения более-менее качественной картинки нужно вводить гамма-коррекцию и использовать минимум 10 бит ШИМ.

Да какое видео на такой разрешаловке... А насчет восьми бит -- на светодиодах больше и не получишь. Вот взяли допустим 10 бит шим -- 1024 единицы. Изменение яркости на 10 единиц вряд ли отличишь. Так зачем такой ШИМ? Я ж писал выше--характеристика яркости светодиодов нехорошая и по цветам отличается сильно(я так понял это о гамма коррекции?).

Есть небольшой примерчик. Насчет градаций. У меня есть индикатор OLED 256x64 16 GrayScale. У него на пиксел идет 4 бита. Преобразуешь bmp в LCD Icon Color и выводишь. Совсем неплохо смотрится с 16-ю градациями.

Посмотрел драйвер 164. Это ж сколько надо таких драйверов, офигеть просто... Нафиг такая штука нужна. Надо другой драйвер искать. Например драйвер индикатора какого-то.

Это видимый эффект. Интенсивность свечения СИД прямо пропорциональна среднему току, протекающему через него. А вот у человеческого глаза логарифмическая чувствительность к яркости объекта, что следует учитывать при регулировке.

Вы все правильно сказали. Только еще есть вольтамперная характеристика и она не линейная. То есть при изменении напряжения ток меняется НЕЛИНЕЙНО... Поэтому и яркость будет нелинейная. Поправьте , если я ошибаюсь... + к этому еще и восприятие глаза, в том числе и к разным спектрам излучения.
Дело в том , что это все уже давно проверено. Я частенько использую RGB подсветку и добиться на этой подсветке нормальных цветов надо попотеть. Я тоже поначалу начал делать кучу цветов, а потом скатился на 32 всего.

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

[Dog Pawlowa]

Это ж сколько надо таких драйверов, офигеть просто... Нафиг такая штука нужна.

Пример не совсем тот, драйвера не те, но нафиг говорить "нафиг"

[WDT]

Пример не совсем тот, драйвера не те, но нафиг говорить "нафиг"

Пример не совсем тот? Насколько соответствует конструкция на фото "техзаданию" Зверюги?
Может у Вас там матрица из одноцветных диодов с общей регулировкой яркости? Так ведь это на 51-м делается спокойно.

Хотя если сканировать матрицу, то получится следующее. На 8 горизонтальных линий один драйвер. То есть получается 5 драйверов на 40линий.
На каждом выходе драйверов тогда надо еще приделать что-то мощное, поскольку выход 90мА всего. Вертикальных линий 240 -- 48 шт. сдвиговых регистров с транзистором на выходе(это навскидку) . Во получается конструкция... А тут еще неясная "ситуевина" со скоростью вывода.
Возможно и другое решение есть.
Да еще и проблемы с питанием будут -- блок питания довольно мощный надо.

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

[Dog Pawlowa]

Может у Вас там матрица из одноцветных диодов с общей регулировкой яркости? Так ведь это на 51-м делается спокойно.

Ага, еще можно тумблером. Включил-выключил.
Тут о видео что-то говорили, не так ли? Скорость смены картинок, объем информации, проч...
Да, это одноцветное табло, и контроллер у него на 51. С маааленькой такой FPGA
Табло не мое, естественно.

[WDT]

Ага, еще можно тумблером. Включил-выключил.
Тут о видео что-то говорили, не так ли? Скорость смены картинок, объем информации, проч...
Да, это одноцветное табло, и контроллер у него на 51. С маааленькой такой FPGA
Табло не мое, естественно.

Так вот эта одноцветность и влияет... А насчет FPGA -- так это ж дело вкуса :-)))
Какая скорость смены картинки у Вашего табло? Какой размер? Может в Вашей панели аппаратный контроллер с кучей памяти. Данных-то нет...
У нас в электронном магазине висит бегущая строка -- на меге с 595-ми регистрами. Тож хорошо крутит.:-)))
Возьмите панел Зверюги(уж больно нравится мне имя)))). Если нет цветов. 240х40. С одной стороны ШИМ. При вертикальном сканировании 240 раз за 1/30 сек (один кадр). У нас же 30 кадров в сек?
Время потратишь примерно 138 мкс. Может еще на чего немного уйдет, но вполне достаточно для нешибко быстрого проца.
А у Вас еще и панель небось поменьше?

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

[Dog Pawlowa]

Может в Вашей панели аппаратный контроллер с кучей памяти. Данных-то нет...

Объясняю еще раз. В панели драйверы светодиодов, включенные последовательно, и собственно светодиоды. Фото выложено. Больше там ничего нет. Контроллер имеет память, и средства доступа к ней помимо процессора. В моем примере - 51+SRAM+FPGA, у автора темы - ARM7 + SDRAM + встроенный в ARM DMA как средство доступа к памяти помимо процессора.

По моему убеждению, это современный уровень проектирования табло. Все эти динамические индикации, отдельные панели с микроконтроллерами - любительщина.
На абсолютную правоту не претендую. Спор продолжать не хотелось бы, поскольку он отошел от темы применения ARM.

[WDT]

Объясняю еще раз. В панели драйверы светодиодов, включенные последовательно, и собственно светодиоды. Фото выложено. Больше там ничего нет. Контроллер имеет память, и средства доступа к ней помимо процессора. В моем примере - 51+SRAM+FPGA, у автора темы - ARM7 + SDRAM + встроенный в ARM DMA как средство доступа к памяти помимо процессора.

По моему убеждению, это современный уровень проектирования табло. Все эти динамические индикации, отдельные панели с микроконтроллерами - любительщина.
На абсолютную правоту не претендую. Спор продолжать не хотелось бы, поскольку он отошел от темы применения ARM.

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

[aaarrr]

А насчет восьми бит -- на светодиодах больше и не получишь. Вот взяли допустим 10 бит шим -- 1024 единицы. Изменение яркости на 10 единиц вряд ли отличишь. Так зачем такой ШИМ?

С десятибитным ШИМ'ом изменение даже на одну единицу внизу диапазона очень хорошо заметно.

Есть небольшой примерчик. Насчет градаций. У меня есть индикатор OLED 256x64 16 GrayScale. У него на пиксел идет 4 бита. Преобразуешь bmp в LCD Icon Color и выводишь. Совсем неплохо смотрится с 16-ю градациями.

Неплохо - понятие весьма расплывчатое и субъективное, не находите?

Вы все правильно сказали. Только еще есть вольтамперная характеристика и она не линейная. То есть при изменении напряжения ток меняется НЕЛИНЕЙНО... Поэтому и яркость будет нелинейная.

Драйвер является источником тока.

[WDT]

Неплохо - понятие весьма расплывчатое и субъективное, не находите?
Драйвер является источником тока.

Неплохо -- это значит максимально возможно для такого индикатора. Субъективно. Еще -- неплохо значит и не хорошо.:-)))
Как-нибудь сфотографирую и пришлю.

Действительно, гуру...

[Зверюга]

Скажите, а разве нельзя сделать реализацию SD программно, если аппаратной нет в контроллере? Кстати, перерыл весь интернет- ничего путного не нашел про SD режим.

[WDT]

Скажите, а разве нельзя сделать реализацию SD программно, если аппаратной нет в контроллере? Кстати, перерыл весь интернет- ничего путного не нашел про SD режим.

Можно.
http://www.piclist.ru/S-MMC-SD-Cards-RUS/S...-Cards-RUS.html

[KAlex]

Скажите, а разве нельзя сделать реализацию SD программно, если аппаратной нет в контроллере? Кстати, перерыл весь интернет- ничего путного не нашел про SD режим.

Для чтения делается достаточно просто.
Для записи надо считать CRC, а это накладно.
Ищи "Simplified_Physical_Layer_Spec.pdf"

[aaarrr]

Скажите, а разве нельзя сделать реализацию SD программно, если аппаратной нет в контроллере?

Можно, но это будет медленнее аппаратного SPI. Для чтения четырех бит потребуется один раз прочитать порт и дважды записать, что на SAM7 даст 4+3+3=10 тактов на 4 бита, а на самом деле еще больше, так как данные нужно перепаковать и положить в память. Ну, и с CRC все не так просто, как уже заметили.

[WDT]

Для чтения делается достаточно просто.
Для записи надо считать CRC, а это накладно.
Ищи "Simplified_Physical_Layer_Spec.pdf"

Я наверное чего-то недопонимаю... Я записываю на карточку 1 Гиг без всякого расчета CRC. Просто вставляю 0xFF после команды записи.

src_mmc[0]=0х58;
src_mmc[1]=(BYTE)(Addr>>24);
src_mmc[2]=(BYTE)(Addr>>16);
src_mmc[3]=(BYTE)(Addr>>8);
src_mmc[4]=(BYTE)(Addr&0xFF);
src_mmc[5]=0xFF;

SSP0Send(src_mmc,6);

//Подтверждение
SSP0Receive(Buff_com0,2);

Buff_com0[0]=0xFF;
Buff_com0[1]=0xFF;
Buff_com0[2]=0xFE;

SSP0Send(Buff_com0,3);

for(i=0;i<BUFSIZE0;i+=FIFOSIZE)
{
SSP0Send(buf,FIFOSIZE);
buf+= FIFOSIZE;
}
и т.д.
Может я где-то ошибаюсь??? Корявенько немного, но все пишется как надо...

[aaarrr]

Может я где-то ошибаюсь??? Корявенько немного, но все пишется как надо...

Без CRC можно работать только в режиме SPI. В SD нужно считать CRC16 по каждой линии данных отдельно.

[KAlex]

Я наверное чего-то недопонимаю... Я записываю на карточку 1 Гиг без всякого расчета CRC. Просто вставляю 0xFF после команды записи.

Попрошу уточнить, в SPI или в SD mode?