Форум РадиоКот

ssvd писал(а):Посмотрите пожалуйста схему, так подключил транзисторы?

Немного не так. Поменяйте коллектор и эмиттер местами. А между базами и выходами порта включите резисторы 5-10 кОм.
Балластных резисторов на каждый светодиод, тоже не вижу.

ValBag писал(а):

ssvd писал(а):Посмотрите пожалуйста схему, так подключил транзисторы?

Немного не так. Поменяйте коллектор и эмиттер местами. А между базами и выходами порта включите резисторы 5-10 кОм.
Балластных резисторов на каждый светодиод, тоже не вижу.

вроде бы все в порядок привел!

ssvd, все верно.

ValBag писал(а):ssvd, все верно.

ух, наконец то! все понятно вроде как!
у нас уже ночь, завтра программу допишу, проверите и ее плиз )))

ValBag писал(а):ssvd, все верно.

Вот окончательный вариант Proteus+исходник. Посмотрите пожалуйста!
Если все ok, побегу за деталями в маг ))))

А вот такой транзистор можно использовать DTC144EK SMD ?

ssvd писал(а):Если все ok, побегу за деталями в маг ))))

OK.
Вариант блока:
switch (cur_dig)
{
case 0:PORTD|=1;PORTB=hour; break;
case 1:PORTD|=2;PORTB=min; break;
case 2:PORTD|=4;PORTB=sec;
}
Тело оператора сase можно не ограничивать {...}.

А вот такой транзистор можно использовать DTC144EK SMD ?

Без проблем, если хватит его возможностей по току - 100 mA.
P.S. Опять там остался PORTB=0xFF;

ValBag писал(а):

ssvd писал(а):Если все ok, побегу за деталями в маг ))))

OK.
Вариант блока:
switch (cur_dig)
{
case 0:PORTD|=1;PORTB=hour; break;
case 1:PORTD|=2;PORTB=min; break;
case 2:PORTD|=4;PORTB=sec; break;
}
Тело оператора сase можно не ограничивать {...}.

А вот такой транзистор можно использовать DTC144EK SMD ?

Без проблем, если хватит его возможностей по току - 100 mA.
P.S. Опять там остался PORTB=0xFF;

ok.
100мА должно хватить, 6 диодов по 15мА=90мА
Спасибо огромное! На неделе постараюсь собрать, отпишусь в личку, обмоем )))

Возник такой вопрос как в CVAVR в Atmega128 отключить JTAG чтобы мона стало использовать порт F на вывод ,а не только на ввод?.
P.S Хелп компилятора не надо отправлять читать с английским очень плохо дружу.

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

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

Вопрос снят :Project>Configure>After Make>Program the Chip>JTAGEN=0; теперь компилятор позволяет работать с портом F.

Появился CodeVisionAVR V2.04.6 но лечения его в сети незамечено, может у когонить есть?

Всем доброго времени суток и МЯУ!
Пришлось мне сюда вернуться с вопросом:

Есть нехитрая программка типа "бегущие огни", написанная на Си в CVAVR.
Такая задача: при включении огоньки должны несколько раз (4-6) повторить определённое мигание, и больше к нему не возвращаться. Можно было бы это всё несколько раз копировать до "while (1)", но хотелось бы укоротить программу. Может как-то repeat сюда впихнуть?
В программирование не силён, да и то, что знал, немного подзабыл.

Подскажите мне решение этой простой задачи

цикл for спасет DataLife

Спасибо за подсказку.
Немного погуглил по этому поводу, значит нужно сделать примерно так: Так? Вроде бы цикл будет выполняться, пока i<4 то есть 4 раза (0,1,2,3)?
Я правильно понял смысл цикла for?

Добавлено:

О! Так тут и вайлом можно (while)! Так ведь?

PS.
вопрос второй: можно как-то коротко написать программку для хаотичного включения 12-ти светодиодов? Как-то не хочется придумывать какой сейчас включать, время задержки и прочее ... Может этот "велосипед" придумали до меня?

вы поняли правильно суть циклов. можно любым способом, но for наиболее кратко и элегантно записывается, не так ли?

что касается хаоса, то кроме использования функции генерации псевдослучайного числа rand() ничего на ум не приходит.

Вопрос к ARV как к профи, ...если можно.
CodeWizard вставляет такие строки:
1. при предварительном делении частоты кварцевого генератора: и при настройке сторожевого таймера:Т. е. выключается оптимизация по размеру, что-то делается..., и включается снова. А для чего это в данных случаях? Какие-то особенности компилятора? Ведь изменяются только регистры.

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

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

имхо, это какой-то кривой способ. в WinAVR, например, все порты ввода-вывода и регистры управления периферией объявлены как volatile переменные, и поэтому обращения к ним не надо как-то по особому оформлять, все будет сделано верно при любом уровне оптимизации.

ARV писал(а):...так как компилятор при оптимизации пытается уменьшить число записей в переменную...

Понятно, спасибо.

имхо, это какой-то кривой способ. в WinAVR, например, все порты ввода-вывода и регистры управления периферией объявлены как volatile переменные, и поэтому обращения к ним не надо как-то по особому оформлять, все будет сделано верно при любом уровне оптимизации.

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

в каждой палатке свои неполадки.
в данном случае речь не о методах оптимизации, а о системном подходе. CVAVR считает, что все периферийные регистры - это обычные глобальные переменные, а WinAVR уверен, что это volatile переменные. между ними большая разница! так вот, подход WinAVR мне видится гораздо более верным, ибо все эти периферийные регистры (ну не все, но многие) имеют обыкновение менять свое значение по аппаратным причинам, о чем компилятор знать не может! и в данном контексте volatile как раз и требуется. для работы с WDTCR или еще чем-то аналогичным в WinAVR нет нужды ни в каких "обрамлениях" типа pragma или чего-то еще - безошибочная работа гарантируется в режиме "по умолчанию".

всегда легче работать с инструментом, поведение которого предсказуемо и определяется какими-то общими для всех требованиями, в частности, стандартами. а когда CVAVR не делает иной раз разницы между volatile и non-volatile переменными, но в то же самое время иногда вдруг "вспоминает об этом" и начинает лепить всякие прагмы - это ни в какие рамки не укладывается.