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

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



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

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


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

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

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

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

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

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

DM164

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

вот 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 кбайт/сек.

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

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

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

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

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



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

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

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

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


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

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

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