Darth Vader

Наверное. Имелось ввиду такое: uint8_t i; ++i; i = i+5; i = i<<3; i |= 1<<3; Т.е. когда надо изменить значение переменной, вычислив её новое значение из текущего. Любые конструкции, где им переменной стоит слева от знака присваивания, и, одновременно, справа от него участвует в выражении. Т.е. там, где значение переменной участвует в вычислениях, и, одновременно, в эту же переменную сохраняется результат этих вычислений.

Если ваша переменная не регистровая, по практически все операции над ней, кроме = (присваивание значения) будут неатомарны. Для любой операции: +, -, *, /, &, |, ^, <<, >> значение из переменной в памяти надо считать в регистр, произвести операцию в регистре и записать результат обратно в переменную в памяти.

Операции чтение-модификация-запись неатомарны ни для каких типов. Если таковые имеются над этой переменной в вашем коде (например |=, &= ), то средства межпроцессного взаимодействия нужны.

Вы пытаетесь заставить считать препроцессор. У него очень ограниченный набор возможных арифметических действий. И все они над целыми числами. Постчитать выражение с float-операндами он не может. Поэтому он сделает простую текстовую подстановку и передаст это все синтаксическому анализатору и далее, собственно, компилятору. Замена выражения его значением произойдет где-то на этапе оптимизации. И вот тогда, в самом конце, видя никогда не выполняющееся условие (или наоборот, выполняющееся всегда) компилятор выкинет эту проверку, а вам напишет предупреждение об этом. И главное. Файлы .h - это НЕ ФАЙЛЫ ОПРЕДЕЛЕНИЙ! Это файлы объявлений. В них ничего не определяется (т.к. нет выделения памяти), а только объявляется.

Читайте в errata про ошибку с ID = 0014. Это особенность FLM из штатного пака. Есть другие, альтернативные, которые не требуют обязательного стирания всего чипа и умеют стирать внутреннюю флеш-память страницами по 4 кбайта, а не только всю полностью.

Этот код тоже не идеален. Там есть поле для рефакторинга. Если массив G[7] нигде больше не используется, то логично объявить его локально внутри функции с квалификатором static const.

Так меняйте: исключайте (удаляйте) имеющийся стартап из проекта и добавляйте в проект другой файл стартапа для вашего целевого МК. Плюс файл описания периферии конкретного МК надо будет тоже заменить. Т.е. там, где в ваших исходниках прописано, скажем, #include "STM32F417.h", заменить на #include "STM32F407.h". А в папку с вашими инклудами положить файл STM32F407.h

Эти микросхемы в металлокерамике с золочеными ножками - для ВВСТ. Там нет никакого рыночного регулирования. Строго ГОЗ. Вопрос цены компонентов там не стоит вообще. Даже при своей конской цене они составляют единицы процентов в цене готового прибора.

Тут поищите. Там почти всё то же самое.

Миландровские Cortex-M3 выпускаются по техпроцессу 180 нм в Китае. TSMC для них избыточен. Для TSMC этот техпроцесс - каменный век. Такой техпроцесс есть у нас в стране только на фабрике Микрона в Зеленограде. И он её всю занял для производства... билетов для метро и прочих транспортных карт. Влезть туда без шансов - поставят в конец очереди со сроком ожидания год.

А как поступит IAR, если аттрибутом __ramfunc будет помечена функция, принимающая параметр типа указатель на функцию, и вызывающая её по этому указателю?

Этими же свойствами обладает константный указатель (не путать с указателем на константу). Например: char a; char * const ptr_a = &a; // создание и инициализация константного указателя на char Здесь указатель ptr_a нельзя оставить неинициализированным при его создании. Также, ему нельзя присвоить адрес иного объекта программы (нельзя изменить) т.к. он константный, т.е. неизменяемый. Вот тут приведён более широкий список различий ссылок и указателей.

Так это вроде-как само собой разумеющееся требование. На то это и зовут ЭМУЛЯЦИЕЙ EEPROM. Если писать каждый раз в одно и то же место новое поверх старого - это уже не эмуляция. Тут рассмотрены возможные варианты реализации этого.

Не появилась Можно и через UART, и через JFlash Нет проблем Эмулировать можно, проблем нет. Особенности программирования флеш-памяти рассмотрены тут. Ответы почти на все ваши вопросы можно найти здесь.

Вы цель свою конечную опишите. Зачем вам нужен именно ассемблерный файл в проекте? Просто, чтобы был? Вы эту функцию на Си написать не можете? Вам ассемблерного стартап-файла мало?

Оно?

Похоже, что ничем. Это одна и та же сущность, которую ARM называет по-разному. Вот тут - Cortex, А вот тут и тут - Common.

Вам точно туда надо записать, а нее в 0x8040000-4 ? Этот же вопрос по адресу 0x08040000 здесь:

Т.е. у вас есть готовый файл .hex и вам надо посчитать CRC32? Установите HashTab и в свойствах файлов вас будет вкладка с разными хэшами. Или вам надо другое - посчитать CRC32 двоичного образа памяти? Тогда сгенерируйте из .hex файл .bin и снова HashTab. Если надо посчитать в процессе отладки - напишите функцию подсчета CRC32 и посмотрите, что она возвращает отладчиком.

Ключевое слово ПЛАГИН (plug-in).

Почему именно 1? Почему не -1 или любое иное целое, отличное от 0. И какое именно целое - знаковое или беззнаковое? А какой разрядности: char, short, int, long?

Делают, если не пытаться обмануть его и самого себя игрой с приведением типов указателей. char - выравнивается по границе 1 байта (т.е. специально не выравнивается никак) short - выравнивается по границе 2 байт long, int, float - выравниваются по границе 4 байт. Так что где бы вы в программе не объявили переменные: float a; int b; a, b гарантированно всегда будут расположены в памяти по адресам, кратным 4 байтам. Умный компоновщик позаботится об этом. Он это гарантирует. А если вы считаете себя умнее компоновщика и решили поиграться с приведением указателей: char c; float a = *(float*)&c; то все последствия на вашей совести. Вы сами должны обеспечить корректность такой операции.

Вы почитайте документ ARMv7-M Аrchitecture Refrence Manual, главу А2.5.4, конкретно Floating-point single precision format, последнее предложение перед рисунком. Что там сказано про выравнивание данных такого типа? И при чем тут компилятор? Он делае ровно то, что вы ему написали. А корректность написанного на совести программиста.

В теме конкретный вопрос про объединение битовых полей с байтом - читайте первое сообщение. При чём здесь int и lsb/msb?

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