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 всего.

Пример не совсем тот, драйвера не те, но нафиг говорить "нафиг" Нажмите для просмотра прикрепленного файла

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

Я наверное чего-то недопонимаю... Я записываю на карточку 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;
}
и т.д.
Может я где-то ошибаюсь??? Корявенько немного, но все пишется как надо...

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

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