aaarrr 69 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба SPI и DMA будет 20 Мбит/сек Не будет. Надо учитывать еще оверхед на команды и задержки карты. И у SE только один SPI. Правда, если работать в режиме "забиваем с карты все ОЗУ - показываем анимацию", то хватит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zverik80 0 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба возьмите контроллер с железным SD. - возьмите быструю SD-карту. - загружайте данные с использованием DMA и команды READ_MULTIPLE_BLOCK. Спасибо. Погуглить, в каких контроллерах такая начинка есть я могу. ОДнако хотелось бы услышать ваши рекомендации. Все таки желательно чтобы контроллер был распространен, без геморроя в освоении, чтобы информации и примеров по нему в сети было достаточно. А то привык я к ATMEL... возьмите контроллер с железным SD. - возьмите быструю SD-карту. - загружайте данные с использованием DMA и команды READ_MULTIPLE_BLOCK. А если сделать так, то какую скорость следует ожидать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба Все таки желательно чтобы контроллер был распространен, без геморроя в освоении, чтобы информации и примеров по нему в сети было достаточно. А то привык я к ATMEL... Я бы, возможно, взял какой-нибудь из ARM9 от того же Атмела. Но назвать это простым решением не могу. А если сделать так, то какую скорость следует ожидать? Предельную для карты. Точной цифры никто не даст, так как все они разные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба А если сделать так, то какую скорость следует ожидать? У нас порт efsl на ARM7 через интерфейс SD без DMA дает около 100 килобайт в секунду на коротких файлах. На половине имеющейся SDRAM можно расположить 50 кадров мультфильма разрешения VGA (на 2 секунды). Так что для непрерывного видео требуется другой подход. И он реализован в дешевых китайских видеоплэйерах - с использованием винчестера. Кстати, может лучше сделать адаптер сигналов TFT дисплея в сигналы ридеборда на какой-нить PGA и использовать готовый прибор? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sasha_sasha 0 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба Чего-то не нашел даташит на этот драйвер DM164... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба DM164 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sasha_sasha 0 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба Я тут о чем подумал, Зверюга... У меня посветка на RGB диодах в девайсе. Так вот -- диоды через ШИМ работают эффективно только в нижней трети заполнения. То есть если добавлять заполнение ШИМа от нуля, то они сначала быстро становятся яркими, а потом яркость почти не изменяется. Так может не имеет смысла так много разрядов на цвет держать? Может быть вообще достаточно 7-ми цветов +белый? Тогда и памяти на борту хватит и не надо заморачиваться со скоростями. Ну например 240*40*(4бит цветности). Еще можно использовать палитру. То есть , в память на место пикселя записывать указатель на цвет в палитре. Тогда получится 240*40*8бит(256 цветов). Я думаю больше и не надо. А то поставил себе какую-то сверх задачу... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zverik80 0 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба Чего-то не нашел даташит на этот драйвер 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 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба 8 бит - 16 000 000 цветов - за глаза 8 бит - это очень мало, особенно для видео (не знаю, что у Вас). Для получения более-менее качественной картинки нужно вводить гамма-коррекцию и использовать минимум 10 бит ШИМ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 февраля, 2009 Опубликовано 10 февраля, 2009 · Жалоба Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)? Распаковка практически не заберет скорости (при правильном подходе к делу скорость будет сравнима с побайтовым копированием), но зато снизит нагрузку на канал чтения данных с карточки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 11 февраля, 2009 Опубликовано 11 февраля, 2009 · Жалоба Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)? Распаковка практически не заберет скорости (при правильном подходе к делу скорость будет сравнима с побайтовым копированием), но зато снизит нагрузку на канал чтения данных с карточки? Оно, возможно, стоит, но мы до сих пор не знаем, что это за табло, и какого рода информацию оно отображает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 11 февраля, 2009 Опубликовано 11 февраля, 2009 · Жалоба Так вот -- диоды через ШИМ работают эффективно только в нижней трети заполнения. То есть если добавлять заполнение ШИМа от нуля, то они сначала быстро становятся яркими, а потом яркость почти не изменяется.Это видимый эффект. Интенсивность свечения СИД прямо пропорциональна среднему току, протекающему через него. А вот у человеческого глаза логарифмическая чувствительность к яркости объекта, что следует учитывать при регулировке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zverik80 0 11 февраля, 2009 Опубликовано 11 февраля, 2009 · Жалоба Качественного видео не надо. В лучшем случае картинка как в анимированном баннере. С резкими переходами цвета, оляпистая. Господа, а может стоит подумать об упаковке кадров каким нибудь методом класса LZ (не LZW)? Все хорошо, но обычно архивация преназначена для уменьшения общего объема хранения данных. А представьте себе картинку такого пискельного состава, который сжимается плохо. Будут неприятные сюрпирзы. Особенно если в момент чтения такого кадра карта затормозит. Если я не прав, поправьте меня. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sasha_sasha 0 11 февраля, 2009 Опубликовано 11 февраля, 2009 (изменено) · Жалоба 8 бит - это очень мало, особенно для видео (не знаю, что у Вас). Для получения более-менее качественной картинки нужно вводить гамма-коррекцию и использовать минимум 10 бит ШИМ. Да какое видео на такой разрешаловке... А насчет восьми бит -- на светодиодах больше и не получишь. Вот взяли допустим 10 бит шим -- 1024 единицы. Изменение яркости на 10 единиц вряд ли отличишь. Так зачем такой ШИМ? Я ж писал выше--характеристика яркости светодиодов нехорошая и по цветам отличается сильно(я так понял это о гамма коррекции?). Есть небольшой примерчик. Насчет градаций. У меня есть индикатор OLED 256x64 16 GrayScale. У него на пиксел идет 4 бита. Преобразуешь bmp в LCD Icon Color и выводишь. Совсем неплохо смотрится с 16-ю градациями. Посмотрел драйвер 164. Это ж сколько надо таких драйверов, офигеть просто... Нафиг такая штука нужна. Надо другой драйвер искать. Например драйвер индикатора какого-то. Это видимый эффект. Интенсивность свечения СИД прямо пропорциональна среднему току, протекающему через него. А вот у человеческого глаза логарифмическая чувствительность к яркости объекта, что следует учитывать при регулировке. Вы все правильно сказали. Только еще есть вольтамперная характеристика и она не линейная. То есть при изменении напряжения ток меняется НЕЛИНЕЙНО... Поэтому и яркость будет нелинейная. Поправьте , если я ошибаюсь... + к этому еще и восприятие глаза, в том числе и к разным спектрам излучения. Дело в том , что это все уже давно проверено. Я частенько использую RGB подсветку и добиться на этой подсветке нормальных цветов надо попотеть. Я тоже поначалу начал делать кучу цветов, а потом скатился на 32 всего. Изменено 11 февраля, 2009 пользователем WDT Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 11 февраля, 2009 Опубликовано 11 февраля, 2009 · Жалоба Это ж сколько надо таких драйверов, офигеть просто... Нафиг такая штука нужна. Пример не совсем тот, драйвера не те, но нафиг говорить "нафиг" :cranky: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться