Epic fail..

Это просто ппц, как у меня все разошлось с планами

То лето, море, потом на мак пересел, допиливал игру для iPhone, портировал ее для IPad-а, грызу дальше гранит мак-оси с ее какавами и обж-си :(

В финале еще и поиграться попробовал на htpc поставить убунту и xbmc, да так понравилось, что стоит теперь стационарно (против всех минусов скорость загрузки в 35 сек, не попрешь)

И когда в очередной раз попались на глаза недоделанные железки мои – дошло, что клиент то у меня виндовый, и что теперь мне делать.. одно уныние короче

От так от…

И про планы…

Обновил заодно планы/повычеркивал готовые пункты

Ненавижу/не умею писать планы; чтобы точно сказать, сколько займет что-то, мне приходится практически сделать это и поставить цифру «потратил столько то»

Надо уже думать над программой на хосте.. какими бы фичами ее нагрузить..

Видео для привлечения внимания..

Диодам не хватает яркости; раньше заметил, что они достаточно ощутимо грелись, выяснилось, что блок питания выдавал 6 вольт (а резисторы то расчитаны на 5), добавил крен-ку; теперь рылся в коде, искал ошибку, потом додумался померять напряжение – а там 4 вольта всего..

6 В было, когда подключал всего пару rgb-светодиодов, а когда 9 штук (да * 3 канала)  – ток большой, а блок питания всего 350 мА обещает, вот напряжение и проседает.. Есть старый АТ-блок питания комповый небольшой, с ним светится веселее, но он неудобный..

Нашел пару очепяток в прошивке, цвета путались.. нашел ошибку в коде управляющей программы, цвета более адекватно определятся стали (и одинаково слева и справа экрана.. а то было – на фаре в фул-скрине с одной стороны цвет синий, с другой – черти что..)

Чувствую много мороки будет с этим определением цвета.. если цвет превалирует на картинке, то и светодиоды подсвечиваются адекватно, но если цвет средний «ни вашим, ни нашим», то светодиод светит «серым», вроде правильно, но визуально некрасиво.. Есть мысль – брать тройку цветов, определять «сильнейший» и усиливать его искусственно.. но надо пробовать. Надо еще развернуть светодиоды назад, когда они в глаза светят – оно не то; но проблема, у меня монитор в углу стоит, соотв. назад светить не на что.. А на телевизор цеплять рано еще – он в другой комнате, а програмить/отлаживать еще много..

Приехали диоды и прочая чепуха, заказывал в харькове; у нас на радиорынке еле купил был для тестов 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 ползунка для каждого канала; все работало, но цвет неправильный генерировался.. Потом разобрался, что меняется не тот канал, который меняю (синий вместо красного например).. Начал уже дебажить код, потом перезагрузил контроллер и все починилось – видимо байт при приеме пропал, вот цвета и сместились..

Но там в “апи” еще есть вещи интересные, про которые даже не прочитал еще толком, некогда было.. Может именно они и “перевесят” в пользу готового протокола; а может как-то получится совместить их?.. надо думать в общем еще..

Результат гугления про dwm и прочее..

Читал свои ссылки, гуглил, прозрел, хотя пока без практического применения

DWM (диспетчер окон рабочего стола) используется для спецэффектов при отображении окон: полупрозрачные рамки окон, «заблюривание» содержимого под окном, «живые» эскизы панели задач и т.д.

Идея создания dwm – в использовании ресурсов видеокарт не только для 3D, но и для всех окон; и технология получилась обратно совместимой со старыми приложениями – программы считают, что они рисуют себя как раньше – но на самом деле dwm получает «картинки» окон, а потом комбинирует их на рабочем столе, добавляя спецэффекты, когда надо, а результаты похоже хранятся в памяти, разделенной с видеокартой – поэтому например можно взять окно и потягать его по экрану, и если раньше окна ниже иногда видимо для глаз перерисовывали себя, то теперь этого не происходит – dwm имеет актуальную картинку всех окон и быстро компонует результирующую картинку, окна ниже я так понимаю иногда даже не получают уведомления о том, что их часть стала невалидной

При этом dwm немного похож на вывод видео в оверлей: я делал приложение, которое регистрировало себя для отображения эскиза другого приложения – после этого прямо поверх моего окна рисовалось чужое окно, причем рисовалось, обновляясь в реал-тайме, нагрузка на процессор при этом отсутствовала; но если получить картинку моего окна «обычным» способом (GetDC -> BitBlt), то превью отсутствовало – теперь понятно почему: картинка эскиза накладывалась dwm поверх моего окна при композиции десктопа

Но если надо получить изображение десктопа (GetDC(0) или нажав кнопку PrintScreen), то видимо dwm или кто-то еще вдупляется, что происходит, и для копирования берется содержимое памяти после накладывания спецэффектов и прочего, т.е. из видеопамяти

При этом dwm выделяет нужное количество памяти (всплеск размера используемой памяти в диспетчере задач) и теоретически должно быть проседание производительности (потому что копирование из видеопамяти медленный процесс), память потом попозже конечно освобождается, но если копировать экран 1920*1080 скажем 35 раз/сек, то она (память) будет выделяться быстрее, чем освобождаться, и через какое-то время система говорит: «Упс, существенно не хватает ресурсов»

И что с этим делать я пока не придумал и решения не нашел; экстенсивное решение – делать это не так часто или не использовать Aero

Про DWM..

Вчера много гуглил, а оказывается у меня в закладках на 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, который стартует, сразу загружает какую-нибудь оболочку и никогда не показывает юзеру десктоп, уже решение..

Ход работ: получение цвета..

Очень простой (и работающий – естественно кроме случая с оверлеем) способ получения данных о цвете (подсказанный в этом топике): «скриншотить» окно.. я думал надо делать все сложнее, типа DirectShow-фильтр перед рендерером.. Читать запись полностью »

Компиляция прошивки

Прошивка пишется на языке Си, значит надо установить компилятор; кроме того, можно/нужно установить ide – интегрированную среду разработки, в которой писать просто удобнее

Читать запись полностью »