Мне сейчас очень лень самому открывать Reference Manual, так что уточните сами. :)

да, и вправду щас попорбовал отключить прерывания при TX только по приему потому что пререрывания по приему сбрасывают все флаги, а вот в отправке чет не так

А зачем тебе прервание по TX, для этого случая 😳

Ну может человек потренироваться решил.

Ибо из этого кода следует что ты решил в прервания дождаться отправки байта по уарт.

Странное решение, так никто не делает, но в плане образования - почему нет.

Поел говна, теперь знаешь что так не стоит делать. Ну или не включать прервания

По хорошему, если у тебя включены прервания на TС  - выкидывать нужно цикл и вместо него return.

А в обработку TC - запрет прерывания

А что, компилятор может затереть USART1->DR = USART1->DR? Зачем буфер, чтоб просто прочитать?

Ну кстати вот же

Ну, буфер не повредит. Если компилятор решит, что он не нужен, то оптимизатор уберет лишнюю переменную.

А так оно легче читается, да и расширять потом в случае чего проще.

Я тоже всегда читаю значение из DR в промежуточную переменную. Просто ради лучшей читаемости.

Т.к. это действие помимо всего прочего предполагает очистку флага, для большей очевидности разумно вынести это присвоение в отдельную строку.

Понятно. Для меня любой регистр в качестве RHS означает чтение автоматом... Ну и в качестве LHS - запись. Вот адреса там уже было бы читать тяжело, но это совсем наркомания была бы )

Ну да, за исключением всяких операций, которые сравнение и проч., но это я пока за скобками оставлю D:

Опять же, портирование. Если вдруг этот кусок кода захочется перенести на другой контроллер, где очистка флага требует другой последовательности действий, или регистр называется по другому, достаточно будет заменить только одну-две строки в начале и не лезть в логику.

Пример реальный. У меня есть проект, в котором в прерывании UART'а прямо на лету идет парсинг ответов на AT-команды. И вот там я как раз читаю в промежуточную переменную, и дальше по-всякому ее сравниваю, пишу в массивы и т.п. За счет промежуточной переменной логика оказывается полностью отделена от чтения из аппаратных регистров. Да, лучше было бы вообще вынести всю логику парсинга в отдельную функцию, и, может быть, я со временем так и сделаю, но пока просто отдельная переменная.

Точнее сказать, там у меня не столько парсинг, сколько предварительная сортировка. Скажем, код в прерывании отлавливает URC и ставит соответствующие им флаги. Но тем не менее.

Господа, а не подскажите, есть ли какой-то стандартизированный формат нетлиста, который можно импортировать в разные кады для рисования из него схемы? Появилось нездоровое желание написать генератор некоторых цепей.

Третий путь грузить процессором при включении по последовательному каналу.

Можно попробовать SPICE. Правда насчёт поддержки прямо везде не скажу.