[aaarrr 69]

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

Не будет. Надо учитывать еще оверхед на команды и задержки карты.

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

[zverik80 0]

возьмите контроллер с железным SD.

- возьмите быструю SD-карту.

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

 

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

 

возьмите контроллер с железным SD.

- возьмите быструю SD-карту.

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

 

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

[aaarrr 69]

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

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

 

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

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

[DogPawlowa 0]

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

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

 

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

 

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

 

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

[Sasha_sasha 0]

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

[aaarrr 69]

DM164

[Sasha_sasha 0]

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

[zverik80 0]

Чего-то не нашел даташит на этот драйвер 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 69]

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

8 бит - это очень мало, особенно для видео (не знаю, что у Вас).

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

[Rst7 5]

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

[aaarrr 69]

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

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

[rezident 0]

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

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

[zverik80 0]

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

 

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

 

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

[Sasha_sasha 0]

8 бит - это очень мало, особенно для видео (не знаю, что у Вас).

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

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

 

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

 

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

 

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

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

Дело в том , что это все уже давно проверено. Я частенько использую RGB подсветку и добиться на этой подсветке нормальных цветов надо попотеть. Я тоже поначалу начал делать кучу цветов, а потом скатился на 32 всего.

Изменено 11 февраля, 2009 пользователем WDT

[DogPawlowa 0]

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

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