Да пофигу что использовал ТС... RMW ещё никто не отменял... и дело здесь не в стандарте СИ...ARV писал(а):если бы топикстартер не использовал нестандартные трюки компилятора, на битовые операции он не нарвался бы никогда? ну, во всяком случае, при соответствии его компилятора стандарту Си...
объясняю: если эта переменная volatile, компилятор ОБЯЗАН считывать ее значение всякий раз, когда встречает ее в тексте программы. два ваших ЭКВИВАЛЕНТНЫХ выражения заставят ОБЯЗАТЕЛЬНО считать эту переменную - куда же, спрашивается, компилятор может считать переменную, если не во временную (регистровую) переменную, создаваемую им по ходу работы?! и это будет так НЕЗАВИСИМО от включенного или отключенного оптимизатора - ТАК НАДО ПО СТАНДАРТУ.Аlex писал(а):Объясните мне тогда (а лучше ткните носом где это написано) то, что строку a=a|(1<<7); , c отключеной оптимизацией для переменной "a", компилятор должен создать ещё одну переменную. Не вижу никакой логической связи этой строки с использованием дополнительной памяти. И это с учётом того, что для компилятора эта строка абсолютно эквивалентна строке a |= (1<<7);
у вас в подписи хорошо сказано - воспользуйтесь этим для себяHHIMERA писал(а):RMW ещё никто не отменял... и дело здесь не в стандарте СИ...
для лучшего эффекта ВНИМАТЕЛЬНО перечитайте мои сообщения.
У ТС'а как бы не совсем проблема, связанная с ЧМЗ. Всё дело в структуре портов.ARV писал(а):повторяю: модификация отдельного бита в регистре/порте делается, как вы говорите, - я в курсе. но делается это ассемблерными командами, например, SBI или SBR.
однако пока не вижу, каким боком это соотносится с моим высказыванием о том, что если бы топикстартер не использовал нестандартные трюки компилятора, на битовые операции он не нарвался бы никогда? ну, во всяком случае, при соответствии его компилятора стандарту Си...
, прикрепив его ссылкой.А как Вы думаете, после перенаправления бита порта, что будет находится в защёлке ?
). Ну и, естественно, когда он перенаправляет порт на вЫход, думая, что в защёлке "0" - напарывается на неприятную ситуацию - на пин из защёлки выводится 1-чка, вместо его задуманного нуля.
Почему он обязан её прочитать ? Отключить оптимизацию - да, согласен. Выполнил с ней какие-то действия, и всё... Но читать то почему он обязан, для чего ? В каком это стандарте описано ?ARV писал(а):если эта переменная volatile, компилятор ОБЯЗАН считывать ее значение всякий раз, когда встречает ее в тексте программы
я так понимаю, что все это происходит как раз именно из-за того, что ТС использует манипуляции отдельными битами порта, используя "расширения" компилятора. если бы он пользовал только стандартные операции для языка Си, он на это "защелкивание" не напоролся бы - так? ведь не смотря на схожесть принципов работы портов в PIC и AVR, я лично никогда на подобные проблемы не нарывался, хотя ногодрыгание и ввод-вывод на одном порту смешивал постоянно... или я чего-то в архитектуре PIC-ов не допонял?Аlex писал(а):Вот и всё....
Это для вас, а не для меня... Никогда не видели как code reordering бред этажерочкой выкладывает??? GCC... кстати... И плевать компилятору, что все регистры SPI с атрибутом volatile...ARV писал(а):в подписи хорошо сказано
Не совсем. Это происходит из-за того, что во время дрыганья другими лапками порта, данные в защёлке меняются. О чём ТС не задумывается, наивно полагая, что одной записи, в начале программы, в защёлку достаточно.ARV писал(а):я так понимаю, что все это происходит как раз именно из-за того, что ТС использует манипуляции отдельными битами порта, используя "расширения" компилятора. если бы он пользовал только стандартные операции для языка Си, он на это "защелкивание" не напоролся бы - так?
да потому что она - volatile! то есть ее содержимое может измениться в любой точке исполнения программы!!!Аlex писал(а):Почему он обязан её прочитать ?
Код: Выделить всё
volatile int vol;
int var;
vol = 5;
var = vol; // будет СЧИТАНО значение vol, а не занесено 5 напрямую - даже если это более оптимально!!!
vol = vol; // будет считано vol и снова туда же записано!!!!
var = var; // может быть выброшено компилятором
vol; // будет просто считано vol и потеряно
var; // компилятор варнингнет и может ничего тут не сделать!!!
Не понятно почему тебе не понятно .ARV писал(а): если переменная не-volatile, оптимизатор компилятора ИМЕЕТ ПРАВО использовать В ОБОИХ случаях команду битовой модификации переменной (если она регистровая или существует такая команда в ядре) вместо явно описанной последовательности СЧИТЫВАНИЕ-МОДИФИКАЦИЯ-ЗАПИСЬ, т.е. обойтись без промежуточного считывания переменной.
что тут не понятного?
оно порой и вам не помешало быHHIMERA писал(а):Это для вас, а не для меня...
я видел некоторые закидоны GCC, но описанного вами не виделHHIMERA писал(а):Никогда не видели как code reordering бред этажерочкой выкладывает???
не повезло 
. так что пока останусь при своем мнении.А чего там не понимать??? Излишняя нагрузка или ёмкость на пине может искажать работу с портом из-за конечного быстродействия и нагрузочной способности... Выводится через защёлку, а читается то всегда реальный уровень на пине... который при быстрых манипуляциях может не соответствовать ожидаемому...ARV писал(а):или я чего-то в архитектуре PIC-ов не допонял?
даже не знаю, поможет ли... но рискну:dosikus писал(а):Дело в том что сама команда ассемблера BSF PORTA,1 будет произведена именно в такой последовательности :
Чтение всего порта , модификация бита с порядковым номером 1 , и записью всего результата обратно ...
Сам охренел когда увидел... Благо окно дизасма висит на постой...ARV писал(а):описанного вами не видел
А вот нет таких команд, окромя NOP , в случае ТС .ARV писал(а):что если заменить команды с RMW-доступом на последовательность команд без RMW, все будет хорошо...
Про что здесь тебе и долбили . мда... чукча не читатель - чукча писатель...dosikus писал(а):А вот нет таких команд, окроме NOP , в случае ТС .
В довольно таки старых где прерываний и не было вовсе. Но согласись на фоне фузов AVR, это мелочи .ARV писал(а): узнать о том, что таймер переполнился, можно только путем переодической проверки содержимого его регистра-счетчика,
Для каждого свои страшилки.
Нда, "вот и встретились три одиночества". Досик, привет!!! Уж не наезжай так на фузы АВР, да и на самого ARV попутно. Не так они страшны, эти фузы. Один раз невовремя "убитый" камень - и ... память на всю оставшуюся жисТь. Да и лечится это в АВР-ках. Лечилки теперь вплоть до автономных клеют.dosikus писал(а):Но согласись на фоне фузов AVR, это мелочи . Для каждого свои страшилки.