Фоновая подсветка телевизора Ambilight

[Eraser]

Как просили, Lightpack с расширенным количеством зон (255).

[MAKC]

Как просили, Lightpack с расширенным количеством зон (255).

Атлично! Eraser, cпасибо огромное.
Надеюсь это попадет и во все последующие сборки в том числе и для линукса.

И еще вопрос-пожелание-идея, раз уж ты присоединился и поддержал нашу беседу
Я её описывал еще когда сделал первый вариант:
добавить в протокол передачи данные с компа на контроллер после синхронизирующего кода 255 количество зон. Библиотека WS2801 позволяет динамически менять количество адресуемых пикселей. И это параметр позволит менять количество зон без перепрошивки контроллера. 8 бит на 1 кадр не сильно увеличат объем передаваемых данных, зато сильно упростят конфигурацию конечной пользовательской системы.
Можно ли добавить галочку-настроечку - передавать/непередавать первым байтом последовательности (после разделителя 255) количество зон?
Но в этом случае максимальное количество зон надо будет убавить до 254.

[Eraser]

Атлично! Eraser, cпасибо огромное.
Надеюсь это попадет и во все последующие сборки в том числе и для линукса.

И еще вопрос-пожелание-идея, раз уж ты присоединился и поддержал нашу беседу
Я её описывал еще когда сделал первый вариант:
добавить в протокол передачи данные с компа на контроллер после синхронизирующего кода 255 количество зон. Библиотека WS2801 позволяет динамически менять количество адресуемых пикселей. И это параметр позволит менять количество зон без перепрошивки контроллера. 8 бит на 1 кадр не сильно увеличат объем передаваемых данных, зато сильно упростят конфигурацию конечной пользовательской системы.
Можно ли добавить галочку-настроечку - передавать/непередавать первым байтом последовательности (после разделителя 255) количество зон?
Но в этом случае максимальное количество зон надо будет убавить до 254.

насколько понял, протокол будет выглядеть так:
FF [кол-во зон] R G B R G B ....

например для 2 зон
FF 02 00 00 00 AA AA AA

ЗЫ а количество зон зачем убавлять, есть ограничение при передаче?

[MAKC]

насколько понял, протокол будет выглядеть так:
FF [кол-во зон] R G B R G B ....

например для 2 зон
FF 02 00 00 00 AA AA AA

Да, именно так

ЗЫ а количество зон зачем убавлять, есть ограничение при передаче?

потому что текущее максимальное значение 255 (FF)- это разделитель пакета данных для разных кадров.

и чтобы не было всякого рода коллизий от получения двух разделителей (FF FF 00 00 00 AA AA AA ...), лучше убавить до 254 (FF FE 00 00 00 AA AA AA ...)

Может быть и будет работать со значением 255, можно например на первое время оставить 255, потестировать, а там уже принять окончательное решение.
Сомневаюсь что в ближайшее время кто-нибудь себе сделает эмбилайт на 255 зон. Это какой же телек надо иметь?
Если 32зоны на метр, 255зон, получаем периметр телека 8 метров
считаем, считаем, считаем
Получаем телек диагональю чуть меньше 3метров - 116дюймов
Чтоб я так жил
Но если использовать проектор ...

Другое ограничение, но я этот момент еще опять же не исследовал, - это размер оперативной памяти в контроллере.
Используемая на текущий момент библиотека создает в памяти массив размером количество_зон*3 байт.
Т.е. для 255 зон надо чтобы в ОЗУ контроллера было место для массива как минимум 765байт.
В АТМеге 328 и покруче, в которых 2048 байт оперативки, наверное найдется место, а вот в АТМеге 168 оперативки всего 1024 байт, часть из которой будет тратится на рабочие переменные. Тонкости использования оперативки надо спрашивать у Chipa - гуру по микроконтроллерам
Опять же, у кого такой телек или проектор и кто купит такую длиннющую ленточку, наверное найдет чуть чуть деньжат и на контроллер чуть покруче чем АТМега 168

[Eraser]

MAKC, спасибо за развернутое объяснение

Данная фишка будет добавлена!

ЗЫ тестовая версия в аттаче

[MAKC]

MAKC, спасибо за развернутое объяснение

Данная фишка будет добавлена!

Отлично, буду ждать Наверняка не только я один

Еще на всякий случай хочу повторить, эта фича должна быть настраиваемой, т.е. надо уметь её включить и отключить.
Т.е. кому-то она нужна, а кому-то не нужна.
Второй байт с количеством зон будет мешать после обновления софта текущим владельцам Ardulight, где в софте не предусмотрено такое гибкое, динамическое изменение количества зон.
Да и на текущий момент нет опубликованного скетча, поддерживающего такой режим работы.

[Eraser]

Отлично, буду ждать Наверняка не только я один

Еще на всякий случай хочу повторить, эта фича должна быть настраиваемой, т.е. надо уметь её включить и отключить.
Т.е. кому-то она нужна, а кому-то не нужна.
Второй байт с количеством зон будет мешать после обновления софта текущим владельцам Ardulight, где в софте не предусмотрено такое гибкое, динамическое изменение количества зон.
Да и на текущий момент нет опубликованного скетча, поддерживающего такой режим работы.

тестовая версия
http://www.compcar.ru/forum/attachme...3&d=1344585679

[HiddenPilot]

добавить в протокол передачи данные с компа на контроллер после синхронизирующего кода 255 количество зон. Библиотека WS2801 позволяет динамически менять количество адресуемых пикселей. И это параметр позволит менять количество зон без перепрошивки контроллера. 8 бит на 1 кадр не сильно увеличат объем передаваемых данных, зато сильно упростят конфигурацию конечной пользовательской системы.

А я вот смотрю сюда и думаю, а стоит ли изобретать велосипед ?
https://github.com/adafruit/Adalight.../LEDstream.pde
может воспользоваться этим скетчем ? тем более поддержка АДА в LightPack'e уже есть.... А в АДА есть поддержка WS2801....

[MAKC]

А я вот смотрю сюда и думаю, а стоит ли изобретать велосипед ?
https://github.com/adafruit/Adalight.../LEDstream.pde
может воспользоваться этим скетчем ? тем более поддержка АДА в LightPack'e уже есть.... А в АДА есть поддержка WS2801....

Тоже хорошее решение.
Только по скетчу пока не пойму как они определяют границы, кадров.
Вроде вижу синхросигнал "Ada" от контроллера в компьютер - запрос получения данных для очередного кадра.
Но как определяется конец данных для кадра, пока не пойму.
Вроде похоже на таймаут ожидания получения порции данных, но пока не уверен на 100%.

Кстати они у себя на странице ссылаются на использование LightPack, как на утилитку с дружественным GUI и хорошей производительностью
http://learn.adafruit.com/adalight-d...ftware-options

[HiddenPilot]

Только по скетчу пока не пойму как они определяют границы, кадров.
Вроде вижу синхросигнал "Ada" от контроллера в компьютер - запрос получения данных для очередного кадра.

Ну в коде вроде все описали...

immediately following the magic word
// are three bytes: a 16-bit count of the number of LEDs (high byte
// first) followed by a simple checksum value (high byte XOR low byte
// XOR 0x55).  LED data follows, 3 bytes per LED, in order R, G, B,
// where 0 = off and 255 = max brightness.

После magic word (Ada) идет 16битное значение количества светодиодов(только количество начинается с 0, т.е. для 120 светодиодов прилетает 119).....
далее чексум по формуле (high byte XOR low byte XOR 0x55). ну а далее цвета.... кстати в коде(во втором скетче ) написано, что у WS2801 цвета перепутаны. Кстати может добавить опцию порядка цветов на уровне Host'а ?

Ну а если я не ошибаюсь, то где-то тут весь буфер уходит в SPI:

     case MODE_DATA:

      while(spiFlag && !(SPSR & _BV(SPIF))); // Wait for prior byte
      if(bytesRemaining > 0) {
        if(bytesBuffered > 0) {
          SPDR = buffer[indexOut++];   // Issue next byte
          bytesBuffered--;
          bytesRemaining--;
          spiFlag = 1;