Ну, я совсем ненормальный: у меня и заголовок свой (и чисто под це++17 или старше), и никакими middleware не пользуюсь (потребовалось вот USB Device для CDC слепить -- посидел, подумал, слепил)... Понятно, что результаты не столь быстры, как на всём готовом -- зато глюков в итоге никаких (ибо все -- мои, если обнаруживаются -- уничтожаются).
Там давно выяснилось. Проблема была в памяти -- но при этом никакие другие программы не глючили, а любые тесты памяти никаких проблем не обнаруживали. Причём, замечу, у меня стояли модули, указанные производителем материнки как протестированные на совместимость. Когда заменил на совершенно другие (и не протестированные производителем) -- проблемы ушли.
И причём здесь макроблоки? Если бы Вы внимательно посмотрели, что я писал на форуме Хилинха, то увидели бы, что ошибка -- не в том, что компилятор не понимал, что я память описываю (это он как раз очень хорошо понимал и всё правильно синтезировал) -- он игнорировал порядок нумерации разрядов в объявлени: я объявлял
reg [0:7] RAM[Size];
а он считал, что я написал reg [7:0] -- и ругался в другом месте.
Извините, но есть стандарт языка, и его ОБЯЗАНЫ придерживаться разработчики компиляторов. Недаром они признали ошибку. А уж то, поймёт компилятор или нет, что я хочу ОЗУ слепить -- это совсем другая проблема.
Интересно, починили баг с порядком нумерации линий в шинах в SystemVerilog? (наткнулся, нумеруя биты не 31:0, а наоборот; запостил на форуме у них -- признали багом).
SYSCFG "идеологически" идентичен, но отличия в конкретике там должны быть существенные. Остальное -- скорей всего, такое же (во всяком случае, между H7 и G4 разницы немного даже тогда, когда она есть -- главным образом, какие-нибудь дополнительные режимы и т.п. вещи; однако названия могут иногда несколько отличаться -- например, в H7 несколько разных DMA, и "обычный" DMA младших семейств в H7, если склероз не изменяет, называется BDMA).
Без IDE -- мазохизм, но можно обойтись и без них, это да. Только непонятно, чем IDE помешала: это ж, по сути, набор инструментов, собранный в кучу, за самого программиста она не программирует.
Ну а плату с такими требованиями -- любую, лишь бы там был не только сам МК, но и программатор к нему. Раз речь про STM, то встроенным программатором там наверняка будет STLink. Можно купить и отдельный программатор, но это лишние деньги и сложности, которые на этапе первоначального освоения явно без надобности.
Вообще-то атомарность -- более строгая вещь. В промежутках между записями двух слов STRD, в принципе, может вклиниться кто-то другой, т.е. в рамках всей системы она не атомарна. Вот в смысле невозможности прервать на середине -- это да.
Возможно, компилятор (точней, его разработчики) считает, что, поскольку LDRD/STRD работают с двумя словами, то они работают с одним двойным словом -- а значит, нужно выравнивание на границу двойного слова (что не так, им достаточно выравнивания на границу слова); если выравнивания нет, то компилятор использует пары команд LDR и STR.
В принципе, можно править ручками в редакторе PDFок, но это такой геморрой... В общем, почти всегда проще выдать схему на "печать" в pdf -- хотя там иногда другие проблемы возникают.
Это помогает лишь ограниченно: если используется правильный шрифт и если этот шрифт установлен на компе, где пдф просматривается. Десигнер не умеет внедрять шрифты в генерируемый пдф и не умеет корректно генерировать сами пдф (в частности, правильно пользоваться юникодом), откуда и все проблемы.
Компилятор нормально запускается и из командной строки (собственно, из неё он и запускается, просто среда это благополучно маскирует). Вопрос, правда, в том, будет ли он работать без лицензии.
