VladislavS

На F100 без таймаутов с I2C нельзя. Он там мягко говоря не очень. Всегда есть ненулевая вероятность остаться в цикле ожидания любого бита навсегда.

Ничего лучше я сегодня на форумах уже не прочту :)))

С таким количеством RAM код на время отладки проще загружать в неё, а не во FLASH.

Перечитал тему ещё раз. Да нет же, у ТС компилятор хрень делает, а не у меня. Хорошо что именно я ничего не понимаю в компиляторах. :)))

Потому что так задумано. DTCM и ITCM только для ядра доступны без всяких шин быстро и сразу. Вообще, настройки линкера никак не влияют на работу периферийных устройст, а лишь размещают данные в памяти. Можете тупо указывать в функциях абсолютные адреса и ни один линкер это не изменит. Проверяйте включены и настроены ли все нужные области памяти и периферийные модули. Обратите внимение на настройки MPU - защита и кэширование областей памяти могут мешать работе DMA.

Действительно, при чём тут С++? Обычный С-код.

Любая программа это последовательность операций "в одно действие". И это правильно, программа должна работать так как задумано. Хорошо что вы понимаете. Только почему-то это "понимание" не помогает правильные программы писать.

Ну вы сказали, и что изменилось?

Критерий "ровно в тот момент времени" огласите? С точностью до такта? На ARM с конвейером, предвыборками, разными шинами, DMA и кэшами это в принципе невозможно даже на ассемблере. "Ровно как написано" в смысле последовательности чтений/записей делается на С правильной расстановкой volatile вне зависимости от режимов компиляции/оптимизации.

А потом включаете LTO и... Во-первых, мы этого не видим, код засекречен. Во-вторых, внимательно следим за руками. Вот тут компилятор выдаёт предупреждение: Ну ок, объясним компилятору КАК мы хотим: И он нас услышал //int main() //{ main: // int tmp_a = a; LDR.N R2,??DataTable1_1 LDR R1,[R2, #+0] // int tmp_b = b; LDR R0,[R2, #+4] // c = tmp_a + tmp_b; ADDS R1,R0,R1 STR R1,[R2, #+8] // for(;;); ??main_0: B.N ??main_0 //} ??DataTable1_1: DATA32 DC32 a Хотите наоборот? Легко. //int main() //{ main: // int tmp_b = b; LDR.N R2,??DataTable1_1 LDR R0,[R2, #+4] // int tmp_a = a; LDR R1,[R2, #+0] // c = tmp_a + tmp_b; ADDS R0,R0,R1 STR R0,[R2, #+8] // for(;;); ??main_0: B.N ??main_0 //} Обращаем особое внимание, что компилятор оставил только операции с volatile сущностями, остальное для него было лишь пояснение что и как я хочу сделать.

Любая программа это и есть жесткая последовательность действий. Но если вы её компилируете оптимизирующим компилятором, то для него важны только функция main и все действия с volatile сущностями. Остальное он воспринимает как описание того что вы с ними хотите сделать. Если вы этого не понимаете, то получаете то что на вашей картинке. Да куда уж нам... 😄

Ещё раз. Компилятор не имеет права менять задуманный код, но для этого его надо правильно писать. Вы это как поняли, если код не предъявлен? В хрустальном шаре?

Чтобы компилятор вообще не менял задуманный код - его надо правильно написать. Если возникли желание/потребность отключить опитимизацию на участке кода, то вы явно что-то делаете не так.

Для этого просто обязательно умение писать под оптимизирующий компилятор. Либо на асме. Третьего не дано.

А смысл его показывать, если компилятор всё равно виноват :)) Ответ: Что в коде написали, то компилятор и сделал.