Реклама на сайте DatasheetsDatasheets

KAZUS.RUN - Электронный портал. Принципиальные схемы, Datasheets, Форум по электронике

Новости электроники Новости Литература, электронные книги Литература Документация, даташиты Документация Поиск даташитов (datasheets)Поиск PDF
  От производителей
Новости поставщиков
В мире электроники

  Сборник статей
Книги и журналы
FAQ по электронике

  Datasheets
Поиск SMD
Онлайн справочник

Принципиальные схемы Схемы Каталоги программ, сайтов Каталоги Общение, форум Общение Ваш аккаунтАккаунт
  Каталог схем
Схемы и проекты
Принципиальные схемы
  Программы
Каталог сайтов
Калькуляторы
  Форумы по электронике
Помощь проекту

Микроконтроллеры, АЦП, память и т.д Темы касающиеся микроконтроллеров разных производителей, памяти, АЦП/ЦАП, периферийных модулей...

 
Опции темы

Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Непрочитано 25.06.2010, 01:21  
291066
Прописка
 
Регистрация: 05.03.2010
Сообщений: 144
Сказал спасибо: 47
Сказали Спасибо 195 раз(а) в 19 сообщении(ях)
291066 на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

В данном случае это была переменная которая использовалась и в обработчике прерывания. Эта была одна из причин изменения логики работы программы при включенной оптимизации. Учитывая тот факт, что компилятор написан под определенный процессор, то разработчикам надо было бы предусмотреть хотя бы анализ того, где переменная используется.
Реклама:
291066 вне форума  
Непрочитано 25.06.2010, 04:26  
Godzilla82
Почётный гражданин KAZUS.RUN
 
Регистрация: 29.10.2006
Сообщений: 1,449
Сказал спасибо: 99
Сказали Спасибо 318 раз(а) в 234 сообщении(ях)
Godzilla82 на пути к лучшему
Сообщение Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Сообщение от 291066 Посмотреть сообщение
В данном случае это была переменная которая использовалась и в обработчике прерывания. Эта была одна из причин изменения логики работы программы при включенной оптимизации. Учитывая тот факт, что компилятор написан под определенный процессор, то разработчикам...
Вот не надо грешить на компилятор и оптимизацию. Если программа написана правильно, то никакой оптимизатор её не испортит.

Говорить сейчас о чём-то конкретном без листинга вашей программы бесполезно. По своему опыту скажу, что ни разу не сталкивался с тем, чтобы оптимизация меняла логику программы.

Было один раз, что использовалось union, и при разных случаях были разные результаты. Но потом, узнав, что данные в union выравниваются, чтобы быть кратными 8 байтам (это про PC), всё встало на свои места. Хотя можно было тоже кричать, что разработчики компилятора накосячили. Ваша же задача - понять суть и сделать так, как надо. Принимая во внимание тот факт, что компилятор не виноват.

Объявлять переменную можно по разному. Да. Но если переменная используется и в программе и в прерывании, то переменная должна быть глобальной и объявляться до её первого вызова.
Для переменных в AVR обычно используются регистры. Это тоже надо учитывать, хотя компилятор (без использования ассемблерных вставок) сам всё разрулит.

Вы бы привели листинг программы, и сказали, что она должна делать. А потом стало бы ясно. Почему после включения оптимизации её работоспособность нарушается.
Godzilla82 вне форума  
Непрочитано 25.06.2010, 11:37  
291066
Прописка
 
Регистрация: 05.03.2010
Сообщений: 144
Сказал спасибо: 47
Сказали Спасибо 195 раз(а) в 19 сообщении(ях)
291066 на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Согласен, что априори компилятор работает верно. Согласен с тем, что проблема в написанном мною исходном коде. Принимаю даже то, что сейчас меня можно назвать "чайником" т.к. очень давно ничего не писАл. Но, покажите мне где можно почитать о том как надо писать под этот компилятор. Конечно, могу выложить листинг, не сомневаюсь в том , что будет найдена моя ошибка, уверен в том что совместными усилиями программа будет запущена будет выполнять свои функции на протяжении долгого времени. Но, хочется самому в этом разобраться. Для меня сейчас эта программа и железяка просто поделка для дома. Вполне возможно, что в дальнейшем что-то изменится, но пока это так. Спасибо за предложенную помощь, но я пока сам поищу. Запустил четвертый ШИМ просто внимательно почитав даташит. Естественно это был мой косяк. Просто получаю огромное удовольствием в процессе копания во всем этом Если уж у меня ничего не выйдет, тогда уже обращусь сюда за помощью.
Судя по активности в данной теме, то я зацепил довольно важную проблему. А действительно, есть ли где то материал описывающий правильный подход к разработке программ для AVR и описывающий особенности компиляторов?

Последний раз редактировалось 291066; 25.06.2010 в 11:39.
291066 вне форума  
Непрочитано 25.06.2010, 13:22  
SasaVitebsk
Гражданин KAZUS.RUN
 
Регистрация: 04.08.2006
Сообщений: 911
Сказал спасибо: 28
Сказали Спасибо 180 раз(а) в 139 сообщении(ях)
SasaVitebsk на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Ещё раз поясняю. Не имеет значения, что за компилятор вы используете в данном случае. Это не проблема конкретного компилятора, это общий принцип языка Си. Причём весьма правильный.

Представьте, что у вас большая прога. При этом основная прога написана в одном файле, а прерывание в другом. Ну? Начинаете соображать? Усложним задачу. Основная прога написана в одном файле, а прерывания написаны на ASM или например на Pascal, а потом это всё собирается линкером. Ну и поставьте себя на место разработчика компилятора - как это разрулить?

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

В данном случае надо объявить переменную глобальной и указать квалификатор volatile, чтобы компилятор понял что переменная может изменится вне логики работы ф-ции.
SasaVitebsk вне форума  
Непрочитано 25.06.2010, 14:09  
OlegNZH
Почётный гражданин KAZUS.RUN
 
Регистрация: 28.02.2010
Сообщений: 2,294
Сказал спасибо: 52
Сказали Спасибо 460 раз(а) в 391 сообщении(ях)
OlegNZH на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Сообщение от SasaVitebsk Посмотреть сообщение
А вопрос эффективности программы, на данном этапе, решается выбором процессора с запасом по производительности. Благо выбор сейчас большой и разница в ценах незначительна. Например не получается решить задачу на ATMEGA88 с производительностью 20 мипсов проц 8 бит - берём LPC1113 с производительностью 50 мипс проц 32 бита. Что в целом обеспечит рост производительности раз в 5-6. Первый проц стоит 1.15$, второй - 1.5$.

Хорошо.А теперь добавьте к 35 центам - зарплату(месяц на ARM переходить) , Оснастку (компилятор- отладчик ),накладные расходы (начальство бывает трудно уговорить перейти на новую платформу)- и потом - станет понятно, что разовая Акция- неудачный пример
OlegNZH вне форума  
Непрочитано 26.06.2010, 03:08  
291066
Прописка
 
Регистрация: 05.03.2010
Сообщений: 144
Сказал спасибо: 47
Сказали Спасибо 195 раз(а) в 19 сообщении(ях)
291066 на пути к лучшему
Злость Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Все, исчерпалась моя фантазия!
Прошу помощи у сообщества.
Есть исходник программы (см. вложение). Не могу заставить реагировать на прерывание с PB1. В инициализации только извращенным способом заставил подняться флаг PCIE в GIMSK

GIMSK = 0b01110000;
GIMSK |= (1‹‹INT0)|(1‹‹INT1)|(1‹‹PCIE);
MCUCR = (1‹‹PUD)|(1‹‹ISC11) |(1‹‹ISC10) |(1‹‹ISC01)|(1‹‹ISC00);

Смотрел в эмуляторе. Только таким извращенным способом он поднимается.

ставлю строчку
GIMSK = (1‹‹INT0)|(1‹‹INT1)|(1‹‹PCIE);
первым исполняемым оператором. Устанавливается INT0 и INT1, а PCIE так и остается нулевым.
В листинге:
GIMSK = (1‹‹INT0)|(1‹‹INT1)|(1‹‹PCIE);
39e: 80 ee ldi r24, 0xE0 ; 224
3a0: 8b bf out 0x3b, r24 ; 59
Вроде тоже все правильно. А оно не работает.
INT0 и INT1 работают нормально. Они у меня отвечают за опрос нажатой клавиши.
В чем я неправ?
Кроме того, никак на могу разобраться нужен ли мне PUD и на что он влияет.
Наверняка какой то очевидный хомут, но уже ничего не могу придумать.
Вложения:
Тип файла: rar Dimmer_2313.rar (7.1 Кб, 45 просмотров)

Последний раз редактировалось 291066; 26.06.2010 в 03:24.
291066 вне форума  
Непрочитано 26.06.2010, 03:47  
Godzilla82
Почётный гражданин KAZUS.RUN
 
Регистрация: 29.10.2006
Сообщений: 1,449
Сказал спасибо: 99
Сказали Спасибо 318 раз(а) в 234 сообщении(ях)
Godzilla82 на пути к лучшему
Сообщение Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Не работал конкретно с этим, но CodeVision генерит:

Код:
// External Interrupt(s) initialization
// INT0: On
// INT0 Mode: Rising Edge
// INT1: On
// INT1 Mode: Rising Edge
// Interrupt on any change on pins PCINT0-7: On
GIMSK=0xE0;
MCUCR=0x0F;
PCMSK=0x02;
EIFR=0xE0;
Этот код включает прерывание на изменение сигнала только на входе PCINT1 и на фронт сигналов на INT0 и INT1.

PCMSK - маска, задающая пины порта, изменение которых должно приводить к возникновению прерывания. Я не нашёл и намёка на него в вашей программе.

Почему функция Init() описана после её вызова в main()?
Переместите функцию main() в самый конец файла.

PB4, PB5 - это что, просто константы 4, 5?

Тогда не совсем понятна такая конструкция:
Код:
PORTB &= ~((1‹‹PB7)|(1‹‹PB6)|(1‹‹PB5)|(1‹‹PB0));
Не проще:
Код:
PORTB &= 0b00011110
И по возможности избегать оператора сдвига, и использовать константы.

Код:
volatile unsigned char i_local;
Надо вынести за пределы функции main() в самое начало файла. Это же проделать со всеми переменными, которые используются в разных функциях или прерываниях.

Напряжение на ноге (после записи в порт) меняется в течении 4 тактов (если не ошибаюсь).
Ставить два нопа и тут же мерять - может не успеть аппаратная часть (из-за ёмкостей, всё-таки частота получается большая). Я бы поставил задержку в несколько микросекунд, что-то типа delay_us(10);

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

Последний раз редактировалось Godzilla82; 26.06.2010 в 07:33.
Godzilla82 вне форума  
Сказали "Спасибо" Godzilla82
291066 (30.06.2010)
Непрочитано 26.06.2010, 05:17  
CERGEI1982
Почётный гражданин KAZUS.RUN
 
Аватар для CERGEI1982
 
Регистрация: 03.01.2007
Адрес: Россия,Иркутская обл.
Сообщений: 2,578
Сказал спасибо: 351
Сказали Спасибо 315 раз(а) в 193 сообщении(ях)
CERGEI1982 на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Было такое в моей практике,что компилятор Си глючил.Помогло что знаю ассамблер и разбирал исходники на ассамблере после компиляции.
Помочь пока не могу,так еще не знаком сильно с АВР
__________________
Глаза боятся,а руки делают.
CERGEI1982 вне форума  
Непрочитано 26.06.2010, 09:51  
testerplus
Прописка
 
Регистрация: 26.01.2009
Сообщений: 249
Сказал спасибо: 23
Сказали Спасибо 102 раз(а) в 61 сообщении(ях)
testerplus на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Сообщение от 291066 Посмотреть сообщение
В инициализации только извращенным способом заставил подняться флаг PCIE в GIMSK

GIMSK = 0b01110000;
GIMSK |= (1‹‹INT0)|(1‹‹INT1)|(1‹‹PCIE);
Вы какой из способов обзываете извращенным? Лично я - первый, т.к. он порождает ошибки в настоящем (Вы вместо 0xE0 нечаянно написали 0x70) и в будущем (особенно при смене контроллера).

(Кстати, когда я открыл Ваш проект, в опциях дебаггера был выбран другой контроллер. Проверьте у себя)

Последний раз редактировалось testerplus; 26.06.2010 в 10:24.
testerplus вне форума  
Непрочитано 26.06.2010, 10:12  
testerplus
Прописка
 
Регистрация: 26.01.2009
Сообщений: 249
Сказал спасибо: 23
Сказали Спасибо 102 раз(а) в 61 сообщении(ях)
testerplus на пути к лучшему
По умолчанию Re: Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

Сообщение от Godzilla82 Посмотреть сообщение
Почему функция Init() описана после её вызова в main()?
Переместите функцию main() в самый конец файла.
Зачем? Все прототипы описаны в h-файле.

Сообщение от Godzilla82 Посмотреть сообщение
PB4, PB5 - это что, просто константы 4, 5?

Тогда не совсем понятна такая конструкция:
Код:
PORTB &= ~((1‹‹PB7)|(1‹‹PB6)|(1‹‹PB5)|(1‹‹PB0));
Не проще:
Код:
PORTB &= 0b00011110
И по возможности избегать оператора сдвига, и использовать константы.
Так не только не проще, но и неправильнее (автор топика именно при таком подходе и ошибся). Так что как раз по возможности нужно избегать использования таких констант, особенно в оперативной части кода. А если при разводке плат под устройство автор решит, что лучше использовать не тот вывод, а этот? Тогда по всей программе бегать и искать константы?

Подход автора тоже не совсем правильный, но намного лучше констант. А правильнее было бы определять имена для таких констант и только ими оперировать в коде:
Код:
#define PIN_LED0    (1 ‹‹ PB0)
#define PIN_LED1    (1 ‹‹ PB5)
#define PIN_LED2    (1 ‹‹ PB6)
#define PIN_LED3    (1 ‹‹ PB7)

а в коде писать так:
     ...
     PORTB |= ~(PIN_LED0 | PIN_LED1 | PIN_LED2 | PIN_LED3);
     ...

Сообщение от Godzilla82 Посмотреть сообщение
Код:
volatile unsigned char i_local;
Надо вынести за пределы функции main() в самое начало файла. Это же проделать со всеми переменными, которые используются в разных функциях или прерываниях.
Это шутка? Или Вы просто издеваетесь над топикстартером?

Сообщение от Godzilla82 Посмотреть сообщение
Напряжение на ноге (после записи в порт) меняется в течении 4 тактов (если не ошибаюсь).
Это откуда такие данные? А как будет работать код:
Код:
    ldi     r16, 0x00
    ldi     r17, 0xFF
    out     PORTB, r16
    out     PORTB, r17
    out     PORTB, r16
    out     PORTB, r17
    ...
? (Не будем пока про паразитные емкости, допустим, что контроллер тактируется 1 Гц). Как тут "4 такта" будут участвовать?

Последний раз редактировалось testerplus; 26.06.2010 в 10:26.
testerplus вне форума  
Сказали "Спасибо" testerplus
291066 (30.06.2010)
 
Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Часовой пояс GMT +4, время: 01:55.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.