Программный I2C

[HHIMERA]

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

Да пофигу что использовал ТС... RMW ещё никто не отменял... и дело здесь не в стандарте СИ...

[ARV]

Объясните мне тогда (а лучше ткните носом где это написано) то, что строку a=a|(1<<7); , c отключеной оптимизацией для переменной "a", компилятор должен создать ещё одну переменную. Не вижу никакой логической связи этой строки с использованием дополнительной памяти. И это с учётом того, что для компилятора эта строка абсолютно эквивалентна строке a |= (1<<7);

объясняю: если эта переменная volatile, компилятор ОБЯЗАН считывать ее значение всякий раз, когда встречает ее в тексте программы. два ваших ЭКВИВАЛЕНТНЫХ выражения заставят ОБЯЗАТЕЛЬНО считать эту переменную - куда же, спрашивается, компилятор может считать переменную, если не во временную (регистровую) переменную, создаваемую им по ходу работы?! и это будет так НЕЗАВИСИМО от включенного или отключенного оптимизатора - ТАК НАДО ПО СТАНДАРТУ.

если переменная не-volatile, оптимизатор компилятора ИМЕЕТ ПРАВО использовать В ОБОИХ случаях команду битовой модификации переменной (если она регистровая или существует такая команда в ядре) вместо явно описанной последовательности СЧИТЫВАНИЕ-МОДИФИКАЦИЯ-ЗАПИСЬ, т.е. обойтись без промежуточного считывания переменной.

что тут не понятного?

[ARV]

RMW ещё никто не отменял... и дело здесь не в стандарте СИ...

у вас в подписи хорошо сказано - воспользуйтесь этим для себя для лучшего эффекта ВНИМАТЕЛЬНО перечитайте мои сообщения.

[Аlex]

повторяю: модификация отдельного бита в регистре/порте делается, как вы говорите, - я в курсе. но делается это ассемблерными командами, например, SBI или SBR.

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

У ТС'а как бы не совсем проблема, связанная с ЧМЗ. Всё дело в структуре портов.
Я не зря ему задал вопрос :

А как Вы думаете, после перенаправления бита порта, что будет находится в защёлке ?

, прикрепив его ссылкой.
Дело в том, что ТС оперирует только направлением порта, а это - не есть гуд.
Когда у него вывод на I2C насроен на вход, и он дёргает какой либо ногой этого же порта, у него в защёлку записывается реальное значение, приложенное на вывод (а там пуллап ). Ну и, естественно, когда он перенаправляет порт на вЫход, думая, что в защёлке "0" - напарывается на неприятную ситуацию - на пин из защёлки выводится 1-чка, вместо его задуманного нуля.
Вот и всё....

[Аlex]

если эта переменная volatile, компилятор ОБЯЗАН считывать ее значение всякий раз, когда встречает ее в тексте программы

Почему он обязан её прочитать ? Отключить оптимизацию - да, согласен. Выполнил с ней какие-то действия, и всё... Но читать то почему он обязан, для чего ? В каком это стандарте описано ?

[ARV]

Вот и всё....

я так понимаю, что все это происходит как раз именно из-за того, что ТС использует манипуляции отдельными битами порта, используя "расширения" компилятора. если бы он пользовал только стандартные операции для языка Си, он на это "защелкивание" не напоролся бы - так? ведь не смотря на схожесть принципов работы портов в PIC и AVR, я лично никогда на подобные проблемы не нарывался, хотя ногодрыгание и ввод-вывод на одном порту смешивал постоянно... или я чего-то в архитектуре PIC-ов не допонял?

[HHIMERA]

в подписи хорошо сказано

Это для вас, а не для меня... Никогда не видели как code reordering бред этажерочкой выкладывает??? GCC... кстати... И плевать компилятору, что все регистры SPI с атрибутом volatile...
Так что... сразу GCC запишем в "как не соответствующий стандарту СИ"... или сойдёмся на истине, что высокий уровень оптимизации может содержать определённые риски???

[Аlex]

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

Не совсем. Это происходит из-за того, что во время дрыганья другими лапками порта, данные в защёлке меняются. О чём ТС не задумывается, наивно полагая, что одной записи, в начале программы, в защёлку достаточно.

[ARV]

Почему он обязан её прочитать ?

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

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

volatile int vol;
int var;
vol = 5;
var = vol; // будет СЧИТАНО значение vol, а не занесено 5 напрямую - даже если это более оптимально!!!
vol = vol; // будет считано vol и снова туда же записано!!!!
var = var; // может быть выброшено компилятором
vol; // будет просто считано vol и потеряно
var; // компилятор варнингнет и может ничего тут не сделать!!!

написано это в стандарте языка: хотите - ищите, не хотите искать - поверьте мне. не хотите верить - ваше право

[dosikus]

если переменная не-volatile, оптимизатор компилятора ИМЕЕТ ПРАВО использовать В ОБОИХ случаях команду битовой модификации переменной (если она регистровая или существует такая команда в ядре) вместо явно описанной последовательности СЧИТЫВАНИЕ-МОДИФИКАЦИЯ-ЗАПИСЬ, т.е. обойтись без промежуточного считывания переменной.

что тут не понятного?

Не понятно почему тебе не понятно .
Попробую объяснить на "пальцах" , для случая именно с пЫк Mid Range .
Речь не о том во что преобразует компилятор пЫк инструкции типа PORTA|=1;
Дело в том что сама команда ассемблера BSF PORTA,1 будет произведена именно в такой последовательности :
Чтение всего порта , модификация бита с порядковым номером 1 , и записью всего результата обратно ...

[ARV]

Это для вас, а не для меня...

оно порой и вам не помешало бы

Никогда не видели как code reordering бред этажерочкой выкладывает???

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

[HHIMERA]

или я чего-то в архитектуре PIC-ов не допонял?

А чего там не понимать??? Излишняя нагрузка или ёмкость на пине может искажать работу с портом из-за конечного быстродействия и нагрузочной способности... Выводится через защёлку, а читается то всегда реальный уровень на пине... который при быстрых манипуляциях может не соответствовать ожидаемому...

[ARV]

Дело в том что сама команда ассемблера BSF PORTA,1 будет произведена именно в такой последовательности :
Чтение всего порта , модификация бита с порядковым номером 1 , и записью всего результата обратно ...

даже не знаю, поможет ли... но рискну:
Я В КУРСЕ ЭТОГО!!!

словить баг из-за RMW-инструкции можно только в том случае, если в коде будет команда BSF - если ее не будет, а будет какая-то команда типа OUT PORTА, W (я пиковского ассемблера не знаю - пишу наугад) - никакого RMW не будет и не будет связанных с ним глюков!!! об этом и писал urry - что если заменить команды с RMW-доступом на последовательность команд без RMW, все будет хорошо...

[HHIMERA]

описанного вами не видел

Сам охренел когда увидел... Благо окно дизасма висит на постой...

[dosikus]

что если заменить команды с RMW-доступом на последовательность команд без RMW, все будет хорошо...

А вот нет таких команд, окромя NOP , в случае ТС . Про что здесь тебе и долбили .
А по предыдущим твоим постам совсем не понятно что ты в курсе, один volatile мелькал ...

[ARV]

А вот нет таких команд, окроме NOP , в случае ТС . Про что здесь тебе и долбили .

мда... чукча не читатель - чукча писатель...

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

P.S. пожалуй, я начинаю понимать, из-за чего возникло недопонимание... я привык к архитектуре AVR, где порты для считывания состояния на пинах и защелки для вывода на пины разделены... а у PIC-ов, похоже, как и у классических MCS51, запись-чтение осуществляется через один и тот же порт, но только запись идет в защелку, а чтение - с пинов... тогда, пожалуй, даже вывод целиком байта в порт, как я предлагал, может порой давать сбои... ну, что я PIC-и не знаю - я и не скрывал

[dosikus]

ARV , не расстраивайся .
Во первых не много потерял, во вторых в пЫк появились LATCH . Правда уже давно .
А в третьих в задницу и пЫк и AVR , STM рулит ...

[ARV]

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

[dosikus]

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

В довольно таки старых где прерываний и не было вовсе. Но согласись на фоне фузов AVR, это мелочи .
Я о том давнем времени , когда начинали . Для каждого свои страшилки.

[Halex]

Но согласись на фоне фузов AVR, это мелочи . Для каждого свои страшилки.

Нда, "вот и встретились три одиночества". Досик, привет!!! Уж не наезжай так на фузы АВР, да и на самого ARV попутно. Не так они страшны, эти фузы. Один раз невовремя "убитый" камень - и ... память на всю оставшуюся жисТь. Да и лечится это в АВР-ках. Лечилки теперь вплоть до автономных клеют.