Столкнулся с очень странным поведением __delay_cycles.
Все прерывания запрещены, ничего лишенего не работает.
Но импульс с порта С имеет совершенно разные длительности, причём разница значительна:


//если батарея подключена - можно включить питание DC/DC 3.3v
if(SYSTEM.flag_BatteryPower)
{
PORTC |= (1<<DC3v3);
__delay_cycles(_1ms); //Вот тут задержка строго равна 1ms
PORTC &=~(1<<DC3v3);

if(CHECKBIT(PINF, CameraVolt)) SYSTEM.flag_CameraPower = true;
else
{

PORTC |= (1<<DC3v3);
__delay_cycles(_1ms); //А вот тут уже 20ms
PORTC &=~(1<<DC3v3);

}
}

А теперь откройте листинг и с удивлением обнаружьте, что __delay_cycles() компилируется в самый обычный цикл. Ну и как одинаковый цикл может выполняться разное время, если все прерывания запрещены? Значит не все, или с тактированием мудрите, или программа в это время дергает ногой где-то в совсем другом месте программы. Чудес не бывает.

Что за страх такой заглянуть в листинг?

Поздно уже смотреть.
Вынес включение из встроенного if{} и всё заработало как надо.
Что-то видимо компилятор мудрил.
Он мне иногда например оптимизировал все задержки в одну кучу.
Из этого:
PORTC |= (1<<PIN);
__delay_cycles(_1ms);
PORTC &=~(1<<PIN);
__delay_cycles(_1ms);
PORTC |= (1<<PIN);
__delay_cycles(_1ms);
PORTC &=~(1<<PIN);

Делал:
PORTC |= (1<<PIN);
__delay_cycles(_3ms);
PORTC &=~(1<<PIN);

И в итоге пин дёргался всего 1 раз.

-

PORTC должен быть объявлен как volatile, иначе получите оптимизацию по полной

А вот интересно, компилятор ведёт лог оптимизаций?
Чтоб можно было быстро посмотреть в текстовом виде где что он сократил?
У меня программа уже огромная и начинаю сталкиваться с проблемой непредсказуемого поведения, потому что компилятор каждый раз меняет её по разному.

В заголовочных файлах дивайсов в IAR порты уже объявлены volatile.

Вашу программу потребуется поздно или рано переписать...

Вы видимо хотели ответить на интересующий меня вопрос? <компилятор ведёт лог оптимизаций?>

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

Сразу всё "Правильно"?!
Не думаю...

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

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


я так понимаю речь идет о AVR ? так там флеша нету даже для средних программ.

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

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

Подсказку еще нужно понять. Для понимания нужно не требовать неведомые "логи оптимизации", а просто уметь читать листинги и, естественно, даже для начала немного представлять, что написали. Не ведаете, что творите и не понимаете что получили? Ну тогда фрагменты этих самых листингов с неработающими после оптимизации кусками представляйте на суд. И непременно оформленные соответствующими тэгами, иначе удалять буду.

Например так:

в блоке: (файл, строка ....)
//-------------------------
1: temp |= (1<<PIN);
2: __delay_cycles(_1ms);
3: temp &=~(1<<PIN);
4: __delay_cycles(_1ms);
5: temp |= (1<<PIN);
6: __delay_cycles(_1ms);
7: temp &=~(1<<PIN);
//--------------------------

оптимизация:
1: temp |= (1<<PIN);
2: delay: циклы
3: temp &=~(1<<PIN);

Разве плохо?
Иногда ввиду работы над большим проектом (или много людей), сложно сразу написать оптимальный код.
Например одна функция сбрасывает бит, а следующая его ставит. Сразу можно увидеть.
Это была бы неплохая подсказка при поиске разных непоняток.

-


Лучшее - враг хорошего.
С вашим талантом, да до сих пор все бы на асме писали.

и пользовались zx-spectrum

Упасть и плакать



Это не лучшее и не худшее, это необходимое.



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

1) Программы написанные на "С" работают очень медленно.
2) Программы написанные на "С" занимают очень много места
3) Все компиляторы глючные, и не всегда дают рабочий вариант кода кода при включенной оптимизации.

О господи, представления на уровне детского сада. Вы полагаете компилятор ТЕКСТЫ оптимизирует .
Moderator:
Последнее предупреждение - пользуйтесь тэгами для форматирования исходных текстов.

Ну все, началось ... "понеслось дерьмо по трубам".
Я хотел спросить только про непонятку с задержкой, которая реально была.
Всем спасибо за помощь.


Не люблю я тэги. Что мне теперь - повесится?

Вам хотят помочь. Судя по вашим вопросам - вы что-то делаете неправильно. От незнания.

Зашибись! "Ну не люблю я ПДД, что мне теперь, машину не водить"? Не любите теги - не публикуйте код.

Если бы знал - не спрашивал.Это очевидно.


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

В следующий раз учту.