Arduino.ru

открыл для себя BCR533, полампера, npn, цифровые

я юзаю BC635

Cделал управляющую электронику все работает.

2whoim. Делали ли вы куб?  есть идеи по эффектам? если да, то предлогаю обменятся,

 ctimas сделал по железу контроллер и первый этаж, и пока забил. новая работа, времени пока нет..

2whoim слушай, а не подскажешь по таймеру? мне надо чтобы через определенное время(скажем 10сек) срабатывала функция. я читал гдето что это возможно при помощи прерываний, счас буду курить мануал, может подскажешь?

 ну, недавно запустил таймер восьмой атмеги на 1мс как СТС, пользуясь одним даташитом, с первого раза) Правда,мозг чуть не вскипел с непривычки)

Камень какой?

но я пишу в winAVR..

тут принцип такой. Задавая правильно биты в регистрах, имеющих отношение к таймеру, ты его настраиваешь (скажем на 1мс).

Я запускал таймер2

OCR2 = 250; // 16000000/(250)/64=1000hz

тут храним TOP, с ним сравнивается TCNT2. Видно из формулы, что при предделителе (зададим ниже) в 64 событие будет происходить в 1000гц, что есть 1мс.

TCCR2 = (1 << WGM21) | (1 << CS22); //CTC mode 64 prescaler

этими битами задаем второму таймеру режим CTC и устанавливаем прескалер (предделитель) в 64

TIMSK = (1<<OCIE2); //вызов функции по прерыванию

тут указываем что будем вызывать функцию по таймеру (каждую 1мс), ее опишем выше основного тела

asm("sei"); //разрешить прерывания

стартуем всю эту мутотень

//обработчик таймера
ISR (TIMER2_COMP_vect) {

Это собсно сама функция, что внутри ее - будет исполняться кеаждую 1мс. Ну а в ней декременть переменную какуюнить, и при 0 в ней исполняй код и устанавливай ей первоначальное значение, иначе декремент

//V-USB опрос
if(usbdelay == 0) {
usbPoll();
usbdelay = 45;
}
else {
usbdelay --;
}

Использую CarDuino Nano Duo на камне Atmega 328 пишу в радной среде для дуины, проблему с таймерами(не стал долго заморачивался и сделал на мойвзгляд самый понятный мне вариант) решил так:

Буду пробовать и с таймером, пока что решил проблему просто. зная время с момента запуска кода я вычисляю 10 секунд и меняю эффект.
подробнее описал тут:  ctimas.blogspot.com/2012/07/blog-post_15.html

Возмите библиотеку TimerOne - там все очень просто.

Было бы очень интересно. Сам только собираюсь делать кубик. Только текстовки делайте разворачивающимся сполером, а то много места займут. Кстати, может порекомендую, как использовать библиотеку.

ну и ВИДЕО )
кто реализует 3D спектроанализатор на базе библиотеки с алгоритмом фурье? )

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

Да кстати можите рассказать в чем прикол....
Я пока так и не понял,
пишу скетч, юзаю оператор цикла for в следующем виде:

for(i = 0; i < 8; i++){
  ///work
}

и все работает а вот если записать так:

for(i = 7; i >=0; i--){
  //work
}

то не работает, скетч сразу тормозит как тока доходит до этого цикла.
  пишу в стандартной ардуиновской IDE

Это Вы наверно что-нибудь с переменной цикла внутри цикла делаете...

int i;

void setup() {                
  Serial.begin(9600);     
}

void loop()
{
  for (i=0; i<8; i++) Serial.print(i);
  Serial.println();  
  delay(1000);
  for (i=8; i>=0; i--) Serial.print(i);
  Serial.println();  
  delay(1000);
}

Результат:

01234567
876543210
01234567
876543210
01234567
876543210
01234567
876543210
01234567
876543210

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

Надо смотреть функции, зависимые от i в теле цикла.

2 функции одна сдвигает массив на 1 слой вниз, вторая соответственно вверх:
 

void moveMassToDown(){
    for(i = 0; i < 8; i++){
        for(j = 0; j < 8; j++){
            for(k = 0; k < 8; k++){
                if(matrix[i][j][k]){
                    matrix[i-1][j][k] = true;
                    matrix[i][j][k] = false;
                }
            }
        }
    }
}

void moveMassToUp(){
    for(i = 0; i < 8; i++){
        for(j = 0; j < 8; j++){
            for(k = 0; k < 8; k++){
                if(matrix[7-i][j][k]){
                    matrix[7-i+1][j][k] = true;
                    if(i <= 7){
                      matrix[7-i][j][k] = false;
                    }
                }
            }
        }
    }
}

И счас все ок, но если я переписываю moveMassToUp вот так:

void moveMassToUp(){
    for(i = 6; i >= 0; i--){
        for(j = 0; j < 8; j++){
            for(k = 0; k < 8; k++){
                if(matrix[i][j][k]){
                    matrix[i+1][j][k] = true;
                    matrix[i][j][k] = false;
                }
            }
        }
    }
}

То весь скетч не работает...
точнее перестает работать как тока подходит к этой функции

Странно как-то... В перваом варианте при сдвиге вниз у Вас получается первый индекс в диапазоне от -1 до 7, при сдвиге вверх - от 0 до 8... а во втором варианте вроде даже и правильно всё :)

О!!! МЫСЛЬ!!! Может что не так с выделением памяти? Оперативка не резиновая... Компилятор, когда ему начинает не хватать памяти, начинает активно пользоваться стеком - и стек может закончиться очень неожиданно...

 А какой у Вас тип матриц? Надо бы битовый... То есть оперировать не тру-фелс, а целыми байтами - строками светодиодов.

Кстати, к вопросу о переменных:

Из arduino.h

typedef uint8_t boolean;
typedef uint8_t byte;

Это ж под одну матрицу 8х8х8 нужно 512 байт!!! А у проца всего 2к оперативки! И как же это он у Вас выкручивается :)

В первом варианте индекс есть -1.... косяк!! надо пофиксить))))) я чето даже и не обратил внимание....

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

Добрый день! Собрала у меня одна школьница кубик 8x8x8 и есть подозрения, что что-то у нас плохо с ним. Не хватает скорости развертки изображения. Сделано все на регистрах 74HC595 и p-n-p транзисторах bc556. Управляет им nano v3.

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

При программировании пробовали пользоваться и фукциями digitalwrite(DS, 0); и PORTD &= ~(1 << DS); Работают они одинаково, кроме того, что на меге конструкция PORTD &= ~(1 << DS); вообще не работала (почему-то), а на нано работала.

На всю схему стоит один общий конденсатор 100 нФ на ногах ST_CP - gnd (синронизация ("защелкивание") выходов, latchPin).

Используемый код программы следующий:

int DS=4; int ST=3; int SH=2;
void setup() {                
 pinMode(DS, OUTPUT);
 pinMode(ST, OUTPUT);
 pinMode(SH, OUTPUT);
}
void loop()
{
 
for (int Z=1; Z<=8; Z++){
 for (int XY=1; XY<= 64; XY++){
  PORTD &= ~(1 << ST); // установка логический 0
  for (int i=1; i<= 8; i++){
    if (i==Z)
    {
    PORTD &= ~(1 << DS); // 0
    PORTD |=  (1 << SH); // 1
    PORTD &= ~(1 << SH); // 0   
    }
  else
  {
    PORTD |=  (1 << DS); // 1
    PORTD |=  (1 << SH); // 1
    PORTD &= ~(1 << SH); // 0   

  }
  }
 
 for (int i=1; i<= 64; i++){
    if (i==XY)
    {
    PORTD &= ~(1 << DS); // 0    
    PORTD |=  (1 << SH); // 1
    PORTD &= ~(1 << SH); // 0   
   
  }
  else
  {
    PORTD |=  (1 << DS); // 1
    PORTD |=  (1 << SH); // 1
    PORTD &= ~(1 << SH); // 0

  }
 }
 
    PORTD |=  (1 << ST); // 1
    delay(0); //<<<<<<<<<<<<<<<<<<<<<< ----_______________-здесь непонятно
    
// digitalWrite(ST, 1);

 }}}
 

Интересно, что результат работы программы зависит от наличия или отсутствия строки delay(0), пометил в тексте "здесь непонятно". Если эту строку вовсе убрать, то загораются лишь некоторые светодиоды, и перемигивают поочередно с другими светодидами. Всего загорается процентов 5 от всего кубика. Если же оствить эту строку, то загораются все светодиоды, но отчетливо видно как загорается сначала один слой, потом следующий и т.д. Что мы делаем не так?

как вставлять программный код в текст - http://arduino.ru/forum/obshchii/vstavka-programmnogo-koda-v-temukomment...

Трудно что-то говорить о оаботе кода, когда неизвестна схема.

Но, предположим, схема известна всем (кроме меня).

Что настораживает в самом коде. Вы в курсе, что наиболее вложенный цикл у Вас выполняется 32768 раз? Мне кажется, для 512 светодиодов это как-то уж слишком избыточно.

Я думаю, что даже 512 раз - это слишком много: посудите сами - каждый светодиод будет гореть не более 1/500 всего времени. Т.е. в 500 раз тусклее, чем он горел бы на постоянном токе. А уж 1/32000 - это вообще ничего видно не будет. А вспыхивание отдельных светодиодов, вероятно, связано с прерываниями, за счет которых время свечения отдельных светодиодов увеличивается в десятки раз.

Но, не видя схемы, трудно что-то утверждать.

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

Схему рисовали в sPlan 7.0: http://fss4.narod.ru/led_cube/led_cube-schem.spl7
Печатную плату в Sprint-Layout 6.0: http://fss4.narod.ru/led_cube/plate_05.lay6

Картинки можно посмотреть здесь:
схема: http://fss4.narod.ru/led_cube/led_cube-schem.gif
плата: http://fss4.narod.ru/led_cube/led_cube-plate.gif

Картинки уж больно огромными получились, поэтому залил их в отдельное место. По программированию все примерно понятно стало, потыкали кубик и пришли к мнению, что развертку 3d изображений лучше делать послойно. Сначала в одном слое зажигаем нужные диоды, потом в другом и т.д. тогда время горения увеличится и составит 1/8. А в некоторых случаях можно и того больше слоев подключать, когда фигура обладает зеркальной симметрией относительно плоскости xy. Я так понимаю все примерно так и делают?

Ну, в общем-то, - да. Диоды нужно подключать не поштучно, а организовать в виде матрицы M*N. У Вас теперь, насколько я понял, матрица 8*64. На Меге для этого ног хватает? Я бы сделал 16*32 или даже 23*23. Впрочем, 46 или 48 ног занято - это уже не принципиально.

Да, матрица 8х64. Про кол-во ног немного не понял. У нас ведь сдвиговые регистры стоят, которые "размножают" ноги микроконтроллера давая возможность подключить 72 вывода кубика используя всего 3 вывода микроконтроллера. Но, одновременно с этим полезным свойством, они также увеличивают время обработки. Это время тратится на забивание 72 битов в регистры. Но основное затруднение в развертке изображения по слоям. Именно во время разворачивания изображения по слоям приходится на некоторое время тушить все слои кроме одного. И на меге и на нане мы использовали всего 3 цифровых вывода.

Если сделать матрицу 16х32, тогда придется делать развертку по 16-ти слоям, если 23*23, тогда уже по 23-ем слоям. А это уменьшит время светимости диодов, идеально было бы уменьшить кол-во слоев до одного получив матрицу 1х512. Тогда диоды друг другу вовсе не будут мешать ни при каких условиях, а значит их можно будет вовсе не гасить. Но тогда придется вести 512 проводов на 64 регистра. Это ж ужас! Особенно если вспомнить о том, что пайка должна представлять из себя нечто 3-х мерное. Этож непроглядная чаща, за которой диодов вовсе видно не будет. Можно конечно использовать какие-нибудь специальные тоненькие провода, но с пайкой проблем меньше не станет - это точно.

Вариант 1. Можно разбить весь кубик на 8 подкубиков, тогда каждый из подкубиков будет управляться со своих 3 цифровых выводов, получается 3*8=32, тактовый вывод можно сделать общим, тогда получается 2*8+1=17 цифровых вывода. Прелесть заключается в том, что необязательно гасить один из подкубиков, чтобы зажечь светодиоды в другом подкубике, а значит и яркость увеличится, но правда всего в два раза, так как у каждого подкубика есть 4 слоя по которым нужно делать развертку и получится 1/4 от нормального свечения. Тогда изначальная матрица 8х64 разбивается на 8 матриц 4х16.

Вариант2. Но если так, тогда логичнее и вовсе пустить 8 отдельных выводов на каждый слой и управлять их включением напрямую с цифровых выводов через ключи без регистров. Тогда изначальная матрица 8х64 разбивается на 8 матриц 1х64. Посчитаем что в этом случае понадобится. Каждый из слоев теперь независим, а значит на КАЖДЫЙ из них нужно 64 вывода или 8 микросхем 74HC595, получается нужно 8микросхем в слое х 8 солев=64 микросхемы! и на каждую из них нужно вести провода, и того получится 64 вывода с одного слоя*8 слоев = 512 вертикальных провода. Это целый лес! А ног микроконтроллера (если тактовый вывод сделать общим) понадобится 2*8+1=17 + 8 ног на слои. Итого получится 25 ног. + конечно усложняется процесс программирования. А в целом эта ситуация аналогична варианту матрицы 1х512.

Вот, составил табличку для кубика 8x8x8:

Думаю что все-таки 8х64 - это самый оптимальный вариант, так как не требует таких временных вложений на пайку как 1х512 или 8 матриц по 1х64 (кроме того, и по финансам накладно получается это ж 64 сдвиговых регистра). А большинство вопросов по светимости легче решать уловками в программировании, нежели в пайке. Увеличение же кол-ва слоев (16х32 или 23х23) только понизит яркость свечения.

Мне кажется так получается.

Выскажу свое ИМХО: посмотрев на схему(картинку, не стал качать программу возможно там подробнее) не понял почему у вас диоды соединены последовательно, предположу что схема управляющей электроники у вас схожа с той что реализовал я, но моя схема опирается на свойства диода и на програмный код. Поэтому я порекомендую переосмыслить ваш код. попробуйте в главном методе(loop) делать заполнение регистров, т.е. метод вызвался записали 72бита информации в регистры, в конце цикла передернули переключатель выводов в регистре, и все... за один вызов светить 1 этаж. и так поочереди... еще расскажите как вы будете делать сами эффекты. т.е. будете их получать с компьютера или будете их применять на самой ардуино...

Ой! Я ж неправильно схему нарисовал! Диоды подругому подключены, позже переделаю.

ну я так понял что схема подключения у вас идентична моей...

ответьте на вопрос о эффектах, где они будут происходить?

Вероятнее всего мы однажды забьем в ардуину n-ное кол-во эффектов и на этом успокоимся, включать (загружать) эффекты с компьютера в режиме онлайн пока не собирались. Из интересного думаем насчет тетриса, змейки и что-то типа цветомузыки. Для тетриса и змейки выведем кнопки, а для цветомузыки, наверное, сделаем аналоговые фильтры на операционных усилителях и пустим на 8 аналоговых входов. Однажды я пытался использовать ардуину как вольтметр, и результат меня очень огорчил. Очень много шума на встроенной ацп. Для нормального измерения напряжения приходилось делать усреднение, а если усреднять звуковой сигнал, то мы получим 0 на выходе. То есть усреднять нельзя. Короче, разложение Фурье делать на штатном АЦП врядли получится, НО я не пробовал.

Понятно, в общем попробуйте переосмыслить и  переписать код. ну и не забывайте освящать свои достижения здесь, можете попробовать адаптировать мой код.

Почти, но я так понял у вас npn-транзисторы на слои, а у нас стоят pnp. Где-то выше видел уже обсуждение pnp-npn.

Будем переосмысливать, дальше будем работать только после школьных каникул.
Вот залил правильную схему: http://fss4.narod.ru/led_cube/led_cube-schem_02.gif

Это вы правильно)))) мне перепаивать и управляющую и сам куб уже небыло смысла, а собрать новый пока нет времени.

Если что пишите вопросы, будем вместе разбираться.

я бы изменил схему:

1. сделать общим для светодиодов не плюс, а минус, тогда не придется заморачиваться с инвертированием свечения

2. если сделать 1 изменение транзисторы заменил бы на 2N7000 или 2N7002. резисторы R1...R8 тогда не понадобятся, а резисторы R17...R24 уменьшил до 10к

3. если сделать первые 2 изменения то R9...R16 вообще убрал бы, а питание 74HC595 (только регистров) сделал бы 3.3В от отдельного стабилизатора (именно отдельного, а не встроенного). тогда если использовать белые или синие светодиоды как раз резисторы не понадобятся. даже если красные или зеленые тоже самое, время свечения очень маленькое, проблемм не должно быть

4. Использовать SPI

Я бы какраз плюс сделал общим а не минус из-за возможности подать на диоды больше чем 5 выходных вольт из регистра, и сила тока на регистре ограничена помоему 50мА инвертировать в коде 0 и 1 не трудно, т.е. можно собрать схему на более ярких диодах.....

Это интересно. Расскажите пожалуйста, какие преимущества даст SPI? Я просто не вкурсе что это, только википедию посмотрел.

вот это рискованно напряжение подавать выше напряжения питания регистра, порты можешь попалить более мощными светодиодами

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

это сильно ускорит скорость отрисовки, что важно на больших кубах

А может и правда прицепить на ардуину внешнюю память (sd-карту к примеру) и в нее забить несколько эффектов. Тогда кадры эффектов можно будет сгенерировать на компе, это во много раз проще, написать простенькую программу, чтобы она формировала последовательности 1010111001100ит.д. по нарисованной картинке. И Дуине не придется каждый раз считать что сейчас нужно 1 или 0. Кроме того можно хоть бабу голую изобразить :) Готовые строки залить на sd-карту и просить дуину считывать строку за строкой и писать в регистры. Как думаете?

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

ты не так представляешь. 11 12 13 пины арудины (уно например) это spi. для сдвигового нужно два из них. data и clock

А если я захочу еще и sd прицепить, то ног уже не хватит?

Ну это уже тут ранее обсуждали, что при 0 на выходе регистр просто замыкает ногу на массу... не спорю, риск конечно есть... ну как вариант можно напаять транзисторы для управления))) но блин их 64.... я об этом думал потомучто я использовал желтые диоды и не мог им подать достаточное напряжение чтобы они горели приемлимо, т.е. днем их было плохо видно

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

а вообще на один spi повесить не одно устройство не проблема, но у сдвигового регистра нет входа CS или CE, поэтому куб будет реагировать на любые данные которые отправляются на карту. это решаемо, но пока расписывать не буду. в данном случае наверно уже оптимальнее ногодрыг

на землю да, а теперь подумай куда замыкает когда на выходе 1? короче еще раз подумай прежде чем так делать.

к тому же есть uln2003. копеечная и легкодоступная

Ну, можно и в оперативку загрузить строки из флешки. Кстати, а сколько бит влезет в оперативку arduino? Я так понимаю нас интересует EEPROM, там 512 байт, то есть 4096 бит. Ага пусть будет так:
1 кадр определяет свечение всех 512 светодиодов, и представляет 3-d изображение, сформированное разверткой по слоям.
1 строка содержит в себе информацию о светимости всех светодиодов на слое (64 бита) и имеет адрес слоя (еще 8 бит).

Тогда 1 кадр содержит (64+8)*8=576 бит. Получается, что в EEPROM есть возможность хранить 4096/576 кадров, то есть можно хранить 7 кадров и еще останется 64 бита. Тогда можно подгружать с SD-карты в EEPROM новые кадры, когда предыдущие больше не используются. На этом можно сэкономить время, так как кадр некоторое время (хотя-бы 1/24 секунды) должен висеть на кубике. Однако важно, чтобы EEPROM работала подобно сдвиговым регистрам не перезаписываясь полностью, а сдвигая информацию в хвост. С хвоста же и будем читать текущий кадр. А может быть нифига и не получится, так как во время записи в EEPROM чтение оттуда будет затруднительно, ведь нужно читать "двигающуюся" информацию. А если ждать этот промежуток времени, тогда получится однофигственно, что с SD-карты читать напрямую, что через EEPROM. А с другой стороны у нас есть 1/24 секунды на запись нового кадра в EEPROM. Короче пока непонятно, слишком много тусовок информации с места на место получается. Может кто уже этим занимался?

Только-что заказал с алиэкспресса sd-шилд и sd-карту :)

а зачем eeprom? в оперативку

но схема непонятно нарисована, или я просто непонимаю

Ну да, ОЗУ даже болше :) Какая схема? Эта?

http://fss4.narod.ru/led_cube/led_cube-schem_02.gif