а у производителей смартфонов (плееров, накопителей, точек доступа и проч. и проч.) есть сертификат ПО? :-)
Когда они выкладывают новую прошивку с исправлениями - кто отвечает и чем? :-)

А что, все из вышеперечисленного может нанести вред здоровью или приведет к катастрофе?? Это банальная бытовуха, на неисправности которой всем пофиг, кроме интернетных зомби, при отключении которых от сети возможен суицид

ну значит моим устройствам везет. :-)
Они не способны нанести вред здоровью.
Максимум - не выключится топливный насос и водителя на АЗС обольет. :-)

Бензином?

ага. :-)
Но там и без электроники таких чудиков! Свет не видывал.
Одна только зажигалка для проверки уровня бензина в баке. :-)

Ну а серьезно, то я тут тусуюсь с 1996 года.
Никогда не слышал ни про какие сертификаты ПО.
Ни у встроенных МК, ни у комп. программ.
У нас тут просто, лоханешься - просто не будут покупать.
Я так в свое время (еще в 90-е) на несколько лет потерял Томскую область.
Пока совсем новое изделие не протолкнули.

Что из всего перечисленного "смартфонов (плееров, накопителей, точек доступа и проч. и проч." управляет подачей бензина или топливным насосом?? Если да, то я бы от греха подальше, застраховал бы заправочку

Лабораторию пропустившую глюки в системе лишают лицензии. А это закрытие фирмы и все такое. Нашу местную лабораторию уже лишили лицензии.
Вот например завтра мою плату будет проверять человек из этой организации - http://www.liftinstituut.com/
Он четко сказал, если цепь безопасности разрывается программно, то надо сертифицировать программу.
Я это аудит программной архитектуры, сорсов, библиотек, тулсов и проч.
Программа также должна поддерживать интерфейс к их тестирующему оборудованию, которое будет задавать тестовые сценарии.
Само тестирование проводится на сдублированной компьютерной системе.
Короче все жестко и бескомпромисно. Кто с этим не сталкивался пускай радуется как ему повезло.

Разрабатываю средства измерений, в том числе взрывозащищенные. Сертифицируется и взрывозащита и метрология и встроенное ПО и автономное (внешнее)

Как оборудование, электронику на взрывозащиту испытывают я видел, а как ПО испытывают?

как говорил уже, я с 1996 года общаюсь с АЗС.
Не слышал ни про один случай не просто кому-то вреда, а даже просто аварии по причине чьей-то ошибки в ПО.
Там куда как больше реальных причин.

По причине ошибок в ПО происходит:
- потеря денег оператором или хозяином (бензин ушел больше оплаченного);
- потеря денег клиентом (деньги уплачены, бензина меньше);
- что-то зависло и АЗС просто не работает, потеря дневной выручки;
- ... ну еще что-то такое, что опять же приводит к простою и потере выручки.

И опять же, не представляю такую сертификацию, что выявила бы такие ошибки.

Хотите сказать, что на АЗС стоят несертифицированные колонки?

По взрывозащищенности? Всё строго.
По точности отпуска? Всё проверено и опломбировано.
По электробезопасности? Всё измерено и заземлено. Хотя... я такие чудеса встречал иногда в монтаже! Волосы дыбом вставали.
Ах про сертификацию ПО? Вот этого никогда не слышал. Есть просто общий сертификат.

Это если кому-то интересно. На робота, которого я разработал, поставили стрелялку. По этой причине с ним проводили BLACK BOX testing. Исходников не спрашивали, что с ним делали не могу знать, но по результатам испытаний претензии пред'явили к системам коммуникации и battery management. Через месяц, после повторных испытаний продукт был закуплен.

Хм... Что значит общий сертификат?
Ссылку на номер в Госреестр СИ, ПЛЗ !


ссылки на ваши средства измерений в Госреестр СИ, в студию!

Откуда ж мне знать?
Я сам колонки не поставляю. Мне заказывают электронику, я ее разрабатываю.
Электронные блоки вставляют в колонки.
Знаю, что у людей такое слов "сертификат" - есть.

К примеру.
Есть такой ведущий производитель в России оборудования для АЗС. Для нас это - конкурент. :-)
Серьезный процент всего рынка в России.
У него на сайте есть даже раздел - "Документы".
Ничего про сертификат ПО нет.
Точнее есть, но только ПО на компьютере. Того, что управляет колонками.
Но мы же говорим про ПО для встроенных МК?

http://topazelectro.ru/document/


По самим колонкам у людей есть только

http://topazelectro.ru/files/ie/51_54_FILE_ou.jpg

и
http://topazelectro.ru/files/ie/51_21_FILE_svidobutv.jpg

согласно ГОСТ Р 8.654-2015 и Р 50.2.077-2014



например, 66314-16

Там ничего необычного нет, простые вещи которые соблюдают нормальные программисты. Вы еще про стандарты оформления ПО вспомните.

Видимо, вы не совсем в теме, бывает. Рекомендую еще взглянуть на ГОСТ Р МЭК 61508-6-2012, но он к метрологии не имеет отношения.

При чем тут метрология, идет разговор о надежности применения CubeMX и HAL в своих изделиях и методов испытания надежности ПО.

про надежность смотрите ГОСТ Р МЭК 61508 и гост р мэк 61511. У импортных он упоминается как SIL

Тоже метрологией занимаюсь. Спорить не буду, но считаю, что гарантом качества и безопасности может выступать только производитель. А всё остальное от лукавого. Все эти сертификаты - лишь бумажки. И лучше разработчика никто не оттестирует изделие. Понятно, что вылизывание - это самая длительная и, соответственно, самая дорогостоящая операция. Любой производитель всегда будет пытаться её минимизировать. Иначе возрастает, цена, неоправданно растут сроки и т.д. Любой производитель может сделать продукт лучше и надёжнее. Вот только вопрос - нужен ли он рынку.
По теме вопроса - личное мнение я уже озвучивал.
Считаю, что тема не особенно актуальна. Если рассматривать чисто обработку железа - то бишь драйвера - то это несколько процентов от общего объёма проекта. Если рассматривать всякие там GUI, OS и прочие входящие компоненты, то надо понимать, что это совершенно независимые разработки. Применение каждой из них должно рассматриваться в отрыве.
Как правило драйвера, в том виде, в котором они написаны - просто не нужны. Я бы сказал бессмысленны и явно избыточны.
Например, мне трудно представить проект, где органично бы вписался драйвер USART от ST. Возможно у меня фантазия слабая.
Что ещё нехорошо, это то, что все библиотеки завязаны друг на друга. В результате, при использовании одного устройства благополучно подключается несколько других. Таким образом весьма проблематично использовать микс из своих и чужих дров и т.п.

Есть проблемы и со своими.
Я не заморачивась. Как правило пишу всётаки драйвера под конкретную задачу/ проект. А универсальность чуть повыше обеспечиваю. Правильно тут отмечали - часы должны идти независимо от того, откуда ты получаешь данные. Это же касается и всего прочего. Например, при изменении типа флэши, не должно быть существенного изменения проекта. Добавление нового протокола, не должно менять логику работы устройства и так далее..

Похоже для STM и ATMEL библиотечный код пишет один и тот же индус. При принятии данных заставить прочитать регистр статуса перед регистром данных - ни в какую не хочет. На STM UARTe такой ленивый подход просто аппаратно блокирует прием данных вообще, если закрался FE при приеме.
Для I2C по атмелу весь код - сплошные прерывания, зачем ? Эти функции например нельзя использовать в контексте другого прерывания ! Система API таймеров для ATMEL оперирует 4 байтными значениями задержек в микросекундах, при использовании подсчета не атомарных величин - запрещают прерывания, длительность расчета превышает десятки микросекунд, при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта, а так как у atmel нет FIFO - данные просто теряются. При задержке в калбек функции по премени вычисления больше чем запрограммировано время следующего калбека - вылет и неопределенное значение внутреннего программного состояния Timer API - ну и т.д.
И это что считается нормальным поиск багов ? Такие API не годятся вообще никуда, они только показательны и только когда работают одни в системе, или таймера или UART или I2C. А вот в связке функционирования - полная Ж... . Вообще халява она для особенных людей, когда ее кто-то ищет - это очень яркий ярлык отсутствия шишек.

Мое впечатление от HAL в этой цитате.

Стандартные решения средствами HAL вполне интересны, но не стандартные варианты увы не подъемны. SPL может помочь для отважных фантазеров. Когда HAL будет способен на ЛЮБУЮ импровизацию, тогда свершится ожидаемый скачок.

Пример. SDIO заточен на обмен с SD. Это значит, что в перечне команд заложены стандартные наборы с соответствующими ответами. Архитектура(CRC7, CRC16, стартовые\завершающие коды, файловая система и т.п.) присутствует явно в HAL. .....Жизнь диктует свои законы и стык SDIO можно использовать для многих применений(подразумевается гибкость ПЛИС).
В этом случае произвольным образом менять коды команд, а также необходимость ответа на них при помощи HAL проблематично.
И вся эта красота моментально рушится.

Кроме банальных и грубых ошибок в API поддержек микроконтроллеров, существует еще и простые политики - зарабатывание денег.


API периферии, а ТАКЖЕ ПЕРИФЕРИЙНЫЕ УЗЛЫ между производителями - ранее, ныне и всегда будут уникальными, это способ затормозить юзеров на переход или смену "периферийного железа" на другого производителя, это по крайней мере должны понимать не наивные люди. И как вследствие этого НИКОГДА НЕ БУДЕТ безболезненного перехода. Время чтения документации + поиск багов + нереальные трудности по изменению "специально написанного" кода - делают своё дело, причём это делается скорее всего целенаправленно, чем случайно.

Сколько продержалась STM_SPL уступив STM_HAL, кому мешала быстро переносимая API архитектура ?

А в каком конкретно месте этот баг? Глянул на вскидку хал для stm32l0 функцию HAL_UART_Receive(), сначало читается ISR, потом RDR.

довод ни о чем. все ваши высказывания в двух словах - "хал грамоздкий". А то что там по времени что-то у вас не пролезло, хал тут не причем. Он грамоздкий - со всеми вытекающими, этим всё сказано. Запустите хал на 150 МГц и пролезут ваши 115200. С другой стороны.... вы свой код соптимизируте на 48МГц, ваши 115200 с запасом будут работать.... в другом проекте нужно будет проц на 1 МГц запустить.... и те же грабли, что вы описали.

дма нет?

В части где нелинейно укрюченый код отловил FE или NOISE Interrupt - ТАМ. Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал.



Это не XMEGA и не STM, не MSP и не LPC. Это класика AVR .



Интересно, а к чему тогда мануалы: ну например что такое 240 mka / 1 Mhz. Сейчас полно автономных устройств на своем питании, где время выполнения кода играет первостепенную роль.
Дык, волшебство превращения контроллера в кирпичеподобную субстанцию за день работы - вот, это точно не выход.
Надо вообще разбить ветку форума на две, в одной высказывания программистов "которым еще кажется" в другой "которые уже открестились"

В этом случае без SPL не обойтись.... Какие рекомендации от корифеев?

А был ли мальчик? Так и не нашел я ни какого бага, о котором вы говорите. Из гита качнул самую первую версию
При приеме вычитывается статусный регистр в течении таймаута, если пришел RXNE, то читаем RDR. По другому - даже кривыми руками не написать. Вы говорите
Но с самой первой версии хала вычитывается статусный регистр. Толи вы не заметили эту вычитку, толи какая-то другая ошибка в хале? Может нет анализа флага FE, может этот баг в функции приема по ДМА?
Почему я за это зацепился? Я использую хал, и не хочу наступить на эту граблю если она есть. Вы можете показать эту граблю? Если не можете, то с вашими выводами всё понятно.

Уже 15 страниц толкуют, что HAL===SPL (только с бóльшими извращениями), и опять начинай сначала…
Только внимательное чтение даташита поможет правильно реализовать требуемый алгоритм. И никакие SPL/HAL/opencm3/что-то-еще не помогут.
Невозможно обойтись без опыта разработки, неизбежно дающего в качестве побочного продукта пополнение личного багажа сниппетов. Если ты один раз написал сниппет для работы с SD-картой и, скажем, файловой системой ext2, то и дальше это будешь использовать. Если не написал, то ничто не поможет.

Вы не поняли... Когда от SDIO не требуется обмен с SD, а требуется клон, который резко отличается от SD-спецификации,-HAL- беспомощен, потому как в нем прописан промышленный стандарт. Выход Только в прямом управлении регистрами!..
HAL хорош для стандартных решений. ЛЕГО!!!

Какого еще таймаута ? Вы что рассказывали мне все время не за работу HAL в прерываниях, а какую-то софт реализацию "hello world" на uarte ?

Конкретно я писал код на stm32f207 еще в 2009. Такой корявой обработки с флагами и нелинейного кода как там я даже в интернет хламе примеров не обнаруживал никогда. Вместо того чтобы просто когда пришел байт данных прочитать регистр USART_SR (не ISR !!!), а потом прочитать USART_DR, просто без каких либо условий и ветвлений - сделать два простых действия.
1. Там сразу по условиям внутренних своих флагов программа упетляла куда-то и не сбросивши прерывание по NOISE - вышло из обработчика.
2. Причём я ни NOISE ни FRAME реакции не заказывал для обработки в прерываниях.
3. Кроме того что оно их установило - оно их еще и не отработало.
4. Если бы там просто сделано было два шага по чтению регистров - БЕЗУСЛОВНО как положено для нормальной работы периферии - то я бы не возмущался и не предостерегал - что писал это человек далекого континента.

5. Один из крупный недостатков - это откат прогресса системы прерываний который появился в Кортексах - откачен корявостью и ленностью архитектуры - до уровня обработки прерываний ядра 7TDMI. Там индусы понасоздавали куча программных флагов вместо того чтобы использовать отдельные прерывания для каждой периферии - у них один общий обработчик для 6 уартов например, который потом разруливает програмно что кому надо.
6. Использование HAL - это необходимость использования вложенных прерываний, так как обработка очень медленная. Писать килобайты в контексте прерываний - это еще один ярлык.



Мне не обсолютно пофиг, если есть траблы - я сказал в чём, разжевывать разжеванное я не буду.

Тогда точно не понял: при чем здесь SPL? SPL — та же жестко зажатая в рамках "помигать диодиком при помощи таймера с DMA". А чуть захочешь что-то пошире сделать, как упираешься в ее тормознутость.
Вообще непонятно, зачем функционал для работы с железом выносили в отдельные функции вместо макросов или true inline. Ну и все эти ассерты и еще толпа ненужностей, в результате чего ничего по-человечески таким образом не сделать.

На счет тормознутости вы загнули...
Уж HAL в этом сравнении не превзойден! Вершина тормознутости.... и прожорливости.
У вас превратное представление о SPL. В палитре разработчика любой регистр и любой бит.... В любой момент.

в stm32l051 статус регистра уарта это USART_ISR (Interrupt and status register), для stm32f207 USART_SR, суть дела от этого не меняется.
смотрим прием уарта в хале на stm32f207

HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
uint16_t* tmp;
uint32_t tmp1 = 0;

tmp1 = huart->State;
if((tmp1 == HAL_UART_STATE_READY) || (tmp1 == HAL_UART_STATE_BUSY_TX))
{
if((pData == NULL ) || (Size == 0))
{
return HAL_ERROR;
}

/* Process Locked */
__HAL_LOCK(huart);

huart->ErrorCode = HAL_UART_ERROR_NONE;
/* Check if a non-blocking transmit process is ongoing or not */
if(huart->State == HAL_UART_STATE_BUSY_TX)
{
huart->State = HAL_UART_STATE_BUSY_TX_RX;
}
else
{
huart->State = HAL_UART_STATE_BUSY_RX;
}

huart->RxXferSize = Size;
huart->RxXferCount = Size;

/* Check the remain data to be received */
while(huart->RxXferCount > 0)
{
huart->RxXferCount--;
if(huart->Init.WordLength == UART_WORDLENGTH_9B)
{
if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
{
return HAL_TIMEOUT;
}
tmp = (uint16_t*) pData ;
if(huart->Init.Parity == UART_PARITY_NONE)
{
*tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
pData +=2;
}
else
{
*tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF);
pData +=1;
}

}
else
{
if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
{
return HAL_TIMEOUT;
}
if(huart->Init.Parity == UART_PARITY_NONE)
{
*pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
}
else
{
*pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
}

}
}

/* Check if a non-blocking transmit process is ongoing or not */
if(huart->State == HAL_UART_STATE_BUSY_TX_RX)
{
huart->State = HAL_UART_STATE_BUSY_TX;
}
else
{
huart->State = HAL_UART_STATE_READY;
}
/* Process Unlocked */
__HAL_UNLOCK(huart);

return HAL_OK;
}
else
{
return HAL_BUSY;
}
}

в аргументах таймаут. Красным вычитка статусного регистра (USART_SR/ISR) в течении таймаута, ждем флаг RXNE, если пришел, то вычитываем DR. Как вы и хотели.

вы наверно не про хал говорите, его тогда не было.


ps в приеме по прерываниям в прерывании первой строчкой вычитка статус регистра.

Я начинал с этой дряни. Потом перешел на opencm3 — небо и земля!!! А после того, как меня достало то, что разработчики opencm3 периодически меняют API, да и документация там никакая — постоянно приходится в коде библиотеки ковыряться, я всю эту гадость решил больше не использовать, только "голый" CMSIS и сниппеты.

Сказал же - что в прерывании и не раз ! Тут же чистый SOFTWARE "Hello India !".

ПРОБЛЕМЫ с HALL были у меня В ОБРАБОТЧИКЕ ПРЕРЫВАНИЙ а не в бредовом с архитектурной точки зрения софтваре коде. Не думал что програмисты вообще такое используют - это же детский сад.
Мда, когда-то лет так 25 назад я мог еще "додуматься" встраивать Delay-ки в программу или код с непрогнозируемыми или динамическими задержками . А ну да - RTOS нам поможет - создаст за нас архитектуру что не надо будет вставлять __HAL_LOCK(huart); , он ВСЁ может . Это бредовый код, НЕ АРХИТЕКТУРНЫЙ. Ожидать прием данных с тормозами - это ЖЕСТЬ.

Все делается по прерываниям и желательно с DMA настроенным, если конечно не лампочками моргать. А по поводу СРАНИ в реализации прерываний - это правда, виснет из-за неправильной реализации обработки.

Уклонились от темы...

Тут мне нечего возразить... В моем опыте переписывание HAL в стиле SPL... Ваш опыт заслуживает уважения..

в прерывании в хале первой строчкой вычитка статус регистра. Тоже уже говорил. Да черт с ним.... с этой граблей... хал с 2014, вы в 2009 году что-то там у кого-то непонятное нашли....

Так когда один поток, почему бы нет? Я пользую в простых проектах. Всякие read()/write() во всяких POSIX/winApi работают как в блокирующем так и не в блокирующем режиме. В хале (на 2018 год, а не в неких либах от 2009 года) есть и блокирующий режим, и IT, и DMA, я просто привел пример первой попавшейся функции приема из хала. А так-то их, этих функций и режимов приема вагон и тележка


Даже с колбаками есть.

С 2009 на SPL писал. На грабли хала напоролся где-то 2011-2012, не помню.

Сходу выбрал что мне больше подходит малыми кровями вот этот режим работы:

Когда отлавливался тот глюк о котором я говорил. Никакой callBack по Error HAL_UART_ErrorCallback() - не вызывался вообще. Всё висло намертво, путём выхода из прерывания по uart и моментального туда захода, так как эфиопы не смогли его сбросить. Дебагер работал, отловил что не отработали сначала FE а потом NOISE попадалось в таком состоянии висячем.
Позже напарник отловил (через пару месяцев) с I2C траблы. В общем больше на нём не пишем.
Когда я фиксил код по UARTу то выкинул более 90 процентов того хлама который там был, ну еще и опасения были по неправильной кастрации кала, так как он со своими статусами постоянно манипулирует. , но обошлось . Такие дни никому не желаю , особенно когда что-то по срокам сдачи. Делали тогда устройства для диагностики автомобильной "периферии", по линии K-LINE. Там протокол основан на синхронизации пакета по фреймэрору, далее всё как обычно. На SPL без проблем можно было быстренько на лету перепрограмировать режими UARTA, хоть после каждого байта. А из-за тормознутости HALA пришлось использовать аппаратный режим детектировани K-LINE старта, хорошо что там он был на STMке. Не во всех уартах есть примочки, НО ВСЕМИ уартами можно прекрасно работать и без них, если не использовать "мегабайты" в прерывании .

По приему K-LINE пробуждения, надо было замерить интервалы старта, паузы и вымерять длительность бита на линии который присутствовал в синхробайте 0x55, чтобы не потерять ни одного байта в посылке, запрограмировать нужную скорость и включить аппаратно прием в конце синхробайта - на его стоповом бите. И всё это прекрасно работало на SPL, кое-что конечно переделал на CMSIS. На хале - нет, такое не сделаешь.

Это всё ваша программа.... что там не получилось c халом... хал грамоздкий какой-то библиотекой..... Позже напарник отловил какие-то с I2C траблы....

Меня интересует имя файла и номер строчки в хале, где есть бага.


Ну это всего лишь колбаки. А приём, судя по вашим постам, вы вели в этом режиме работы


странно всё это....


Вот их обработчик. При приеме по прерываниям вы вызоваете HAL_UART_Receive_IT(), в ней разрешается прерывание обработка FE
Флаг FE не генерирует прерывание. Генерирует RXNE. В обработчике по приему проверяется FE и сбрасывается. Если был FE, то вызывается HAL_UART_ErrorCallback(huart).

Постоянно попадать в обработчик по несброшенному FE вы не могли, т.к. FE не генерирует прерывание. Может чего-то недонастроили/недопоняли с халом и была такая какая-то грабля? Я бы пошагал дебагером и выяснил бы.... или в хале есть баг конкретный, или же я где-то ошибся.


ps думаю, что далее бессмысленно ворошить.... у вас что-то не получилось на хале, какие-то прерывания от FE..... Вы сочли, что это ошибка в хале и он вам не понравился.

Вы что на STM работаете, склалось такое впечатление .

ГДЕ В ФУНКЦИИ void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) -- Выполняется ЖЕЛЕЗНОЕ ПРАВИЛО СБРОСА БЛОКИРОВКИ UARTА в случае ошибки ????????????????????? 0-0 . Хдееееее ?! Код похожий очень на тот что я правил, только меньше раз в 10. НО ошибки похоже те же. Тыкать не буду - тут просто банальная практика выявляет очень быстро эти огрехи. Здесь нет строки где есть ошибка - ТУТ строк НЕТ и Правильной последовательности сброса. Должен быть линейный код который без ВЕТВЛЕНИЙ делающий две базовые вещи о которых говорит мануал по UARTу.
Просто понять что чтение регистра флагов не сбрасывает некоторые ошибки - понять нельзя - нужно ЧИТАТЬ .
Я устал спорить на эту тему, если Вы считаете что там нету ошибок приводящих к фатальным зависаниям системы - ваше право ! Они там есть, потому что код хала ДЕТСКИЙ и технически неграмотный.

Просто сделайте генератор помех на линию UART - и результат не заставит себя ждать.

К каком месте хала и/или даташита говориться, что уарт блокируется при возникновении ошибки? Почему нужно сбрасывать БЛОКИРОВКУ уарта и что такое БЛОКИРОВКА УАРТА?

Есть флаг FE, он говорит что был Frame error. Если вы вошли в перывание по приему (а не по FE), то в HAL_UART_IRQHandler(UART_HandleTypeDef *huart) будет ЖЕЛЕЗНЫЙ сброс флага FE. Не будет ни каких сбросов БЛОКИРОВКИ УАРТА.
Где??? Я уже приводил где, вот ещё раз приведу

tmp1 = __HAL_UART_GET_FLAG(huart, UART_FLAG_FE); //чтение статусного регистра USART_SR, не сброс, просто чтение
tmp2 = __HAL_UART_GET_IT_SOURCE(huart, UART_IT_ERR);
/* UART frame error interrupt occurred -------------------------------------*/
if((tmp1 != RESET) && (tmp2 != RESET))
{
__HAL_UART_CLEAR_FEFLAG(huart);//Сброс FE флага

huart->ErrorCode |= HAL_UART_ERROR_FE;
}

я так не считаю. я их не вижу. я не хочу в них попасть, я не хочу поппасть в эти ошибки со своим кодом (без хал и спл). Вы говорите что там не правильно , не по даташиту. я читаю даташит и вижу что всё сделанно правильно не вижу ошибок. Я бы написал в тойже последовательности, не так грамоздко и всеобъемлюще, но принцип тот же.

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


Вместо постоянных переобуваний, переформулировок и каких-то мифических катастрофах в халехпустых разговоров про траблы колег в I2C, вам достаточно сделать ОДИН копипаст из даташита, с двумя базовыми вещами, которые вам говорит даташит и копипаст баги в хале и можно без хала сказать "В хале вот именно этих базовых вещей НЕТ". Какие именно базовые вещи в даташите по УАРТу отсутствуют в хале?
Пока всё, что вы требуете от хала - оно там есть.. Все сбросы, все последовательности, все вычитки регистров и заходы в HAL_UART_ErrorCallback().

STM32F207



Это по поводу источников прерываний. Они есть - просто в API кала их нет, но он их включает, ну и путается с правильностью аппаратных сбросов.


При обработке EIE - который был без разрешения включен, произошла "петляющая ошибка". Чтение регистра статуса БЫЛО, а другого важного действия ВТОРОГО ШАГА - не было. Вот и всё собственно.
The FE bit is reset by a USART_SR register read operation followed by a USART_DR
register read operation.
EIE: Error interrupt enable - при разрешенном прерывании оно срабатывает от 3 источников FE, NOISE, ORE.
Сброс каждой причины хоть индивидуален - но одинаков - просто очень тупо был пропущен. Шо для технарей читающих мануалы просто - не приемлемо.

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

Не следил за вашим спором, ибо в разных семействах STM32 УАРТы реализованы слегка по-разному, и тот HAL, что я применял, проблем не имел.

Но вот по последней фразе скажу - все люди разные, и не нужно так категорично говорить за всех.
Для меня, например, "искать корявости или выкорчёвывать ненужные действия - занимает раз в 5 МЕНЬШЕ времени чем написание правильного кода с нуля"

Как говориться, "ломать - не строить". Если, конечно понимаешь, что ломать и как нужно строить...

ну наконец-то предметный разговор, а не спор.
срезюмирую даташит

(In case of multibuffer communication) == (USART_CR3.DMAR is set), т.е. FE даст прерывание только при приеме по DME.

есть картинка, в которой прерывание через И объединено с флагами (FE && EIE && DMAR)....

Всётаки я с первого поста нашего спора диалог я спрашивал и ещё раз спрашиваю, как вы вели прием при такой баге?
HAL_UART_Receive()
HAL_UART_Receive_IT()
HAL_UART_Receive_DMA()?

в HAL_UART_Receive_IT() разрешается обработка флага FE в прерывании, но не разрешается прерывание по FE, ибо DMAR не выставляется. Почему при приеме по прерываниям (по Receive_IT() ) у вас выставлен DMAR в "1"?
в HAL_UART_Receive_DMA() устанавливается DMAR, но ... тут да, может быть косяк, судя по коду хала... в HAL_UART_Receive_DMA() выставляется DMAR, но не выставляется обработка ошибок по FE, но нужно ещё проверить есть ли флаг EIE. Я с UARTом по дме не работал, ни чего не скажу. В очередном проекте, если подниму UART по DME, обращу на это внимание.

согласен. Особенно если писать код по приему через ДМА.

ps а как это так EIE без разрешения включился? Тут вообще весь код хала с усартом не причем, если EIE без разрешения включается.

Работал с HAL_UART_Receive_IT(). Хал включил не спрося обработку по EIE (так ему захотелось) и упетлял кудато, не выполнив банальную очистку (два простых безусловных действия, без петляния)- вышел из интерупта - на этом всё и закончилось ;(. В общем эта проблема + куча кода по проверке своих статусов- видимо для RTOS-ов, много кода в контексте прерывания. В общем не чувствовалась рука профи.

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

Потом подзабыл ту проблемку с уартом, лет через 5 взял попробовать ETHERNET на STM32F429, на своём боарде. Создал проэкт на кубе со всеми настройками, после в Кейле поменял на свой код инициализацию внешнего PHY-RMII (под KSZ8041 вроде, там другие биты были в автоопределении 10/100), думал всё. По дефайнам настроил количество буферов и режимы. Ну и начались траблы то иногда пакеты тупо дублировались при передачи то приёма не было (по дефайнам установил 1 буфер на приём и 1 на передачу - в этом и была проблема, код кала оптимизирован на минимум двойную буферизацию - коряво, на 4 буфера - лучше двойной, но не идеал). У меня проэкт не позволял транжировать память 4-мя буферами на приём и на передачу... собственно когда эта периферия используется опционально по необходимости.
(реализовывал код под ARP, IP/UDP - код старый обкатаный еще на RTL8019, LPC1768, STM32F207). Провозился дня два - под вечер снёс этот кал; за два часа поставил пример сервера на lwIp (или как он там называется) - для того чтобы выудить две базовые функции на RX и TX, выудил, сервер снёс так-же. Пересоздал новый проэкт на базе SPL и по екзамплах юзания езернета с lwIp - за 3-5 часа и всё работало как надо.

У товарищей которые создают кал - проблемы с чем-то, причём непонятно на каком уровне, но они есть. А оттягивать время разработки на игры в бирюльки - это очень дорогое удовольствие.

У меня в нескольких проектах постоянно используется HAL_UART_Receive_IT().
И что я делаю не так?
Хотя да, принимаю по одному байту. Ублюдочно у меня малость, посылки на приеме произвольного размера.

Все правильно делаешь. Читай только постов 20 перед последним, будешь в теме.

Судя по тому что вы написали, проблема у вас в уровне именно вашей квалификации, а не тех, кто пишет HAL...

Если подитожить, многие здесь на форуме используют HAL, многие в МИРе используют HAL, обсуждений в интернете море. Но есть какой-то процент несостоявшихся гениев, у которых HAL не работает ВООБЩЕ, и поэтому они все пишут сами. Пишут они исключительно самый лучший, безглючный, эффективный и красивый код. Я уверен, это только их проблема, индивидуальная.

Все гораздо проще: есть потребители легкого поведения (они используют кал, абдурину, мастдайку и т.п.), есть просто потребители (используют С и сами что-то ваяют) и есть гении (уж что они делают, я не ведаю).