Добрый день!
Удалите с карты памяти все файлы, из прикрепленного архива скопируйте файлы на карточку. Файлы надо копировать по порядку, с 1 по 16, причем копируйте по-одному. Скиньте видео работы вентилятора, лучше на мыло accilatem_cobaka_mail.ru.

Я вам скинул видео на мыло

Ураа!!! Все заработало, спасибо огромное за помощь. Принес на работу свой картридер, форматнул и записал файлы cat32, fish, textfish, my_files, end_flash и все сразу же поехало. Только изображение под углом маленько, ну да ладно...

Очень рад что все заработало. По поводу "под углом" - датчик со ИК светодиодом необходимо расположить так, что бы в момент их пересечения линейка со светодиодами была горизонтальна, тогда картинка будет без наклона.

Добрый день котам.)

Очень понравилась игрушка и прям загорелся тоже собрать, давно мечтаю что-нибудь подобное изготоить. Хочется подарить в качестве подарка)))

Вопрос к автору:
Идея очень интересная, если я не прав, то поправьте пожалуста...

Хочется сделать все же не 2х цветную ( точнее не 3х цветную, как сейчас уже сделано), а 8ми!!! МК у нас уже работает как переносчик битов в регистры, т.е. здесь нам даже дорабатывать ничего не требуется. Давайте пребставим что мы используем РЖБ диоды аналогично двухцветным (1-кр, 2-зел, 3-син, 4-кр и т.д.) Для оболденного качества анимации нам нужно чтобы в секунду мы наблюдали 24 кадра (можно и меньше, ЭТО Ж НЕ ВИДЕОЭКРАН КАК НИКАК, но все же), т.е. ~4мс на один кадр. А для получения промежуточного спектра (желтого, фиолетового, голубого) нам всего лишь требуется зажечь какие-либо два диода одновременно (красный+зеленый=желтый, например). Чтобы получить белый, понятно надо все три зажечь. 1500 об/мин. Что давольно приемлемо для стандартных кулеров я считаю. (даже если после прицепки платы к вентилятору будет иметь место потеря угловой скорости, решается все путями балансировки или тупо подбором другова вентилятора. Стандартные разгоняются до 3,5к где-то, так что здесь проблем не должно быть)
Фактически нам необходимо только изменить софт:
1. Расширить линейку и регистры до, предположим 64 диодов и, соответственно, 8ми регистров.
2. Минимум, это конечно добавить синий цвет на панеле и далее по-кадрам чередовать цвета, но будет иметь место потери цветности. Для удобства можно решить эту проблему на программном уровне и научить программу, при использовании промежуточных цветов зажигать одновременно требуемые диоды. (кр+зел, зел+син, син+кр, кр+зел+син)
3. Т.к. я не программист, а только слегка касаюсь этого дела, понимаю что проблему с размером файла можно будет легко решить тем же способом что и в предыдущей версии. А вот исправить или написать софт для создания таких файлов с линейкой на 64 диода и таким колличеством цветов не имею представления.
Наткнулся на софт автора для 3D анимации. Здесь синий цет уже добавлен! Возникает вопрос, если использовать только первый слой, как это отразится на коде записанного файла, будут ли размеры создааемых файлов меньшего размера?

Конечно для анимации может качество супер и не получится, но все же работать должно давольно приемлемо, мне кажется. А что касается статических картинок, так здесь вообще опросов НЕТ, все должно получиться на высшем уровне.

Хотелось бы узнать ваше мнение!!!

Повторюсь, что с программированием сталкивался только на парах своего заочного отделения, сам я ближе к железу))) Хотя потенциально не вижу проблем в освоении необходимых навыков для решения данной задачи.

Но все же хочется обратиться к автору:

Поясни пожалуста как создаются файлы в софт-программе и что они содержат в нутри?
Не можешь ли ты мне помочь с переделкой софта?
И вообще в чем ты писал этот софт, есть ли исходники с коментами? Сложно ли переделать софт с двумя цветами (НЕ 3D) на 8 цветов с 60 диодами (20 RGB диодов) с возможностью сводки готовых BMP изображений?

Для лучшего качества картинки необходимо данный прект выполнять на RGB диодах в одном корпусе.

С ув. кот Жека))) Жду аших ответов

Добрый день!
Спасибо за ваше внимание к моей конструкции.
В процессе создания своего вентилятора в голове уже были мысли о создании 8-ми цветного вентилятора, но я боялся, что карточка будет не успевать, однако после я замахнулся сразу на 3D и результат не заставил себя долго ждать - все отлично работает. Потом начал уже другой проект - создание аналога MonkeyLectric и SpokePov, и полноцветный вентилятор ушел на задний план. Я думаю теперь можно возродить эту идею.
Ну а теперь мои мысли:

Несогласен, нужно менять все: схему, прошивку и софт.


Я бы остановился на 20 RGB светодиодах(60 кристаллов)


Непонимаю смысл ваших слов. Если у нас 8 регистров, то как ни прыгай надо забивать 64 бита информации, которые в любом случае содержать все 8 комбинаций цветов. Надо как вы написали только ввести в программу дополнительные цвета. Никаких чередований не требуется.


Дополнительные цвета приведут естественно к увеличению размера файлов, но это не критично, в любом случае прошивку надо подгонять под формат файла.



Да, будут меньше, но опять же повторюсь - малейшее изменение формата файла влечет изменение прошивки.



Думаю качество анимации будет отличным, все зависит от исходных картинок.


В файл пишутся байтики, которые должны быть забиты в регистры. Байтики формируются исходя из картинки на диске пограммы. Мы имеем 40 бит на полоску, 120 полосок, итого один кадр - 4800 бит(600 байт). Инфа на SD хранится блоками по 512 байт, один кадр занимает 1 КБ, из них 600 байт полезной инфы, а остальное - мусор, причем этот мусор равномерно распределен между полосками.


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


Сто-пудово, причем корпус PLCC-4.

Итак, 20 RGB светодиодов в одну линейку, 8 регистров 74HC164, ATmega48-20AU. Под вопросом питание светодиодов - мне не нравится, что центральный круг очень яркий(малая линейная скорость), как вариант - поставить резисторы для уменьшения тока.

1. Прошивку необходимо менять т.к. загоняем в регистры 64 бита на полоску каждую, верно? Остальная геометрия переноса битов (по 64 бита) остается прежней?
2. Согласен остановится на 20ти RGB диодах. Это не существенный вопрос)))
3. Если добавить в софт промежуточные цвета, то, совершенно верно, никаких чередований не потребуется. Такой способ приемлем только для тех, кто не будет менять софт. Таким способом уже можно получить желтый цвет в твоем первом вентеляторе)))
4. За то что просветил немного по прошивке и геометрии расположения битов ОТДЕЛЬНОЕ СПАСИБО! На счет равномерного мусора, это я так понял особенность структуры FAT32
5. На счет яркости в центральном круге удобнее оставить на разводке контактные площадки, чтобы потом подобрать номинал, когда все заработает.

Кстати еще один подводный камень... Не уверен что таким способом добъемся точных промежуточных цветов, т.к. яркость у разных цветов основного цвета на диодах различная. Но все же это будут еще доп.цвета и это радует)))

А есть ли возможность просмотреть начинку dat файлов, в целях ознакомления?

Вообщем есть дикое желание собрать эту вэшчь)) Атор прям вдохновил!

Нужно все пересчитать. Получается одна полоска 8 байт, в блоке 64 полоски, если для кадра взять два блока по 512 байт, то получим 64 полоски в первом блоке и 56 во втором. Останется 64 байта мусора. Но можно поступить хитрее - сделать круг не из 120 полосок, а из 128, тогда оба блока будут заполнены полностью без лишнего мусора по 64 полоски каждый.


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


ФАТ диктует только одну особенность - файл занимает 32768 байт минимум, т.е. если у нас картинка из одного кадра (1024 байта), то выводится будут все равно все 32768 байт. Но это можно обойти.
Про мусор. Как я писал ранее мы имеем 600 байт на 1 кадр. Если мы расположим их подряд, а в конце мусор, то контроллер будет работать так: от датчика считаем время одного оборота, делим его на 120, через полученные интервалы выводим полоски. когда мы выведем 120-ю полоску мы в аккурат сделаем оборот, теперь останется дочитать из карточки мусор, чтобы к следующей полоске(уже следующего кадра) быть готовым выдать валидные данные. Но размер мусора 424 байта и его чтение займет значительное время, поэтому у нас появится темная полоса в конце кадра и вдобавок картинка будет плыть. В связи с этим сделано равномерное распределение мусора: перед четными полосками расположено 3 байта, а перед нечетными 4 байт мусора. Именно такова структура файла: 3 байт мусора - 5 байт данных - 4 байт мусора - 5 байт данных - 3 байт мусора - 5 байт данных - 4 байт мусора и т.д.


Цвета будут нормальные, можете посмотреть мое видео на канале ютубе.

Посмотреть файл можете сами. Для этого в программе подготовки файлов оставьте пустой диск и количество повторов 1. Создайте файл. Потом программой winhex откройте полученный файл. Данные картинки будут представлены числами FF, а мусор возрастающими группами чисел 0, 0, 0, потом 1, 1, 1, 1 потом 2, 2, 2 и т.д. Последний будет 77, 77, 77, 77 и завершающие 2 байта 78, 78. Кстати мусор фактически показывает номер полоски от 0 до 77 в шестнадцатиричном формате(от 0 до 119 в десятичном).

т.е единичкамы мы наоборот тушим диоды? а нулями зажигаем.
Это кстати объясняет многое в схеме)))

Да ты наверное прав от мусора проще избавиться. Плюсов больше от этого

и тогда использовать 21 RGB и один (64 кристал) скажем направить от центра в сторону (для подсветки внешнего контура например)

Уважаемые коты!!! Кто-нибудь подскажите где скачать CodVisionAVR под атмегу.
Или лучше выложите здесь, если есть возможность

В инете не могу найти никак

Ребят не могу никак скомпоновать биты на полоске. Использую 21 RGB диод и 8 регистров (каждый по байту). Использую 8 цветов. Т.е. не могу догнать как прогу научить забивать последовательно биты, и чтоб они соответствовали 8 цветовому спектру.

Вот кусок программы автора для 2х цветов:

for j:=0 to 3 do
begin
case data_pic[127-i,j] of
clRed : data_out[i,4]:=data_out[i,4]+(1 shl (j*2));
clLime : data_out[i,4]:=data_out[i,4]+(1 shl (j*2+1));
end;
end;
for j:=4 to 7 do
begin
case data_pic[119-i,j] of
clRed : data_out[i,3]:=data_out[i,3]+(1 shl ((j-4)*2));
clLime : data_out[i,3]:=data_out[i,3]+(1 shl ((j-4)*2+1));
end;
end;
for j:=8 to 11 do
begin
case data_pic[119-i,j] of
clRed : data_out[i,2]:=data_out[i,2]+(1 shl ((j-8)*2));
clLime : data_out[i,2]:=data_out[i,2]+(1 shl ((j-8)*2+1));
end;
end;
for j:=12 to 15 do
begin
case data_pic[119-i,j] of
clRed : data_out[i,1]:=data_out[i,1]+(1 shl ((j-12)*2));
clLime : data_out[i,1]:=data_out[i,1]+(1 shl ((j-12)*2+1));
end;
end;
for j:=16 to 19 do
begin
case data_pic[119-i,j] of
clRed : data_out[i,0]:=data_out[i,0]+(1 shl ((j-16)*2));
clLime : data_out[i,0]:=data_out[i,0]+(1 shl ((j-16)*2+1));
end;
end;
end;

Т.к. у меня не 2а цвета, а три, то и цвет диода зависит от троиц битов, причем от 000 до 111. Вот и вся симметрия и геометрия сбивается. У автора все красиво конечно)))

Мож кто умную мысль подскажет???

В этом случае цветам будут соответствовать числа от 0 до 7. Вот простейший код для 32 светодиодов:

for i:=0 to 119 do
begin
for j:=0 to 31 do
begin
case data_pic_color[i,j] of
clRed : data_pic[i,j]:=red_set;
clLime : data_pic[i,j]:=lime_set;
clBlue : data_pic[i,j]:=blue_set;
clYellow : data_pic[i,j]:=yellow_set;
clFuchsia : data_pic[i,j]:=fuchsia_set;
clAqua : data_pic[i,j]:=aqua_set;
clWhite : data_pic[i,j]:=7;
clSilver : data_pic[i,j]:=0;
end;
end;
end;

Где перменные red_set .. aqua_set определяют комбинацию битов под конкретный тип светодиодов и принимают значения от 1 до 6. Самое сложное расположить эти данные в порядке, соответствующем порядку подключения светодиодов к выводам регистров. А это уже определяется вашей схемой. Так что схему(а лучше печатку) в студию.

Я печатку еще не делал и даже в код вижион еще не открывал. Занимаюсь переделкой софта под 128 полосок по 22 диода (21 диод RGB и один (22ой) хочу поставить обычный, но подключить тоже к регистру, чтобы можно было управлять им, использовать как подсветку рамки,например.)

но вот как блин эти биты забить, что-то я не бум-бум)))пока

Кстати, это что?

data_out[i,j]:=not data_out[i,j];

Так как светодиоды зажигаются нулями, то массив данных надо инвертировать. Это и есть побитное инвертирование.

Мы имеем 8 регистров по 8 бит каждый, подключенных последовательно. Значит последовательность данных будет такая:
out7d8, out6d8, out5d8, .., out0d8, out7d7, out6d7, .., out0d7, out7d6, .., out1d1, out0d1. Где outx - один из 8 выводов регистра, а dx - один из 8-ми регистров. Пока мы не будем знать какой светодиод подключен к конкретному выводу регистра, мы не сможем установить правильную последовательность бит. Для простоты представим что светодиоды подключены так: красный-out7d8, зеленый-out6d8, синий-out5d8 21-го св., потом красный-out4d8, зеленый-out3d8, синий-out2d8 20-го св., и т.д. до 1-го светодиода. В этом случае алгоритм будет весьма прост: берем переменную, которая будет записана в выходной файл, прибавляем к ней data_pic[i,21], сдвигаем влево на 3 разряда, прибавляем data_pic[i,20], сдвигаем на 3 разряда влево, прибавляем ... и так до тех пор пока не запишем все данные, при этом учитывая разрядность наших переменных.

я так понимаю поскольку у меня 21 трех цветный диод, один обычный 22ой диод, и 8 не делится на 3, то мне необходимо в полоске каждый диод описывать отдельно?

кстати я могу зписать вот так:

clYellow : data_out[i,7]:=data_out[i,7]+(3 shl (1)); чтобы байт выглядел вот так: 00000110