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

[OlegNZH]

Использование констант- в корне неверное решение.Как ни странно - , но в АВР-ках используется разные биты в прерываниях (залетел однажды).Поэтому нуно пользовать define , определённый в .h к МК. (в CV есть хорошая фича "Globally #define" - но это может породить проблемы-при переносе на другой компилятор)

[OlegNZH]

а про 4 такта....Автор просто буквально понимает принцип "чтение- модификация -запись" - All AVR ports have true Read-Modify-Write functionality when used as general digital
I/O ports

[Godzilla82]

Зачем? Все прототипы описаны в h-файле.

Сорри, не смотрел в этот H файл. На других компиляторах может не быть такого файла, вот поэтому всегда надо самому следить где и какая функция описывается и вызывается.

Так не только не проще, но и неправильнее...

Я бы даже согласился с вами. Но чтобы обратиться к 6 биту каждый раз писать 1‹‹PB6 - это маразм. Тем более, что PB6 определяется компилятором и лучше это определение не менять.

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

Это шутка? Или Вы просто издеваетесь над топикстартером?

Отойдя от конкретного компилятора, от его правил и оптимизаций надо делать именно так. Все переменные, значение которых надо сохранить до следующего вызова функции надо делать глобальными и описывать в самом начале вне тел функций. И потом не придётся наступать на грабли реализаций конкретных компиляторов.

а про 4 такта....Автор просто буквально понимает принцип "чтение- модификация -запись" - All AVR ports have true Read-Modify-Write functionality when used as general digital
I/O ports

Я имею ввиду, что если записать в порт 1, и тут же его считать (через PINB), то возможно считывание предыдущего значения, потому, что новое ещё не успело физически выставиться на порту.

Это откуда такие данные?

Состояние вывода микроконтроллера (независимо ог установок бита DDxn) может быть получено путем чтения бита PINxn регистра PINx. При этом следует помнить, что между действительным изменением сигнала на выводе и изменением бита РINxn существует задержка. Эта задержка вносится узлом синхронизации, состоящим, как показано на Рис, 6.1, из бита PINxn и дополнительного триггера-защелки. Значение сигнала на выводе микроконтроллера фиксируется триггером-защелкой при НИЗКОМ уровне тактового сигнала и переписывается затем в бит PINxn по нарастающему фронту тактового сигнала. Соответственно, величина задержки может составлять от 0,5 до 1,5 периодов системного тактового сигнала, как показано на Рис. 6,3, а.
По этой же причине между операциями изменения и повторного считывания состояний вывода необходимо вставлять команду NOP Поскольку команда OUT устанавливает сигнал «SYNC LATCH» в 1 по положительному фронту тактового сигнала, задержка в этом случае равна одному периоду тактового сигнала (Рис. 6.3,6)

Это из "Микроконтроллеры AVR семейства Mega (А.В.Евстифеев)", страница 326. Или для Tiny это несправедливо? Насчёт 4 тактов я ошибся, о чём и предупреждал. Не 4, а 1,5.

А как будет работать код:

Код:

ldi r16, 0x00 ldi r17, 0xFF out PORTB, r16 out PORTB, r17 out PORTB, r16 out PORTB, r17 ...

В два раза медленнее.

? (Не будем пока про паразитные емкости, допустим, что контроллер тактируется 1 Гц). Как тут "4 такта" будут участвовать?

Давайте не будем в крайности вдаваться А если 20 МГц? Тогда клавиатура будет опрашиваться со скоростью мегагерц? Не многовато?

[OlegNZH]

Давайте не будем в крайности вдаваться А если 20 МГц? Тогда клавиатура будет опрашиваться со скоростью мегагерц? Не многовато?

Вот как-раз учёт 1.5 тактов- это крайности. Необходимо всегда иметь ввиду переходные процессы "за МК".На высоких тактовых- они соизмеримы уже.

[OlegNZH]

Сообщение от testerplus Посмотреть сообщение
А как будет работать код:
Код:

ldi r16, 0x00
ldi r17, 0xFF
out PORTB, r16
out PORTB, r17
out PORTB, r16
out PORTB, r17
...

В два раза медленнее.

что значит- в два раза медленнее?

[testerplus]

Сорри, не смотрел в этот H файл. На других компиляторах может не быть такого файла, вот поэтому всегда надо самому следить где и какая функция описывается и вызывается.

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

Я бы даже согласился с вами. Но чтобы обратиться к 6 биту каждый раз писать 1‹‹PB6 - это маразм.

Маразм, говорите? Обращение к битам таким способом даже в даташите производителя приведено. И потом, в конечном счете мы работаем не с "6 битом", а с выводом PB6 (или не с 5-м битом GIMSK, а с битом PCIE). Представьте себе проблему перелопачивания кода при изменениях в схеме (каково будет менять код, при переносе функционала PB6 на PB3, например, если Вы вместо (1‹‹PB6) пишете 0x01000000).

Тем более, что PB6 определяется компилятором и лучше это определение не менять.

Его и не удастся поменять. При попытке получим от компилятора "PR6 redefined". Определять надо свои константы, опираясь на h-файлы компилятора, например:

#define PIN_BUTTON   (1 ‹‹ PB6)

(Иногда предполагается использовать программу на различных платформах или компиляторах, тогда нужно определять целиком макросы установки/сброса/чтения выводов контроллера, обрамляя это #ifdef'ами так, чтобы для каждой платформы или компилятора выбиралась своя схема)

Отойдя от конкретного компилятора, от его правил и оптимизаций надо делать именно так. Все переменные, значение которых надо сохранить до следующего вызова функции надо делать глобальными и описывать в самом начале вне тел функций. И потом не придётся наступать на грабли реализаций конкретных компиляторов.

Вы путаете volatile и static. volatile - запрещает компилятору призводить оптимизацию над переменной. А static - выделяет под локальную переменную фиксированный статический адрес, что гарантирует сохранение ее значения при следующем входе в функцию (в приведенной программе, вроде бы, нет таких переменных, чье значение должно быть сохранено. Хотя с ходу незаметно, исходник очень плохо оформлен).

На первый взгляд глобальными volatile должны быть три переменные: FLAG220, KS[], KTS[]. (Еще, возможно, TempLed, но я не видел к ней обращения вне обработчика прерывания).

Сообщение от testerplus

А как будет работать код: Код: ldi r16, 0x00 ldi r17, 0xFF out PORTB, r16 out PORTB, r17 out PORTB, r16 out PORTB, r17 ...

В два раза медленнее.

Медленнее, чем что? Эта последовательность команд меняет состояние выводов порта с частотой, равной частоте задающего генератора. Понятное дело, что при высокой тактовой частоте надо думать о том, что в нагрузке. Собственно, я код привел просто для примера, что "4 такта на запись" - что-то не то.

Давайте не будем в крайности вдаваться А если 20 МГц? Тогда клавиатура будет опрашиваться со скоростью мегагерц? Не многовато?

Это уже другое дело; это вопрос алгоритма, а не железа. И потом, это же не частота опроса клавиатуры, а скорость однократного опроса (если мы говорим о фунции GetKeyPress). Да я не возражаю против nop'ов при записи/чтении, и у автора они стоят на месте и в нужном количестве (полностью код не изучал, возможно он их где-то и пропустил).

[kison]

Его и не удастся поменять.

#ifdef PB6
#undef PB6
#define PB6 (5)
#endif
PORTB = (1‹‹PB6);
// :)

[OlegNZH]

кстати- по поводу 1.5 такта - datasheet

[OlegNZH]

kison - . Но переопределять - это грубовато.Бардак получится - кинутся все :=D

[testerplus]

Код:

#ifdef PB6 #undef PB6 #define PB6 (5) #endif PORTB = (1‹‹PB6); // :)

Ну, постараемся не опускаться до такого (хотя, приходилось иметь дело с исходниками, где программист применял нечто подобное)