Не получается мигание светодиодом с AVR Studio

РобоКОТ

Здравствуйте. Попытался написать простую программку для мигания светодиодом в AVR Studio с использованием таймера/счетчика Т/С0 (ATmega64). Идея такая: при переполнении таймера программа уходит в отработчик прерывания, там декрементируется некоторое число, которое затем сравнивается с нулем и если оно равно нулю- меняется состояние светодиода.
Написал, но симулятор не хочет показывать то, что я ожидал. Исходник присоединен к посту.
При компиляции и запуске в симуляторе программа не хочет уходить в отработчик.
И что еще интересно- в функции main() есть цикл while(1), который по идее должен быть бесконечным. Но бегать внутри него симулятор не хочет.
При создании хекса и прошитии контроллера ничего не происходит.
При переносе программы в IAR и изименении кое-чего кое-где для совпадения синтаксиса программа шьется и работает нормально (диод мигает).
Ткните носом, люди добрые

Реклама

ARV · Сообщение **ARV** » Вт сен 22, 2009 13:42:04

Код: Выделить всё

#include (avr/io.h)
#include (avr/iom64.h)       //[1]
#include (avr/signal.h)       //[2]
#include (avr/interrupt.h)
long SYS_FREQ=14745600;//тактовая частота [3]
int STROBE_FREQ=1;		//частота мигания
int i;					//просто переменная
long Schetchik;			/*Число переполнений
счетчика до смены состояния*/
// обработчик прерывания по переполнению Т/С0
SIGNAL (SIG_OWERFLOW0) // [4]
{Schetchik--;
 if (Schetchik==0)
 {
  PORTD^=(1<<6);/*Смена значения бита
  6 порта Д*/
  Schetchik=SYS_FREQ/(STROBE_FREQ*256);
 }
}

void main (void) // [5]
{	TCCR0=1;/*установка предделителя=1*/
	TIMSK=0b00000001;/*разрешение прерывания
по переполнению Т/С1*/
	sei();/*установка бита I в регистре SREG*/
	Schetchik=SYS_FREQ/(STROBE_FREQ*256);
	DDRD=0xFF;
	PORTD=0xFF;
	while (1)
	{i++;
	}
}

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

[1] вы должны подключать только avr/io.h и все, подключение конкретного хидера выбранного МК происходит автоматически
[2] signal.h не нужно подключать - это устаревший модуль, функции которого полностью реализованы (с улучшениями) в interrupt.h
[3] здесь есть недочет и ошибка:
- недочет: есть макрос F_MCU, который необходимо задавать для сборки проекта - он определяет тактовую частоту в герцах, поэтому вводить дополнительную переменную - излишество
- ошибка: 14745600 нельзя указывать в таком виде, т.к. по умолчанию все числа имеют тип int и значение вашей переменной будет совсем не то, что вы ждете. надо указать суффикс UL - тогда все будет верно: 14745600UL
[4] макрос SIGNAL - устаревший, рекомендуется использовать макрос ISR
[5] функция main должна определяться как int main(void)

почти на каждое из мойх примечаний компилятор должен давать WARNING - вы не читаете, что он вам пишет?

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

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

Реклама

РобоКОТ

Спасибо за ответ. Внес исправления, но :
- Встал вопрос: "как "поймать" процесс в бесконечный цикл?". Ведь иначе декрементируемая переменная в новом прогоне функции main() вернет себе старое значение.
- в окне Build осталось единственное предупреждение "../diod.c:10: warning: 'SIG_OWERFLOW0' appears to be a misspelled signal handler" - я так воспринял это как ошибку синтаксиса (misspelled - неправильное написание). Поменял 'SIG_OWERFLOW0' на "TIMER0_OVF_Vect"- предупреждение пропало. Но почему оно появлялось? ведь это два описания одного вектора прерывания, судя по хидеру, они равнозначны.
- еще на первом курсе учили что т.к. функция main не возвращает значения- она описывается как void. Почему здесь важно чтобы функция имела тип целого числа?

Код: Выделить всё

#include <avr> 
#include <avr> 
#define F_CPU 14745600UL;			//тактовая частота [3] 
volatile int STROBE_FREQ=1;     //частота мигания 
volatile int i;               	//просто переменная 
volatile long Schetchik;      	/*Число переполнений 
 счетчика до смены состояния*/ 

// обработчик прерывания по переполнению Т/С0 
ISR (SIG_OWERFLOW0) // [4] 
{
 Schetchik--; 
 if (Schetchik==0) 
 { 
  PORTD^=(1<<6);				/*Смена значения бита 
  6 порта Д*/ 
  Schetchik=F_CPU/(STROBE_FREQ*256); 
 } 
} 


int main (void) // [5] 
{   TCCR0=1;					/*установка предделителя=1*/ 
   TIMSK=0b00000001;			/*разрешение прерывания 
по переполнению Т/С1*/ 
   sei();						/*установка бита I в регистре SREG*/ 
   Schetchik=F_CPU/(STROBE_FREQ*256); 
   DDRD=0xFF; 
   PORTD=0xFF; 
 while (1) {i++;}
}

Макрос, запоминающий частоту процессора похоже зовется F_CPU.

РобоКОТ

вроде заработало, прошилось-мигает как надо. Но симулятор первые пару кругов всеравно себя ведет не понятно для меня

Реклама

ARV · Сообщение **ARV** » Ср сен 23, 2009 09:59:48

РобоКОТ писал(а):Спасибо за ответ. Внес исправления, но :
- Встал вопрос: "как "поймать" процесс в бесконечный цикл?". Ведь иначе декрементируемая переменная в новом прогоне функции main() вернет себе старое значение.
- в окне Build осталось единственное предупреждение "../diod.c:10: warning: 'SIG_OWERFLOW0' appears to be a misspelled signal handler" - я так воспринял это как ошибку синтаксиса (misspelled - неправильное написание). Поменял 'SIG_OWERFLOW0' на "TIMER0_OVF_Vect"- предупреждение пропало. Но почему оно появлялось? ведь это два описания одного вектора прерывания, судя по хидеру, они равнозначны.
- еще на первом курсе учили что т.к. функция main не возвращает значения- она описывается как void. Почему здесь важно чтобы функция имела тип целого числа?

1. на счет F_CPU - да, конечно, прошу прощения, зарапортовался.
2. бесконечный цикл это while(1); зачем вы в нем инкрементируете i, если эта самая i никогда нигде никем не используется? просто, щоб було?

это лишнее.
2. вообще-то макроса SIG_OWERFLOW не существует и правильно ругался компилятор. существует SIG_OVERFLOW. но для макроса ISR не надо использовать макросы SIG_xxx, я уже об этом говорил: это устаревший синтаксис, сохраняемый пока для совместимости со старыми версиями компиляторов.
3. функция main() по стандарту Си определена как возвращающая int - не знаю, кто и как вас учил... по стандарту эта функция возвращает результат в ОС. т.к. в МК нет "окружающей" ОС (обычно нет), то результат main() может не возвращать, но определяться все равно должна по правилам, иначе будет WARNING компилятора. Принципиального значения это не имеет (для МК), но лучше не привыкать делать неправильно.

в вашем коде есть несколько неоптимальностей, которые, в принципе, ликвидируются компилятром (и его оптимизатором), но в итоге вы можете с удивлением пытаться поставить в отладчике точку останова на вашем i++, а ничего не выйдет... поэтому я бы советовал "причесать" код, выкинув из него все реально лишнее. например, глобальную переменную Schetchik. кстати, действительно нужна аж 32-битовая переменная со знаком для этого? может, лучше сделать предделитель таймера побольше, а счетчик взять типа uint16_t или еще лучше uint8_t ? чем меньше размер переменной, тем оптимальнее результирующий код. переменные со знаком обрабатываются менее оптимально, чем беззнаковые. не используйте типы с "перебором" - старайтесь использовать минимально достаточные.

Реклама

РобоКОТ

Вроде разобрался с вопросом:) Вещи просты, но почему- то сразу до них не доехал.
Вопрос не совсем по сабжу: На работе программисты сказали что у AVR STudio есть какая-то жутко неприятная особенность при работе с прерываниями, которая делает использование данной среды не возможным при решении многих задач. Так это, или люди не разобрались просто?

Реклама

ARV · Сообщение **ARV** » Пн сен 28, 2009 07:46:07

так разве ваши программисты не сказали, что это за особенность? или слышали звон, да не знают, где он?

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

РобоКОТ

Сказали. По какой-то причине на определенных участках программы при заходе в отработчик не сбрасывался бит I SREG. В итоге выхода из отработчика небыло.

ARV · Сообщение **ARV** » Пт окт 09, 2009 17:44:52

РобоКОТ писал(а):Сказали. По какой-то причине на определенных участках программы при заходе в отработчик не сбрасывался бит I SREG. В итоге выхода из отработчика небыло.

одно из двух - либо ваши программисты лохи последние, либо просто вам пудрят мозги. выход из обработчика обеспечивается командой reti которую студия на 100% точно эмулирует

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

и бит разрешения прерываний тут ни при чем.

Pooher

Ну, если такой "баг" действительно существует, то я готов поспорить с ARV.
Если при входе в обработчик флаг I не сбрасывается, то при наличии задержки достаточной длительности (при использовании прерываний таймеров), и в целом, при наступлении условия прерывания в процессе выполнения обработчика, контроллер в нём и "зависнет".

ARV · Сообщение **ARV** » Пт окт 09, 2009 19:39:32

Pooher писал(а):Ну, если такой "баг" действительно существует, то я готов поспорить с ARV.
Если при входе в обработчик флаг I не сбрасывается, то при наличии задержки достаточной длительности (при использовании прерываний таймеров), и в целом, при наступлении условия прерывания в процессе выполнения обработчика, контроллер в нём и "зависнет".

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

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

хотя, конечно, спор о багах просто смешон - баг потому и баг, что непредсказуем

Pooher

Просвятите. А что произойдёт в "реальном железе", если стек перепролнится? Очень стало интересно, завтра обязательно попробую зашить такой программой.

Pooher

Блин, не удержался, проверил. Поставил sei в начале обработчика, и...ничего не изменилось. Программа как работала, так и работает. Я в прострации...

ARV · Сообщение **ARV** » Пт окт 09, 2009 21:25:03

Pooher писал(а):Блин, не удержался, проверил. Поставил sei в начале обработчика, и...ничего не изменилось. Программа как работала, так и работает. Я в прострации...

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

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

Redrik Shuhart

а че низя так
x= имя порта (А,В,С...)
CHA4AJlA include "delay.h";

Код: Выделить всё


......
PORTX.0=0;
delay_ms(500);
PORTX.0=1;
delay_ms(500);
PORTX.0=0;

все в цикле основном, и оно просто миганет

Pooher

sei в начале обработчика прерываний - так это даже нормальная практика в некоторых случаях

Ну, это я в курсе. Просто я совершенно не понял почему ничего не произошло при том, что я разрешил прерывания в обработчике, в котором абсолютно обязательно произойдёт тоже самое прерывание, что как Вы и говорили, непременно должно переполнить стек. Железо как работало, так и продолжает уже больше часа. Мигает, зараза, светодиодом и хоть ты тресни

ARV · Сообщение **ARV** » Сб окт 10, 2009 13:11:19

Pooher писал(а):Просто я совершенно не понял почему ничего не произошло при том, что я разрешил прерывания в обработчике, в котором абсолютно обязательно произойдёт тоже самое прерывание, что как Вы и говорили, непременно должно переполнить стек. Железо как работало, так и продолжает уже больше часа. Мигает, зараза, светодиодом и хоть ты тресни

ну не знаю

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

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