Borderlands прошел, светодиоды приехали, больше вроде ничего не мешает (ну, Splinter Cell разве что еще.. зараза.. прошел)
Игрался все это время с мелкими проектиками, все в основном в протеусе, и все в основном бился с ним, разбирался, как работает :)
Но надо чухаться, а чухается лучше всего, когда завидно – для «завидования» себе вот выбрал видео:
Приехали диоды и прочая чепуха, заказывал в харькове; у нас на радиорынке еле купил был для тестов 2 шт по 14 грн ($1.75), а так купил 20 шт (нужно 14 + по углам будут сдвоенные и по центру снизу-сверну по 2 на канал), по $0.3/шт.. По параметрам и «чисто внешне» одинаковые
Благодаря моему первому (и единственному пока :) ) комментатору почитал про уже существующий протокол – AtmoLight, может действительно есть смысл поддерживать "стандартный", тогда и управляющую программу чужую можно использовать, и моя программа будет совместима с такого типа амби-системами..
Выглядит там все вот так:
|
Байт в посылке: |
Смысл: |
|
0xFF |
Всегда 0xFF, стартовый байт |
|
0х00 |
Номер стартового канала, младший байт |
|
0х00 |
Номер стартового канала, старший байт (это на сколько ж каналов задел?..) |
|
0x0F |
Количество каналов (* 3), 15 = 3 * 3 |
|
0х23 0х23 0х23 … |
R, G, B данные очередного канала |
Вот так; одно не понял, зачем 2 байта под номер стартового канала, но видимо причины были
Я себе в MindMeister набросал немного другую схему:
|
Байт в посылке: |
Смысл: |
|
0х00 – 0х09 |
Стартовый байт, от 0 до 9 – зарезервировано место для 10 команд, 0х00 например – начало “обычной” передачи, 0х01 – тест излучателя и т.д. |
|
0х0E |
Длина посылки, что бы там внутри ни было |
|
0х23 0х23 0х23 … |
Данные посылки ( например R,G,B канала или номер излучателя для теста) |
|
0х88 |
CRC от тела посылки, для контроля целостности передачи |
Из чисто практических целей пока вижу следующие команды: 0х00 – передача данных, 0х01 – проверка излучателей (каждый излучатель == 3-канальный светодиод) зажигается на 1 сек, потом тухнет), 0х02 – тест излучателя (указанный излучатель выводит по очереди основные цвета), 0х09 – отключение всех излучателей
Зачем проверка с crc – может конечно из-за отладки (а даже 99% скорее всего) у меня был глюк – перестали правильно отображаться света при управлении из тестовой программки, в которой 3 ползунка для каждого канала; все работало, но цвет неправильный генерировался.. Потом разобрался, что меняется не тот канал, который меняю (синий вместо красного например).. Начал уже дебажить код, потом перезагрузил контроллер и все починилось – видимо байт при приеме пропал, вот цвета и сместились..
Но там в “апи” еще есть вещи интересные, про которые даже не прочитал еще толком, некогда было.. Может именно они и “перевесят” в пользу готового протокола; а может как-то получится совместить их?.. надо думать в общем еще..
Много чего писал, но протоколов еще никогда не изобретал (вообще все мною написанное это gui и какие-то задачи по переработке файлов как правило)
Прикидываю: связь с компьютером у меня через сом-порт; максимальная скорость обмена с сом-портом допустим 112500.. или 115200?.. бит/сек, так, с учетом стоповых разных бит, четностей и прочего грубо говоря 10 бит на байт – значит максимальная скорость передачи данных будет где-то 10 кбайт/сек. Допустим, что я буду обновлять цвета 10 раз/сек, значит у меня есть где-то 1 кбайт данных на один «пакет обновления» – этого больше чем достаточно я считаю
Прикидываю с другой стороны: у меня 14 светодиодов по 3 цвета = 42 канала, по байту на канал – 42 байта на обновление – скорость обмена по сом-порту может быть мизерная совсем, на мои нужды хватит с головой
14 зон мне точно хватит для моего 32″ тв, картинки DIY-проектов показывают, что в углах обычно яркость ниже, чем по сторонам, так что я думаю, что в углах надо по 2 светодиода ставить
Дальше думаю принять скажем условие, что управляющая программа на компьютере никогда не будет слать значение 0х00 для канала – значит протокол будет выглядеть примерно так:
Для crc надыбал вот код:
#define CRC8INIT 0x00
#define CRC8POLY 0x18 //0X18 = X^8+X^5+X^4+X^0
uint8_t crc8 ( uint8_t *data_in, uint16_t number_of_bytes_to_read )
{
uint8_t crc;
uint16_t loop_count;
uint8_t bit_counter;
uint8_t data;
uint8_t feedback_bit;
crc = CRC8INIT;
for (loop_count = 0; loop_count != number_of_bytes_to_read; loop_count++)
{
data = data_in[loop_count];
bit_counter = 8;
do {
feedback_bit = (crc ^ data) & 0x01;
if ( feedback_bit == 0x01 ) {
crc = crc ^ CRC8POLY;
}
crc = (crc >> 1) & 0x7F;
if ( feedback_bit == 0x01 ) {
crc = crc | 0x80;
}
data = data >> 1;
bit_counter--;
} while (bit_counter > 0);
}
return crc;
}
Читал свои ссылки, гуглил, прозрел, хотя пока без практического применения
DWM (диспетчер окон рабочего стола) используется для спецэффектов при отображении окон: полупрозрачные рамки окон, «заблюривание» содержимого под окном, «живые» эскизы панели задач и т.д.
Идея создания dwm – в использовании ресурсов видеокарт не только для 3D, но и для всех окон; и технология получилась обратно совместимой со старыми приложениями – программы считают, что они рисуют себя как раньше – но на самом деле dwm получает «картинки» окон, а потом комбинирует их на рабочем столе, добавляя спецэффекты, когда надо, а результаты похоже хранятся в памяти, разделенной с видеокартой – поэтому например можно взять окно и потягать его по экрану, и если раньше окна ниже иногда видимо для глаз перерисовывали себя, то теперь этого не происходит – dwm имеет актуальную картинку всех окон и быстро компонует результирующую картинку, окна ниже я так понимаю иногда даже не получают уведомления о том, что их часть стала невалидной
При этом dwm немного похож на вывод видео в оверлей: я делал приложение, которое регистрировало себя для отображения эскиза другого приложения – после этого прямо поверх моего окна рисовалось чужое окно, причем рисовалось, обновляясь в реал-тайме, нагрузка на процессор при этом отсутствовала; но если получить картинку моего окна «обычным» способом (GetDC -> BitBlt), то превью отсутствовало – теперь понятно почему: картинка эскиза накладывалась dwm поверх моего окна при композиции десктопа
Но если надо получить изображение десктопа (GetDC(0) или нажав кнопку PrintScreen), то видимо dwm или кто-то еще вдупляется, что происходит, и для копирования берется содержимое памяти после накладывания спецэффектов и прочего, т.е. из видеопамяти
При этом dwm выделяет нужное количество памяти (всплеск размера используемой памяти в диспетчере задач) и теоретически должно быть проседание производительности (потому что копирование из видеопамяти медленный процесс), память потом попозже конечно освобождается, но если копировать экран 1920*1080 скажем 35 раз/сек, то она (память) будет выделяться быстрее, чем освобождаться, и через какое-то время система говорит: «Упс, существенно не хватает ресурсов»
И что с этим делать я пока не придумал и решения не нашел; экстенсивное решение – делать это не так часто или не использовать Aero
Вчера много гуглил, а оказывается у меня в закладках на del.icio.us давным-давно лежит статья заначенная для “почитать” – Создание специальных эффектов с помощью диспетчера окон рабочего стола
Надо в конце-концов взять, да и почитать все, что заначено, а то какой смысл заначивать..
Как говорил др. Шелдон Купер – «есть проблемка с телепортацией»..
Случайно заметил, что в моем механизме получения цвета что-то не в порядке: если вызывать метод получения цвета быстро (порядка 20 раз в секунду в глаза сразу бросается) и наблюдать за списком процессов, то видно, что процесс dwm отжирает порядочно памяти, до сотен мегабайт, через время память освобождается, начинает расти снова и так пока не остановлю «скриншотание»
Заметил это в w7, скорее всего такая же байда в Vista; dwm – это Desktop Window Manager, он обеспечивает навороты висты – эскизы для кнопок на панели задач и в списке Alt-Tab, может что-то еще, не уверен.. Понятно, что вроде это не бага, но хорошего мало, надо поискать другой механизм
Ага, msdn то предупреждала оказывается: «Avoid reading or writing to or from a display DC. Although supported by DWM, we do not recommend it because of decreased performance»
Собственно посмотреть на тот же DWM: например простой и грубый способ – отключить DWM Composition (механизм отображения окон на десктопе, благодаря которому и работают фенечки типа прозрачности края окон); при этом windows переключится в «упрощенный» режим и все будет работать (собственно тот же эффект был бы, если бы в настройках экрана вручную выбрать тему «Упрощенная»). Собственно для случая htpc, который стартует, сразу загружает какую-нибудь оболочку и никогда не показывает юзеру десктоп, уже решение..
Начинаю думать, как все хозяйство будет за телевизором крепится :(
Прихожу к мысли, что поск. светодиодов много, то контроллер ведь столько тока не выдаст в пике (даже если переиграть все, и вместо кучи контроллеров использовать регистры, или как оно там называется) – значит на каждый канал надо по транзисторному ключу
Наверное отдельный диод будет на малюсенькой платке, со своими резисторами/транзисторами; к телевизору можно будет крепить например двусторонним скотчем в удобных местах, между собой платки/контроллер соединять плоским кабелем многожильным
Если окажется, что света будет мало, то можно платки сделать длинными, на 2 светодиода, параллельно включенных (т.е. количество зон для вычисления не меняется, просто вместо одной «лампочки» для зоны будет две)
Как-то так..
Параллельно вчера писал немного программу для контроллера; сейчас схема представляет из себя 2 rgb-светодиода, контроллер и связь с компом по rs232
Очень простой (и работающий – естественно кроме случая с оверлеем) способ получения данных о цвете (подсказанный в этом топике): «скриншотить» окно.. я думал надо делать все сложнее, типа DirectShow-фильтр перед рендерером.. Читать запись полностью »